ich habe hier einen Lenovo Thinkpad X1 Yoga mit NVME-SSD, der früher problemlos unter Windows 11 im EFI-Modus gebootet hat. Jetzt bekomme ich ihn nicht dazu, aus Linbo heraus zu starten.
wenn ich die EFI-Partition formatiere und mit bcdboot C:\Windows..., dann kann ich den Windows Boot Manager im EFI-Bios auswählen und Windows 11 startet einwandfrei
auf der EFI-Partition (per Diskpart eingebunden) sind dann die Verzeichnisse Boot und EFI und die Dateien bootmgr und BOOTNXT. Unter EFI findet sich Microsoft und Boot (mit bootx64.efi)
sobald einmal Linbo bootet, entsteht unterhalb von EFI das Verzeichnis GRUB. Im EFI-Bios ist nur noch grub auswählbar und Linbo startet ab dann
Ubuntu startet aus Linbo einwandfrei
Windows hingegen startet nicht. Nach dem Neustart kommt eine Fehlermeldung (grubenv not found) (erst, wenn man noch einmal OS localboot wählt) und es wird ein PXE-Boot versucht und ich lande im grub Menü (und kann von dort zurück zu LINBO).
Die Kernel Parameter noefibootmgr und forcegrub habe ich ausprobiert - ohne Änderung.
und wenn du das ganz pragmatisch lößt?
Einfach das grub bootmenü verwenden und Windows von dort aus starten lassen.
Also die Auswahl nicht in linbo machen, sondern im grubbootmenü?
ich bezweifele ja, dass das geht (grub startet ja und bootet Windows nicht - warum sollte das anders sein, wenn man die GUI weglässt) - aber davon unabhängig würden die Schülerinnen und Schüler vermutlich nicht so prall finden, warum bei ihren bisher schick benutzbaren Geräten jetzt ein Textmenü kommt. Ipad-Konkurrenz
Bevor gar nichts mehr geht, teste ich das vielleicht nochmal - aber ich hoffe ja, dass es da eine richtige Lösung gibt - die Geräte haben ja früher funktioniert (und wurden deswegen zum Kauf empfohlen).
Ich poste jetzt erstmal den Debug-Kram, den ich auf dem Client zusammengesammelt habe.
linbo_cmd update 10.0.0.1 /dev/nvme0n1p6
Mounting cache partition /dev/nvme0n1p6 ...
Looking for LINBO updates.
receiving incremental file list
linbofs64.lz.md5
33 100% 32.23kB/s 0:00:00 (xfr#1, to-chk=0/1)
LINBO is up-to-date.
Downloading torrent-client.conf.
Downloading multicast.list.
Downloading linbo wallpaper.
Updating ipxe file.
receiving incremental file list
Updating common grub configuration.
receiving incremental file list
adapter-bethnvme.bethnvme.grub.cfg
3,357 100% 3.20MB/s 0:00:00 (xfr#1, to-chk=0/1)
Updating host and group specific grub configuration.
receiving incremental file list
adapter-bethnvme.cfg
11,552 100% 11.02MB/s 0:00:00 (xfr#1, to-chk=0/1)
Updating grub themes ... OK!
Updating linuxmuster-win ... OK!
mk_boot
prepare_grub /cache/boot/grub /cache/boot/grub/grubenv /usr/share/grub
Providing grub environment in cache ...
* Providing grub environment ...
Installing GRUB in MBR/EFI of /dev/nvme0n1 ... OK!
EFI bootorder has been successfully set.
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000
Boot0000* grub
Boot0010 Setup
Boot0011 Boot Menu
Boot0012 Diagnostic Splash Screen
Boot0013 Lenovo Diagnostics
Boot0014 Startup Interrupt Menu
Boot0015 Rescue and Recovery
Boot0016 MEBx Hot Key
Boot0017* USB CD
Boot0018* USB FDD
Boot0019* NVMe0
Boot001B* USB HDD
Boot001C* PCI LAN
Boot001D Other CD
Boot001E Other HDD
Boot001F* IDER BOOT CDROM
Boot0020* IDER BOOT Floppy
Boot0021* ATA HDD
Boot0022* ATAPI CD
Linbo & grub update successfully finished.
Uploading linbo.log ...
linbo_wrapper start:1
linbo_wrapper start:1
Command : start
OS number : 1
Starting Windows 11 ...
No kernel auto on partition /dev/nvme0n1p3. Using "auto".
mk_boot /dev/nvme0n1p3 auto
prepare_grub /cache/boot/grub /cache/boot/grub/grubenv /usr/share/grub
prepare_reboot /dev/nvme0n1 /dev/nvme0n1p3 /cache/boot/grub/grubenv auto /dev/nvme0n1p1
repair_efi /dev/nvme0n1p1
Failed to restore windows EFI bootfiles.
EFI boot entry for Windows Boot Manager successfully created.
EFI bootnext for grub has been set to 0000.
EFI bootorder has been successfully set.
BootNext: 0000
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000
Boot0000* grub
Boot0001* Windows Boot Manager
Boot0010 Setup
Boot0011 Boot Menu
Boot0012 Diagnostic Splash Screen
Boot0013 Lenovo Diagnostics
Boot0014 Startup Interrupt Menu
Boot0015 Rescue and Recovery
Boot0016 MEBx Hot Key
Boot0017* USB CD
Boot0018* USB FDD
Boot0019* NVMe0
Boot001B* USB HDD
Boot001C* PCI LAN
Boot001D Other CD
Boot001E Other HDD
Boot001F* IDER BOOT CDROM
Boot0020* IDER BOOT Floppy
Boot0021* ATA HDD
Boot0022* ATAPI CD
Failed to write EFI boot configuration.
Write reboot informations to /cache/boot/grub/grubenv.
Restrict access rights on .linbo:
"/dev/nvme0n1p3" opened read-write
"/dev/nvme0n1p3" closed
No errors were found
ntfssecaudit 1.5.0 : NTFS security data auditing
Posix descriptor :
acccnt 0
defcnt 0
firstdef 0
mode : 0700
tagsset : 0x00
Posix ACL :
version 2
flags 0x00
File .linbo mode 0700
No errors were found
Restrict access rights on .guid.disk:
"/dev/nvme0n1p3" opened read-write
"/dev/nvme0n1p3" closed
No errors were found
ntfssecaudit 1.5.0 : NTFS security data auditing
Posix descriptor :
acccnt 0
defcnt 0
firstdef 0
mode : 0700
tagsset : 0x00
Posix ACL :
version 2
flags 0x00
File .guid.disk mode 0700
No errors were found
Restrict access rights on .guid.efi:
"/dev/nvme0n1p3" opened read-write
"/dev/nvme0n1p3" closed
No errors were found
ntfssecaudit 1.5.0 : NTFS security data auditing
Posix descriptor :
acccnt 0
defcnt 0
firstdef 0
mode : 0700
tagsset : 0x00
Posix ACL :
version 2
flags 0x00
File .guid.efi mode 0700
No errors were found
Restrict access rights on .guid.part:
"/dev/nvme0n1p3" opened read-write
"/dev/nvme0n1p3" closed
No errors were found
ntfssecaudit 1.5.0 : NTFS security data auditing
Posix descriptor :
acccnt 0
defcnt 0
firstdef 0
mode : 0700
tagsset : 0x00
Posix ACL :
version 2
flags 0x00
File .guid.part mode 0700
No errors were found
Restrict access rights on linuxmuster-win:
"/dev/nvme0n1p3" opened read-write
"/dev/nvme0n1p3" closed
No errors were found
ntfssecaudit 1.5.0 : NTFS security data auditing
Posix descriptor :
acccnt 0
defcnt 0
firstdef 0
mode : 0700
tagsset : 0x00
Posix ACL :
version 2
flags 0x00
Directory linuxmuster-win mode 0700
No errors were found
receiving incremental file list
receiving incremental file list
Initiating machine password update on server 10.0.0.1 ...
receiving incremental file list
Uploading linbo.log ...
ich bezweifele ja, dass das geht (grub startet ja und bootet Windows
nicht - warum sollte das anders sein, wenn man die GUI weglässt)
… weil es ein ganz anderer Startvorgang ist: es wird nicht linbo
verwendet und es wird nicht der uefi bootloader von windows benutzt: das
grubmenü bootet windows direkt.
aber
davon unabhängig würden die Schülerinnen und Schüler vermutlich nicht so
prall finden, warum bei ihren bisher schick benutzbaren Geräten jetzt
ein Textmenü kommt. Ipad-Konkurrenz
tut mir Leid: in den Kategorieren kenne ich mich nicht aus.
Ich find iPads und deren Oberfläche sau hässlich und textkonsolen super
hübsch …
Bevor gar nichts mehr geht, teste ich das vielleicht nochmal - aber ich
hoffe ja, dass es da eine richtige Lösung gibt
ich brauch das grubmenü nicht: windows 10 startet auch aus linbo heraus:
trotzdem verwende ich überall das grubmenü: ich finde es super praktisch.
die Geräte haben ja
früher funktioniert (und wurden deswegen zum Kauf empfohlen).
ich weiß es nicht, was windows 11 wieder meint anders machen zu müssen
… es wird seine Zeit brauchen bis wir das raus haben und die Probleme
umschiffen können.
es sah ja alles (z.B. die IDs der SSDs) gut aus, aber mir war die folgende Zeile aufgefallen: Failed to restore windows EFI bootfiles.
Die Dateien unter C:\ schienen mir auch unauffällig, aber ich habe sie einfach mal gelöscht und mit einer frischen „Kopie“ der Dateien auf der EFI-Partition ersetzt - immerhin waren diese Dateien mit dem Image schon länger unterwegs.
Und dann - hurra - lief es sofort. Morgen teste ich es auf anderen Geräten. Aber es scheint mir gelöst.
Für den Hinterkopf also: auch die Dateien unter C:\EFI können offenbar „kaputt“ gehen (oder kaputt gemacht werden) und dann klappt das Booten nicht - ohne offensichtliche Fehlermeldung a la OS not found.
Die Debug-Ansätze von Thomas hier sind auf jeden Fall sehr hilfreich (wobei der Befehl zum Abschalten des reboots inzwischen vermutlich lautet: sed -i 's|reboot -f|echo no reboot|' /usr/bin/linbo_start).
Für mich noch interessant:
Was macht Linbo, wenn es den Order C:\EFI gar nicht gibt?
Gibt es irgendwelche Regeln/Besonderheiten für die Ablage dieser Dateien auf C:? Ich habe ja jetzt einfach nur eine Kopie von [EFI-Disk]\EFI erstellt… Kann man da auch verschiedenen Konfigurationen ablegen (da lagen auch Dateien wie BCD. drin).
… weil es ein ganz anderer Startvorgang ist: es wird nicht linbo
verwendet und es wird nicht der uefi bootloader von windows benutzt: das
grubmenü bootet windows direkt.
Ja schon klar - ich bin nur nicht sicher, ob es das Problem behoben hätte, weil ja schon ein Start von Linbo genügt hat, um Windows umzuhauen. Kann gut sein, dass das gegangen wäre, aber ich bin ganz froh, dass ich DAS niemandem an der Schule erklären muss…
tut mir Leid: in den Kategorieren kenne ich mich nicht aus.
Dir muss das nicht leid tun wenn es nach mir ginge, … na ich rede mich mal nicht um Kopf und Kragen. Ipads sind die Zukunft der Bildung! So und nicht anders.
ich weiß es nicht, was windows 11 wieder meint anders machen zu müssen
… es wird seine Zeit brauchen bis wir das raus haben und die Probleme
umschiffen können.
Mir scheint es, als sei der Bootvorgang selbst nicht großartig verändert geworden. Was natürlich morgen schon wieder anders aussehen kann. Windows 11 selbst - na, wer es benutzen mag, kann es jetzt benutzen. Bei den Geräten geht es um Schüler-Endgeräte ohne Domäne, die wir als „Service“ der Schule mit Linbo/Windows/Ubuntu bespielen. Und da steht so ein altes gebrauchtes X1 Yoga halt in Konkurrenz zu edlen, teuren Geräten bekannter Marken…
Dass unser Angebot nachhaltig, offen, vielseitig und auch noch günstig ist - und dank Linbo auch noch Selbstheilung mitbringt… wird den meisten erst klar, wenn sie damit eine Zeit lang gearbeitet haben.
Ansonsten kann ich nur sagen: dieses Geräte würde ich so, wie wir sie einrichten, auch selbst „haben wollen“. Bootet schnell, ich kann selbst aus Linbo per Touch starten, Multitouch unter Windows und Gnome, habe einen Stift für Xournal++ oder Kunstunterricht, … Viel universeller geht es kaum.
auch bei mir an der Schule haben wir auf Yogas gesetzt: die sind klein
und leicht und man kann mit ihnen arbeiten, weil man eine echte Tastatur
hat und weil man Monitore und Beamer ohne Probleme anschließen kann.
In meiner Umgebung sinkt die Erkenntniss, dass iPads in Lehrerhand
einfach keine Arbeitsgeräte sind, langsam ein und unsere Kollegen werden
für die guten Geräte beneidet.
HDMI einstecken ist halt einfach super: viel besser als über irgend eine
drahtlose Verbindung in jedem Raum zu einem sau teuren Apple TV zu
verbinden.
Wer sich nicht von der Schickheit und dem Couchfaktor der Tablets
blenden läßt bemerkt: wirklich gut und unproblematisch damit arbeiten
geht halt nicht.
Nach meinem Verständnis: Wenn man einen neuen Muster-Client erstellt, partitioniert man mit Linbo und installiert dann Windows da rein. Das Windows-Setup erkennt die vorhandene EFI-Partition und installiert seine benötigten Dateien da rein. Dann hat man ein bootfähiges Setup. Es ist dann die Aufgabe der Linbo Image-Aufzeichnung dafür zu sorgen, dass der Inhalt der EFI-Partition auch auf anderen/neuen/leeren Rechnern der Image-Gruppe landet. Also wird der Inhalt schlicht nach C:\EFI kopiert und damit Teil des Images. Dann muss ein nagelneu ausgepackter Client beim „Heilen“ nur noch den Inhalt von C:\EFI wieder in die EFI-Partition kopieren.
Die Antwort auf deine Frage 1 wäre dann: Der Fall tritt nicht ein. Im Image sollte es immer einen Ordner c:\EFI geben, weil es Teil des Aufzeichnungsprozesses ist.
Ich kann mich auch irren. Ich habe es nicht im Code gelesen/überprüft, aber zumindest klingt diese Abfolge für mich logisch.
das C:\EFI Verzeichnis sollte immer mit im Image sein: da sollten
eigentlich keien Probleme sein.
Der Bootcode in der EFI Partition wird von linbo hergestellt.
Möglicherweise spielt da irgend wo die IMAGENAME.macct Datei eine Rolle:
das weiß ich leider nicht so genau.
Unter linbo wird aber auch
efibootmgr bemüht um in der EFI Partition das richtige BS als erstes in
die Bootreihenfolge zu nehmen.
Das ist aber nicht imemr ganz einfach, weil übereifrige EFI BIOSe da
gerne schlauer sind als was auf dem Rechner gemacht wird und dann
reinspucken beim nächsten Boot.
Manche haben auch im BIOS eine „lock bootorder“ Funktion, die die
Änderungen von efibootmgr blockieren: wenn man Glück hat, kann man das
ausschalten.
Ichhabe aber auch schon lenovolaptops auf dem Tisch gehabt, bei denen
das EFI Bios nur Betriebsysteme aus folgenden Verzeichnissen gebootet
haben (auf der EFI Partition):
/EFI/microsoft/
/EFI/redhat/
Kein Scherz!
Da aber der Bootloader von linbo im Verzeichnis /EFI/grub/ residierte,
konnte man linbo nur per PXE booten lassen (oder vom Stick).
Abhilfe schuf es, das Verzeichnis /EFI/grub/ um zu nennen in /EFI/redhat/
… das nur als Beispiel, wie sehr EFI BIOSe da reinspucken können.
Nicht alles was die da machen können wir umschiffen (leider).
ich habe den Quellcode mal überflogen und es ist im Grunde, wie Du sagst:
bei der Image-Erstellung wird C:\EFI als Kopie erstellt - das war ja bei mir auch vorhanden. Ich habe mich nur gefragt, ob man den Ordner z.B. testweise löschen könnte und er dann neu angelegt wird. Wird er - wenn ich damals Thomas richtig verstanden habe - erst bei der Image-Erstellung.
ich habe dennoch mal getestet, was passiert, wenn ich C:\EFI lösche, danach die EFI-Partition „repariere“ und versuche zu booten. Das geht nicht. Es werden (natürlich) keine Dateien kopiert (das führt auch zu einem „Fehler beim Kopieren“ im Log, aber der Boot schlägt auch hier im Anschluss fehl - vermutlich weil Linbo auf etwas verweist, was es nicht gibt. Warum das nicht geht, habe ich aber noch nicht 100% verstanden - ist aber auch nicht wichtig, weil das im Normalfall ja nicht vorkommt).
Das EFI-Backup wird bei jedem Start von C: zurückgespielt und dann der Startliste hinzugefügt (mit der nextboot-option von Grub) - es zählt also immer die Kopie auf C: (!), nicht der Inhalt der EFI-Partition.
spannend scheint dabei eh nur der BCD (Boot Configuration Data) zu sein. Wenn das nicht zum System passt, bootet es halt nicht. Und das erklärt auch das Scheitern einiger meiner Versuche: EFI zu reparieren bringt nichts, wenn danach ein defektes EFI von C:\ zurück kopiert wird.
was ich auch im Quellcode gelesen zu haben (und sehr interessant finde) ist, dass es verschiedene BCDs geben kann (jeweils mit der Endung .. - im Quellcode: bcd_backup="$bootdir"/BCD."$HOSTGROUP"."$partname"). Wenn das also so funktioniert, wie ich denke, dann kann man verschiedene BCDs für verschiedene HWK und Partitionsschemata in diesem Ordner sichern - das wäre richtig schön flexibel!
Ich bin jedenfalls in Sachen EFI/Linbo wieder etwas klüger und denke, damit bekomme ich evtl. nicht bootende Systeme zuverlässig in den Griff. Zumindest, wenn es so ist, wie ich schrieb
hier kann ich weitere Infos geben: Diesen Umstand hatten wir auch entdeckt, aber allein durch die Betrachtung der Dateinamen in C:\EFI. Wir haben sehr viele gleiche Rechner verteilt auf viele Räume und wir wollten die Räume separat steuern können (Autostart/Heilung an/aus). Daher haben wir in der WebGUI separate Image-Gruppen pro Raum gebildet, aber nur einen Muster-PC aufgezeichnet. Weil die Hardware in den verschiedenen Räumen identisch ist, haben wir auf unserem Muster-Rechner vor Aufzeichnung die Datei „$bootdir“/BCD.„$HOSTGROUP“.„$partname“ einfach mehrfach kopiert und statt der $HOSTGROUP die jeweilige Image-Gruppe des Raumes im Dateinamen eingefügt. So funktionieren ca. ein dutzend identisch ausgesttlte Räume mit dem selben Image in separaten Image-Gruppen.
