FreeBSD 12 findet zfs pool (root) nicht (UEFI)

Columbo0815

Kaffeemann
Teammitglied
Moin,

ich hatte ein FreeBSD 11.2/amd64 auf einem ZFS laufen (zroot). Ich habe per "freebsd-update upgrade -r 12.0-RELEASE" auf FreeBSD 12.0 aktualisiert. Nach dem ersten "freebsd-update install" habe ich neu gebootet und erneut "freebsd-update install" ausgeführt. Danach habe ich per "pkg-static install -f pkg" zuerst pkg auf 12.0 hochgebracht und im Anschluss per "pkg upgrade" alle Pakete auf 12.0 erneuert. Danach habe ich ein drittes mal "freebsd-update install" ausgeführt um die überflüssigen Libs löschen zu lassen.

Nachdem ich nun neu gebootet habe, bekomme ich wie gewohnt das Bootmenü angezeigt. Dann erkennt der Rechner die ganze Hardware, bis der Boot mit folgender Meldung hängen bleibt:

Bootprozess schrieb:
Loader variables:
vfs.root.mountfrom=zfs:zroot/ROOT/default

Manual root filesystem specification:
<fstype>:<device> [options]
...
...
mountroot>
Wenn ich "?" eingebe, bekomme ich alle verfügbaren Platten angezeigt. Wenn ich "zfs:zroot/ROOT/default" eingebe, kommt die Meldung "unknown file system". Nach mehrfachem Neustart bootet der Rechner sauber durch. Ich habe dann mit "zpool upgrade" alle Pools aktualisiert und auf zroot den bootcode für UEFI aktualisiert.

Boote ich jetzt neu, bleibt das Phänomen. Ich erhalte die oben zitierte Meldung. Nach mehrfachem Neustart bootet er ohne weitere Probleme.

Weitere Infos:

gpart show nvd0 schrieb:
=> 40 2000409184 nvd0 GPT (954G)
40 409600 1 efi (200M)
409640 2008 - free - (1.0M)
411648 4194304 2 freebsd-swap (2.0G)
4605952 1995802624 3 freebsd-zfs (952G)
2000408576 648 - free - (324K)

zpool status zroot schrieb:
pool: zroot
state: ONLINE
scan: scrub repaired 0 in 0 days 00:06:56 with 0 errors on Tue Sep 4 09:19:36 2018
config:

NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
nvd0p3 ONLINE 0 0 0

errors: No known data errors

Mir wäre es natürlich lieb, wenn ich den Fehler finden könnte und bin deshalb für Ideen und Hinweise dankbar.
 
Ich habe da auf Anhieb zwei Vermutungen:
  • Mit 12.0 haben sich die Bootloader völlig verändert. Bisherige Setups werden zwar in einem Kompatibilitätsmodus unterstützt, aber das war in meinen Test mit den Betas und Release Candidates teilweise etwas bröselig. Manchmal fanden die Loader unter anderem die /boot/loader.conf nicht, was erklären würde, wieso die ZFS fehlt. Kannst du mal kurz beschreiben, wie du den Bootloader installiert oder aktualisiert hast?
  • vfs.root.mountfrom=zfs:zroot/ROOT/default sollte natürlich noch funktionieren. Aber vielleicht, ganz vielleicht ist es durch die Integration der neuen Boot Environments kaputt gemacht worden. Die verhalten sich subtil anders als bisher, was mir auch schon auf die Füße gefallen ist.
Ich würde erstmal nach dem Bootloader schauen und dann weitersehen.
 
Das könnte vielleicht der Grund sein:

Bisher, also bis 11.2, war die Bootkette so: UEFI -> boot1 (meist unter anderem Namen) von der EFI-Partition -> boot1 sucht die Partition mit dem Root-Dateisystem, lädt /boot/loader.efi und führt den aus -> loader.efi raddelt /boot/loader.conf durch und lädt den Kernel.

Das ist übermäßig kompliziert und komplett anders als das, was Linux und Windows machen. Wodurch Multiboot nur schwer möglich war. In 12.0 wird das noch so lala unterstützt, um vorhandene Installationen nicht zu zerdeppern, aber eigentlich soll man nun: UEFI -> loader.efi von der EFI-Partition -> loader.efi macht alles andere.

Ich würde als ersten Schritt mal umstellen, genügend Speicherplatz hast du ja. Also in etwa so:
Code:
# Die EFI-Partition komplett löschen.
dd if=/dev/zero of=/dev/nvd0p1 bs=4M

# Ein neues Dateisystem erstellen.
newfs_msdos /dev/nvd0p1

# Das mounten...
mount -t msdosfs /dev/nvd0p1 /mnt

# ...den Loader kopieren...
mkdir -p /mnt/EFI/BOOT
cp -r /boot/loader.efi /mnt/EFI/BOOT/freebsd.efi

# ...und registrieren.
efibootmgr -c -l /mnt/EFI/BOOT/freebsd.efi -L FreeBSD
Anschließend im UEFI "FreeBSD" als Bootgerät auswählen. Das Löschen der Partition ist vielleicht etwas paranoid, aber viele UEFIs sind leider recht bröselig und sicher ist sicher.

Wenn es dann noch nicht geht, wäre der nächste Schritt sicherzustellen, dass bootfs eines Pools richtig gesetzt ist:
Code:
zpool set bootfs=zroot/ROOT/default zroot
Wenn auch das nicht hilft, müsste man graben...
 
Nicht nützlich beim Problem, aber ein Booten von 12.0-RELEASE vom Stick wollte partout das bestehende Geli-Passwort der beschriebenen Platten haben. Nach 3x leerem PW eingeben, stand ich auch da wie Columbo:
Loader variables:
vfs.root.mountfrom=zfs:zroot/ROOT/default

Manual root filesystem specification:
<fstype>:<device> [options]
...
...
mountroot>

Einfach ne Kiste plattmachen ist wohl nicht bei diesem Weg. :)
 
Code:
# Die EFI-Partition komplett löschen.
dd if=/dev/zero of=/dev/nvd0p1 bs=4M

# Ein neues Dateisystem erstellen.
newfs_msdos /dev/nvd0p1

# Das mounten...
mount -t msdosfs /dev/nvd0p1 /mnt

# ...den Loader kopieren...
mkdir -p /mnt/EFI/BOOT
cp -r /boot/loader.efi /mnt/EFI/BOOT/freebsd.efi

# ...und registrieren.
efibootmgr -c -l /mnt/EFI/BOOT/freebsd.efi -L FreeBSD
Das habe ich gemacht. Wenn ich dann neu boote, bekomme ich die Meldung "Missing boot loader", ohne dass ich auch nur Teile des Bootvorganges sehe.

Anschließend im UEFI "FreeBSD" als Bootgerät auswählen. Das Löschen der Partition ist vielleicht etwas paranoid, aber viele UEFIs sind leider recht bröselig und sicher ist sicher.
Allerdings frage ich mich, was du damit meinst...
Wenn es dann noch nicht geht, wäre der nächste Schritt sicherzustellen, dass bootfs eines Pools richtig gesetzt ist:
Code:
zpool set bootfs=zroot/ROOT/default zroot
Wenn auch das nicht hilft, müsste man graben...
Hatte ich zuvor schon geprüft:
Code:
zpool get bootfs
NAME   PROPERTY  VALUE               SOURCE
pool0  bootfs    -                   default
zroot  bootfs    zroot/ROOT/default  local
 
Allerdings frage ich mich, was du damit meinst...
Durch den efibootmgr Aufruf registrierst du eine neue Bootoption "FreeBSD" in deinem UEFI. Wenn du ins Setup geht, also diese Sache mit 'entf' oder so beim Boot drücken, kannst du anschließend dort unter Boot oder so "FreeBSD" als Bootgerät auswählen.

Das wäre zwar der korrekte Weg, aber du kannst es dir auch sparen, indem du den Loader einfach in den Standardpfad kopierst. Dann greift das UEFI ihn auf, ohne das du etwas registrieren und auswählen musst. Das wäre:
Code:
mkdir -p /mnt/EFI/BOOT
cp -r /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.EFI
 
Durch den efibootmgr Aufruf registrierst du eine neue Bootoption "FreeBSD" in deinem UEFI. Wenn du ins Setup geht, also diese Sache mit 'entf' oder so beim Boot drücken, kannst du anschließend dort unter Boot oder so "FreeBSD" als Bootgerät auswählen.
Ok. Ich lebe einfach noch in der alten Welt. Ich sage dazu "BIOS" (auch wenn mir klar ist, dass ich UEFI habe). Ich hatte gestern nachgesehen, als ich neu gestartet habe. Er zeigt mir den Namen *nicht* an. Er zeigt nur den Namen der Platte. ich teste das aber heute Abend noch einmal.
Das wäre zwar der korrekte Weg, aber du kannst es dir auch sparen, indem du den Loader einfach in den Standardpfad kopierst. Dann greift das UEFI ihn auf, ohne das du etwas registrieren und auswählen musst. Das wäre:
Code:
mkdir -p /mnt/EFI/BOOT
cp -r /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.EFI
Was ich nicht ganz verstehe: Wenn die Änderungen am Bootloader nicht automatisch vorgenommen werden, warum man nichts darüber liest. Aber das ist erstmal nebensächlich. Wichtiger ist, dass ich den Grund finde und ihn lösen kann :)
 
Heißt das, daß der sicherste Weg bei Rechnern mit kaputtem BIOS, wie es bei Lenovo ja gerne vorkam, eine Neuinstallation ist?
Ich habe da noch so zwei drei Server von Lenovo laufen, die einige Verrenkungen erforderten, bis sie mit FreeBSD und ZFSonRoot laufen wollten. Bis 11.2 ist alles gut gegangen.
 
Da hab ich was angerichtet... :) Also, FreeBSD und UEFI waren am Anfang nicht unbedingt gute Freunde. Man nahm einfach die EFI-Bootloader aus dem inzwischen eingestellten FreeBSD/ia64 (für Itanium), frickelte die auf normales x86 UEFI um und war damit erstmal glücklich. Dann kam die Realität in Form mieser UEFI-Implementierungen, die Sache wurde wichtiger, also begann man da Arbeit reinzustecken. Das führt dann über 10.0 bis 11.2 zu nach und nach besserer UEFI-Unterstützung. Aber es blieben zwei Probleme:
  • Jeder Bootloader ist ein komplett eigenständiges Stück Software, ich glaube es waren über 25 Stück. Alleine für FreeBSD/amd64 BIOS-MBR-UFS, BIOS-MBR-ZFS, BIOS-GPT-UFS, BIOS-GPT-ZFS und UEFI. FreeBSD/arm war noch schlimmer. Also entschloss man sich die Bootloader komplett umzubauen.
  • Der UEFI-Bootloader entsprach nicht diesem UEFI Multiboot Protokoll. Das sieht vor, dass es eine globale EFI-Partition für das ganze System gibt. Auf dem liegen die Bootloader, sie werden durch efibootmgr im NVRAM des Mainboards registriert und können kann durch das UEFI aufgerufen werden. Außerdem können die UEFI-Bootloader untereinander kommunizieren. Das ermöglicht theoretisch tolle Dinge.
In der neuen Welt mit 12.0 sind diverse Bootloader verschwunden und alle überlebenden basieren auf dem gleichen Kern. Darum kann nun zum Beispiel auch der UEFI-Loader von per geli verschlüsselten Dateisystemen booten. Auf den Tier-1 Plattformen FreeBSD/i386 und FreeBSD/amd64 ist das aber weitgehend transparent, als Nutzer muss man da nichts ändern außer den vorhandenen Bootcode neuzuschreiben. Und das ist noch nicht mal zwingend. Wenn es funktioniert ist alles gut. Aber wenn es Probleme gibt, ist es eine gute Idee den Kompatibilitätskram rauszukratzen und auf eine moderne Konfiguration zu wechseln. Die ist (oder zumindest soll) auch deutlich weniger zickig mit problematischer Hardware sein. Der Installer legte bisher eine 1 MB große EFI-Partition an, /boot/loader.efi ist 400 Kilobyte groß und FAT sehr effizient. Das passt ohne Neuinstallation.
 
Moin,

ich glaube deine Ausführungen bringen aktuell für mich ein wenig Licht ins Dunkle. Ich dachte mir nämlich, das wenn ich mit efibootmgr in den NVRAM des Mainboards schreibe kann, muss ich den doch auslesen können. Das Ergebnis:

Code:
efibootmgr
BootCurrent: 0005
Timeout    : 1 seconds
BootOrder  : 0005, 0004, 0000
+Boot0005* UEFI OS
 Boot0004* Hard Drive
 Boot0000  FreeBSD

Wenn ich das ohne tiefere Kenntnis deute, habe ich die falsche Bootorder. Richtig wäre wohl BootOrder: 0000.

Ich sehe mir das mal später an.

Danke!
 
Genau. Und im BIOS / UEFI /Setup oder wie auch immer wir das nennen kannst du die umstellen. Wo und wie ist aber wieder von anderen Optionen, wie z.B. dem Legacy Boot, abhängig. Man kann die auch irgendwie mit efibootmg umsortieren, aber da kann ich dir aus dem Stehgreif nicht sagen wie.
 
Man kann es mit efibootmgr -o umstellen. Hilfreich fand ich auch folgenden Hinweis in der manpage:
EFIBOOTMGR(8) schrieb:
Note newly created BootVars are created inactive. The active state is
denoted by an '*' following the BootVar name in the output. They are
also inserted into the first position of current BootOrder variable if it
exists. They must first be set to active before being considered
available to attempt booting from, else they are ignored.

Ich bin zuversichtlich, dass mein Problem so gelöst werden kann, ich gebe Bescheid. :)
 
Mein Kollege ist auf seinem X220 auch beim Upgrade mit dem selben Fehlerbild auf die Nase gefallen.
Der Einfachheit halber habe ich dann /home, /boot, und {/usr/local,}/etc weggesichert, neu installiert und zurückgesichert.
Jetzt läuft alles zu seiner Zufriedenheit.
 
So, ich glaube nun fest an einen Bug. Der Rechner bootet jeden dritten Neustart durch. Ich habe /dev/nvd01p1 wie oben beschrieben nochmals neu geschrieben und "BootVars" auch aktiviert (siehe manpage-Eintrag oben). Ebenso habe ich zuvor jeden Eintrag im NVRAM gelöscht. Kein Erfolg.

@lme weißt du, ob der Kollege einen Bugreport erstellt hat, an den ich mich anhängen kann? Ich tu mir beim Erstellen eines neuen wegen meines übertrieben guten Englisch etwas schwer beim Erstellen. Die Entwickler sollen sich schließlich dem Fehler annehmen und sich nicht schepp lachen. ;)

Ich bin weiterhin auf der Suche. Wenn also noch jemand Ideen hat, was man untersuchen könnte: Gerne. Ein Backup und Neuinstallation will ich vorerst vermeiden.
 
Möglicherweise bin ich auch von diesem Problem betroffen. Jedenfalls bleibt das System irgendwo während dem Starten hängen. Auf Grund des amdgpu Grafiktreibers sehe ich auf dem Bildschirm aber nur Müll und keine Bootmeldungen. Daher kann ich nicht wirklich sagen was das Problem ist. Jetzt muss ich erst mal den Treiber deaktivieren und dann sehe ich weiter.
 
Interessant wäre zu wissen, ob das 'zfs.ko' Modul geladen wird. Ich vermute nicht. Die Loaderausgabe fliegt nun so schnell durch, dass man es kaum sehen wird. Du könntest aber "Rollen" drücken, sobald er auf Eingabe des Root-Dateisystems wartet und mit den Cursortasten nach oben scrollen. ZFS sieht in der Bootausgabe so aus:

Code:
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)

Wobei ich auch keine Vermutung habe, warum es manchmal geladen wird und manchmal nicht. Aber dann wüsste man zumindest schon mal in welcher Richtung der Fehler liegt.
 
Bei mir hat sich mein Verdacht nicht bestätigt. Nachdem ich den Grafiktreiber deaktiviert und die packages upgegradet habe läuft das System nun wieder.
Also als kleiner Hinweis für Radeon Besitzer: Vor dem Update auf 12.0 das amdgpu Kernelmodul deaktivieren.
 
@lme weißt du, ob der Kollege einen Bugreport erstellt hat, an den ich mich anhängen kann? Ich tu mir beim Erstellen eines neuen wegen meines übertrieben guten Englisch etwas schwer beim Erstellen. Die Entwickler sollen sich schließlich dem Fehler annehmen und sich nicht schepp lachen. ;)
Leider nicht. Ich war beim Update nicht dabei und habe ihm dann nur bei der Neuinstallation geholfen.
 
Interessant wäre zu wissen, ob das 'zfs.ko' Modul geladen wird. Ich vermute nicht. Die Loaderausgabe fliegt nun so schnell durch, dass man es kaum sehen wird. Du könntest aber "Rollen" drücken, sobald er auf Eingabe des Root-Dateisystems wartet und mit den Cursortasten nach oben scrollen. ZFS sieht in der Bootausgabe so aus:
Wenn der Rechner nicht korrekt bootet, wird zfs.ko nicht geladen.
 
Als kleiner Nachtrag: Laut Handbuch soll ich
Code:
zfs_enable="YES"
in /etc/rc.conf eintragen. Ich habe zusätzlich zfs_load="YES" in /boot/loader.conf stehen. Aktuell bootet der Rechner bei jedem zweiten Start sauber durch. Zudem ist mir aufgefallen, dass mal das eine, mal ein anderes Modul beim Boot nicht geladen wird. Häufig fehlt nvidia-modeset. Eben hat er vmm.ko nicht mitgeladen. Vielleicht hilft das bei der Ursachensuche.. :)
 
Hallo Kaffeemann

steht in der loader.conf bei Dir ein
Code:
vfs.root.mountfrom="zfs:<dein-root-dataset>"

Vielleicht mal ausprobieren.
 
Moin,
werde ich gerne bei Gelegenheit testen. Allerdings verspreche ich mir davon wenig bzw. sogar nichts. Wenn die root-Partition nicht gefunden wird und ich deshalb bei "mountfrom>" lande, müsste ich spätestens jetzt durch die Eingabe von "zfs:zroot/default" das erreichen, was dein Eintrag bewirkt/bewirken soll.

Bei mir ist aber das Modul zfs.ko gar nicht geladen, weshalb ich auch durch manuelles festlegen nicht weiter komme. Ich kann jedoch - was ich erfolgreich getestet habe - von anderen Nicht-ZFS-Partitionen booten.

Wie gesagt: Ich werde es dennoch testen. :)

Danke
 
vfs.root.mountfrom="zfs:<dein-root-dataset>"
hatte mir auch schon geholfen.
Eigentlich braucht man das nicht wirklich, wenn ich die man-page recht verstanden habe und es nur einen root-Pool gibt. Ein System machte aber mir aber tatsächlich solche Schwierigkeiten und zwar erst nach irgendeinem Update auf ein neueres BSD.
Seither schleppe ich den Eintrag stur mit, schadet ja auch nicht.

Allerdings war das bei mir zwar ein EFI-PC, bootete aber im legacy Mode und ohne EFI(Partition).
 
Zurück
Oben