Solved Multiple zpools on boot, broke in 10.1

S

starslab

Back on FreeBSD 9, I setup a four-drive multipurpose/NAS machine for my personal use at home. The drives all have the same configuration:

GPT partition table
p1 - GPT boot partition
p2 - 8GB UFS /boot partition - gmirrored together (pegasus-boot)
p3 - 80GB GELI ZFS-mirror (pegasus-root)
p4 - 1.6ishTB GELI ZFS-RaidZ1 (pegasus-data)

/etc/fstab contains one line:
Code: 
#Device                         MntPt           FSType  Opts    Dump    Pass
/dev/mirror/pegasus-boot        /bootpart       ufs     rw      0       1

/bootpart has a single directory under it - boot
/boot is a symlink to /bootpart/boot

/boot/zfs/zpool.cache contains a cache file describing both ZFS pools.

On FreeBSD 9, this worked as expected - both pools were available to the system at boot-time.

I've now migrated to FreeBSD 10.1 (I skipped 10.0), and I'm finding that pegasus-data is no longer available at boot-time. A simple " zpool import -a" fixes it, but it never sticks across reboots.

What's the cleanest way to fix this?
 
I'm not familiar with GELI configurations. I suspect that may be complicating things. Perhaps re-setup the GELI? You could try specifying the specific pool instead of -a. It could be something to do with the zpool cache, try temporarily moving the zpool cache. It may re-create a healthy one.

Personally I prefer to keep my root pool separate from my data pools. But it doesn't sound like that's your problem.
 
I'm pretty sure the issue isn't GELI per se, but rather the very odd partition structure that this use of GELI requires. The zpool.cache file lives on the small UFS partition in the expected location (boot/zfs/zpool.cache), and this worked in FreeBSD-9, but somehow FreeBSD-10 handles loading that file on startup differently.

I don't even know if it's the kernel or the bootstrap that handles loading that file.

If it's the kernel, and the file is only loaded after the root filesystem is imported on startup, then (/boot/zfs/zpool.cache) does not exist, because /boot is a symlink to /bootpart/boot, which isn't mounted until the UFS mounts are done.

hrm. Were changes made to the bootstrap code? I haven't written the GPT bootcode stuffs since before the upgrade...
 
Got it working.

I unmounted /bootpart, and created /bootpart/boot/zfs/zpool.cache, then remounted /bootpart. So the kernel is able to find zpool.cache in the expected location (symlinked /boot -> /bootpart/boot/zfs/zpool.cache) at boot-time.

Administratively this is a less than desirable solution because it not only makes things more complex but makes them hidden more complex, but it works and it's good enough for me.
 
You must log in or register to reply here.
Back
Top