cryptsetup starts too early
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cryptsetup (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Karmic |
Fix Released
|
High
|
Steve Langasek | ||
Lucid |
Fix Released
|
High
|
Unassigned |
Bug Description
I hope that the tilte is correct.
I have encrypted a sdcard using cryptsetup.
During the boot sequence, it does not ask for the password. I fail to find an error message in the logs.
I think my config is ok because /etc/init.
* Starting remaining crypto disks...
* data (starting)
Enter passphrase to unlock the disk /dev/mmcblk0p1 (data):
(I enter the password)
key slot 0 unlocked.
Command successful.
data (started)... [ OK ]
and then, "mount -a" mounts the encrypted partition.
It looks like cryptsetup starts *before* /dev/mmcblk0p1 is created.
That would explain why cryptsetup fails to see my encrypted disk at boot time.
My config files:
crypttab:
# <target name> <source device> <key file> <options>
data /dev/mmcblk0p1 none luks
fstab:
/dev/mapper/data /home/gnata/data ext4 defaults 0 1
TEST CASE:
1. install the cryptsetup package from karmic
2. Configure a device that will be slow to be initialized by the kernel, such as a USB drive or an SD card, to be used with cryptsetup by running commands such as this:
cryptsetup luksFormat /dev/mmcblk0p1
cryptsetup luksOpen /dev/mmcblk0p1 slowdisk
mkfs.ext4 /dev/mapper/
3. Set the device up to be decrypted at boot time by adding a line such as this to /etc/crypttab:
slowdisk /dev/mmcblk0p1 none luks
4. Set the device up to be mounted at boot time by adding a line such as this to /etc/fstab:
/dev/
5. reboot a few times (in single user mode, to prevent gdm from starting and killing usplash); verify that the passphrase prompt for decrypting this disk is racy, and does not always appear
6. install the cryptsetup package from karmic-proposed
7. reboot a few times (in single user mode, again); verify that the passphrase prompt now appears reliably.
REGRESSION POTENTIAL:
With this change cryptsetup will no longer be racing udev; however, cryptsetup instances *will* be racing each other. In the unlikely case that a user has CRYPTDISKS_MOUNT set to a non-empty value in /etc/default/
This change also increases the chance that a filesystem not marked as 'bootwait' in /etc/fstab will get in a race with gdm at boot time, leading to the passphrase prompt being masked by X, or cryptsetup fighting X for control of the console. However, that class of race is already present in karmic and documented in the release notes, so I don't think this should be a blocker for SRU.
affects: | ubuntu → cryptsetup (Ubuntu) |
Changed in cryptsetup (Ubuntu): | |
status: | New → Confirmed |
Changed in cryptsetup (Ubuntu): | |
status: | Confirmed → Fix Committed |
importance: | Undecided → High |
Changed in cryptsetup (Ubuntu Karmic): | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in cryptsetup (Ubuntu Karmic): | |
status: | Triaged → In Progress |
assignee: | nobody → Steve Langasek (vorlon) |
description: | updated |
description: | updated |
I confirm the problem on a EEE 901A.
I use an encrypted SD card for my home folder, and even if /etc/crypttab is configured correctly I usually do not get a prompt at the splash screen.
However, I said "usually": sometimes I DO get the prompt as it should be, typically when starting encrypted partitions is delayed by some reason, such as a fsck of the root partition.
So if I have to guess it is really a timing issue.