Win10 (EFI) aus Linbo nicht startbar

TomS · 29. August 2022 um 08:23

Hallo zusammen,

ich habe letzte Woche ein LM7.1 komplett neu aufgesetzt (Gratulation an die Entwickler und das Dokumentations-Team!) und einen Client-PC (nvme, EFI) mit einem aktuellen Windows 10 installiert.
Als start.conf-Vorlage habe ich die mitgelieferte Win10EFI-Version leicht abgeändert (Daten-Partition gelöscht, Win10-Partition und Cache-Partition auf je 150GB eingestellt).

Die einzige Auffälligkeit bei der Installation war (ist mir erst bei der Fehlersuche aufgefallen), dass die SSH-Keys nicht in den Linbo-Clients stimmten. Dies konnte ich aber beheben und linbo-ssh sowie der Upload der Logs funktioniert jetzt auch.
Da Windows10 manchmal den grub aus der Bootreihenfolge verdrängt hat, habe ich im Windows einen zeitgesteuerte Aufgabe eingestellt, dass nach dem Windowsstart der grub wieder an die erste Stelle gesetzt werden soll. Auch dies funktioniert gut:

bcdedit /set {bootmgr} path \EFI\grub\grubx64.efi

Das Problem ist jetzt, dass mein Vorlagen-Rechner perfekt läuft, aber die per Linbo (v4.0.33-0) geklonten PCs nicht in der Lage sind das Windows 10 aus dem grub/Linbo zu starten. Bei Auswahl des „Start“-Buttons im Linbo werden kurz Änderungen vom Linbo durchgeführt und dann neu gestartet. Dann dauert es etwas (im Display das EFI-Logo von Fujitsu) und man landet wieder reproduzierbar über grub im Linbo.
Auf den geklonten Client-PCs lässt sich Windows10 allerdings trotzdem fehlerfrei über das F12-Bootmenü des EFI-BIOS starten. Das BIOS-Bootmenü zeigt dabei als Auswahl
UEFI PXE IPv4
Windows Boot Manager
grub

Ich habe das Image auch per Linbo auf ein Lenovo-Laptop kopiert (für einen zweiten EDV-Raum). Dort ist das gleiche Problem: per Linbo lässt sich Windows nicht starten. Über das BIOS-Bootmenü zeigt er allerdings 2x den Windows-Eintrag:
grub
EFI PXE Network
Windows Boot Manager
Windows Boot Manager

Der erste Eintrag „Windows Boot Manager“ führt beim Lenovo sofort wieder in den grub/Linbo.
Der zweite Eintrag „Windows Boot Manager“ startet Windows 10.

Die EFI-Partition der Kopiervorlagen sieht außerdem ganz anders aus als auf den geklonten PCs.
Hier die Ausgabe des efibootmgr auf der Kopiervorlage (PCE01-01):

PCE01-01: ~ # efibootmgr --verbose
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0001
Boot0000* grub  HD(1,GPT,7ef180d3-dc12-4b2c-942c-7ab3cbb0971c,0x800,0x64000)/File(\EFI\grub\grubx64.efi)
Boot0001* UEFI: PXE IPv4 Realtek PCIe GBE Family Controller     PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/MAC(98eecbfa8035,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0002* Windows Boot Manager  HD(1,GPT,7ef180d3-dc12-4b2c-942c-7ab3cbb0971c,0x800,0x64000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)..BO
Boot0003  Windows Boot Manager  HD(1,GPT,7ef180d3-dc12-4b2c-942c-7ab3cbb0971c,0x800,0x64000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)..BO
Boot0004  UEFI: PXE IPv6 Realtek PCIe GBE Family Controller     VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)..BO
Boot0005* Windows Boot Manager  HD(1,GPT,7ef180d3-dc12-4b2c-942c-7ab3cbb0971c,0x800,0x64000)/File(\EFI\grub\grubx64.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...3...............
Boot0006* UEFI: PXE IPv6 Realtek PCIe GBE Family Controller     PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/MAC(98eecbfa8035,0)/IPv6([::]:<->[::]:,0,0)..BO

PCE01-01: ~ # find /mnt/ -name "*efi" -print
/mnt/EFI/grub/grubx64.efi
/mnt/EFI/Microsoft/Boot/bootmgfw.efi
/mnt/EFI/Microsoft/Boot/bootmgr.efi
/mnt/EFI/Microsoft/Boot/memtest.efi

Und hier ein per Linbo kopierter PC (PCE01-02):

PCE01-02: ~ # efibootmgr --verbose
BootCurrent: 0005
Timeout: 1 seconds
BootOrder: 0000,0001
Boot0000* grub  HD(1,GPT,7ef180d3-dc12-4b2c-942c-7ab3cbb0971c,0x800,0x64000)/File(\EFI\grub\grubx64.efi)
Boot0001* UEFI: PXE IPv4 Realtek PCIe GBE Family Controller     PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/MAC(98eecbfa802a,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0002* Windows Boot Manager  HD(1,GPT,7ef180d3-dc12-4b2c-942c-7ab3cbb0971c,0x800,0x64000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)..BO
Boot0003* UEFI: PXE IPv6 Realtek PCIe GBE Family Controller     PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/MAC(98eecbfa802a,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0005* Windows Boot Manager  HD(1,GPT,7ef180d3-dc12-4b2c-942c-7ab3cbb0971c,0x800,0x64000)/File(\EFI\GRUB\GRUBX64.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...3...............


PCE01-02: ~ # find /mnt/ -name "*efi" -print
/mnt/EFI/grub/grubx64.efi
/mnt/EFI/Microsoft/Boot/bootmgfw.efi
/mnt/EFI/Microsoft/Boot/bootmgr.efi
/mnt/EFI/Microsoft/Boot/memtest.efi

Irgendwie habe ich also zu viele Windows-Einträge im EFI und Linbo nimmt eventuell den falschen.

Hier ist meine start.conf:

[LINBO]
Server = 10.0.0.1
Group = Win10EFI-Fujitsu-EDVRaum
Cache = /dev/nvme0n1p4
RootTimeout = 600
AutoPartition = no
AutoFormat = no
AutoInitCache = no
DownloadType = rsync
GuiDisabled = no
UseMinimalLayout = no
Locale = de-DE
SystemType = efi64
KernelOptions = quiet splash dhcpretry=9

[Partition]
Dev = /dev/nvme0n1p1
Label = efi
Size = 200M
Id = ef
FSType = vfat
Bootable = yes

[Partition]
Dev = /dev/nvme0n1p2
Label = msr
Size = 128M
Id = 0c01
FSType =
Bootable = no

[Partition]
Dev = /dev/nvme0n1p3
Label = windows
Size = 150G
Id = 7
FSType = ntfs
Bootable = no

[Partition]
Dev = /dev/nvme0n1p4
Label = cache
Size = 150G
Id = 83
FSType = ext4
Bootable = no

[OS]
Name = Windows 10
Version = 21H2
Description = Windows 10 1903

LM7.1 ist auf dem aktuellen Stand. Das BIOS der Fujitsu-PCs ist ebenfalls aktuell. Ich habe schon die Lösungsansetze von Klaus ( Linbo Schleife bei Neustart - #23 von garblixa ) und den Reset der BIOS-Einstellungen durchgeführt. Hat beides keine Abhilfe gebracht.

Wenn ich im Linbo (per linbo-ssh) mittels „efibootmgr --bootnext 0002“ statt dem Windows Boot Manager an der Stelle 0005 denjenigen an der Stelle 0002 verwende, startet Windows10 korrekt.

Ich denke daher die Ursache des Problems könnten die beiden „Windows Boot Manager“ Einträge im EFI sein, von denen einer (0005) nicht funktioniert bzw in den grub/Linbo führt. Mir fehlt allerdings das EFI-Know-How um den „falschen“ Windows Boot Manager aus der EFI-Partition (und dem Linbo-Image) zu entfernen. Vielleicht gibt es auch eine andere Ursache.

Ich wäre für jeden Tipp dankbar.

Beste Grüße,
Tom

Till · 29. August 2022 um 09:01

Du könntest mal den Kernelparameter forcegrub probieren. Dieser würde statt bootnext grub zum Starten von Windows verwenden.

TomS · 29. August 2022 um 09:10

Ich glaube ich habe die Ursache gefunden:
Mein Windows-Script (bcdedit /set {bootmgr} path \EFI\grub\grubx64.efi) setzt nicht nur Grub für den nächsten Boot, sondern setzt einen weiteren „Windows Boot Manager“ Eintrag ins EFI welcher Grub startet. Linbo nimmt dann für das „grün Starten“ genau diesen Eintrag, statt den „Windows Boot Manager“ welcher Windows starten würde.

Wenn ich mit dem efibootmgr den entspr. Eintrag lösche, bootet auch Linbo wieder das Windows 10.
Allerdings fehlt mir dann eine Lösung unter Windows sauber den Grub/Linbo für das nächste booten zu setzen…

TomS · 29. August 2022 um 09:29

Hallo Till,

vielen Dank für den Hinweis.

Der Kernelparameter forcegrub löst das Problem. Jetzt wird Windows gestartet, auch wenn der grubx64-Eintrag als Weiterer Windows Boot Manager existiert.

Jetzt bin ich nicht sicher, ob ich weiter probieren sollte den zweiten Windows-Boot-Manager-Eintrag (GRUB) zu entfernen, oder das Problem durch forcegrub zu umgehen. Was davon wäre die saubere Lösung?
Was bewirkt forcegrub genau? In der Doku steht nur „Forces grub boot on uefi systems (in case of uefi boot issues).“
Würde das auch mein Windows-Script überflüssig machen?

Till · 29. August 2022 um 09:44

Frocegrub verwendet einfach grub zum starten der Betriebssysteme. Das ist das gleiche verfahren was auf legacy Systemen, sprich Geräte welche im Firmware noch mittels BIOS booten können, verwendet wird.

Unsauber ist das ganze nicht. Eleganter ist es natürlich die UEFI Optionen zu verwenden, da sich aber jeder Hersteller eine andere Implementierung des ganzen aussucht umgeht man damit das Problem relativ sauber.

Ob dein Windows Script noch benötigt wird musst du ausprobieren. Das hängt ebenfalls wieder vom Firmware deiner Rechner ab. Manche Rechner setzen Windows einfach immer wieder über Grub. In dem Fall wird dein Script benötigt.

Gruß,
Till

TomS · 29. August 2022 um 10:06

Danke für die Erklärung.
Jetzt habe ich zwei Lösungswege und werde erstmal (weil hier noch genug andere Baustellen offen sind) mit der Forcegrob-Option arbeiten.
„Mein“ Skript (von Windows 10 changes UEFI boot order every time) macht eigentlich genau das was es soll: erzwingt immer den GRUB und verhindert damit den normalen Windows-Start per EFI. Ich hätte nur die Beschreibung genau durchlesen müssen. Zusammen mit forcegrub arbeitet es jedenfalls wie es soll.

Danke und viele Grüße,
Tom

createc-solution · 29. August 2022 um 12:05

Ich hatte das Problem mit Fujitsu Esprimo-Rechnern auch, und hatte über die WIndows-Aufgabenplanung das gleiche Script mit BCDEDIT drin.

Mittlerweile mach ich das so mit der LMN7.1 und LINBO-4.0.33:

BCDEdit-Script in der Windows-Aufgabenplanung wieder entfernt.
LINBO-Kerneloption ‚noefibootmgr‘ in die start.conf hinzugefügt.
BootOrder folgend festgelegt:

UEFI PXE IPv4 Boot

Wenn dann das LINBO das erste mal vom Netzwerk gestartet wird polt LINBO die Bootorder folgend um:

grub
UEFI PXE IPv4 Boot

Seitdem funktioniert das Booten in Windows & Linux von LINBO aus (ich nutze Win10 & Linux im Dualboot). Über die ‚noefibootmgr‘-Option fummelt LINBO ausser den ‚grub‘-Eintrag an die erste Stelle zu setzen nichts an den UEFI-Bootoptionen rum.

Das einzigste Problem was ich jetzt noch habe ist dass manchmal (noch nicht herausgefunden warum und wann) trotz ‚grub‘ an erster Stelle direkt Windows gebootet wird und nach Neustart gleich wieder. Es gibt ein Tool ‚BootICE‘ für Window womit man die UEFI-Bootorder sich anschauen und ändern kann, wenn ich damit schaue steht die Bootorder immer noch ‚grub‘ an erster Stelle. Ich kanns mir nur so erklären dass in der grubenv oder woanders im lokalen GRUB noch was drinsteht was Ihn direkt veranlässt ins Windows zu booten. Jedenfalls erscheint seit ‚noefibootmgr‘ kein ‚Windows Boot Manager‘ mehr in den Bootoptionen.

Hab mir jetzt mal die /cache/boot/grub/grubenv Datei mit einem EXT4-Reader unter Windows angeschaut, da stand drin ‚$reboot_kernel=/auto‘, kann das der Grund sein?

Zusatz: forcegrub hab ich noch nie verwendet, versteh auch nicht ganz den Unterschied zwischen ‚forcegrub‘ und ‚noefibootmgr‘

TomS · 29. August 2022 um 12:23

Soweit ich das verstehe/interpretiere wird bei forcegrub im Linbo der Windows-Start nicht über EFI (next boot…) durchgeführt, sondern direkt aus dem grub heraus die Windows-Datei gestartet. Dadurch ist es egal was alles in der EFI Bootreihenfolge steht (besonders wenn, wie bei mir, mehrere Windows Boot Einträge im EFI existieren).

Bei ‚noefibootmgr‘ wird wohl nach dem Clonen die „windows boot manager“ Einträge in der EFI-Partition nicht erstellt (ist jetzt eher geraten) - bitte korrigieren wenn es anders ist.

createc-solution · 29. August 2022 um 13:36

Wäre ‚forcegrub‘ dann nicht das gleiche wie ‚warmstart=1‘ (oder so ähnlich) beim Windows-Start?

Till · 29. August 2022 um 15:05

Nein, forcegrub verwnedet wie schon gesagt grub zum starten des OS.

warmstart hat unter Windows soweit ich informiert bin keinerlei auswirkung, unter Linux wird mit warmstart direkt aus Linbo das entsprechende OS gestartet ohne nochmal einen reboot des Systems durchzuführen.

Buster · 29. August 2022 um 19:26

Hallo,

wir hatten ähnliche Probleme mit Dell-Optiplex-Rechnern und konnten die mit noefibootmgr lösen. Gibt es in dem Fall überhaupt eine Möglichkeit Windows 10 direkt aus dem Linbo-Menü zu booten ohne zusätzlicnhen Reboot?

MfG Buster

TomS · 29. August 2022 um 20:35

Kurzes Update:
Nach dem erneuten Verteilen der Images mit forcegrub (Image von der Hardwareklasse Lenovo-Laptops erstellt und auf die Hardwareklasse Fujitsu verteilt) startet auf den Fujitsu PCs Win10 nun weder über Linbo noch über das BIOS Startmenü.
In der EFI Partition fehlen nun anscheinend alle Windows-Dateien nach dem Verteilen. Im BIOS-Bootmenü taucht Windows nicht mehr auf.
Beim „grün Start“ per Linbo(forcegrub) kommt ein
„Falling back to LINBO“ und ein Hinweis dass /boot/grub/x86_64-efi/cpuid.mod nicht gefunden wird. Danach startet ein iXPE und dann landet man wieder im LINBO.

Auf den Lenovo-Laptops klappt das Image noch. Dort zeigt der efibootmgr auch entspr. Windows-Einträge.

Liegt die EFI-Partition im qcow2-Image? Kann ich irgendwie prüfen was im Image auf der EFI-Partition ist?
Ich habe zum Glück zwei Fujitsu-PCs noch nicht überschrieben. Kann ich von dort einfach die EFI-Partition auf einen nicht bootbaren PC kopieren und dann ein neues Image davon erstellen?

Viele Grüße
Tom

TomS · 5. September 2022 um 11:26

Nach einigen erfolglosen Versuchen, konnte ich nun das Problem mit der Kernel-Option „noefibootmgr“ lösen.

Vor dem Verteilen habe ich präventiv über „neu Partitionieren“ sichergestellt, dass die EFI-Partition leer ist und per efibootmgr alle Einträge aus dem NVM gelöscht.
Bei zwei Testrechnern schaut das Ergebnis gut aus: keine unsinningen EFI-Booteinträge (nur noch PXE4 und Grub) und Windows10 wie auch grub können starten.

Danke für die Tipps!

Viele Grüße
Tom