zfs move boot to ext4

move boot to ext4

1. Create your ext partition
2. Mount it somewhere temporarily
3. rsync -avPX /boot/. /<tempboot>/.
4. unmount /<tempboot>
5. Move /boot to another location on zfs (eg. /bootbackup)
6. Recreate /boot mountpoint and mount your new partition there
7. Add the new boot ext4 partition to /etc/fstab

UUID=1b1d424c-9fd1-4fd2-aba7-80252f1a8d64 /boot           ext2    defaults        0       2

1. Re-run update-grub (maybe even update-initramfs for good measure)
2. reboot

 The /bootbackup allows you to a location to periodically rsync your /boot ext4 into the pool for recovery purposes.

after reboot you might have to manually select the second partition as boot device
#############

# zpool import -a -N -R /mnt

Mount the root pool into /mnt

# zfs mount LP_Pool/ROOT/lp_root

mount -t proc /proc /mnt/proc
mount --rbind /dev /mnt/dev
mount --rbind /sys /mnt/sys
chroot /mnt /bin/bash --login

sgdisk -p /dev/sdx
#creating 
sgdisk -n 1:2048:4095 -c 1:"BIOS Boot Partition" -t 1:ef02 /dev/sdx
#below command will create new partition number "2" of size 3219MB 
sgdisk -n 2:4096:6291456 -c 2:"Linux /boot" -t 2:8300 /dev/sdx 

mkfs.ext4 /dev/sdx2 and mount it on /newboot
copy /boot/* to /newboot
rename /newboot to /boot

get UUID of /dev/sdx2 and change fstab as below:-

UUID=1b1d424c-9fd1-4fd2-aba7-80252f1a8d64 /boot           ext4    defaults        0       2


grub-install /dev/sdx
update-grub2
grub-mkdevicemap
update-initramfs -u -k all


exit from chroot


# zfs unmount -a
# zfs set mountpoint=/ LP_Pool/ROOT/lp_root
# reboot

############

UPDATE (2020-01-27): The SuperMicro X10SRH-CLN4F motherboard boots just fine from a root-on-ZFS disk in UEFI mode from the built-in SAS HBA. The only required change is the last step in the description below; to add a delay before attempting to mount ZFS volumes at boot-time.

There is a potential drawback to installing Proxmox in root-on-ZFS mode in a UEFI system: The drive gets partitioned, so ZFS doesn’t get uninhibited access to the entire block storage. This may or may not make a difference for performance, but in terms of speed on an SSD solution, I haven’t really seen any cause for concern for my real-world use case. An alternative would be to install the underlying operating system to a separate physical drive.

Also note that the workaround below works on a single vFAT volume. Since FAT doesn’t support symlinks, kernel or initramfs updates in Proxmox/Debian will require some manual work, which most sane people would likely wish to avoid.

I’m leaving the rest of my article intact for posterity:

---

My workaround was to place /boot – not the system – on a USB stick connected directly to the motherboard.

Process

After installation, reboot with the Proxmox installation medium, but select Install Proxmox VE (Debug mode).

When the first shell appears, Ctrl+D to have the system load the necessary drivers.

Check the name of the USB drive.

lsblk

Partition it.

cfdisk /dev/sdb

Clear the disk, create an EFI System partition and write the changes. Then apply a FAT to the new partition

mkfs.vfat /dev/sdb1

Prepare to chroot into the installed Proxmox instance

mkdir /media/rescue
zpool import -fR /media/rescue rpool
mount -o bind /dev /media/rescue/dev
mount -o bind /sys /media/rescue/sys
mount -o bind /dev /media/rescue/dev
chroot /media/rescue

Make room for the new /boot

mv /boot /boot.bak

Edit /etc/fstab and add the following:

/dev/sdb1 /boot vfat defaults 0 0

Make the stick bootable

mount -a
grub-install --efi-directory=/boot/efi /dev/sdb
update-grub
grub-mkconfig -o /boot/grub/grub.cfg

Exit the chroot, unmount the ZFS file system (zfs export rpool)and reboot

In my specific case I had a problem where I got stuck in a shell with the ZFS pool not mountable.

/sbin/zpool import -Nf rpool

Exit to continue the boot process. Then edit /etc/default/zfs and edit a delay before attempting to boot the file system.

ZFS_INITRD_PRE_MOUNTROOT_SLEEP=15

Then apply the new configuration:

update-initramfs -u