geli decrypt only one partition

[Fabian Keil]

joerg_surmann <joerg_surmann at snafu.de> wrote:

> Sorry, i no had enough time for this geli problem.
> I work with a testsystem.
> When start booting in verbose mode the system found the keypaths.
> 
> Preloaded ada0p4:geli_keyfile0 "/root/keys/ada0p4.key" at 0xc14bf540.
> Preloaded ada1p4:geli_keyfile1 "/root/keys/ada1p4.key" at 0xc14bf598.
> 
> loader.conf
> geom_eli_load="YES"
> 
> geli_ada0p4_keyfile0_load="YES"
> geli_ada0p4_keyfile0_type="ada0p4:geli_keyfile0"
> geli_ada0p4_keyfile0_name="/root/keys/ada0p4.key"
> 
> geli_ada1p4_keyfile1_load="YES"
> geli_ada1p4_keyfile1_type="ada1p4:geli_keyfile1"
> geli_ada1p4_keyfile1_name="/root/keys/ada1p4.key"
> 
> zfs_load="YES"
> vfs.root.mountfrom="zfs:zroot"
> 
> on boottime i can decrypt ada0p4.
> for ada1p4 ... wrong key.
> 
> i can decrypt ada1p4 later by hand with the keyfile like loader.conf.
> same situation.
> ada0p4 and ada1p4 are a zfs mirror.

Like I already wrote before, the problem is most like that you named
the first keyfile for the second provider keyfile1 instead of keyfile0.

The keyfile numeration restarts for each provider and geli
will not use keyfile1 if keyfile0 doesn't exist.

I missed that the "Preloaded ..." messages are a bit misleading
here as they only show that the loader lines are recognized and
that the kernel read the files, not that geli does anything useful
with them.

If you increase kern.geom.eli.debug you'll probably see that
/root/keys/ada0p4.key is used by geli while /root/keys/ada1p4.key
isn't.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120701/dfaee2b0/signature.pgp