Neue SSD: device name hat sich geändert

Hi,

ich habe in meinem Laptop ein kleines Upgrade vorgenommen: von einer 250 GB M.2 SSD auf eine 500 GB M.2 NVMe.
Mein zuvor erstelltes Image habe ich zurückgesichert.
Leider klappt das Booten nun nicht mehr: der device name hat sich von /dev/ada0 auf /dev/nvd0 geändert.
Gibt es einen Weg das geradezubiegen? Ich nutze zfs.
 
Ich denke, ich habs selbst hinbekommen im single user mode:

# zfs set readonly=off zroot/ROOT/default
# nano /boot/loader.conf

hinzugefügt:
nvme_load="YES"
nvd_load="YES"
# nano /etc/fstab
alle Einträge von "ada" in "nvd" geändert.
# reboot

Danke @schorsch_76

Als nächstes muss ich die Partition und den zfs pool vergrößern.
 
Nächstes Problem:
Das Vergrößern der Partition führt wieder in einen nicht bootfähigen Zustand :/

Was habe ich gemacht:
Mit Live System booten!
# gpart show --> freien Speicherplatz merken und auf die addieren
# gpart resize -i 4 -a 4k -s 463G nvd0

Das wurde ausgeführt und die neue Größe liess sich mit "gpart show" anzeigen.

Doch das Booten bricht ab:
Failed to find bootable partition
ERROR: cannot open /boot/lua/loader.lua: no such file or directory.


Hinweis: mein System ist encrypted, falls das einen Einfluss auf die Partitionsvergrößerung hat.
Wie vergrößere ich nach dem Einbau der größeren Disk richtig die "freebsd-zfs" Partition?

Einen Auszug von "gpart show" liefere ich, wenn ich das Image erneut zurückgesichert habe.
 

schorsch_76

FreeBSD Fanboy
AFAIK kann man den zpool nach der Einrichtung nicht mehr vergrößen.

Mach einen rekursiven zfs snapshot und sende den von deiner alten Platte auf einen neuen zpool auf der neuen Platte.


 
AFAIK kann man den zpool nach der Einrichtung nicht mehr vergrößen.

Mach einen rekursiven zfs snapshot und sende den von deiner alten Platte auf einen neuen zpool auf der neuen Platte.

Das wäre doof. Aber es gibt doch das zpool flag "autoexpand=on" und den Befehl "zpool online -e zroot nvd0", weshalb ich dachte, es müsste gehen.

Hier noch die Ausgabe von gpart:


# gpart show
=> 40 976773095 nvd0 GPT (466G)
40 532480 1 efi (260M)
532520 1024 2 freebsd-boot (512K)
533544 984 - free - (492K)
534528 4194304 3 freebsd-swap (2.0G)
4728832 495388672 4 freebsd-zfs (236G)
500117504 476655631 - free - (227G)


Ich möchte die Partition 4 um die verfügbaren 227G vergrößern.
 

Yamagi

Possessed With Psi Powers
Teammitglied
gpart resize -i 4 nvd0 vergrößert die Partition. Nummer 4 ist dabei die Partition, die vergrößert werden soll. ZFS kommt je nach Konfiguration automagisch hinterher oder braucht einen manuellen Tritt.
 
gpart resize -i 4 nvd0 vergrößert die Partition. Nummer 4 ist dabei die Partition, die vergrößert werden soll. ZFS kommt je nach Konfiguration automagisch hinterher oder braucht einen manuellen Tritt.
Ohne Größenangabe?

Mein Befehl oben:
Code:
# gpart resize -i 4 -a 4k -s 463G nvd0
hat mir ja das System zerschossen. Das möchte ich natürlich verhindern ;)
 

turrican

Well-Known Member
AFAIK kann man den zpool nach der Einrichtung nicht mehr vergrößen.
Das geht in OpenZFS (seit welcher Version weiß ich nicht) - habs selber allerdings noch nie ausprobiert (geschweige denn auf ner Single Disk nach nem Re-Image), der Pool muss offline und wieder online genommen werden:

Code:
zpool online -e <poolname> <device>
 

Yamagi

Possessed With Psi Powers
Teammitglied
Ich habe es für ZFS leider nicht im Kopf. Mit UFS würde es im laufendem System gehen. Man kann die Sperre mit sysctl kern.geom.debugflags=16 rausnehmen. Dann macht er, was man ihm sagt. Egal ob es dumm oder nicht. Ich würde es aber lassen. :)
 
So,
hab
Code:
gpart resize -i 4 nvd0
ausgeführt.

Folgende Meldung kam:
Code:
g_dev_taste: g_dev_taste(gptid/foobarblabla) failed to g_attach, error=6
g_dev_taste: g_dev_taste(gpt/zfs0) failed to g_attach, error=6
nvd0p4 resized

Git:
gpart show
hat auch die Vergrößerung angezeigt.
Code:
4728832 972044303 4 freebsd-zfs (464G)

Doch nach dem Reboot gehts wieder nicht weiter.
Meldung wie in Beitrag #4. :(
 

mr44er

moderater Moderator
Teammitglied
Hinweis: mein System ist encrypted, falls das einen Einfluss auf die Partitionsvergrößerung hat.
Native oder komplett mit geli? geli will da nämlich auch 'Bescheid' wissen. -> geli resize
ZFS vergrößern kommt ganz am Schluss, das funktioniert auch live ohne das busy-Problem bzw. sollte, mit single disk hab ich das auch noch nicht gemacht.

Mach einen rekursiven zfs snapshot und sende den von deiner alten Platte auf einen neuen zpool auf der neuen Platte.
Das erscheint mir als die bessere Methode, da gibts auch am wenigsten busy-disk.

Code:
gpart resize -i 4 -a 4k -s 463G nvd0
hat mir ja das System zerschossen. Das möchte ich natürlich verhindern
Was da jetzt genau krumm war, kann ich nur raten, aber nochmaliges alignment erscheint mir falsch, auch wenn es hier erwähnt wird: https://people.freebsd.org/~rodrigc/doc/handbook/disks-growing.html

Da gibts einen Hinweis, wenn die disk als corrupted gemeldet wird: https://marcocetica.com/posts/grow_partitions_freebsd/
 
Konnte das alls nun in einer VM nachvollziehen.
Die Fehlermeldung nach gpart resize kam zwar ebenfalls, aber das geli resize hat dann geklappt.
Laptop bootet nun wieder einwandfrei und auch der zroot pool ist vergrößert.
Danke nochmal an @mr44er und an die anderen!
Der Link war Gold wert, denn man benötigt auf jeden Fall die consumer media size.
 
Oben