gpart bootcode schlägt fehl nach zpool upgrade

Krull

Well-Known Member
Hallo,
ich habe vorhin ein 'zpool upgrade' auf meinem Laptop durchgeführt. Fehler wurden keine gemeldet. In diversen Netzbeiträgen habe ich gelesen, dass man anschließend unbedingt mit gpart den Bootcode aktualisieren muss, wenn man von diesem Pool weiterhin booten können möchte. Interessanterweise wird dieser Sachverhalt mit keinem Sterbenswörtchen in der Manpage oder vom Programm selbst erwähnt.

Nun ja, jetzt hat 'gpart bootcode' nicht funktioniert weil: "Operation not permitted". Vermutlich weil ich vergessen habe, kern.securelevel zu deaktivieren (stand zu diesem Zeitpunkt auf 2) und deshalb nicht roh auf die Platte geschrieben werden konnte. Ich nehme an Booten kann ich damit erst mal vergessen. Meine Idee ist jetzt, mit BSD 13.0 von einem USB-Stick zu starten (13.0 ist auch auf dem Laptop) und dann
Code:
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 adaX
auf die Platten in meinem Pool anzuwenden.

Kann das so funktionieren? Oder habe ich hier etwas wichtiges vergessen? Und kann ich hierfür das /boot-Verzeichnis vom Rettungssystem hernehmen oder muss es zwingend das /boot von meinem Laptoppool sein und dafür importiert werden? Ich lasse den Rechner erstmal noch eine Weile laufen, sonst komme ich vielleicht nicht mehr ins Internet :D
 
Interessanterweise wird dieser Sachverhalt mit keinem Sterbenswörtchen in der Manpage oder vom Programm selbst erwähnt.
ZFS on FreeBSD gab nach dem zpool upgrade eine Meldung aus, aber vielleicht ist die mit OpenZFS unter den Tisch gefallen.

Kann das so funktionieren?
Ja, das wird so funktionieren. Aber stelle auf jeden Fall sicher, dass Partitionsindex 2 auch wirklich die freebsd-boot Partition ist. Den Anfang vom Dateisystem zu überschreiben dürfte ziemlich destruktiv sein :) Und wenn es ein EFI-System ist, wäre der Weg völlig anders. Dann muss man die EFI-Partition mounten und dort den Loader austauschen. Es soll demnächst(tm) ein Script geben, was das automagisiert.
 
Kann das so funktionieren?
Ja. Aber guck genau welche Partition, die 'zweite' erscheint mir hier suspekt.

Edit:
vielleicht ist die mit OpenZFS unter den Tisch gefallen.
Nope, die erscheint noch. Eigentlich jedes Mal, sobald man was mit zroot macht.
Ich habe auch getestet, ob man von einem nachträglich auf zstd umgetestellten zroot booten kann, funktioniert tadellos. (irgendwo hatte ich da eine Warnung aufgeschnappt)
 
Danke für die flotten Rückmeldungen. Ich mag meine Hand dafür lieber nicht ins Feuer legen, aber mir ist jedenfalls kein Hinweis auf gpart bootcode aufgefallen. Wobei es mir in diesem Fall auch gar nicht weitergeholfen hätte ^^

Ich habe es jetzt so verstanden, dass ein 'zpool import' nicht notwendig ist und das /boot vom Rettungssystem genommen werden kann.

Die zweite Partition sollte für mich die Richtige sein. Da liegt die Bootpartition drauf:
Code:
# gpart show ada0 ada1  
=>       40  488397088  ada0  GPT  (233G)
         40     409600     1  efi  (200M)
     409640       1024     2  freebsd-boot  (512K)
     410664        984        - free -  (492K)
     411648    4194304     3  freebsd-zfs  (2.0G)
    4605952    4194304     4  freebsd-swap  (2.0G)
    8800256  479596544     5  freebsd-zfs  (229G)
  488396800        328        - free -  (164K)

=>       40  488397088  ada1  GPT  (233G)
         40     409600     1  efi  (200M)
     409640       1024     2  freebsd-boot  (512K)
     410664        984        - free -  (492K)
     411648    4194304     3  freebsd-zfs  (2.0G)
    4605952    4194304     4  freebsd-swap  (2.0G)
    8800256  479596544     5  freebsd-zfs  (229G)
  488396800        328        - free -  (164K)
 
So wie es partitioniert, ist es beides. Aber ich glaube, dass das der Installer inzwischen automagisch so anlegt. sysctl machdep.bootmethod zeigt an, wie das aktuell laufende System gebootet wurde.
 
Die Operation war erfolgreich, die Kiste bootet so wie es sein soll. Danke nochmals für euren Beistand!

PS: Kann man ein zpool upgrade eigentlich mit einem zpool checkpoint ggf. wieder rückgängig machen?
 
AAAAARRRGH: Es geht doch nicht so ohne weiteres. Beim ersten Boot hat es noch geklappt. Bei weiteren Bootversuchen bekomme ich bloß:
Code:
 Reboot ans Select proper Boot Device or Insert Boot Media in selected Boot device an press a key

Wie kann das denn sein, dass es beim 1. Mal geht und dann reproduzierbar nicht mehr?? Jetzt hilft es auch nicht mehr, gpart bootcode vom Rettungssystem auszuführen. Hab's mehrfach probiert - ohne Erfolg (immer auf die 2. Partition, immer auf beide Platten). Die Festplatten sind im BIOS auch wieder als die ersten beiden Bootmedien eingetragen.
 
Was mich jetzt am ehesten interessiert: kennt jemand für diesen Fall einen "Trick", den man hier noch anwenden könnte? Oder bleibt hier nicht anderes mehr übrig, als eine komplette Neuinstallation?
 
Ka, was da jetzt schiefging. :(
Hab's mehrfach probiert - ohne Erfolg (immer auf die 2. Partition, immer auf beide Platten)
Das nur auf eine Platte wäre ein Trick gewesen.

Der zweite Trick wäre legacy/MBR (manchmal brauchts dazu 2-3 Einstellungen, damit das insgesamt wirkt) im BIOS zu aktivieren und nochmal versuchen.
 
Du hast die wichtigste Frage immer noch nicht beantwortet: Wird das System über UEFI oder klassisch gebootet?
Wenn UEFI, dann war das Aktualisieren des Bootcodes in der freebsd-boot-Partition unnötig. Hier muss dann der loader in der EFI-Partition aktualisiert werden.

Rob
 
Du hast die wichtigste Frage immer noch nicht beantwortet: Wird das System über UEFI oder klassisch gebootet?
Wenn UEFI, dann war das Aktualisieren des Bootcodes in der freebsd-boot-Partition unnötig. Hier muss dann der loader in der EFI-Partition aktualisiert werden.

Rob
Im 'BIOS' ist UEFI enabled, Secure Boot ist disabled. Das war ein guter Hinweis. Wenn UEFI deaktiviert ist, kann ich wieder booten!

Also wenn ich jetzt
Code:
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 adaX
mache, könnte es auch mit EFI wieder klappen?
 
Ne, das müsste der für BIOS sein, für UEFI ist es laut meinen Notizen gpart bootcode -p /boot/boot1.efi -i1 ada0.

Hab gerade nochmal in Installing FreeBSD Root on ZFS using GPT geschaut, vielleicht hilft das?
Code:
# ...
 # prior to FreeBSD 12.x
 gpart bootcode -p /boot/boot1.efifat -i 1 ada0
 # for FreeBSD 12.x and up, create a FAT32 partition
# ...
 mount -t msdosfs -o longnames /dev/ada0p1 /mnt
# ...
 cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi
 
Hmmm, und was macht man, wenn die loader.efi zu groß ist?
Code:
$ sudo cp loader.efi /mnt/efi/boot/BOOTx64.efi  
cp: /mnt/efi/boot/BOOTx64.efi: No space left on device
$
$ ls -l /mnt/efi/boot/BOOTx64.efi 
-rwxr-xr-x  1 root  wheel  393216 13 Sep.  2017 /mnt/efi/boot/BOOTx64.efi
$
$ ls -l /boot/loader.efi   
-r-xr-xr-x  2 root  wheel  896000 14 Jan. 17:47 /boot/loader.efi
$
$ df -T | grep msdosfs 
/dev/ada1p1         msdosfs       779       386       393    50%    /mnt
$
$ gpart show ada1 | grep efi 
         40     409600     1  efi  (200M)

Das sieht alles irgendwie merkwürdig aus. Die loader.efi ist mehr als doppelt so groß, wie die BOOTx64.efi, das FAT-Dateisystem ist sehr klein (<1 M), obwohl die EFI-Partition 200 M hat. ??? Das verhält sich bei ada0 und ada1 identisch.

Bei Linux gibt/gab es mal ein fatresize... bei BSD finde ich da nichts entsprechendes...
 
Das sieht alles irgendwie merkwürdig aus. Die loader.efi ist mehr als doppelt so groß, wie die BOOTx64.efi, das FAT-Dateisystem ist sehr klein (<1 M), obwohl die EFI-Partition 200 M hat. ??? Das verhält sich bei ada0 und ada1 identisch.
Das liegt daran, dass irgendwo auf dem Weg der UEFI-Bootrprozess nochmal umstrukturiert wurde. Ältere Setup haben diese sehr kleine EFI-Partition, dort kannst du boot1.efi als Loader raufkopieren. Der frickelt sich dann loader.efi aus /boot, lädt den und übergibt die Kontrolle.

Nachtrag: Andererseits sind die Bootloader durch die GELI-Integration wirklich sehr groß geworden. Ich hatte beim Update 13.0 diverse Systeme, wo meine freebsd-boot Partition zu klein war. Zum Glück lag direkt daher die Swap, weshalb ich umpartitionieren konnte.
 
Das liegt daran, dass irgendwo auf dem Weg der UEFI-Bootrprozess nochmal umstrukturiert wurde. Ältere Setup haben diese sehr kleine EFI-Partition, dort kannst du boot1.efi als Loader raufkopieren. Der frickelt sich dann loader.efi aus /boot, lädt den und übergibt die Kontrolle.

Das war's! Mit boot1.efi läuft auch der UEFI-Boot wieder wie am Schürchen. Hab dieses Mal auch zweimal neu gestartet. Sicher ist sicher ^^

Vielen Dank an alle; mit vereinten Kräften hat's dann doch noch geklappt! Und ein bissl was Neues gelernt habe ich dabei sogar auch noch...
 
du könntest, ah, schon zu spät. Hat ja schon geklappt.
Also, du hättest auch können:
  • FAT16 neu formatieren, statt FAT32, aber ich nehme lieber FAT32 und eine größere EFI-SP
  • neu partitionieren, denn außer der ESP und der ZFS-Root (und evtl SWAP), brauchst du nichts zum Booten.
  • die ESP auf einen Stick anlegen und von dem booten, nicht sehr elegant, aber...
 
du könntest, ah, schon zu spät. Hat ja schon geklappt.
Also, du hättest auch können:
  • FAT16 neu formatieren, statt FAT32, aber ich nehme lieber FAT32 und eine größere EFI-SP
  • neu partitionieren, denn außer der ESP und der ZFS-Root (und evtl SWAP), brauchst du nichts zum Booten.
  • die ESP auf einen Stick anlegen und von dem booten, nicht sehr elegant, aber...
Neben EFI und ZFS-root brauche ich leider auch noch den ZFS-bootpool auf adaXp3. Als ich dieses System aufgesetzt hatte, konnte der UEFI-Bootloader leider noch keine verschlüsselten ZFS-Pools starten.

Beim alten BIOS war das ja ähnlich. Da brauchte ich früher auch eine Zeit lang eine unverschl. Partition für /boot. Irgendwann war der Bootloader dann schlau genug um Geli-Container aufzumachen, und ich konnte mit einer Umbauanleitung (finde sie leider nicht mehr) sogar das alte /boot wegwerfen. Gibt es so ein Howto evtl. auch für den UEFI-Loader? (wobei ich nicht so recht weiß, ob ich das nach dem heutigen Tag sofort ausprobieren würde ;) )
 
Zurück
Oben