Bug 519644 - Boot fails with additional encrypted partition
Summary: Boot fails with additional encrypted partition
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-08-27 08:58 UTC by Sven Lankes
Modified: 2009-09-03 18:13 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-09-03 18:13:30 UTC
Type: ---

Attachments (Terms of Use)
lsinitrd of mkinitrd generated initrd (23.10 KB, text/plain)
2009-08-28 19:33 UTC, Sven Lankes
no flags Details

Description Sven Lankes 2009-08-27 08:58:29 UTC
Description of problem:

I have the following setup that fails to boot when using a dracut generated initrd:

Encrypted root, encrypted 2nd hdd that is decrypted on boot by a luks-keyfile that is located on the encrypted root.

from /etc/fstab:

/dev/mapper/crypt       /crypt                  ext4    defaults        0 2

from /etc/crypttab:

crypt /dev/disk/by-uuid/f4a99d9c-c4b6-468d-bcb7-e24f656eb3d5 /home/user/.keyfile luks

How reproducible:

Boot a system with the above setup using a dracut generated initrd-generic

Actual results:

Boot hangs when trying to mount /crypt

Expected results:

No hang

Additional info:

This setup works fine (and has been working for a long time) when generating a mkinitrd image.

Comment 1 Harald Hoyer 2009-08-27 09:24:16 UTC

rd_LUKS_UUID=<luks uuid of your root> 

to the grub.conf

Comment 2 Harald Hoyer 2009-08-27 09:24:47 UTC
(In reply to comment #1)
> add:
> rd_LUKS_UUID=<luks uuid of your root> 
> to the grub.conf  

to the kernel command line in grub.conf

Comment 3 Sven Lankes 2009-08-28 09:15:04 UTC
Still no luck.

The root partition is unlocked successfully while mounting the crypt partition fails (as it doesn't seem to be unlocked yet).

Comment 4 Harald Hoyer 2009-08-28 10:09:11 UTC
mounting the crypt partition should happen later in the process..

Comment 5 Harald Hoyer 2009-08-28 13:57:13 UTC
<haraldh> zeig mal /etc/crypttab
<haraldh> und 
<haraldh> # ls -l /dev/mapper
<haraldh> killefiz, oh, ja... gib mir auch den output von "lsinitrd <mkinitrd-generated-initrd>"

Comment 6 Sven Lankes 2009-08-28 19:33:00 UTC

luks-1ce54578-5e0b-41a3-b17e-788f0b150b8f UUID=1ce54578-5e0b-41a3-b17e-788f0b150b8f none
share /dev/disk/by-uuid/f3a99d9c-c3b6-468d-aca7-e24f858ea3d5 /home/sven/.keyfile luks

[root@xob ~]# ls -l /dev/mapper/
total 0
crw-rw---- 1 root root  10, 62 2009-08-28 21:18 control
brw-rw---- 1 root disk 253,  0 2009-08-28 21:18 luks-1ce54578-5e0b-41a3-b17e-788f0b150b8f
brw-rw---- 1 root disk 253,  1 2009-08-28 21:18 luks-f3a99d9c-c3b6-468d-aca7-e24f858ea3d5
brw-rw---- 1 root disk 253,  2 2009-08-28 21:18 VolGroupXob-root

from fstab:

/dev/mapper/share       /share                  ext4    defaults        0 2

Changing the the 2nd crypttab line according to the first one will probably fix my bootup issues but this is still a regression as it works fine using mkinitrd generated initrds.

See attached lsinitrd for 2.6.31-0.174.rc7.git2.fc12

Comment 7 Sven Lankes 2009-08-28 19:33:38 UTC
Created attachment 359108 [details]
lsinitrd of mkinitrd generated initrd

Comment 8 Harald Hoyer 2009-08-31 14:00:17 UTC
adding "rd_LUKS_UUID=1ce54578-5e0b-41a3-b17e-788f0b150b8f" to the kernel command line should really help.

Comment 9 Sven Lankes 2009-09-01 08:17:46 UTC
(In reply to comment #8)

> adding "rd_LUKS_UUID=1ce54578-5e0b-41a3-b17e-788f0b150b8f" to the kernel
> command line should really help.  

It doesn't. Booting a mkinitrd initrd gets me a /dev/mapper/share after boot, booting with dracut only gets me /dev/mapper/luks/f3a99d9c-...

This is my kernel-cmdline:

kernel /vmlinuz-2.6.31-0.190.rc8.fc12.x86_64 ro root=/dev/VolGroupXob/root rhgb quiet SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us rd_plytheme=charge rd_LUKS_UUID=1ce54578-5e0b-41a3-b17e-788f0b150b8f

Comment 10 Sven Lankes 2009-09-03 18:13:30 UTC
After updating to Kernel 199 /dev/mapper/share is back


Note You need to log in before you can comment on or make changes to this bug.