• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Systemumzug UFS auf ZFS ohne Neuinstallation

Kamikaze

Warrior of Sunlight
Themenstarter #27
Mal ein Update:

Ich habe die vdevs mit zpool detach und attach beide neu geschrieben, jetzt kann ich das System zumindest mit gptzfsboot starten. Allerdings muss ich das Passwort immer noch 2 mal eingeben.

Nach dem ersten mal kommt noch ein: Failed to read pad2 area of primary vdev

Danach kommt der loader und fragt mich noch mal nach dem Passwort (da der loader auf der verschlüsselten Partition liegt scheint mir das überflüssig).

Der EFI Loader sagt einfach ich hätte keine bootbaren Devices.

Vor meinem leidigen Versuch die alten Metadaten los zu werden haben beide Loader funktioniert und mich jeweils nur ein mal nach der Passphrase gefragt.
 
#28
Ich glaube zwar nicht, dass du ein ähnliches Problem hast, aber vielleicht ist es ja doch ein Glückstreffer. ich hatte nach dem Upgrade auf 12.0 das Problem, dass mein ZFS-Pool beim Booten nicht (immer) gefunden wurde. Ursache war, dass ich das nvidia-Modul über /boot/loader.conf geladen hatte. Die Reihenfolge, in der die Module aus der loader.conf geladen werden, ist wohl zufällig (?). Immer dann, wenn nvidia.ko zuerst geladen wurde, hat das System nicht gebootet. Es ist wohl eine Größenbeschränkung.

Kurzum: Nachdem ich nvidia.ko über /etc/rc.conf geladen habe (kld_list="nvidia-modeset nvidia"), hat das System durchweg sauber gebootet. Wie viele Module lädst du denn über /boot/loader.conf? Sind Module dabei, die du später (also über /etc/rc.conf) laden kannst?

HTH!
 

Kamikaze

Warrior of Sunlight
Themenstarter #30
So, inzwischen habe ich einige Fortschritte gemacht:

Nach dem ersten mal kommt noch ein: Failed to read pad2 area of primary vdev
Das lag an einem latenten ZFS label Überrest.

Das GPT Layout ist folgendes:
Code:
# gpart show -lp
=>        40  1953525088    ada0  GPT  (932G)
          40         984  ada0p1  9gptzfsboot  (492K)
        1024       31744  ada0p2  9efisys  (16M)
       32768    33521664  ada0p3  9swap  (16G)
    33554432  1918894080  ada0p4  9zpool  (915G)
  1952448512     1076616          - free -  (526M)

=>        40  1953525088    ada1  GPT  (932G)
          40         984  ada1p1  8gptzfsboot  (492K)
        1024       31744  ada1p2  8efisys  (16M)
       32768    33521664  ada1p3  8swap  (16G)
    33554432  1918894080  ada1p4  8zpool  (915G)
  1952448512     1076616          - free -  (526M)
In 8zpool und 9zpool liegen jeweils die Geli container und darunter der Zpool.

Code:
# zdb -l /dev/ada1p4.eli
------------------------------------
LABEL 0
------------------------------------
    version: 5000
    name: 'z8pool'
    state: 0
…
Insgesamt gibt es im Pool 4 mal das gleiche Label. Auf der verschlüsselten Ebene darüber gibt es natürlich keine Label:

Code:
# zdb -l /dev/ada1p4
------------------------------------
LABEL 0
------------------------------------
failed to unpack label 0
------------------------------------
LABEL 1
------------------------------------
failed to unpack label 1
------------------------------------
LABEL 2
------------------------------------
failed to unpack label 2
------------------------------------
LABEL 3
------------------------------------
failed to unpack label 3
Nur war das nicht der Fall. Von einer früheren Iteration war LABEL 3 noch gesetzt. Was der Bootloader für vermurkste Loader Parameter hält.

Ich musste das label also löschen. Dafür musste ich die Partition natürlich aus dem Pool nehmen:

Code:
# zpool offline z8pool ada1p4.eli
# geli detach /dev/ada1p4
Damit ist der Pool natürlich in einem Degraded state, weil es keinen Mirror mehr gibt.

Code:
# zpool labelclear /dev/ada1p4
Damit ist das Label weg. Leider ist damit auch der Geli container hin. Ich bin eigentlich davon ausgegangen, dass ich das danach wieder einbinden kann und mit einem Scrub in Ordnung bringe was dabei kaputt ging. Leider hat das Geli attach schon nicht funktioniert.

Ich habe also kurzerhand den Container neu angelegt und eingebunden:

Code:
# geli init -bg … /dev/ada1p4
# geli attach /dev/ada1p4
# zpool replace z8pool ada1p4.eli ada1p4.eli
Danach nur noch warten, bis das Device Resilvered wurde. Danach ist mir dann eingefallen, dass ich das wahrscheinlich mit Geli restore wieder hinbekommen hätte. Aber dafür war es dann schon zu spät. Und so lange das Andere Device funktioniert hat es bis auf die Dauer keinen Nachteil komplett zu resilvern.

Das nächste Problem habe ich auch in den Griff bekommen:

Der EFI Loader sagt einfach ich hätte keine bootbaren Devices.
Wie ich den Loader kaputt gemacht habe, weiß ich gar nicht, wahrscheinlich durch ein:

Code:
# gpart -p /boot/boot1.efifat -i2 ada0
# gpart -p /boot/boot1.efifat -i2 ada1
Das installiert aber /boot/boot1.efi was jedoch gar kein Geli kann. Der Trick war /boot/loader.efi zu installieren:

Code:
# newfs_msdos -L 9efisys /dev/gpt/9efisys
# mount -t msdos /dev/gpt/9efisys /mnt/tmp
# mkdir -p /mnt/tmp/efi/boot
# cp /boot/loader.efi /mnt/tmp/efi/boot/BOOTx64.efi
# umount /mnt/tmp
Und das Gleiche noch mal mit 8efisys.

Ein letztes Problem bleibt aber:

Allerdings muss ich das Passwort immer noch 2 mal eingeben.
 
Zuletzt bearbeitet:

Zirias

Well-Known Member
#31
Das installiert aber /boot/boot1.efi was jedoch gar kein Geli kann.
Das hat mir eben einen restlichen Teil der Nacht gerettet! Ist ja wirklich Murks, um den Bootcode auf einem System, das per EFI von GELI bootet, zu aktualisieren, muss man allen ernstes von Hand in die EFI Partition schreiben? Naja, gut zu wissen, für die Zukunft...
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#32
Nicht, dass ich den UEFI-Boot in irgendeiner Weise durchdacht finden würde, aber /boot/boot1.efifat war halt ein FreeBSDism und das manuelle Kopieren des /boot/loader.efi und anschließende Registrieren mit efibootmgr(8) ist nun mal der offizielle Weg, den auch Linux und Windows gehen... Man könnte / sollte allerdings ein Script bereitstellen, was es automatisiert.

Aber eigentlich wollte ich sagen, dass @Kamikaze den Bootloader nicht per efibootmgr(8) registriert, stattdessen darauf vertraut, dass die Firmware ihn auch ohne Registrierung aus dem von Windows genutzten Pfad liest. Das wird bei der meisten Konsumerhardware funktionieren, aber zur Sicherheit sollte man sich wirklich die Registrierung gönnen.
 
#33
Das er ein zweites Mal nach der Passphrase fragt ist ein Überbleibsel vom alten Layout mit bootpool und zroot. Das hatte ich auch nach meinem Umstieg vom alten Layout zum aktuellen zroot only.
Wenn ich mich recht entsinne, habe ich in der rc.conf das ganze geli Geraffel entfernt.