| 2009-10-18 19:09:43 |
Xavier Gnata |
bug |
|
|
added bug |
| 2009-10-18 19:59:00 |
Søren Bredlund Caspersen |
affects |
ubuntu |
cryptsetup (Ubuntu) |
|
| 2009-11-03 10:59:48 |
papukaija |
cryptsetup (Ubuntu): status |
New |
Confirmed |
|
| 2009-12-15 05:02:13 |
Steve Langasek |
cryptsetup (Ubuntu): status |
Confirmed |
Fix Committed |
|
| 2009-12-15 05:02:15 |
Steve Langasek |
cryptsetup (Ubuntu): importance |
Undecided |
High |
|
| 2009-12-15 05:02:32 |
Steve Langasek |
nominated for series |
|
Ubuntu Karmic |
|
| 2009-12-15 05:02:32 |
Steve Langasek |
bug task added |
|
cryptsetup (Ubuntu Karmic) |
|
| 2009-12-15 05:02:32 |
Steve Langasek |
nominated for series |
|
Ubuntu Lucid |
|
| 2009-12-15 05:02:32 |
Steve Langasek |
bug task added |
|
cryptsetup (Ubuntu Lucid) |
|
| 2009-12-15 05:02:47 |
Steve Langasek |
cryptsetup (Ubuntu Karmic): status |
New |
Triaged |
|
| 2009-12-15 05:02:51 |
Steve Langasek |
cryptsetup (Ubuntu Karmic): importance |
Undecided |
High |
|
| 2009-12-15 05:03:13 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-core-dev/cryptsetup/ubuntu |
|
| 2009-12-16 02:15:08 |
Launchpad Janitor |
cryptsetup (Ubuntu Lucid): status |
Fix Committed |
Fix Released |
|
| 2009-12-16 06:55:48 |
Steve Langasek |
cryptsetup (Ubuntu Karmic): status |
Triaged |
In Progress |
|
| 2009-12-16 06:55:51 |
Steve Langasek |
cryptsetup (Ubuntu Karmic): assignee |
|
Steve Langasek (vorlon) |
|
| 2009-12-16 07:52:32 |
Steve Langasek |
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.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 |
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
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/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. |
|
| 2009-12-16 08:37:42 |
Steve Langasek |
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.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
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/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. |
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
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/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. |
|
| 2009-12-18 11:55:50 |
Martin Pitt |
cryptsetup (Ubuntu Karmic): status |
In Progress |
Fix Committed |
|
| 2009-12-18 11:55:57 |
Martin Pitt |
tags |
|
verification-needed |
|
| 2009-12-18 21:40:57 |
Søren Bredlund Caspersen |
removed subscriber Søren Bredlund Caspersen |
|
|
|
| 2009-12-22 16:08:18 |
Pille |
removed subscriber Pille |
|
|
|
| 2010-01-14 12:14:56 |
Launchpad Janitor |
cryptsetup (Ubuntu Karmic): status |
Fix Committed |
Fix Released |
|
| 2010-02-15 19:17:31 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/cryptsetup |
|
| 2010-02-20 03:45:23 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/karmic-updates/cryptsetup |
|
| 2013-11-01 16:56:30 |
Launchpad Janitor |
branch linked |
|
lp:~xnox/debian/sid/cryptsetup/ubuntu |
|
