efibootmgr to add your new efi boot entry. zpool split to split the two drives into 2 distinct pool, so that you still have a backup if something goes terribly wrong.
gpart destroy -F da0
gpart create -s gpt da0
gpart add -t efi -s 260M -l efi1 da0
gpart add -t freebsd-boot -s 512K -l boot1 da0
gpart add -t freebsd-swap -s 2G -l swap1 da0
gpart add -t freebsd-zfs -l zfs1 da0
dd and then run gdisk repair to update GPT header stuff, and that's it. Somebody correct me if I'm wrong. I did this with Linux, I think, so there's no reason it shouldn't work with FreeBSD.This looks right, don't forget to create the efi filesystem.
It does that is why the previous instruction is to make a mirror.
This is not recommended if you are not extra cautious about which pool you import since then when doing the copy with dd the two pools will be the same, with the same unique id which can be messy.
So basically:
zpool split zroot old-zroot gpt/zfs0Have done it many times. This is just straightforward. Partition a new disk. Add new partition as a mirror to an existing pool with
zpool attach zpool-attach(8). Also set the zpool set autoexpand=on for your pool. Then let it resilver and remove the old disk and delete it from mirror.. You may have done it many times, but this my first time and the procedure seems error prone if you don't know what you are doing which I don't.
Not sure what is meant by adding a new partition as a mirror to an existing pool....
Last time my sequence was this (my new drive was nda0 and old drive nda1) --
# Create partition table
gpart create -s GPT nda0
# Add UEFI boot partition
gpart add -i 1 -t efi -s 200M -b 40 nda0
# Create swap partition (I do not use it on that drive, but for compatibility)
gpart add -i 2 -a 8K -t freebsd-swap -s 16G nda0
#The rest of the drive for ZFS
gpart add -i 3 -a 8K -t freebsd-zfs nda0
# Now it looks like this
root@Aurum ~# gpart show nda0
=> 40 2000409184 nda0 GPT (954G)
40 409600 1 efi (200M)
409640 8 - free - (4.0K)
409648 33554432 2 freebsd-swap (16G)
33964080 1966445136 3 freebsd-zfs (938G)
2000409216 8 - free - (4.0K)
# Then I copied loeder
# created file system for UEFI
newfs_msdos -F 32 -c 1 /dev/nda0p1
# Mounted this
mount -t msdosfs /dev/nda0p1 /mnt
# Created directofy for loader
mkdir -p /mnt/EFI/BOOT
# Copied loader
cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi
umount /mnt
## Now we have UEFI loader on that drive
# Attached new ZFS partition to existing pool (my existing pool ssd_sys was on nda1)
zpool attach ssd_sys nda1p3 nda0p3
# Now waited for resilver
zpool status
# Check if autoresize is on
zpool get autoexpand ssd_sys
NAME PROPERTY VALUE SOURCE
ssd_sys autoexpand on local
# After that removed the first drive
# When the new drive booted successfully, removed old drive from the pool using its GUID
# to get vdev GUID-s
zpool status -g
# Now removed old partition
zpool detach ssd_sys 3946041219947219899Interesting, I never had any concerns just running
zpool replace ..., but somehow autoexpand bothers me. I prefer doing an explicit zpool online -e at the end instead. gpart backup/ gpart restore. It really shines when replacing (nearly) identical disks or to consistently setting up a multi-disk pool, but nonetheless good to know about.Agree. I have sometimes done the
zpool online -e also. zpool replace is probably a good way to do it. I have just wanted to have a little more control over the process, so being hesitant with that. But yes, you are right!Yes. This is important. If you mistype attach and use add instead, you are in big trouble.
Using dd sounded like the simplest option so I thought I would give it a try, but unfortunately I got:-
After several hours of dd, followed by 'gpart recover' and 'gpart resize' I think I'm reading for the next step.
I've booted up successfully from the new disk in my W520.