cryptsetup can't get input at boot.

Bug #518964 reported by Stephen Day
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: cryptsetup

The karmic startup scripts run cryptsetup in parallel with other scripts and/or getty. The effect is that user input doesn't get delivered to cryptsetup making it impossible to enter a passphrase to decrypt the disks mentioned in /etc/crypttab at boot time. This can also result in the passphrase being echoed to the screen.

This errant behavior appears both on encrypted disks devices and encrypted md devices. This was not the case with the last release of ubuntu.

I have only tested with luks encryption. This does not affect encrypted root disks which are setup by initfs.

Tags: cryptsetup
Revision history for this message
Stephen Day (sd) wrote :

Please note this is not the same, but does appear to be related to 445888 ( X starts at the same time as cryptsetup. )

Kees Cook (kees)
security vulnerability: yes → no
visibility: private → public
Revision history for this message
Michael Evans (mjevans1983) wrote :

I noticed this regression after re-installing 9.10 and performing normal system updates. I was backing out of a full Lucid install to dual 9.10 / lucid installs.

I can enter the passwords for / and swap correctly within the initrd.
Then fsck is run on /boot (/dev/sda3) and / (lvm).

Next a second round of cryptsetup runs, indicating that the devices that had been started are running, and starting that it is about to try starting lin-home_crypt ; which is when it then displays a message:

One or more of the mounts listed in /etc/fstab cannot yet be mounted:
(ESC for recovery shell)
/home: waiting for /dev/mapper/lin-home_crypt

No input displays on the screen, but I am unable to enter the password to unlock exactly what it needs.

A workaround of appending break=bottom and manually running cryptsetup luksOpen src destname allows me to unlock the device before this race condition occurs.

Changed in cryptsetup (Ubuntu):
status: New → Confirmed
Changed in cryptsetup (Ubuntu):
assignee: nobody → Dmitrijs Ledkovs (xnox)
Changed in cryptsetup (Ubuntu):
assignee: Dimitri John Ledkov (xnox) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.