… sorry: deine Mail war „nach unten“ aus dem Blick geraten (passwiert mir leider manchmal).
Ich lese das Forum als Mailingliste (finde ich praktischer, weil die Nachrichten automatisch alle zu mir kommen und ich nicht auf die Webseite muß).
Ja: ich denke, dass bei dir ein ähnliches Problem vorliegt.
Du hast Probleme mit dem uefi Boot von ubuntu aus linbo heraus, aber nur auf den sata Clietns und icht auf den nvme Clients.
Zu deiner Frage wann der grub wo eine Rolle spielt.
Das kommt darauf an.
Wir haben eigentlich drei grub die hier „mitspielen“:
den der per PXE über das Netz geladen wird und normalerweise linbo startet
den den linbo in die cachpartition schreibt und der über das BIOS gestartet wird
den des installierten ubuntus.
Ich rede jetzt mal nur davon, wie ubuntu gestartet wird, wenn linbo läuft: also aus linbo heraus.
Und jetzt kommt es drauf an, was dem linbo gesagt wird, wie es das machen soll.
Dafür gibt es zwei Möglichkeiten:
I) linbo startet den ubuntu kernel direkt (läd ihn also und startet ihn) genannt: warmstart. Dabei wird der Rechner nciht neugestartet. Dies ist das Defaultverhalten von linbo. Leider haben neuer linuxkernels Schwierigkeiten beim initialisieren der Hardware, wenn diese zuvor schon durch linbo initialisiert wurden. Dann funktioniert gerne mal die Netzwerkkarte im gestarteten linux nicht mehr, obwohl sie unter linbo tadellos funktionierte. Bei warmstart werden keinerlei weitere grubs benötigt: linbo läd und startet den kernel von ubuntu
II) nowarmstart: hier wird, wenn linbo das installierte linux startet, der Rechner neugestartet, nachdem dem lokalen grub gesagt wwurde (also dem von linbo), starte beim nächsten Start ubuntu.
Ich kann es nicht genau sagen, aber ich denke, dass der „linbogrub“ dann den kernel von ubuntu nach dem reboot aus der Ubuntupartition läd: deswegen muß der Pfad korrekt sein (also vmlinuz und initrd.img bei Debian und boot/vmlinuz und boot/initrd.img bei ubuntu).
Das wird in der start.conf.GRUPPE so eingetragen.
Und hier nochmal: VORSICHT: was in der start.conf.GRUPPE eingetragen wird (im Bezug auf grub) wird erst „wahr“, wenn man linuxmuster-import-devices hat laufen lassen UND die Zeile
managed by linuxmuster.net
in der /srv/linbo/boot/grub/GRUPPE.cfg
intakt ist (mit allen hashtags am Anfang der Zeile.
In deinem Fall würde ich folgendes Vorgehen testen:
nowarmstart
vielelicht hilft es ja
linbo bringt zwei switches mit, um mit uefibootproblemen um zu gehen.
Da du nvme und sata Clients hast, hast du auch zwei GRUPPEn, kannst also die nvme Gruppe in Ruhe lassen und nur das Startverhalten der sata Gruppe manipulieren.
Schau dir die Switches hier an:
Kein Stress, ist ja alles benutzbar und ich muss ja auch unterrichten, wenn keine Ferien sind…
Dieser Weg funktioniert an den NVME-Clients ja auch nicht wie er eigentlich soll. Die Rechner bringen ja auch erstmal eine Fehlermeldung und booten dann nur ins LinuxMint, weil im Image bzw. der EFI-Partition (?) noch ein für NVME configurierter GRUB liegt. Die SATA-Clients würden starten, wenn ich den Grub im Image für SATA konfiguriere. Dann bräuchte ich aber ein zweites Image…
Ich denke der „linbogrub“ wird nicht korrekt angelegt. Unter Linbo 2.4 ging das noch. Was hat sich verändert oder sind irgendwelche Einstellungen beim Update nicht richtig angelegt worden? Oder ist es ein Bug?
Du meinst forcegrub und noefibootmgr, oder? Das muss ich noch probieren.
forcegrub lässt sowohl bei den SATA-Clients als auch bei den UEFI-Clients alle Fehlermeldungen verschwinden und die Rechner starten wie sie sollen: Linbo > Reboot > direkt ins LinuxMint
Linbo schreibt wohl mit dieser Option nochmal einen Grub und repariert die EFI-Partition. Zumindest zeigt Linbo ganz kurz entsprechende Meldungen an, bevor ins System neugestartet wird.
Kann es sein, dass man mit dem neuen Linbo 4.2 bei EFi-Systemen und der Option nowarmstart immer auch die Option forcegrub braucht?
Meine Kernel-Optionen in beiden Hardwareklassen sind nun diese: quiet splash nowarmstart dhcpretry=10 forcegrub
Ich fasse meine Update-Erfahrungen nochmal zusammen:
Das Update lief unproblematisch durch.
Den FreeRadius musste ich neu einrichten, wie ich hier beschrieben habe - das war aber zu erwarten und relativ schnell gemacht.
Dann ging es um die Probleme mit Linbo:
Beim ersten Start der Clients holten sich diese das neue Linbo, machten dann einen Reboot und booteten dann aber nicht ins neue Linbo, sondern direkt ins alte LinuxMint. Ich musste an jedem einzelnen Client manuell ins BIOS und dort die Bootreihenfolge anpassen. Bei den Lenovo-Laptops sogar das BIOS komplett zurücksetzen und mehrmals neustarten, bis Networkboot überhaupt wieder auswählbar war. Ein Glück, dass ich „nur“ 80 Clients habe. Erst dann kam ich wieder ins Linbo.
Dann folgte obige Fehlersuche.
Und nun musste ich alle Clients noch neu partitionieren und synchronisieren, was aus der WebUI zumindest an den fest am LAN hängenden Clients ferngesteuert schnell gemacht werden konnte. Die Laptops sind leider einzeln dran, solange ich Linbo über WLAN noch nicht eingerichtet habe.
Bitte nehmt doch die EFI-Kernel-Optionen in die Upgrade-Anleitung 7.1 > 7.2 mit auf. Dort steht, was Linbo betrifft, bis jetzt nur, dass man einen Geräteimport machen muss und dann alles laufen sollte. Es hätte mir sehr geholfen, wenn dort auch die Fallstricke des Linbo-Updates genannt werden.
Versteht mich bitte nicht falsch, ich liebe linuxmuster.net und schätze eure Arbeit sehr! Auch die Hilfe hier im Forum ist grandios. Ich sehe Fehlersuche auch als Challange und hab sogar Spaß dabei - man lernt ja auch immer unglaublich viel dazu und ich gebe gerne auch meine Erfahrungen hier an die Community zurück. Dieses Update hat meinen Idealismus aber schon sehr strapaziert.
Gut, dass jetzt alles wieder läuft und das Update auch einige tolle neue Features bietet! Ich danke euch für eure Hilfe und den Entwicklern für ihre tolle Arbeit!