Solved Moving my FreeBSD installation to another disk

F

fmc000

When I decided to try FreeBSD on my laptop I bought a 128GB nvme drive and removed my 512GB nvme drive, on which I had my Archlinux installation. I opted to install on ZFS root with Geli encryption. Now, a month and a half after that day I decided that I'm keeping FreeBSD and that I would like to use the bigger drive for that.

So my question is: is there a wiki or some "official" documentation on how to migrate from my 128GB drive to the 512GB drive whilst keeping ZFS and encription? Of course the 512GB drive will be connected to the laptop via a USB-C enclosure during the process.
 
You create your partition on the new drive and label them, copy the bootloader (is it uefi or legacy bios ?), setup geli with the same passhrase with the boot option (-b).
Then you simply make a zfs mirror with your two drive, wait for the second drive to be synchronized, then do a scrub.
Once it is done, swap the two drive position: the 512gb became internal, and the 128gb became external.
Try to boot, if it is a success, power off, remove the external one, try to boot.
If all is good, reconnect the external drive, boot, wait for the synchronization, then detach the corresponding device (Or use zpool-split to have an extra backup pool).
 
Boot from a USB stick
dd the whole disk
use gdisk on the new disk to re-write the partition table, with the last partition now bigger
expand ZFS by setting the appropriate option
 
No need for sysutils/gdisk.

After dd(1) whole disk
  • gpart recover <512GB disk> ( partition table will be corrupted, because secondary, backup copy of the tables metadata is not at the end of the last sector of disk)
  • boot in cloned system on 512GB disk
  • zpool set autoexpand=on <pool>
  • gpart resize -i <n - freebsd-zfs partition> <512GB disk>
Backup the geli(8) metadata of the provider on a external device.

Note, the geli(8) provider is set to AUTORESIZE by default. ( see geli list )
 
tl;dr - it didn't work.

After dd-ing the disk I recovered the partition, swapped the disks but the system didn't boot. It didn't ask the geli passphrase and therefore it couldn't find a bootable kernel. What did I do wrong?

The second try it worked perfectly.
 
T-Daemon said:
Let the 512GB disk in laptop, boot the installation media, see if the geli(8) provider (freebsd-zfs) can be attached.
Click to expand...
Maybe you didn't see that I modified my previous post. Your instructions worked like a charm. I'm now writing from my 512GB laptop :)

Code: 
[20:56][fmc000@tu45b-freebsd][~]
 ⤷ $ zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
zroot   463G  66.9G   396G        -         -     7%    14%  1.00x    ONLINE  -
[20:58][fmc000@tu45b-freebsd][~]
 ⤷ $
 
Depending on the drive, trim commands may not have zeroed out unused space so dd configuration to skip writing unused sectors would write them too. Partitioning the disk, formatting the partitions, copying the boot loader to it, and using zfs send/recv would have lead to the least amount of sectors being marked as written whereas a blind dd + resize marks all sectors of the old drive as written sectors on the new drive so none are treated as free by the new drive's firmware until future trim operations mark "some" of them as such. In your case, the other 3/4ths of the drive will still have used/unused sectors properly tracked for wear leveling purposes.
 
Mirror176 said:
Depending on the drive, trim commands may not have zeroed out unused space so dd configuration to skip writing unused sectors would write them too. [...] whereas a blind dd + resize marks all sectors of the old drive as written sectors on the new drive so none are treated as free by the new drive's firmware until future trim operations mark "some" of them as such. In your case, the other 3/4ths of the drive will still have used/unused sectors properly tracked for wear leveling purposes.
Click to expand...

Mirror176, I would like to read up on this topic, can you refer to a documentation?

Not much in system manuals (trim(8), zpool-trim(8), zpoolprops(7) "autotrim").

Web searching even less (probably due to the lack of appropriate keywords).
 
T-Daemon said:
Mirror176, I would like to read up on this topic, can you refer to a documentation?

Not much in system manuals (trim(8), zpool-trim(8), zpoolprops(7) "autotrim").

Web searching even less (probably due to the lack of appropriate keywords).
Click to expand...
dd(1) has info about conv=sparse will skip writing blocks of zeroes. Default is to write what is read, even if it is an entire block. If the destination drive did onboard compression then such writes likely were greatly reduced. Using GELI means blocks of written zeroes were likely scrambled anyways.
nda(4) has good basic reading in kern.cam.nda.max_trim, kern.cam.nda.enable_biospeedup, and kern.cam.nda.N.trim_ticks to start becoming aware that not all trims always happen right away just because space is freed.
geli(8) has an option -T best described in the initialization section which causes trim instructions to not reach the underlying drive and comes with a warning that the drive may or may not actually destroy contents of trimmed sectors. This section introduces more terminology to read of BIO_DELETE and unmap (good luck trying to "easily" use this term without additional content filtering.

https://openzfs.github.io/openzfs-docs/Performance and Tuning/Module Parameters.html#zfs-trim-extent-bytes-min mentions that there is a trim minimum size limit so even a manual trim will only trim blocks above a certain size.

nvmecontrol(8) sanitize command has options about how a drive could have its data made inaccessible. https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf has information that if a drive does ereases as a secure erase, it could overwrite the data or could just delete cryptographic keys to the data; guess that means 'if' the encryption could be broken then returned blocks go back to serving a purpose? In any case it mentions that data could be filled by something other than 0s, and not being 0s means that dd couldn't know to not write it.

I haven't seen anything about trim for FAT filesystem on FreeBSD so an EFI partition's free space will not get a later trim command. Same with the older bootloader partition format.
 
and it seems I have no idea how the manpage entries are supposed to be done on the web interface, but it gives the idea for manual lookup
 
Simply use [man=1]dd[/man] -> dd(1)
For man pages from ports, you even can be more specific: [pman=5]xorg.conf[/pman] -> xorg.conf(5)

These reference the most recent supported version of the highest -RELEASE version number, or the "latest" repository from the ports tree: they change over time!
If you wish to refer to a specific -STABLE or -RELEASE man page other than that, use the "url-form".

More formatting: BB codes
 
Mirror176, many thanks taking the time to summarize the information from the system manuals and external documentations. I very much appreciate it.

For future use, information and external documents have been added to my documentation collection.

Thank you again.
 
You must log in or register to reply here.
Back
Top