FreeBSD 10.0: Password problem on encrypted ZFS root

P

picard315

Hi.

I tested a FreeBSD 10.0 install in VirtualBox with encrypted ZFS root as shown here http://www.freebsdnews.net/2013/10/23/f ... ion-video/. For this install I used the i386-disc1 ISO and everything worked fine. Then I tried to do the same install onto an external USB HDD. Because this machine has no optical drive, I used the amd64 memstick image. The install went smoothly but when trying to boot the installed system geli does not accept the password I used for encryption.

What am I doing wrong? Am I missing something?
 
Are you using a USB keyboard? I had a similar issue with one of my machines running 9.1-RELEASE. A little searching revealed others had too; see problem reports kern/120090 and kern/105368. Thread 1358 also discusses it. You may be experiencing the same issue.

You can try adding one of the following in /boot/loader.conf:
Code: 
hint.kbdmux.0.disabled="1"
or
Code: 
hint.atkbd.0.disabled="1"
hint.atkbdc.0.disabled="1"
 
Thank you for your hint. The USB keyboard wasn't the issue, but it helped anyway.

After some more rebooting I recognized, that geli was sometimes asking for the password of /dev/da0p4 and sometimes for /dev/da1p4. Then I remembered, that in /boot/loader.conf the configuration of geli pointed to the device da1p4. I changed the configuration to use da0p1 and everything worked like a charm.

So the source of the issue is, that when I installed FreeBSD using the memory stick, my USB HDD was named da1 and the installer configured geli to use da1. After reboot and removing the memory stick, the harddisk was named da0 and the configuration in /boot/loader.conf did not match anymore.
 
I'm glad you identified the cause, even if it was totally unrelated to keyboards :) The solution to problem report kern/167562 suggests that it should be possible to use GPT labels (listed in /dev/gpt/; see gpart(8) for how to set) in /boot/loader.conf instead of referencing by device number. This would be ideal for situations like yours as it wouldn't matter if the device number changed after installation. Presumably the same would be true for GPT identifiers (listed in /dev/gptid/). I'll have to try a set up using labels when I have a moment as I had always assumed that the name of the variable was important. Plus, perhaps drafting a suggested addition for the geli(8) man page if it hasn't been done already.

You should be able to use any variable name prefix for the keyfiles,
you just have to have all three variables:

<name>_load="YES"
<name>_type="<provider>:geli_keyfile0"
<name>_name="/path/to/your/keyfile"

Those three tells the loader to load the given file. GELI uses what's in
_type to find keyfiles. If you have gpt/foo provider you have to be sure
to put it into _type's value, but you can use any prefix you like, eg.

doesntmatter_load="YES"
doesntmatter_type="gpt/foo:geli_keyfile0"
doesntmatter_name="/boot/keys/key"
Click to expand...
 
You must log in or register to reply here.
Back
Top