Solved moving drive/zpool between servers

patpro

patpro

Hello (again)

I’ve installed FreeBSD 14 on a brand new Kingston DC600M SSD 2.5” Enterprise SATA SSD 7.6TB in a spare NUC on my desktop, and data sync from my old system has started. I’m supposed to ship this SSD to the datacenter where it will take place into a proper server (full project here)
But I realize my new zpool («ssd») has been created by the FreeBSD installer with a reference to «ada0p4» :

Bash: 
# zpool status -v ssd
  pool: ssd
 state: ONLINE
  scan: scrub repaired 0B in 00:17:29 with 0 errors on Sun May  5 08:41:57 2024
config:

        NAME        STATE     READ WRITE CKSUM
        ssd         ONLINE       0     0     0
          ada0p4    ONLINE       0     0     0

errors: No known data errors

On the destination server, current SAS HDDs are hooked to an LSI SAS3004 PCI card, hence, they show up as «daX» :

Bash: 
$ zpool status -v sas
  pool: sas
 state: ONLINE
  scan: scrub repaired 0B in 06:43:12 with 0 errors on Wed Jan  3 10:53:53 2024
config:

    NAME        STATE     READ WRITE CKSUM
    sas         ONLINE       0     0     0
      raidz1-0  ONLINE       0     0     0
        da0p3   ONLINE       0     0     0
        da1p3   ONLINE       0     0     0
        da2p3   ONLINE       0     0     0
        da3p3   ONLINE       0     0     0

errors: No known data errors

When the SAS HDD da0 will be replaced by my new SATA SSD to reboot on my new zpool «ssd», it will probably be known as da0 (or da4). How can I make sure the new zpool «ssd» will properly boot if the underlying device has changed names?
 
If you have configured to boot FreeBSD from UEFI and it is possible to UEFI boot from LSI SAS3004, there is no problem. The loader will find ZFS pool and import it even if underlying device name changes.
 
Thanks.
That’s a lot of «if», I’m not sure I can take that risk :/
Is there a way to recreate (from scratch I guess) my «ssd» zpool in order to make it agnostic of the device type («ada» vs «da») ?
 
I’m not sure I understand what you said.
The current «ssd» zpool boots on a NUC PC. I will send it to a datacenter so it will take place into a rack-mounted server, hooked to a LSI SAS3004. The drive it self will most probably be named daX instead of ada0. And I want to make sure this «ssd» zpool will boot in the rack-mounted server.

Current bios settings on the rack-mounted server:
capture_bios-settings08.png

capture_bios-settings09.png
 
I’ve read that thread a while ago, unfortunately it’s not that useful when you install a fresh FreeBSD system on top of a blank disk.
I’ve ordered a SATA-to-USB adapter to plug my second SSD: I’ll create properly labelled partition, a zpool that uses the label instead of the device name, and transfer data from 1st SSD to recreate a smarter version of the same storage.
Stay tuned ;)
 
Ok.
Got my SATA-to-USB adapter in the mail yesterday and started to play with it:
1- plugged the second SSD to a USB port, rebooted on a FreeBSD install memory stick, installed FreeBSD on the SSD
2- rebooted on the external SSD -> OK
3- rebooted on the internal SSD, destroyed the zpool of the external SSD, labeled its ZFS partition with gpart
4- create a new zpool «extSSD» with altroot and using the gpt/label instead of the device name (da0)
5- create a recursive snapshot on internal SSD, then zfs send -vR inSSD@snap | zfs receive -uF extSSD
6- apply some tuning to ensure proper «bootability»:
zfs set mountpoint=/extSSD extSSD
zpool set bootfs=extSSD/ROOT/default extSSD
7- last check with:
zpool export extSSD
zpool import -N extSSD
zfs list
8- reboot on external SSD -> OK
9- open NUC, remove internal SSD, install external SSD inside, close NUC
10- reboot on zpool extSSD from inside (now known as ada0 instead of da0) -> OK

Now I’m pretty sure that SSD will boot properly when it’ll get plugged on my server’s LSI SAS3004.

If you wonder why I’ve been through steps 1-2-3, it’s because I’m lazy and I wanted to play safe. Those steps make sure the drive has the proper layout, including ashift, an EFI partition and a freebsd-boot partition.

pict in action (during step 5): https://mastodon.green/@patpro/112451745065520719
 
You must log in or register to reply here.
Back
Top