Bootloader update

carbuncle

carbuncle

Rainbow Six
Moin,

ich hatte von FreeBSD 13.3 auf 14.2 Release upgedated. Soweit, so gut. Danach hatte ich ein zpool upgrade ausgeführt. Bisher noch kein Neustart gemacht. Jetzt musste ich den bootcode updaten damit er mit der neuen Pool Version zurecht kommt. Dafür habe ich folgendes Skript genommen:

github.com

zfs-update-boot/zfs-update-boot.sh at main · morganwdavis/zfs-update-boot

Updates FreeBSD ZFS EFI and legacy boot code on GPT devices - morganwdavis/zfs-update-boot
github.com github.com

Allerdings hat das Skript bei mir abgebrochen weil in /boot/efi/boot die startup.nsh fehlt. Laut diesem Reddit Eintrag:

Reddit - The heart of the internet

www.reddit.com www.reddit.com

müsste in der startup.nsh quasi nur "bootx64.efi" stehen. Ich habe die mal so angelegt und das Skript ist dann auch fehlerfrei durchgelaufen. Er hat mir quasi den alten (BIOS) bootcode upgedated und danach den loader auf der efi Partition. Jeweils für beide Platten.

Habe ich irgendwas ganz entscheidendes vergessen bevor ich jetzt einen reboot mache? Wie kann ich checken ob ich im Moment im uefi mode oder BIOS legacy mode bin? Der Server läuft schon lange, ich kann mich nicht mehr erinnern :).
 
Ich muss mich gerade mal selbst korrigieren. Das Skript legt ja sogar selbst die startup.nsh an in Zeile 119. Die Datei hatte ich vorher nicht. Die Frage ist jetzt ob ich überhaupt über uefi boote..
 
startup.nsh ist sowas von egal... Ich hatte noch nie Hardware, die es gebraucht hätte:

  • Der einzige korrekte Weg ist sich mit efibootmgr einen Starteintrag im NVRAM zu erstellen.
  • Bis auf ganz, ganz, ganze wenige Ausnahmen gibt es praktisch immer ein Fallback auf den Pfad des Windows Bootloaders aufs \EFI\BOOT\BOOTX64.EFI

Der Fallback ist nicht standardisiert, aber die einzige Hardware, die ich je in den Händen hatte, die ihn nicht hatte, war ein Supermicro-Board von ca. 2011 mit der ersten verbuggten UEFI-Generation... Davon abgesehen habe ich unter Schmerzen gelernt, dass in meine Rechenzentrumstasche ein Boot-Stick gehört, mit dem ich zur Not Bootcode neu schreiben kann.

Ich würde in deiner Stelle nochmal schauen, ob dein /boot/efi/boot/bootx64.efi einen aktuellen Timestamp hat. Wenn du ganz paranoid bist, könntest du noch mal schauen, ob es die gleiche Checksum wie /boot/loader.efi hat. Letzteres unter der Voraussetzung, dass es kein altes Setup mit dem Shim-Loader ist...
 
ein funktionierendes Script hatte @Kamikaze dazu geschrieben, lässt sich bestimmt hier noch ein Beitrag dazu finden.

Yamagi schrieb:
startup.nsh ist sowas von egal... Ich hatte noch nie Hardware, die es gebraucht hätte:

  • Der einzige korrekte Weg ist sich mit efibootmgr einen Starteintrag im NVRAM zu erstellen.
  • Bis auf ganz, ganz, ganze wenige Ausnahmen gibt es praktisch immer ein Fallback auf den Pfad des Windows Bootloaders aufs \EFI\BOOT\BOOTX64.EFI
Zum Vergrößern anklicken....
oder, wenn ich nicht ganz daneben liege, auch anders ausgedrückt:
wenn du eh nur ein System bootest, sollte das in den allermeisten Fällen automagisch das System aus \EFI\BOOT\BOOTX64.EFI booten und wenn hier das neue boot64.efi aus /boot/loader.efi des aktuellen FreeBSD liegt (also die Datei entsprechend umbenannt nach /efi/boot kopiert wird), dann sollte auch dein FreeBSD mit dem neuen ZFS booten können.
Das Nvram liest dann dieses Eintrag und folgt ihm.
 
pit234a schrieb:
wenn du eh nur ein System bootest, sollte das in den allermeisten Fällen automagisch das System aus \EFI\BOOT\BOOTX64.EFI booten und wenn hier das neue boot64.efi aus /boot/loader.efi des aktuellen FreeBSD liegt (also die Datei entsprechend umbenannt nach /efi/boot kopiert wird), dann sollte auch dein FreeBSD mit dem neuen ZFS booten können.
Zum Vergrößern anklicken....
Du hast das viel besser als ich ausgedrückt :) Es ist halt der Pfad des Windows-Bootloaders und daher haben die aller-allermeisten Hersteller ein stumpfes Fallback drin: "Wenn nichts anderes zum Booten da, nehme stumpf \EFI\BOOT\BOOTX64.EFI"
 
Danke an alle! Md5 Summe von bootx64.efi gecheckt. Neu gebootet, Patient lebt.

Hätte aber irgendwie erwartet dass freebsd-update das macht. Denn das will man ja eigentlich immer.
 
carbuncle schrieb:
Hätte aber irgendwie erwartet dass freebsd-update das macht. Denn das will man ja eigentlich immer.
Zum Vergrößern anklicken....
Ja. Aber der weiß ja im Zweifel gar nicht, wie Deine Boot-Konfiguration ist. Gibt ja 1000 Arten zu booten und nicht es lässt sich auch nicht immer eindeutig feststellen, welche Methode Du benutzt. Und dann kann eine Automatik in freebsd-update Dir auch was kaputt machen.
Insofern gibt es schon nachvollziehbare Gründe es nicht zu tun.
Auf der anderen Seite könnte das Update aber zumindest 'ne Abfrage machen a-la "Wenn Du hier ein Standard-Setup fährst, würde ich für Dich den Loader überprüfen und ggf. aktualisieren (Y/N)?"
 
Andy_m4 schrieb:
Ja. Aber der weiß ja im Zweifel gar nicht, wie Deine Boot-Konfiguration ist. Gibt ja 1000 Arten zu booten und nicht es lässt sich auch nicht immer eindeutig feststellen, welche Methode Du benutzt. Und dann kann eine Automatik in freebsd-update Dir auch was kaputt machen.
Insofern gibt es schon nachvollziehbare Gründe es nicht zu tun.
Auf der anderen Seite könnte das Update aber zumindest 'ne Abfrage machen a-la "Wenn Du hier ein Standard-Setup fährst, würde ich für Dich den Loader überprüfen und ggf. aktualisieren (Y/N)?"
Zum Vergrößern anklicken....
Stimmt schon. Dein letztgenannter Punkt wäre eine Option.
 
Kamikaze

Beitrag im Thema '[CfT] BSDA2: loaderupdate'

Ich habe gestern den aktuellen Stand gepusht. Jetzt gibt es auch einen README.md Abschnitt:

github.com

GitHub - lonkamikaze/bsda2: BSD Administration Scripts v2

BSD Administration Scripts v2. Contribute to lonkamikaze/bsda2 development by creating an account on GitHub.
github.com github.com

Hier ist noch mal die Anleitung zum Testen:
Code: 
# fetch https://github.com/lonkamikaze/bsda2/archive/master.tar.gz
# sha256 master.tar.gz
SHA256 (master.tar.gz) = 637564205549d43f0bb6e458ce7bec119ba42cd400e675d3fbfcc633091eac09
# tar -xf master.tar.gz
# cd bsda2-master/
# src/loaderupdate -Pa
Boot Environment               
----------------            
destdir:                /   
ostype:                 FreeBSD
kernel version:         FreeBSD...
dazu vielleicht mal diesen älteren Thread ansehen. Da werden wohl dann schon einige Probleme oder unterschiedliche Sichtweisen deutlich.
 
Andy_m4 schrieb:
Wobei an freebsd-update selbst wohl keiner mehr großartig was machen wird, weil die Zukunft klar in Richtung PkgBase geht.
Zum Vergrößern anklicken....
PkgBase (oder PKGBASE oder pkgbase) wird mit FreeBSD 15.0 kommen. Es ist meines Wissens noch nicht entschieden, ob die klassischen Distributionssets und damit freebsd-update noch einen Hauptversionszyklus mit durchgezogen wird oder nicht. Wie ich FreeBSD kenne, aber wahrscheinlich ja.

Wir werden in unserer News zu FreeBSD 14.3 in sehr naher Zukunft auch explizit erwähnen, dass man klassisch installierte Systeme nun auf PkgBase konvertieren - mit https://github.com/FreeBSDFoundation/pkgbasify - und PkgBase ab sofort nutzen kann.
 
lme schrieb:
Es gibt auch noch sysutils/loaders-update. Damit geht das Update des Loaders auch recht einfach:

loaders-update show-me zeigt an, was gemacht werden würde.
loaders-update shoot-me installiert dann den neuen Loader.
Zum Vergrößern anklicken....
Der output von loaders-update show-me sieht zumindest vertrauenserweckend aus. Es erkennt sogar die EFI-Einträge von meinem Skript.

Es liegt in der Natur der Sache, dass ich mein Skript besser finde, schließlich macht es das genau so wie ich mir das vorstelle. Inklusive den Text für den EFI Eintrag aus einem noch nicht gebooteten Kernel zu generieren.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben