Booting does not wait until "remaining" disks have been unlocked

Bug #462224 reported by Gillen Daniel
This bug report is a duplicate of:  Bug #454898: cryptsetup starts too early. Edit Remove
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: cryptsetup

Hi

I'm using current xubuntu 9.10 release and installed it using the alternate disk. I set up an encrypted root partition and everything seemed to work fine. During installation, I also set up a raid 10 array spawning over 4 disks. After setup, I fdisk'ed /dev/md0 and created one partition using all available space. I then encrypted this partition (/dev/md0p1) using "cryptsetup luksCreate /dev/md0p1" and afterwards unlocked it and formated it.

As I want to use this partition as local storage place, I added the following line to /etc/crypttab to unlock this partition during boot (I added a line to /etc/fstab too, in order to mount the unlocked partition).

local_crypt /dev/disk/by-uuid/<uuid> none luks

During reboot, I am asked the password for the root partiton first, which is ok, and afterwards, I am asked the password for /dev/md0p1 which is also ok, but booting continues after +-1 minute if I dont' enter a password and when entering a password, the disk isn't unlocked.

After boot, I can unlock the partition manually and mount it without any problems.

I had the same setup with xubuntu 9.04 and there it worked fine. (It was a single disk, and no raid. But that shouldn't make any difference I think)

Shouldn't /etc/rcS.d/S28cryptdisks interupt booting until the disks are unlocked or isn't this possible anymore with the new upstart?

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.