[solved] Bootup: unlocking encrypted devices fails

deconstrained · 2010-01-30 00:37:24

EDIT: For the record, I solved this problem by commenting out my crypttab / fstab entries for the encrypted home partition, booting without mounting /home, then uncommenting the entries and upgrading the kernel/rebuilding the ramdisk (pacman -Sy kernel26, which of course ran mkinitcpio). Before trying this, however, I also tried changing my crypttab entry to "home /dev/sda3 ASK"; I realized that the "ASK" keyword is necessary instead of "none" as in other distros, because of how rc.sysinit parses /etc/crypttab. This didn't fix immediately, although it was necessary, so it was definitely a combination of this AND running mkinitcpio in the non-chrooted environment.

At boot time, just after the message "Unlocking encrypted volumes: home...failed" I'm seeing a bunch of text that looks like output from cryptsetup.static being improperly called; it includes a bunch of what looks like option flags enclosed in square brackets and separated by spaces (i.e. [--usage] [--vl-verbose] )

This is what I did before this started happening (In order to remove encryption on my root FS):

1. I made a backup clone of my hard drive, then made a new filesystem on the root partition.
2. I updated /etc/crypttab, /etc/fstab and /etc/mkinitcpio.conf accordingly:

/etc/fstab wrote:

UUID=[uuid-of-my-root] / reiserfs defaults 0 1
UUID=[uuid-of-my-boot] /boot ext2 defaults 0 1
/dev/mapper/home /home jfs defaults,iocharset=utf8 0 1

/etc/crypttab wrote:

home /dev/disk/by-uuid/[uuid-of-my-home-partition] none luks

(I want to enter my passphrase at boot time)
In mkinitcpio.conf I removed "encrypt" from the hooks, but left the modules dm-crypt, aes-x86_64 and jfs/reiserfs in the modules array.
3. I chrooted into the root partition (after mounting the proc and dev filesystems), mounted boot, and generated an interim ramdisk with mkinitcpio, then added an entry in /boot/grub/menu.lst for the image.

I have tried quite a number of things already, including removing the "luks" extension from the end of my /etc/crypttab entry, and enclosing none in double quotes. Should I perhaps move the filesystem and encryption modules in mkinitcpio.conf to rc.conf? Also, would it help if I removed the "filesystems" hook from mkinitcpio.conf, and regenerated the ramdisk?

Last edited by deconstrained (2010-01-30 03:18:15)

gile · 2010-01-31 01:06:49

I confirm the same issue, but I found out that this was caused by initscripts-2010.01-1, so downgrading back to the old version fixed the issue.

wget http://www.schlunix.org/archlinux/core/ … pkg.tar.gz
pacman -U initscripts-2009.08-1-i686.pkg.tar.gz

Hope someone else will find this helpful.

brain0 · 2010-01-31 13:05:31

There have been no changes in the cryptsetup code of rc.sysinit between 2009.08-1 and 2010.01-1. Not a single line.

gile · 2010-01-31 21:09:17

So I get this with the new initscripts package:

:: Unlocking encrypted volumes: home..failed swap..ok mand failed: Error opening device: No such file or directory [FAIL]

The only difference (for the cryptsetup / lvm part) which I saw between the two versions is this line:

/sbin/lvm vgscan --ignorelockingfailure --mknodes >/dev/null

Which is missing in the latest package, but I am no expert in sysinit scripts, and I confirm that adding that line doesn't resolve the issue.

gile · 2010-02-02 06:59:54

http://bugs.archlinux.org/task/18087

it works after updating the following: device-mapper 2.02.60-2 cryptsetup 1.1.0-1 lvm2 2.02.60-2 udev 151-2

brain0 · 2010-02-02 13:09:53

Good, thanks for the valuable information. I was hoping it was "just that".

Jonhoo · 2011-01-24 12:21:46

Hey fellow archers,

Sorry to revive this old thread, but the issue seems to have come back up again..
I'm having the exact same problem as the OP, but his solution does not work for me..

Anything I can post to help debugging, because I'm completely stumped..?

bender02 · 2011-01-26 16:35:59

Same problem here; things are working for me with lvm2-2.02.79 and not with the newer ones.

From the bugreport linked above it looks like that it also depends on some other packages being the same version (eg device-mapper) and there've been some updates of those today; I haven't tested with them yet.

If it continues not to work, either reopen that bug above or open a new one.

Last edited by bender02 (2011-01-26 16:36:43)

Jonhoo · 2011-01-30 10:54:48

Still doesn't work after updates, reopen request filed.

Jonhoo · 2011-01-30 22:51:01

Sorry, had to open a new bug.
New bug @ https://bugs.archlinux.org/task/22673

jordan.milne · 2011-02-03 00:37:45

I had this issue yesterday while installing arch with an encrypted root and home partition. It's worth noting that a simple

home_crypt /dev/sda3 ASK luks

in crypttab won't work anymore. Change it to

home_crypt /dev/sda3 ASK "-c {cipher} -h {hash}"

You can get that info by running `cryptsetup status /dev/mapper/home_crypt` if you're able to get into maintenance mode to manually use luksOpen. Or, if you used the defaults, cryptsetup --help will tell you the cipher and hash.

cryptsetup should probably allow, but ignore the -s parameter for luksOpen in the next release so this doesn't happen again.

Unfortunately, in the meantime, half of the wiki's how-tos on setting up encrypted systems are broken.

Last edited by jordan.milne (2011-02-03 00:41:35)

treysis · 2011-02-06 03:09:15

actually, with LUKS, you don't need to specify hash and cipher as it's stored in the metadata, one of the main advantages of the idea behind LUKS (it was needed for cryptsetup long time ago when LUKS wasn't used by cryptsetup as default).

Unfortunately, there seems to be a problem in the current release if you enter the password as plaintext in /etc/crypttab. This way at boot cryptsetup is not able to unlock the volume. A workaround is to use the feature of multiple keyslots and associate one slot with a keyfile. Reading the keyfile seems to be working without problems!

jalu · 2011-08-27 21:12:54

Same problem here.

/etc/crypttab

swap /dev/sda2 SWAP -c aes-xts-plain -h whirlpool -s 512

/etc/fstab

/dev/mapper/swap swap swap defaults 0 0

During boot, I get the following message: "unlocking encrypted volumes: swap..failed"

edit: Looks like I needed quotes around the options I was using in /etc/crypttab. Changing that line to the following solved my problem.

swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512"

Last edited by jalu (2011-11-22 19:42:42)

Wallsy · 2012-05-21 10:59:13

I am having an issue with this at the moment, exactly the same problem as jalu, however mine are already quoted.

Any ideas?

jalu · 2012-06-05 03:24:18

Wallsy wrote:

I am having an issue with this at the moment, exactly the same problem as jalu, however mine are already quoted.
Any ideas?

My problem eventually resurfaced, even with the quotes. I seem to remember hearing that it was due to a bug in some package. Not sure.

Arch Linux

#1 2010-01-30 00:37:24

[solved] Bootup: unlocking encrypted devices fails

#2 2010-01-31 01:06:49

Re: [solved] Bootup: unlocking encrypted devices fails

#3 2010-01-31 13:05:31

Re: [solved] Bootup: unlocking encrypted devices fails

#4 2010-01-31 21:09:17

Re: [solved] Bootup: unlocking encrypted devices fails

#5 2010-02-02 06:59:54

Re: [solved] Bootup: unlocking encrypted devices fails

#6 2010-02-02 13:09:53

Re: [solved] Bootup: unlocking encrypted devices fails

#7 2011-01-24 12:21:46

Re: [solved] Bootup: unlocking encrypted devices fails

#8 2011-01-26 16:35:59

Re: [solved] Bootup: unlocking encrypted devices fails

#9 2011-01-30 10:54:48

Re: [solved] Bootup: unlocking encrypted devices fails

#10 2011-01-30 22:51:01

Re: [solved] Bootup: unlocking encrypted devices fails

#11 2011-02-03 00:37:45

Re: [solved] Bootup: unlocking encrypted devices fails

#12 2011-02-06 03:09:15

Re: [solved] Bootup: unlocking encrypted devices fails

#13 2011-08-27 21:12:54

Re: [solved] Bootup: unlocking encrypted devices fails

#14 2012-05-21 10:59:13

Re: [solved] Bootup: unlocking encrypted devices fails

#15 2012-06-05 03:24:18

Re: [solved] Bootup: unlocking encrypted devices fails

Board footer