Hallo Carsten,
Da dürfte gemeint sein, daß man mit Linbo formatiert. Dann ist die Platte „leer“. Also formatieren, neu starten und die UEFI Einträge auflisten.
Viele Grüße
Klaus
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
GuMo!
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.
VG, Thomas
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
1 „Gefällt mir“
Hallo @thomas,
in den folgenden Zeilen fehlt jetzt wieder das /cache.
local win_efidir=„$(ls -d /boot/efi/[Ee][Ff][Ii]/[Mm][Ii][Cc][Rr][Oo][Ss][Oo][Ff][Tt]/[Bb][Oo][Oo][Tt] 2> /dev/null)“
win_efidir=„/boot/efi/EFI/Microsoft/Boot“
Daher werden die efiboot Dateien nicht mehr auf die EFI Partition kopiert.
Viele Grüße
Christian
1 „Gefällt mir“
1 „Gefällt mir“
Hallo @thomas ,
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.
Viele Grüße,
Jochen
Hallo Jochen,
Nein. Was ist, wenn du die 1x über BIOS grub booten lässt?
warmstart=no hilft.
VG, Thomas
Hallo Jochen,
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).
LG
Holger
Hallo,
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.
LG
Holger
Hallo @thomas und Holger,
die eine HWK (exone PCs mit AMD CPU) macht nun mit Linbo 4.0.27 Folgendes:
- wir stellen im UEFI einzig und allein PXE Boot ein.
- es startet Linbo
- anschließend steht grub an Position 1 (so weit ja ok aber:)
- rebooted man nun aus Linbo, erscheint - anders als bei 4.0.26 - folgende Fehlermeldung:
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.
Viele Grüße,
Jochen
Hallo @jochen,
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 -vblkid <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_cmdlinbo_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.
VG, Thomas
Hallo @thomas
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.
Viele Grüße
Klaus
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.
VG, Thomas
Ja, das funktioniert auch nach dem Formatieren noch.
Viele Grüße
Klaus
Sehr gut. 
Vielleicht genau das, was wir bei der einen HWK brauchen!? Teste ich kommende Woche.
Viele Grüße,
Jochen
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.
Danke und Gruß,
Jochen