** Description changed:
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.d/cryptdisks start does work:
* 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/slowdisk
+ cryptsetup luksFormat /dev/mmcblk0p1
+ cryptsetup luksOpen /dev/mmcblk0p1 slowdisk
+ mkfs.ext4 /dev/mapper/slowdisk
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
+ 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/mapper/slowdisk /mnt ext4 defaults,bootwait 0 0
+ /dev/mapper/slowdisk /mnt ext4 defaults,bootwait 0 0
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/cryptdisks,
*and* has more than one volume configured in /etc/crypttab, the upstart jobs
can race each other and one job can unmount the filesystems before the other
job has a chance to use them. However, even in this case the cryptdisks-enable
catch-all job should still take care of it, unless the second failed decrypt
job then unmounts the filesystem when cryptdisks-enable needs it (a double
race).
+
+ 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.
--
cryptsetup starts too early
https://bugs.launchpad.net/bugs/454898
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
