Linbo PXE friert nach linbofs64.lz ein

Hallo zusammen,

folgendes Problem habe ich mit Linbo mit unseren neuen HP250G7-Notebooks, die von der Tastatur abgesehen ganz OK sind: Der PXE-Boot friert nach dem Download von /linbofs64.lz ein. Es ist kein Wechsel in Konsolen möglich, Neustart auch nicht und Ausmachen geht nur per 8-Sekunden-An/Aus-Knopf drücken.

Server: LM 6.2
/etc/apt/sources.list.d: deb http://archive.linuxmuster.net/ babo/ (und deb-src identisch)
apt-get update, upgrade und dist-upgrade zeigen neuesten Stand an
Pakete linuxmuster-linbo und linuxmuster-linbo-common in Version 2.3.26-0
Linbo-Kernel laut Linbo-Konsole auf älterem PC: 4.9.27
Ein Update auf LM 7 ist am Anfang der Planung, weiter aber noch nicht.
Beginn des PXE-Boots im Textmodus u.a.: „NBP filename is boot/grub/x86_64-efi/core.efi“
Dann grafisch: LINBO for group GRUPPE
Loading /linbo64 … 100%
Loading /linbofs64.lz … 100% dann ist Ende!

Das HP250G7 kann nur noch EFI, sprich ein Legacy-Modus mit MBR wird leider nicht unterstützt. (Wir nutzen nur Linux, da wäre MBR auch noch möglich.) Es ist eine i915-Grafikeinheit verbaut (UHD Graphics 620).

Nach der Lektüre dieser (Linbo startet PCs einer HW-Klasse nach Linbo update nicht mehr , https://docs.linuxmuster.net/de/basiskurs/release-information/linbo.html) und einiger weiterer Seiten habe zahlreiche KernelOptions ausprobiert (i915.modeset=0, i915.modeset=0, i915.alpha_support=1, acpi=noirq irqpoll) und auch quiet und splash deaktiviert in der Hoffnung, hilfreiche Informationen zu Gesicht zu bekommen. „linbo-remote -i MEINPC -p format,halt“ habe ich ausgeführt.
Nach den Änderungen in der Datei /var/linbo/start.conf.GRUPPE habe ich auch import_workstations gemacht, wenngleich ich der Meinung bin, dass dies, sobald der Symlink von start.conf-IP auf start.conf.GRUPPE existiert, nicht mehr nötig wäre.

Natürlich kann ich nicht ausschließen, irgendeinen Fehler gemacht zu haben, aber nach allem, was ich über den i915 im Zusammenhang mit Linux gelesen habe, fürchte ich, dass der Linbo-Kernel zu alt für das Notebook ist. Alte Linux-RettungsCDs bleiben auch hängen, Kubuntu 20.04.1 ließ sich hingegen einwandfrei installieren und mit den alsa-firmware-loaders funktionieren auch Ton und HDMI einwandfrei.

=> Habt ihr eine Idee, was ich noch versuchen könnte? Und im ersten Link oben schreibt Chris, das Problem sei nach dem Update auf Linbo 2.3.51-0 aufgetreten, aber unser Server hält sich mit 2.3.26-0 für aktuell. Auf github gibt es schon Linbo 2.3.66 mit Kernel 4.14.192, allerdings muss man das dann selber bauen. Gibt es da vielleicht ein Repository, aus dem ich das neueste Linbo auf dem Server installieren könnte, ohne sonstige Probleme zu bekommen?

Ich hoffe wirklich auf gute Tipps, sonst heißt es 40 Notebooks per USB-Stick installieren (und aktuell halten).

Vielen Dank im Voraus!

Henning

EDIT: Aufgrund eines Tippfehlers ( :frowning: ) ging das Repo balo62 nicht => mir werden nun Updates angeboten, obendrein sind Linbo-Kernel und -initrd von Platte startfähig. Vor den Updates mache ich aber Backup, entsprechend probiere ich jetzt wieder etwas herum.

Hallo zusammen,

für mich wird es jetzt unverständlich, aber hoffentlich kann mir hier geholfen werden (google half nicht).
Zwischenzeitlich habe ich einen Snapshot gemacht und alle Updates aus balo62 installiert, das Problem in folgender Form tritt aber mit Linbo 2.3.53 und dem zuvor installierten 2.3.26 identisch auf:
Auf besagtem HP250G7 bleibt Linbo beim PXE-Boot weiterhin nach „Loading /linbofs64.lz … 100%“ hängen, startet aber von Festplatte. Hält man jedoch den „tftpd-hpa“ Server an, startet Linbo auch über PXE - also genau umgekehrt zum erwarteten Verhalten, bei dem Linbo bei fehlendem TFTP Probleme haben sollte.
Die älteren Rechner starten aber korrekt mit PXE und laufendem TFPT, sind allerdings als BIOS-Boot mit MBR definiert.
(„atftpd“ ist nicht installiert, es sollte diesbezüglich keine Überschneidung geben.)

Desweiteren ist der Bildschirm, auf dem „Loading /linbofs64.lz … 100%“ angezeigt wird, in einer groben Auflösung, wenn TFPT läuft, und in FullHD, wenn TFPT gestoppt ist.

=> Hilft euch das weiter? Für mich klingt das schwer nach einer falschen Konfiguration, aber ich habe ubuntu-efi als Vorlage benutzt. start.conf.GRUPPE und boot/grub/GRUPPE.cfg sind vorhanden.

Vielen Dank!

Henning

Hallo Henning,

ich habe diese Anmerkung von Chris gefunden:
"mit dem Kernelparameter i915.alpha_support=1 funktionieren meine
Fujitsu 775 PCs nun "
und zwar hier:

oder hier:

Die Option stand bei deinen „probierten“ nicht dabei: vielleicht hilft
es… (Daumendrück!).

Noch zu deiner Aussage wegen der Notwendigkeit des imports:
ja, er ist nötig, denn wenn du Kernelparameter in die start.conf rein
schreibst, dann kommen die nur dann bei linbo auch an, wenn du einen
import machst, weil dann die /var/linbo/boot/grub/.cfg
neu geschrieben wird.
Deswegen kontrollier mal, ob in der entsprechenden Datei die Zeile
3 mal hashtag managed by linuxmuster
noch intakt ist: sonst kommen die Änderungen nämlich trotzdem nicht an
und alle deine Versuche waren Sinnlos …

LG

Holger

Hallo Holger,
vielen Dank für die Infos, aber das war es noch nicht. Den Beitrag Linbo startet PCs einer HW-Klasse nach Linbo update nicht mehr hatte ich abgearbeitet und dann dummerweise nicht geschrieben, diesen Parameter zuerst getestet zu haben.
Der „3 mal hashtag managed by linuxmuster“ hat bei mir noch 1 hashtag und 1 Leerzeichen davor und es funktioniert einwandfrei, dass die Einstellungen aus start.conf.GRUPPE in boot/grub/GRUPPE.cfg übernommen werden. Letztere kann man auch direkt editieren für schnellere Tests.

Die Sache sieht nun so aus:
Kopiere ich nur Kernel und initrd auf ein Notebook und nehme es als Booteintrag in Grub eines anderen Systems auf, kann ich Linbo ohne jegliche Parametrisierung in FullHD einwandfrei starten.
Boote ich über PXE mit der Vorgabe „set gfxpayload=800x600x16“, bleibt er mit dem Kernel-Splash-Screen nach „Loading /linbofs64.lz … 100%“ hängen, sprich die Ausgangslage.
Mache ich dasselbe mit einem zuvor ermittelten und verfügbaren Wert (Grub-Konsole und videoinfo, hier also 1920x1080x32), wird es trotz i915.alpha_support=1 nach „Loading /linbofs64.lz … 100%“ schwarz, aber das Backlight bleibt an - ich komme also etwas weiter.
Boote ich über PXE während der TFPT aus ist, startet Linbo wieder in FullHD durch und kennt seinen Gruppennamen, hat aber natürlich keine sonstigen Parameter erhalten.
=> Es muss irgendeine Option sein, die diese Grafikeinheit nicht mag und die über die Linbo/Grub-Konfiguration geladen wird. Ich habe schon ein wenig unprotokolliert rumgespielt, auch in der zuvor von Grub ausgewerteten /var/linbo/boot/grub/grub.cfg, wobei ich nicht weiß, ob die nicht irgendwie „angewendet“ werden müsste - bei einem lokalen Grub muss man nach dem Ändern der /etc/default/grub auch ein update-grub machen.

Etwas Zeit investiere ich noch, dann schaue ich, ob ich nicht mal ein korrektes Linbo mit Grub auf Platte kriege (per USB-Boot). Wenn das Problem da auch ist, habe ich Pech, wenn nicht, muss ich das halt so lösen, Hauptsache die anderen Mechanismen (Images, Postsynch) stehen mir zur Verfügung.

=> Hat jemand eine Ahnung, ob Änderungen in /var/linbo/boot/grub/grub.cfg direkt Wirkung zeigen oder ob etwas update-grub-Analoges stattfinden muss?
=> Und: welchen Parameter würdet ihr euch zuerst vorknöpfen?

Vielen Dank und viele Grüße - Henning

Hallo Henning,

=> Hat jemand eine Ahnung, ob Änderungen in
/var/linbo/boot/grub/grub.cfg direkt Wirkung zeigen oder ob etwas
update-grub-Analoges stattfinden muss?

ja, wirken sofort ohne irgend welche Scripte.

=> Und: welchen Parameter würdet ihr euch zuerst vorknöpfen?

ich würde am gfx Payload rumspielen…

LG
Holger

Hallo Henning

ich hatte das Problem auch mal mit HP Prodesk 600 Computern.

Probier mal:

set gfxpayload=ist mir doch egal

genauso in deine grub.cfg eintragen.

Bei uns hat es geholfen. Damals konnte mir auch keiner sagen warum.

Gruß

Uwe

Hallo zusammen,

alle Vorschläge und einen Nachmittag lang viele andere Parameter habe ich erfolglos ausprobiert. Linbo mit Linbo-Grub verhält sich identisch, wenn man es auf Platte installiert.
Strategiewechsel: Neues Grub, altes Linbo von Platte. Grub von Kubuntu 20.04 ist in der Lage, Linbo korrekt zu booten. Es funktioniert dann auch fast alles, solange man kein neues Image einspielt, denn dann wird die Zielpartiton formatiert und anschließend werden Linbo-Grub und System an die neue UUID angepasst, wovon der Kubuntu-Grub natürlich nichts mitkriegt. Da das BIOS der HP250G7-Notebooks das Linbo-Grub nicht automatisch booten kann, nur manuell über Auswahl der Grub-Datei auf der EFI-Partition, startet es immer das Kubuntu-Grub. Somit musste auch dieser Ansatz verworfen werden. Es wäre ohnehin zu erwarten gewesen, dass dann der ursprüngliche Fehler wieder auftaucht. Zudem funktioniert der Sound unter Kubuntu nicht, wenn zuvor Linbo gebootet war. (So ein Phänomen kenne ich von meinem PC mit Bluetooth, das unter Linux nur tut, wenn zuvor kein Windows lief. Erst nach einigen Minuten stromlosem Mainboard geht es dann wieder unter Linux.)
Abhilfe: Letztlich habe ich mich von Linbo für die HP-Notebooks verabschiedet und ein zweites minimal-Kubuntu mit einigen Skripten versehen. Für die Images kommt fsarchiver zum Einsatz, der die UUIDs der Partitionen erhält. Im Laufe der Woche werde ich wissen, ob sich das investierte Wochenende gelohnt hat - viel über bash-Skripte habe ich jedenfalls gelernt.
Nun hoffe ich darauf, Zeit und professionelle Hilfe bei einer kompletten Neuinstallation mit LM7 zu bekommen - Ende des Schuljahres. Bis dahin ist bestimmt ein 5.4er oder neuerer Kernel und 100%ige EFI+GPT-Umsetzung in Linbo und alles wird gut.

Trotzdem vielen Dank! - Henning

Hallo Henning,

Ich habe mit einem HP240G7 das gleiche Problem. Inzwischen gibt es in den Testing-Repositories einen aktuelleren Linbo-Kernel. Hast Du den einmal ausprobiert?

Viele Grüße

Alois

Hallo Alois,
nein, ich habe meine Skript-Lösung mit zweitem Mini-Kubuntu im Einsatz, wobei das bisher noch nicht nötig war, da die automatischen Updates funktionieren - nur genau die zerschießen bisweilen Grub. Dann landet man in der Grub-Konsole. Beim neuesten Fall hat es gereicht, die Bootreihenfolge zu ändern, weshalb ich nun das BIOS im Verdacht habe. Diese HPs sind ziemlich Gaga und für ein BIOS-Update braucht man Windows.
Ich hoffe weiterhin auf LM7. Wenn ich mal so richtig Zeit hätte (LOL), würde ich mich ja selbst dran setzen.
Sorry!
Viele Grüße
Henning

Hallo Henning,

wir haben es hin bekommen. Bei uns waren es HP240G7-Notebooks.

Der Schlüssel zum Erfolg war die Testing-Pakete für Lmn 6.2 einzuspielen. Damit kam Linbo mit einem neuen Kernel der die eingebaute Netzwerkkarte unterstützt.

Weiterhin haben wir die Zertifikate für die erlaubten BS gelöscht (war vermutlich nicht nötig). Damit war Secure Boot ausgegraut und kam uns nicht mehr in die Quere.

Dann bin ich zunächst über die Festplatten gestolpert. Es hat etwas gedauert bis ich bemerkte dass keine SSD’s, sondern Nvme eingebaut waren.

Die start.conf musste für Efi eingerichtet werden, da die Geräte kein Legacy mehr unterstützen.

Gruß

Alois

Hallo Alois,
gratuliere, super … und verdammt schnell ward ihr damit! Ich habe länger gepröbelt, bis ich aufgegeben habe :-/
Jetzt bräuchte ich aber noch einige Details, wenn ich darum bitten darf!
Testing => woher/wie eingespielt?
„Zertifikate für die erlaubten BS“ sagt mir irgendwie gar nichts! Aber bei dem HP250G7 war SecureBoot vom ersten Tag an grau und auf disabled.
Die Sache mit nvme hatte ich direkt festgestellt, als ich die Vorlage installiert habe. Das macht dem alten Linbo aber nichts aus, wenn nvme… statt sda da steht.
Dass nur EFI geht, war mir auch klar - eine zeitlang hatte ich das ja auch im Verdacht. Die entsprechende conf hatte ich aber hingekriegt.
Wenn ich ein woanders vorinstalliertes System eingespielt und erfolgreich in Linbo habe, dann lösche ich die GRUB-Pakete, oder? Da ich die automatischen Updates anhabe, pfuscht der sonst in der Bootreihenfolge rum, denke ich.

Irgendwie juckt es jetzt doch, das nochmal zu probieren, denn letztlich ist Linbo schon extrem praktisch. Und mein Background-Sync-Skript, um neue cloop-Images im normalen Betrieb zu laden, zu prüfen und bei Erfolg gegen das alte cloop zu tauschen, existierten schon grob. Mehr als 100 MBit kriegen wir erst nach Abschluss der Baumaßnahmen, deren Planung gerade am Anfang steht, in die Klassenzimmer. Da wäre ein Torrent mit Bandbreitenbeschränkung schon nett, zudem muss niemand das Passwort kennen, das man braucht, um neues cloops zu laden. Dann müssen sich nicht mal mehr die Admins um die Updates kümmern. :slight_smile:

Vielen Dank und viele Grüße - Henning

Hallo Henning,

in der passenden

/apt/sources.list.d/lml.list (lml.list ist beispielhaft)

steht statt

…babo62/
…babo62-testing/

hier die zwei Zeilen wie sie bei mir lauten:

deb http://archive.linuxmuster.net/ babo62-testing/
deb-src http://pkg.linuxmuster.net/ babo62-testing/

dann apt-get update

und

apt-get dist-upgrade

Damit wird die neue Version von Linbo installiert und die Netzwerkkarte funktioniert.

Wenn SecureBoot ausgegraut ist, dann ist das ok. Offenbar sind da noch keine Zertifikate hinterlegt.

Gruß

Alois

1 Like

Hallo zusammen,
ich habe heute 12 refurbished HP Workstations, welche wir als Spende erhalten haben, unter LMN7 mit Bionic und Win10 bespielt.
Von den vier Z400 zeigten zwei Geräte exakt das gleiche Problem.
Nach dem Laden von linbofs64.lz werden die Bildschirme schwarz und nix geht mehr.
Ich war erst einmal ratlos, da alle anderen Workstations problemlos liefen.
Ich werde am Montag eure Tipps ausprobieren :pray:
Viele Grüße
Ralf

Hallo Ralf,

meine Ausführungen beziehen sich auf die 6.2. Aber auch in der 7.x gibt es das neue Linbo. Ob in testing oder stable weiß ich nicht.

Gruß

Alois

Hallo!

Mensch möge mich korrigieren, falls folgende Aussage nicht stimmt:

In der Version 7 ist die Linboversion drin!

Beste Grüße

Thorsten

Hallo Jungs,

Mensch möge mich korrigieren, falls folgende Aussage nicht stimmt:

In der Version 7 ist die Linboversion drin!

aktuell (Jan 2021) ist folgende Version in lmn7 stable:

linuxmuster-linbo-common7_2.3.68-0_all.deb

und in Testing:

linuxmuster-linbo7_2.4.1-0_all.deb

LG

Holger