zpool-zfs'es on a GELI-encrypted volume are not mounted at boot [patch included]

[Christopher J. Ruwe]

On Sun, 10 Jul 2011 22:23:36 +0400
Pan Tsu <inyaoo at gmail.com> wrote:

> "Christopher J. Ruwe" <cjr at cruwe.de> writes:
> 
> [...]
> > /etc/rc.d/zvol
> > /etc/rc.d/zfs
> > /etc/rc.d/dumpon
> > /etc/rc.d/ddb
> > /etc/rc.d/initrandom
> > /etc/rc.d/geli
> > /etc/rc.d/gbde
> > /etc/rc.d/encswap
> > /etc/rc.d/ccd
> > /etc/rc.d/swap1
> > /etc/rc.d/fsck
> > /etc/rc.d/root
> > /etc/rc.d/hostid_save
> > /etc/rc.d/mdconfig
> > /etc/rc.d/mountcritlocal
> >
> > This makes sense to me and reflects the order I assumed in my
> > description. The question remains, however, if my configuration is
> > of any in {unusual, ..., stupid} as I require first zfs mount of /,
> > then GELI-unlock and then zfs mount of {/usr,/usr/local, ...}.
> 
> Do you mount the root pool over smth else? Otherwise, root should be
> mounted by kernel before init(8) is started. And /etc/rc.d doesn't
> exist before root is mounted.

I mount root-pool via 

zfs_load="YES"
vfs.root.mountfrom="zfs:rpool/root"

in /boot/loader.conf.  So far, all is right from what I understand.
 
> I think the correct order is
> 
>   0 vfs_mountroot*
>   ..
>   2 rc.d/zvol (pre v28)
>   ..
>   6 rc.d/geli
>   ..
>   15 rc.d/mountcritlocal
>   16 rc.d/zfs
> 
> where extra datasets from the root pool can be mounted via fstab at
> rc.d/mountcritlocal time. Not sure if you import geli pool during boot
> or not and leak its configuration via zpool.cache.

In this setup, I should not have any problems. However, I do not realize (and very much doubt) that I changed anything in the order of the services (lacking the capability to deterministically do so, anyway).

From rcorder I understand that all that is required to set rcorder right would be to change /etc/rc.d/zfs to include a REQUIRE: geli, so that my geli-encrypted volume would be unlocked before all zfs-datasets are mounted?
If so, what could be the reason that my rcorder-setup deviates from the standard and how could I coerce it back to standard?

Thank you for your help so far, cheers
-- 
Christopher J. Ruwe
TZ GMT + 2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20110711/6d5bc138/signature.pgp