Upgrade von 12.3 auf 14.1 hängt bei "Cannot identify running kernel"

[turrican]

Gut, aber wenn wir damit ein root on zfs haben, dann brauchte doch ein Upgrade des zpool danach den passenden gpart bootcode?

ja, das wird nach meinem Verständnis so sein - wenn neuer Bootcode im Update da ist; das muß aber ggf nicht der Fall sein;
diesen Code müssteste dann händisch auf der 2. Platte nachpflegen, da beim Update nur die erste angefaßt würde (über den Mount, welchen wir allerdings stillgelegt hatten)

steht der aber bei Fritz Müller in 120km weg, fährst Du die 240km hin und zurück

die Gefahr dabei ist auch, dass man bei einer solchen Konstellation (Update nur auf 1. Platte durchgeführt) ggf vergißt, den EFI Code auf der 2. Platte manuell nachzuziehen - und dann bei Ausfall der 1. Platte und Rechnerneustart wirklich in den Wagen steigen muss...

 

[peterle]

Zunächst: es schadet nicht, bei der Installation bereits GPT+UEFI auszuwählen, denn das ist ein kleiner Fallback. Man muss aber dann GPT und EFI jeweils neu schreiben (oder das adminscript walten lassen, vorher dry mode hilft fürs Verständnis.)


Du ziehst die Systemupdates rein, kernel, userland, ports. Ab dann kannst du 'neuen' bootcode schreiben, weil dieser mit den Updates kam. Entweder brauchst du diesen (selten), wenn es hervorgehoben dabeisteht um die Updates zu vervollständigen zwischen den reboots, aber spätestens nach den Updates und vor dem zpool upgrade, solltest du ihn schreiben. Du kannst auch erst zpool upgrademachen, aber dann darf kein reboot/crash passieren, bis du den neuen bootcode geschrieben hast.
Es ist nicht schädlich, wenn man ihn mehrmals (über)schreibt, lieber einmal zuviel neu geschrieben als kein reboot mehr.

OK, dann gehört zu einem
-> Upgrade von FreeBSD ein Blick in /boot/efi und was er da reingemalt hat, kommt auf die EFI-Partitionen der Platten
-> bei einem zpool upgrade machen wir wie gehabt bei EFI ein gpart bootcode -p /boot/boot1.efi -i1 adaX auf allen Platten.

Zumindest, wenn ich das hier heranziehe: https://forums.freebsd.org/threads/how-to-restore-boot-loader.62390/

So richtig?

 

[turrican]

hier wäre zumindest ein getestetes Kochrezept zum Update von 13 auf 14 beschrieben

 

[pit234a]

gpart bootcode -p

afair hatte eben das ja nicht mehr funktioniert, ich müsste meine Mitschriften nachlesen, was aber schon alleine deshalb unergiebig sein würde, weil das sich alles auf inzwischen vergangene Versionen bezieht.
Habe trotzdem nachgesehen und lese, dass ich mich da irre:

# [CODE]gpart bootcode -b /boot/pmbr

-p /boot/boot1.efifat -i 1 da0
war früher.
leider hat man den boot1.efifat entfernt und muss nun manuell seine EFI-SP einrichten[/CODE] boot1.efifat != boot1.efi, ich liege also irgendwo falsch.
Weil man das aber zumindest eine Weile manuell machen musste, hat auch @Kamikaze sein Script geschrieben, um uns die Arbeit zu erleichtern.

Die volle EFI-Boot-Magie liegt im /boot/loader.efi
Mehr braucht man dazu nicht.
Es ist irgendwann mal größer geworden und passte nicht mehr gut auf die alten, automatisch von bsd-install angelegten EFI-Partitionen (Dateisysteme), weshalb hier wieder Handarbeit notwendig wurde und mir den Schritt nahe legte, ausreichend große EFI-Partitionen in FAT32 zu formatieren und zu benutzen.

Ich weiß nun also gar nicht, was gpart bootcode -p überhaupt macht und ob es auch bei EFI taugt. Ich hatte es zuletzt mit MBR benutzt (btw: GPT != EFI, es ist allermeist gleichzeitig, aber hat im Grunde nichts miteinander zu tun).
Ich weiß das eben deshalb auch nicht, weil es doch so überaus einfach ist, manuell die EFI zu mounten und die eine Datei /boot/loader.efi hierhin zu kopieren (in meinem Fall mit neuem Namen, weil ich nur die bootx64.efi benutze).

In meinem Codeschnipsel von oben:

gpart bootcode -b /boot/pmbr

sieht man auch, dass ich da einen pmbr schreiben möchte. Anstelle des alten MBR, benutzt GPT einen PMBR, der quasi nichts sonst macht, als die Platte für andere Systeme als besetzt kennzeichnet. Für die Funktion innerhalb von FreeBSD ist dieser PMBR vollkommen uninteressant. Man geht am einfachsten gleich auf GPT und nutzt eine EFI-Partition und denkt nicht mehr an früher.
Auf die weiteren Möglichkeiten und Kombinationen will ich hier verzichten, weil sie nichts mit FreeBSD zu tun haben und meist auch obsolet sind. Aber man könnte einen echten MBR anstelle des PMBR schreiben und dann ein System schaffen, das sowohl von EFI als mit MBR gebootet werden kann. Macht bei fest installierten System keinen Sinn und wir vergessen das am liebsten.
Das Leben ist deutlich einfacher, wenn wir nur FreeBSD von EFI booten wollen und dazu GPT partitionieren.
Sobald wir eine taugliche EFI-System_Partition haben, brauchen wir sonst keine weitere Boot-Magie, als das loader.efi.

 

[turrican]

Ich habe das glaube ich noch nicht so richtig verstanden, wie das dann mit dem EFI läuft.

• nach dem Einschalten des Rechners wird die eingebaute UEFI-Firmware aufm Board aktiv;
• die sucht der Reihe nach die hinterlegte Bootreihenfolge ab (meist ist das ja ein eingebauter Bootmanager, man könnte noch selber ne Auswahl treffen);
• bei FreeBSD findet sie die Datei bootx64.efi (*), den FreeBSD UEFI Bootloader;
• ab jetzt übernimmt der FreeBSD UEFI Bootloader das Regiment und sucht den Kernel-Loader loader.efi;
• dieser kennt den installierten Kernel und weiß mit zfs umzugehen (ein neuer Loader könnte somit das "alte" zfs booten aber nicht umgekehrt);
• der loader.efi sucht nun auf dem zfs den Bootkernel und startet diesen; ab da übernimmt der FreeBSD Kernel das Heft;

(*) mit bootx64.efi und loader.efi könnts auch genau andersrum sein, die beiden verwechsel ich immer, ich meinte aber, dass diese Reihenfolge stimmt

 

[pit234a]

mit bootx64.efi und loader.efi könnts auch genau andersrum sein

es braucht in der EFI (bisher) definitiv nur die bootx64.efi die auch identisch ist, zur loader.efi
Die loader.efi in der EFI ist Luxus, aber nicht notwendig.

Die EFI-Spezifikation geht ja davon aus, dass viele verschiedene Systeme aus der EFI gebootet werden können, die dann jeweils ihren eigenen Loader haben. Verzichtet man hierauf, genügt ein passendes Loader-File für sein System.

 

[KobRheTilla]

• bei FreeBSD findet sie die Datei bootx64.efi (*), den FreeBSD UEFI Bootloader;
• ab jetzt übernimmt der FreeBSD UEFI Bootloader das Regiment und sucht den Kernel-Loader loader.efi;

Das ist IMHO falsch. Es gibt einen generischen Pfad für den Loader, dieser ist z.B. für amd64-Systeme /efi/boot/bootx64.efi. Für Freebsd ist der Pfad /efi/freebsd/loader.efi vorgesehen. Das muss aber mit efibootmgr entsprechend eingerichtet werden.

Wenn man /boot/loader.efi also auf der ESP als /efi/boot/bootx64.efi ablegt, ist das alles. Dann wird nicht nochmal der andere Loader ausgeführt, sondern der FreeBSD-Boot startet dann direkt über bootx64.efi.

Rob

 

[pit234a]

Das ist IMHO falsch. Es gibt einen generischen Pfad für den Loader, dieser ist z.B. für amd64-Systeme /efi/boot/bootx64.efi. Für Freebsd ist der Pfad /efi/freebsd/loader.efi vorgesehen. Das muss aber mit efibootmgr entsprechend eingerichtet werden.

Wenn man /boot/loader.efi also auf der ESP als /efi/boot/bootx64.efi ablegt, ist das alles. Dann wird nicht nochmal der andere Loader ausgeführt, sondern der FreeBSD-Boot startet dann direkt über bootx64.efi.

Rob

so wollte ich das auch sagen

 

[peterle]

Habt herzlichen Dank für die Begleitung. Das ist echt top mit Euch hier.

 

[mr44er]

Am sichersten ist es, /var/log/bsdinstall_log anzugucken und festzustellen, was damals gemacht wurde. Das prüfen wir dann gegen gpart showab.

'Vorher' also ohne EFI war das so (man beachte, -i 1 ist keine EFI-Partition):

FreeBSD - Festplatte im Root ZFS Pool wechseln

Ich plane irgendwann in der Zukunft den Betrieb meiner Server von Debian auf FreeBSD umzustellen. Auch wenn meine Bemühungen FreeBSD auf meinem Thinkpad X201 zu installieren immer noch am Suspend/Resume scheitern habe ich jetzt über Freenas schon einiges an Erfahrungen sammeln können. Da hier kei...

www.hagen-bauer.de

Vollzieht man ein resilver oder upgrade eines bootpools, kommt immer der wohlwollende Hinweis mit Beispiel (die richtige Partitionsnummer und das richtige device zeigt das Beispiel nicht).
Resilver:

If you boot from pool 'zroot', you may need to update
boot code on newly attached disk '/dev/ada0p3'.

Assuming you use GPT partitioning and 'da0' is your new boot disk
you may use the following command:

    gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

---

Hat man nun beides, GPT+UEFI also hybrid, muss man schauen, was -i 1 und was -i 2 ist.
-> gpart show und grob https://www.thomas-krenn.com/de/wiki/OPNsense_ZFS_Mirror_Installation

---

Wenn es nur eine gibt und die EFI ist, ist die dann -i 1
Grob: https://solence.de/2019/05/01/update-uefi-boot-code-after-zfs-upgrade-on-freebsd/

 

[turrican]

Das ist IMHO falsch. Es gibt einen generischen Pfad für den Loader, dieser ist z.B. für amd64-Systeme /efi/boot/bootx64.efi. Für Freebsd ist der Pfad /efi/freebsd/loader.efi vorgesehen. Das muss aber mit efibootmgr entsprechend eingerichtet werden.

einigen wir uns auf "halb richtig"?
falsch hört sich so... negativ an, so knallhart
so hatte ich mir das mal vor Jahren aufnotiert - wenn ich die Quelle dazu wieder finde, dann kann ich die nochmal begutachten

Wenn man /boot/loader.efi also auf der ESP als /efi/boot/bootx64.efi ablegt, ist das alles. Dann wird nicht nochmal der andere Loader ausgeführt, sondern der FreeBSD-Boot startet dann direkt über bootx64.efi.

also ist in FreeBSD die bootx64.efi und die loader.efi die gleiche Datei?

again what learned...

 

[pit234a]

neeh.
Also, vielleicht verstehe ich das alles nicht richtig. Das ist sogar recht wahrscheinlich.
Deshalb nochmal mein Stand:
benutzt man EFI (und heute will jeder EFI und MBR (=LEGACY) ist zum Booten quasi obsolet), braucht es keinen PMBR und keinen Bootcode irgendwohin zu schreiben, außer die eine kleine Datei loader.efi an den rechten Platz mit richtigem Namen in der EFI-System-Partition.

Ich habe das mit unterschiedlichen Systemen häufig probiert und es für wahr gefunden.

also ist in FreeBSD die bootx64.efi und die loader.efi die gleiche Datei?

ja, siehe weiter oben, den diff von @peterle


Mein zuletzt aus Sicherheitsgründen geklontes BSD des aktuell laufenden Systems hat gebootet und ich habe da nichts gemacht, außer zwei Partitionen einzurichten (und für EFI zu formatieren)

• die EFI-System-Partion und
• eine ZFS-Partition für den Rest

Wobei die Label-Geschichte hier nochmal ein eigenes Thema sein würde und was wann von BIOS oder System erkannt wird.
In die EFI habe ich den Inhalt meiner EFI des laufenden Systems kopiert, das passt ja eben zu dem laufenden System
In die ZFS habe per ZFS send den letzten SNAP meines laufenden Systems geschickt
Eigentlich fertig an der Stelle, aber weil ich einen neuen Namen für den Pool benutzt habe und einige weitere Dinge ändern wollte, habe ich den neuen ROOT/default gemountet und die Änderungen in den entsprechenden Dateien vorgenommen, was natürlich hier nicht zum Thema passt. Es soll nur zeigen, dass da nicht irgendwas magisches mit irgendeinem Bootcode in Richtung Speichermedium oder BIOS passiert ist.
Anschließend kann ich das neue Device an meinem PC booten und es ist ein Klon meines laufenden Systems.
Das ist mir Beweis genug, dass man keine Bootmagie zusätzlich zu dem loder.efi benötigt*, wenn man EFI bootet.

*das Boot-Dataset braucht noch die Eigenschaft, dass es ein Boot-FS ist. Das ist aber nachgelagert und folgt erst auf den ersten Boot-Schritt des EFI-Loaders.