FS#22673 - Unlocking encrypted drive fails at boot

Attached to Project: Arch Linux
Opened by Jon Gjengset (Jonhoo) - Sunday, 30 January 2011, 22:50 GMT
Last edited by Thomas Bächler (brain0) - Monday, 07 February 2011, 08:12 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture i686
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
At boot time, I get "Unlocking encrypted volumnes: ... chome..failed", followed by what looks like the output of cryptsetup called without any arguments ([-?|--help] [--usage] [--version] ... <action> ...)

I am not entirely sure what upgrade caused this unfortunately, but subsequent upgrades have not resolved the problem.
I found this thread in the forum (https://bbs.archlinux.org/viewtopic.php?pid=698105#p698105) which describes the exact same problem, but his solution did not work for me.
My setup is running plain partitions, i.e. no LVM.

Additional info:
Very similar to bug #18087.
* package version(s)
initscripts 2010.07-2
device-mapper 2.02.81-1
cryptsetup 1.2.0-1
kernel26 2.6.36.3-2
udev 165-1
* config and/or log files etc.

/etc/fstab
/dev/mapper/cswap swap swap defaults 0 0
/dev/mapper/chome /home ext4 defaults,relatime 0 1
# The swap line has never worked because createswap complains that the partition is already formatted..?

/etc/crypttab
swap /dev/sda3 SWAP "-c aes-xts-plain -h whirlpool -s 512"
chome /dev/sda5 ASK "-c aes-xts-plain -h whirlpool -s 512"
# swap seems to be working fine...

Also, there are no .pacsave or .pacnew files on the system that could contain a fix..
Unlocking the drive manually in single user mode works fine, and subsequent mounting also works without problems using:
cryptsetup luksOpen /dev/sda5 chome

Steps to reproduce:
Not sure how this happened... Have an encrypted partition?
This task depends upon

Closed by  Thomas Bächler (brain0)
Monday, 07 February 2011, 08:12 GMT
Reason for closing:  Not a bug
Comment by Jon Gjengset (Jonhoo) - Sunday, 30 January 2011, 23:52 GMT
Just as a side note, the swap problem is explained and fixed here: https://bbs.archlinux.org/viewtopic.php?pid=511016#p511016
Comment by Jon Gjengset (Jonhoo) - Monday, 31 January 2011, 00:01 GMT
Also, before anyone asks, I have not changed the crypttab file to cause this problem. It simply worked one day, and after an upgrade, it stopped working..
Comment by Jordan Milne (jordan.milne) - Wednesday, 02 February 2011, 07:30 GMT
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.
Comment by Jens Adam (byte) - Thursday, 03 February 2011, 17:15 GMT
The point of LUKS is that the used cipher is recorded in the metadata, so with a LUKS-formatted device/partition in combination with "ASK" you should leave the fourth field empty. That was always the case with Arch's crypttab.
Comment by Thomas Bächler (brain0) - Monday, 07 February 2011, 08:11 GMT
'Problem was therefore fixed by removing "-s". Note that this is a backwards incompatible change that should probably be mentioned somewhere?'

'-s' was never a valid option with luksOpen, I have no idea why it would accept it in the past. Closing.

Loading...