OK, das krieg ich noch hin…
also folgende Ausgabe mit im zurückgesetztem UEFI (ausschließlich Windows bootet, via Boomten ist auch PXE und grub auswählbar): IMG_0697|666x500
Dieselbe Ausgabe erhalte ich nach dem Formatieren mit Linbo.Nachdem jetzt (via linbo) Windows neu installiert bootet Linbo und ich erhalte ich einen veränderten Eintrag: Der grubeintrag steht nun hinter Boot0000*, der Windowseintrag fehlt vollständig, es geht also mit dem Setup-Eintrag unter Boot0010 unverändert weiter.
Im UEFI befinden sich zu diesem Zeitpunkt noch alle Auswahloptionen (außer namentlich Windows), alle Laufwerke und PXE sind auszahlbar. Dies ändert sich, wenn ich erstmalig in linbo versuch Windows zu starten (nur starten). Anschließend wird erneut linbo gebootet und im UEFI sind alle Bootoptionen außer grub verschwunden. Unter linbo erhalte ich dennoch dieselbe efibootmge-Ausgabe wie zuvor.
Mit besten Grüßen
Carsten
Doch. Der Grub-Eintrag verweist auf die korrekte UUID der EFI-Partition. Das wäre allerdings nicht mehr so, wenn neu partitioniert würde. v4.0.23 ist da auch noch fehlerhaft. Merkt man halt nicht immer.
Tipp: Du kannst dich per linbo-ssh auf den Client einloggen, dann lassen sich Konsolenausgaben einfach per Copy&Paste teilen.
Hallo Thomas,
stimmt hatte ich glatt übersehen. Hilft halt doch, wenn man weiß, wo man suchen muss…
Danke für den Tipp, leider habe ich von diesem Verwaltungsrechner hier keinen ssh-Zugriff auf das andere Netzwerk, weshalb das leider so nicht ging. Daher die Behelfslösung mit den Bildern…
Grüße
Carsten
ich will ja nicht unken aber mit 4.0.27 macht nun wieder eine unserer HWK Probleme, die vorher funktionierte. Probleme heißt, Windows schiebt sich wieder an die erste Stelle und es bootet nicht standardmäßig Linbo.
Kann es sein, dass die Einträge, die @Blair helfen, bei uns Probleme verursachen und andersherum?
Die andere HWK hat dieses Problem nicht, dafür frieren dort die Rechner, wenn eine neue Linbo-Version kommt, beim Linbo-Start ein und man muss sie hart aus- und wieder einschalten bevor sie dann die neue Linbo-Version booten. Nervig, weil Turnschuh-Administration aber immerhin funktionieren sie danach wie gewünscht.
Die andere HWK hat dieses Problem nicht, dafür frieren dort die Rechner,
wenn eine neue Linbo-Version kommt, beim Linbo-Start ein und man muss
sie hart aus- und wieder einschalten bevor sie dann die neue
Linbo-Version booten. Nervig, weil Turnschuh-Administration aber
immerhin funktionieren sie danach wie gewünscht.
das kann man verhindern duch den Append Parameter
warmstart=no
(import danach machen und sicherstellen, dass die
/srv/linbo/boot/grub/GRUPPE.cfg
vom import geschrieben werden kann).
Die andere HWK hat dieses Problem nicht, dafür frieren dort die Rechner,
wenn eine neue Linbo-Version kommt, beim Linbo-Start ein und man muss
sie hart aus- und wieder einschalten bevor sie dann die neue
Linbo-Version booten. Nervig, weil Turnschuh-Administration aber
immerhin funktionieren sie danach wie gewünscht.
… ach so: Turnschuh ist aber sowiso nicht nötig: linbo-ssh geht in dem
Zustand trotzdem: der Client hängt nciht, er zeigt nur die GUI nicht an.
und anschließend startet Windows. (obwohl nach wie vor grub an erster Stelle steht).
Die andere HWK (exone PCs mit Intel CPU) verhält sich anders, dort wird der Windows Boot Manager an die erste Stelle geschrieben, da waren wir mit einigen der letzten Linbo-Versionen schon mal weiter.
tut mir leid, das zu lesen, aber hier auf meinen UEFI-Systemen kann ich das nicht nachvollziehen. Beim Windows-Sync werden die Partitions-UUIDs von EFI- und Windowspartition auf die Werte des Mastersystems gesetzt, beim Windows-Start werden die Windows-EFI-Bootdateien auf die EFI-Partition nach EFI/Microsoft/Boot kopiert und ein efibootmgr-Eintrag für „Windows Boot Manager“ erstellt, der auf den Bootloader "EFI/Microsoft/Boot/bootmgfw.efi auf der EFI-Partition verweist. Dieser Eintrag wird als BootNext markiert, dann rebootet. Läuft auf hier und woanders auch, denke ich, sonst hätten wir hier schon einen grandiosen Shitstorm.
Der Unterschied von 4.0.26 zu 4.0.27 besteht allein darin, dass der falsche Pfad /boot/efi nach /cache/boot/efi korrigiert wurde, d.h. unter 4.0.26 wurden die Windows-EFI-Bootdateien beim Start nicht auf die EFI-Partition kopiert. Heißt weiter, deine Systeme haben von einem Fehler profitiert. Hier müsste man weiter suchen.
Hilfreich beim Debuggen sind div. Konsolenausgaben von betroffenen Systemen.
Booteinträge:
efibootmgr -v
blkid <efipartition>
Ausgabe von LInbo-Update:
rm /tmp/.*
linbo_cmd update <serverip> <cachepartition>
Ausgabe des Linbo-Startbefehls, hierzu muss zunächst der Reboot abgeschaltet werden:
sed -i 's|reboot -f|echo no reboot|' /usr/bin/linbo_cmd
linbo_wrapper start:1
Bewirken die Linbo-Kernelparameter
forcegrub (bootet zuerst grub, welches dann das OS bootet, umgeht UEFI)
noefibootmgr (überspringt das Bereitstellen der EFI-Bootdateien und Booteinträge, simuliert quasi oben erwähnten Fehler)
eine Verhaltensänderung?
Reboot ohne/mit Linbo-Start/Sync? Hatten wir IMO schon, hier findet das BIOS die Cachepartition nicht.
vielen Dank erstmal für die Schilderungen der Abläufe beim Bootprozess und für die Möglichkeiten des Debugging.
Ich habe also auch alles durchgespielt und kann nur sagen, daß alles läuft, wie es soll. Also zumindest in meiner Virtualbox Testumgebung. Genial ist noefibootmgr. Ohne den Parameter schiebt sich der Windows Boot Manager wieder an die erste Stelle. Setzte ich den Parameter ein, bootet zuverässig grub und dieser dann Windows.
Bei meinen Tests hatte ich den PC vorher formatiert, so daß auch die EFI Partition leer war. Ebenso hatte ich mit efibootmgr grub und Windows Bootmanager gelöscht.
Ich bin gespannt, wie sich das auf den verschiedenen Hardwareklassen verhält.
Hatte ich nicht mehr auf dem Schirm, dass ich den Parameter für den Zweck ja implementiert hatte. Jahre ists her. Muss ich noch dokumentieren. Die Frage ist, ob das nach einer Neuformatierung der HD noch funktioniert.
noefibootmgr rulez!
Jetzt müssen wir nur noch die andere HWK zähmen…
[Edit]: so, alle HWK scheinen™ jetzt mit 4.0.27 so zu funktionieren, wie sie sollen.
bei Desktop-Rechnern Dell Optiplex 3080 gab es irgendwann auf der EFI-Partition auch noch ein Verzeichnis Dell mit Recovery-Daten. Das musste ich auch löschen, damit ein booten von lokaler NVMe möglich war und Linbo lokal von Festplatte sauber geladen wurde.
Gab es noch den Windows Booteintrag oder das Dell-Verzeichnis, dann gab es auch die Fehlermeldung mit invalid filename ‚dhcp‘. Allerdings ergab sich dann der günstige Zufall, dass nach dem Timeout von ca. 10 Sekunden (oder Enter-Taste) der Windows Bootloader als nächstes versucht wurde und Windows doch startete. Man hatte dann aber keine Möglichkeit zur Steuerung, da Linbo nie sauber geladen wurde.
