Hallo Michael,
„Inhalt der EFI Partition“:
wenn du in linbo bist, dann geh mal auf den Reiter „Imaging“ und dann öffne eine Konsole.
Dann mountest du die efi Partition nach /mnt mittels
mount /dev/sda1 /mntund dann schaust du dir den Inhalt mit ls an.
Das ganze geht bequemer per linbo-ssh vom Server aus.
LG
Holger
Vielen Dank
Vielen Dank, die Inhalte der EFI-Partition habe ich gelöscht. Das hatte allerdings zu keinen Änderungen am Startverhalten geführt.
Nun habe ich das Verzeichnis „EFI“ von der Windows-Partition gelöscht und bekomme bei einem Neustart diese Fehlermeldung:
Der „Kaltstart“ läuft nach wie vor unverändert. Die Fehlersuche in Richtung „EFI“ scheint der richtige Weg zu sein. Aber wie kann ich jetzt weiter vorgehen? Ist es möglich, dass bei der Windows-Installation die EFI-Partition nicht oder nicht richtig konfiguriert wird?
Hallo Michael,
Du könntest probieren die EFI Dateien neu zu schreiben:
Von einer Windows 10 Boot DVD/ISO booten dann:
diskpart
list disk
sel disk 0 (Die Platte mit der Windows Installation auswählen)
list vol
sel vol 1 (Deine EFI Partition auswählen)
assign letter=e:
sel vol 3 (Deine Windows Partition auswählen)
assign letter=f:
exitbcdedit /set {bootmgr} device partition=e:
bcdedit /set {default} device partition=f:
bcdedit /set {default} osdevice partition=f:Der PC sollte jetzt mit Windows Booten.
Dann ein neues Image erstellen, damit Linbo die EFI Konfiguration sichert.
Viele Grüße
Klaus
Hallo,
erstmal vielen Dank für die zahlreichen Tipps. Ich habe Windows 10 jetzt noch mal neu installiert, zuvor aber die Größe der Daten-Partition auf 1G festgelegt. Offensichtlich scheint jetzt alles sauber zu funktionieren.
Hallo zusammen,
tut mir leid, wenn ich einen alten Thread ausgrabe, aber das Thema ist für uns nahezu identisch, nur bisher ohne Lösung.
Wir versuchen einen PC-Raum mit neuen PCs zu imagen: UEFI und NVME (M.2)-Festplatten. Gewünscht ist ein Boot in Linbo und von dort weiter in Windows 10.
Da Windows die Bootreihenfolge ändert setzen wir diese über das Tool UEFI-PXE-Firstboot beim Systemstart auf PXE-Boot.
Bei manchen Geräte funktioniert alles wie gewünscht. Bei anderen kommen wir aus Linbo nicht in Windows 10, der Rechner startet dann einfach neu und landet wieder im Linbo (Dauerschleife).
Wir haben nun seeeeehr viel experimentiert mit Formatieren der Boot-Partition, komplette Formatierung der gesamten Festplatte (sauber), vorherige Installation von Windows, dann neu partitionieren über Linbo etc. pp. Auch die Lösung aus diesem Thread ist, wie gesagt, erfolglos probiert worden.
Manche Rechner gehen jetzt, andere nicht. Der Fix ist leider nicht reproduzierbar, d.h. wir wissen letztendlich nicht, was eine Änderung gebracht hat und bekommen die meisten Rechner mit keinem Mittel dazu, aus Linbo Windows 10 zu starten.
Ich stelle gerne alle möglichen Log-Dateien bereit, müsste aber bitte gesagt bekommen, wo ich die finde.
Für Vorschläge bin ich äußerst dankbar.
LG
Lars
Kleines Update: Wir hatten nun bei den meisten Rechnern einen Erfolg, indem wir über einen Windows-Bootstick in die Eingabeaufforderung sind und mittels
bcdboot c:\Windows /l de-de (ausgeführt auf c:)
den EFI-Bootloader zurückgesetzt haben.
Um das Problem ganz beheben zu können wäre es hilfreich zu wissen, was genau LINBO/GRUB wann mit dem Bootloader anstellt, also ausgehend von einem PXE-Boot → Laden von GRUB/LINBO → starten von Windows 10 aus LINBO.
Könnte hier jemand etwas Licht ins Dunkel bringen?
LG
Lars
Hallo Lars,
selbes Problem bei mir. Betrifft nur PC’s mit NVME Platten. Entweder Reboot Schleife oder Fehler 0x0000225
Mein Thread dazu:
Dein Hinweis mit
bcdboot c:\Windows /l de-de hilft auch bei mir. Vielen Dank dafür!
@thomas
Das ist doch ein eindeutiger Hinweis darauf, daß da etwas mit EFI/GPT nicht stimmt.
Der Bootloader nach der obigen Reparatur sieht auf VirtualBox so aus:
~ # efibootmgr -v
BootCurrent: 0006
Timeout: 0 seconds
BootOrder: 0004,0006
Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI VBOX CD-ROM VB0-01f003f6 PciRoot(0x0)/Pci(0x1f,0x1)/Ata(0,0,0)N.....YM....R,Y.
Boot0002* UEFI ORCL-VBOX-NVME-VER12 VB1234-56789 1 PciRoot(0x0)/Pci(0xe,0x0)/NVMe(0x1,00-00-00-00-00-00-00-00)N.....YM....R,Y.
Boot0003* EFI Internal Shell FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0004* grub HD(1,GPT,28ad830f-6562-49d7-855e-fac8b6966159,0x800,0x64000)/File(\EFI\grub\grubx64.efi)
Boot0005* Windows Boot Manager HD(1,GPT,045bab3a-fbaf-43f4-8f91-28bf6f69614f,0x800,0x64000)/File(\EFI\Microsoft\Boot\bootmgfw.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.}...,................
Boot0006* UEFI PXEv4 (MAC:080027183F0F) PciRoot(0x0)/Pci(0x3,0x0)/MAC(080027183f0f,1)/IPv4(0.0.0.00.0.0.0,0,0)N.....YM....R,Y.
Boot0007* Windows Boot Manager HD(1,GPT,c5d684d0-9c82-4f71-a129-2a37a1e137ad,0x800,0x64000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)Vor der Reparatur und mit der Bootschleife:
~ # efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0004
Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI VBOX CD-ROM VB0-01f003f6 PciRoot(0x0)/Pci(0x1f,0x1)/Ata(0,0,0)N.....YM....R,Y.
Boot0002* UEFI ORCL-VBOX-NVME-VER12 VB1234-56789 1 PciRoot(0x0)/Pci(0xe,0x0)/NVMe(0x1,00-00-00-00-00-00-00-00)N.....YM....R,Y.
Boot0003* EFI Internal Shell FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0004* grub HD(1,GPT,28ad830f-6562-49d7-855e-fac8b6966159,0x800,0x64000)/File(\EFI\grub\grubx64.efi)
Boot0007* Windows Boot Manager HD(1,GPT,c5d684d0-9c82-4f71-a129-2a37a1e137ad,0x800,0x64000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)Viele Grüße
Klaus
Wir haben nun nochmal weiter getestet. Das Problem tritt bei uns auch bei Rechnern mit SATA-SSDs auf. Wir haben die Rechner bisher im alten Linuxmuster und abgeschaltetem UEFI betrieben. Bei aktiviertem UEFI ergeben sich ähnliche Probleme.
Beim aktuellen Test ist es folgendermaßen:
Auffällig ist mir noch, dass grub sehr schnell mehrfach in der GPT auftaucht. Ist das so gewollt??
LG
Hallo Lars,
nutzt Du schon Linbo 4.0.x aus der lmn 7.1? Da sollte das in der aktuellen Version 4.0.7 alles funktionieren.
Viele Grüße
Klaus
Ich wusste bisher weder etwas von Linbo 4 noch von lmn 7.1… Habe das Update jetzt gemacht und werde erst mal wieder mit dem Erstellen eines neuen Images beschäftigt sein.
Ist das normal, dass in der Schulkonsole jetzt Linbo und Linbo 4 untereinander auftauchen? Greifen die Gruppen von Linbo noch in irgendeiner Form?
Hallo Lars,
du hast auf die lmn7.1 komplett upgedatet?
Hast du die Migrationsanleitung linbo 2.x → linbo 4 beachtet?
Dir ist bewußt, dass die 7.1 noch Beta ist?
LG
Holger
Hallo Holger,
unser System ist noch ziemlich jungfräulich und vor dem Update haben wir einen Snapshot erstellt - Netz und doppelter Boden also. Die Migrationsanleitung habe ich (jetzt jedenfalls) beachtet und ich konnte nun auch das konvertierte „alte“ Image laden. Das Ergebnis schaue ich mir morgen früh an 
Viele Grüße
Lars
Ich komme einfach nicht klar. Habe jetzt das konvertierte Image gezogen. Das Windows lässt sich starten, allerdings nur, wenn (manuell) über den Windows-Boot-Manager gebootet wird. Bei einem Boot aus LINBO (4.0.7) erfolgt der übliche Neustart, dann ein PXE-Start sofort gefolgt von einem Bluescreen:
„Wiederherstellung
Der PC/das Gerät muss repariert werden.
Ein erforderliches Gerät ist nicht verbunden, oder es kann nicht darauf zugegriffen werden.
Fehlercode: 0xc000000e“
In den Boot Sources im BIOS taucht jetzt gar kein grub mehr auf, sondern nur noch der Windows Boot Manager (oder halt Netzwerk).
Würde es etwas bringen, ein neues Image zu erstellen? Das würde ich eigentlich gerne vermeiden…
LG
Lars
Hallo Lars,
wenn Du von dem Windows, welches startet ein neues Image machst(unter Linbo 4.x), dann sollte das auch funktionieren. Lässt sich leider nicht vermeiden.
Viele Grüße
Klaus