# Geli - can't decrypt one disk at bootup



## xy16644 (Jun 8, 2014)

I have the following disk setup in my server:
2 x SSD drives in a ZFS mirror
1 x SATA drive (just a single disk with ZFS)
All the above drives are encrypted using GELI.

My ZFS root sits on the mirrored SSD drives. All the drives are encrypted and use the same encryption key. Yesterday I rebooted my server after applying the latest security updates and the first disk would not accept the password no matter how many times I tried. Therefore after booting up my ZFS mirror was broken.

Here's where it gets even weirder. After booting up my ZFS mirror was broken (since the first disk in the mirror couldn't be unlocked/decrypted using the password I normally use) but if I run `geli attach -k /boot/bootdir/encryption.key /dev/da0p1.eli` and enter the exact same password that I tried at bootup, it works! After that I bring the disk online and the ZFS mirror resilvers and all is good. This is worrying however as, if the second disk fails and I reboot I won't be able to boot up the machine.

So why can't I decrypt the one disk at bootup? I know I am entering the correct password as the other two disks decrypt fine. In the past I have decrypted all three disks when rebooting with no issues at all and my /boot/loader.conf hasn't changed.


----------



## wblock@ (Jun 8, 2014)

Has the hardware changed at all, like a different motherboard or keyboard?  On a couple of notebooks I've tried, the keyboard did not work until a few seconds after boot.  Keys that were pressed during that time were lost.


----------



## xy16644 (Jun 8, 2014)

Absolutely nothing has changed with the hardware. I tried many times by rebooting but every time I could not unlock the first disk. I know the bootup screen messages get in the way of the first password prompt but that has never been a problem before as I usually just hit enter and it clears the screen which then takes me back to the password prompt.


----------



## xy16644 (Aug 13, 2014)

This seems to be a bug and is fixed:

https://svnweb.freebsd.org/base?view=re ... ion=267860

I have yet to update my system to 267860 to test this (I am currently running 10-STABLE r267210)

Hope this helps someone, it drove me mad!


----------



## jrm@ (Aug 15, 2014)

I gather you watch BSDNow. ;-)


----------



## xy16644 (Aug 15, 2014)

jrm said:
			
		

> I gather you watch BSDNow. ;-)



Guilty!


----------

