zpool bootfs restrictions when boot and root pools are different?
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 26 Dec 2022 19:32:05 UTC
I asked this on freebsd-questions a while back and didn't get an answer, so I'm trying here instead. The setup: "bootkey" pool: A UEFI-boot USB flashdrive with /boot on it. It's ZFS so I can use copies=2 and scrubs to ensure integrity, but it was UFS in its prior incarnation. "nvme" pool: Contains the BootEnv-managed root. The nvme pool sits on GELI-encrypted drives, and the keys are on the bootkey pool. This is so the keys are never on the same devices as the partitions they decrypt. This is where I run into an issue: BootEnv uses the bootfs property to steer the loader, but I can't set bootfs to point to a different pool: # zpool set bootfs=nvme/ROOT/13.1p5 bootkey cannot set property for 'bootkey': 'nvme/ROOT/13.1p5' is an invalid name In order for BootEnv to "work" I let it set bootfs on nvme instead: # zpool get bootfs NAME PROPERTY VALUE SOURCE bootkey bootfs - default mech bootfs - default nvme bootfs nvme/ROOT/13.1p5 local and have a script that copies that value to /boot/loader.conf: # grep ROOT /boot/loader.conf vfs.root.mountfrom="zfs:nvme/ROOT/13.1p5" That somewhat defeats the ease of BootEnv, but does make the rest of it work. With neither vfs.root.mountfrom nor bootfs set on bootkey, the kernel assumes /boot is on the root filesystem then panics because it can't find /sbin/init. And now the questions: 1. Why does the bootfs property restrict the value to only datasets on that pool if it also requires the pool name in the value? 2. Is there a way around this that would make BootEnv work without vfs.root.mountfrom in loader.conf? 3. If the answer to (2) is no, would it be welcome if I added to bectl the option to have it use vfs.root.mountfrom instead of bootfs?