Bug 530898 - dracut doesn't seem to consider /etc/crypttab
Summary: dracut doesn't seem to consider /etc/crypttab
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 530411 531991 532598 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-10-25 22:43 UTC by Thomas Meyer
Modified: 2010-01-28 00:52 UTC (History)
6 users (show)

Fixed In Version: 004-4.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-01-28 00:52:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
cryptroot-ask.sh with modifications (1.69 KB, text/plain)
2009-12-31 17:07 UTC, Tomas Hoger
no flags Details

Description Thomas Meyer 2009-10-25 22:43:42 UTC
Description of problem:
My /etc/crypttab contains this line:
luks-home /dev/sda3

But it seems as the initramfs created by dracut seems to create the luks device with "luks-UUID".

So this is why my home directory does not get mounted, because /etc/fstab expects /dev/mapper/luks-home.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Harald Hoyer 2009-10-26 06:38:32 UTC
add "rd_NO_LUKS" to the kernel command line, if your root device is not encrypted, otherwise add "rd_LUKS_UUID=<uuid of root>"

Comment 2 Harald Hoyer 2009-11-05 12:14:24 UTC
*** Bug 531991 has been marked as a duplicate of this bug. ***

Comment 3 Harald Hoyer 2009-11-05 12:24:05 UTC
*** Bug 532598 has been marked as a duplicate of this bug. ***

Comment 4 Harald Hoyer 2009-11-05 12:25:28 UTC
*** Bug 530411 has been marked as a duplicate of this bug. ***

Comment 5 Need Real Name 2009-11-05 20:25:45 UTC
Please can the default be that only the encrypted devices that the user wants loaded do load.

Comment 6 Harald Hoyer 2009-11-06 07:40:34 UTC
rd_LUKS_UUID argument handling was bugged... stay tuned.

Also anaconda will add rd_LUKS_UUID to the kernel command line in future versions.

Comment 7 Thomas Meyer 2009-11-08 22:06:53 UTC
Okay. Thanks for the update. With the current dracut my non-root luks device that get's mounted at "/home" is sometimes created as "luks-home" as stated in the file /etc/crypttab" and sometimes as "luks-UUID". I don't use the option "rd_LUKS_UUID". Is the file "/etc/crypttab" only considerd by dracut, when using the option "rd_LUKS_UUID"?

Comment 8 Bug Zapper 2009-11-16 14:19:06 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 9 Fedora Update System 2009-11-27 15:12:03 UTC
dracut-003-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/dracut-003-1.fc12

Comment 10 Fedora Update System 2009-12-01 04:39:28 UTC
dracut-003-1.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dracut'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-12432

Comment 11 Thomas Meyer 2009-12-01 22:41:53 UTC
Hi,

Thanks for the fix. luks device creation seems to be stable now.

But I still have a problem with resume from disk.

I'v got two entries in /etc/crypttab:
luks-home /dev/sda3
luks-swap /dev/sda4

Both devices using the same password.

pm-hibernate seems to write the ram correctly to disk (/dev/mapper/luks-swap).

I appended this to my kernel command line: "resume=/dev/mapper/luks-swap". But the ramdisk created by dracut fails to resume from above device.

I get an error message like "root not found [..] wait for ever" - need to check for the exact text.

Comment 12 Andriy Tsykholyas 2009-12-01 22:54:57 UTC
dracut-003-1.fc12 does not fixed the problem. Details are below.

Updated dracut:
#yum --enablerepo=updates-testing update dracut
Rebooted. No effect. F12 still asks for passwords for all encrypted partitions.

Updated initramfs as suggested at https://admin.fedoraproject.org/updates/F12/FEDORA-2009-12432:
# mv /boot/initramfs-$(uname -r).img /boot/initramfs-old-$(uname -r).img
# dracut /boot/initramfs-$(uname -r).img $(uname -r)
Rebooted. The problem worsened. F12 now doesn't asks for password at all. Even for encrypted / (root) partition. So, boot fails with following message:
"No root device found.
Boot has failed, sleeping forever"

To boot F12 I use backed up initramfs: /boot/initramfs-old-$(uname -r).img now.

If I can provide some more helpful info (e.g. logs, screen shots, etc), just let me know.

Comment 13 Thomas Meyer 2009-12-12 14:04:07 UTC
(In reply to comment #12)
> dracut-003-1.fc12 does not fixed the problem. Details are below.
> 
> If I can provide some more helpful info (e.g. logs, screen shots, etc), just
> let me know.  

Hi Andriy,

I see the same behaviour on one of my machines, that have encrypted root file system. I can circumvent the problem by removing the resume=/dev/xxx from my boot command line; I guess something with the resume handling seems to be still broken in above stated dracut version.

Do you pass the option "resume=/dev/xxx" in your grub boot command line. When yes, could you please try to remove it and see fedora boots correctly than?

Comment 14 Andriy Tsykholyas 2009-12-12 16:52:05 UTC
Hi Thomas,

I don't pass resume=/dev/xxx to in my grub boot command line. Here is my current grub entry for Fedora:

title Fedora (2.6.31.6-166.fc12.x86_64)
	root (hd0,1)
	kernel /vmlinuz-2.6.31.6-166.fc12.x86_64 ro root=/dev/mapper/luks-ce6a558e-435c-4dc2-a617-8965268ed3ba rd_LUKS_UUID=luks-c1af2161-0e3f-4d67-a9c3-a2e60d030f87 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet nouveau.modeset=0
	initrd /initramfs-2.6.31.6-166.fc12.x86_64.img

As you can see there is no resume=/dev/xxx. And I'm quite sure it was never here. Some more details:
1) I use proprietary Nvidia driver. Probably this should not cause the problem. Also, the problem was already present before I installed this driver.
2) When I installed Fedora 12 I created only [not encrypted] /boot and encrypted /. There were no swap. I've added it later. Maybe that's why resume=/dev/xxx is absent.

Comment 15 Tomas Hoger 2009-12-31 17:05:07 UTC
As I got bitten by this bug after upgrade to F12, I had a look at the current git version (466d8db2) of cryptroot-ask.sh.  I've noticed couple of issues:

- script chokes on empty lines and comments; see rc.sysinit for the way around it
- device name from crypttab is never used (as of 394f30d8), so it won't help in configurations where different name than luks-UUID is expected (e.g. in fstab)
- crypttab can contain UUID=... instead of the device path, which is not handled by the script (isn't that what anaconda adds there by default?)
- 394f30d8 is incorrect, it skips all devices not listed in crypttab assuming root device is never listed there;  it may be possible that anaconda currently does not add root device to crypttab, but it was required (at least in some configurations) by F11's mkinitrd (see bug #501198#c27), so the script needs to assume it is listed there;  what if swap is listed in crypttab?  will resume work?
- issues with ambiguity of device-mapper device names, for encrypted LVs, script is called with $1 = /dev/dm-X, while crypttab may contain /dev/vg0/lvname or /dev/mapper/vg0-lvname; use of readlink is not sufficient way around this ambiguity

I'll attach my modified cryptroot-ask.sh script with multiple enhancements for crypttab reading (some based on rc.sysinit) - comment and empty line handling, UUID= handling, luks name from crypttab is used in luksOpen.  It also contains an ugly hack using dmsetup to convert /dev/dm-X name to /dev/mapper/name, so I can readlink + compare it with what's in crypttab.  Someone more familiar with device mapper can probably figure out more elegant solution.

In my setup, I use encrypted LVs and I'm not using UUIDs or luks-UUID names anywhere.  My crypttab contains entries like "root /dev/vg0/lvroot" and fstab uses /dev/mapper/root name.  That device name is also passed to kernel as root=.  I'm now passing "rd_LUKS_UUID=root rd_LUKS_UUID=swap" on kernel cmdline, so dracut only tries to luksOpen root and swap partitions.  With my script, I can boot and hibernate / resume.

Comment 16 Tomas Hoger 2009-12-31 17:07:17 UTC
Created attachment 381099 [details]
cryptroot-ask.sh with modifications

Harald, can you have a look and see which fixes are ready to be upstreamed now and which may need more work?

Comment 17 Andriy Tsykholyas 2010-01-05 12:20:03 UTC
Hi Tomas,
I'd like to try your cryptroot-ask.sh. Could you, please, provide some instructions how to use it? :)

Comment 18 Tomas Hoger 2010-01-05 12:40:22 UTC
This may help:
- back up your current (working) initramfs file so you can boot again if this does not work for you ;)
- copy the script to /usr/share/dracut/modules.d/50plymouth
- iirc, you need to edit 50plymouth/install and add "inst readlink"
- generate new initramfs
- check that you have readlink and the right cryptroot-ask in new initramfs (it's just gzipped cpio archive)

Anyway, from the comments above, it's not clear to me if you are using "standard" luks-UUID encrypted device names or custom ones defined in crypttab.  My script should only help in the latter case.

HTH

Comment 19 Harald Hoyer 2010-01-05 12:41:11 UTC
(In reply to comment #16)
> Created an attachment (id=381099) [details]
> cryptroot-ask.sh with modifications
> 
> Harald, can you have a look and see which fixes are ready to be upstreamed now
> and which may need more work?  

Looks good! Thank you! Anaconda will write the root to crypttab in the future, so I will add your modifications.

Comment 20 Andriy Tsykholyas 2010-01-05 22:51:01 UTC
Tomas,
thanks for your instructions. I've tried them with no success :(
Then I've read all comments of this bug once again and now I believe my problem is somewhat different:
1) Before installing Fedora I had some encrypted partitions (located on logical volumes). They have distinct passwords and I don't want Fedora to open them.
2) I've installed Fedora on encrypted / partition (also located on logical volume). Password for this partition differs from passwords for partitions mentioned in 1).

The problem.
When Fedora boots it asks password for its / partition. Which is ok. But then it asks passwords for the remaining encrypted partitions. If fact it asks for password 3 times, the first is for its / and I *assume* the remaining 2 are for other partitions, if I just skip the last 2 Fedora boots fine.

Should I report a separate bug?

Comment 21 Tomas Hoger 2010-01-06 14:23:06 UTC
(In reply to comment #20)
> When Fedora boots it asks password for its / partition. Which is ok. But then
> it asks passwords for the remaining encrypted partitions.

I believe rd_LUKS_UUID is what you want to use if you only want to luksOpen certain devices.  Comment #14 suggests that you're not passing UUID of / for rd_LUKS_UUID.

Comment 22 Andriy Tsykholyas 2010-01-06 23:16:41 UTC
(In reply to comment #21)
> I believe rd_LUKS_UUID is what you want to use if you only want to luksOpen
> certain devices.  Comment #14 suggests that you're not passing UUID of / for
> rd_LUKS_UUID.  

Originally my crypttab was (only /, no swap):
luks-ce6a558e-435c-4dc2-a617-8965268ed3ba UUID=ce6a558e-435c-4dc2-a617-8965268ed3ba none

And my grub boot entry originally was:
title Fedora (2.6.31.9-174.fc12.x86_64)
	root (hd0,1)
	kernel /vmlinuz-2.6.31.9-174.fc12.x86_64 ro root=/dev/mapper/luks-ce6a558e-435c-4dc2-a617-8965268ed3ba rd_LUKS_UUID=luks-c1af2161-0e3f-4d67-a9c3-a2e60d030f87 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet nouveau.modeset=0
	initrd /initramfs-2.6.31.9-174.fc12.x86_64.img

The crypttab and grub were in this state after installation (and updating). I only added nouveau.modeset=0, needed for nvidia driver :)
In this state Fedora tries to open all encrypted partitions it can find (I see this by pressing Esc before first password prompt appears).

According to your suggestions I've changed my crypttab to:
root_crypt       /dev/mapper/vg_acer-lv_f12r     none

and grub boot entry to:
title Fedora (2.6.31.9-174.fc12.x86_64) new
	root (hd0,1)
	kernel /vmlinuz-2.6.31.9-174.fc12.x86_64 ro root=/dev/mapper/luks-ce6a558e-435c-4dc2-a617-8965268ed3ba rd_LUKS_UUID=root_crypt LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet nouveau.modeset=0
	initrd /initramfs-2.6.31.9-174.fc12.x86_64.img

No luck - Fedora does not asks for password at all and boot fails.
I've also tried passing root=/dev/mapper/root_crypt and root=/dev/mapper/vg_acer-lv_f12r (rebuilding initramfs each time). But the result was the same - no prompt for password (and boot failed). 

I've checked the content of initramfs. readlink is present in /usr/bin, cryptroot-ask (correct one) in /sbin.

Am I missing something? :)

Comment 23 Tomas Hoger 2010-01-07 08:34:13 UTC
(In reply to comment #22)
> Originally my crypttab was (only /, no swap):
> luks-ce6a558e-435c-4dc2-a617-8965268ed3ba
> UUID=ce6a558e-435c-4dc2-a617-8965268ed3ba none

...

> root=/dev/mapper/luks-ce6a558e-435c-4dc2-a617-8965268ed3ba
> rd_LUKS_UUID=luks-c1af2161-0e3f-4d67-a9c3-a2e60d030f87

Why the different UUID passed to rd_LUKS_UUID?  Btw, as noted in comment #6 (which probably refers to bug #533177), there were issues with rd_LUKS_UUID handling that may or may not be resolved in the cryptroot-ask you are using (I believe that should be fixed in the version I attached).

Side note: rd_LUKS_UUID is documented to expect UUID, but I can cope with luks- prefix in current git versions, but not in the current stable versions, iirc.

> According to your suggestions I've changed my crypttab to:
> root_crypt       /dev/mapper/vg_acer-lv_f12r     none

...

> root=/dev/mapper/luks-ce6a558e-435c-4dc2-a617-8965268ed3ba
> rd_LUKS_UUID=root_crypt

...

> No luck - Fedora does not asks for password at all and boot fails.

I'd expect my script to ask for password, but still expect boot to fail, as the root path will not be valid.  With your original crypttab, I'd expect this to work:

root=/dev/mapper/luks-ce6a558e-435c-4dc2-a617-8965268ed3ba
rd_LUKS_UUID=ce6a558e-435c-4dc2-a617-8965268ed3ba

If not, try modifying cryptroot-ask.sh to add some extra info / echo calls with more debug info to see where it is misbehaving.  'set -x' after dracut-lib import can give some debug info too.

Comment 24 Andriy Tsykholyas 2010-01-08 09:54:34 UTC
Hi Tomas,

many thanks for your help!

(In reply to comment #23)
> Why the different UUID passed to rd_LUKS_UUID?
This grub entry was created by Fedora installer :)

> Btw, as noted in comment #6
> (which probably refers to bug #533177), there were issues with rd_LUKS_UUID
> handling that may or may not be resolved in the cryptroot-ask you are using (I
> believe that should be fixed in the version I attached).
I'm using dracut-002-13.4.git8f397a9b.fc12. I've tried dracut-003 from testing repo, but I could not to boot with if, so I've downgraded back to dracut-002 :(

> I'd expect my script to ask for password, but still expect boot to fail, as the
> root path will not be valid.  With your original crypttab, I'd expect this to
> work:
> 
> root=/dev/mapper/luks-ce6a558e-435c-4dc2-a617-8965268ed3ba
> rd_LUKS_UUID=ce6a558e-435c-4dc2-a617-8965268ed3ba
Using rd_LUKS_UUID as you suggested and your cryptroot-ask.sh Fedora asks for password only once, boots and works fine. Which makes me happy :)

However, I've noticed following error in boot.log:
modprobe: FATAL: Error inserting padlock_sha (/lib/modules/2.6.31.9-174.fc12.x86_64/kernel/drivers/crypto/padlock-sha.ko): No such device

Again, Fedora works fine with despite of this error, but it was not present with old initramfs (I've checked this). I've googled a bit and found this topic:
http://bbs.archlinux.org/viewtopic.php?id=43705

The guys suggested blacklisting padlock_aes and padlock_sha. Those modules seams to be used only on VIA CPU. I have an Intel CPU, so I've added following lines to /etc/modprobe.d/blacklist.conf:
blacklist padlock_aes
blacklist padlock_sha

Now that error has gone :)

Comment 25 Fedora Update System 2010-01-26 10:47:14 UTC
dracut-004-4.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/dracut-004-4.fc12

Comment 26 Need Real Name 2010-01-26 18:40:55 UTC
Can I ask how this works now?

Does dracut boot from the root disk specified somewhere, then read the crypttab file to decide what other encrypted disks to mount?

Comment 27 Tomas Hoger 2010-01-26 19:34:56 UTC
crypttab is copied to initramfs when it's generated.

Comment 28 Fedora Update System 2010-01-27 01:05:00 UTC
dracut-004-4.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dracut'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1088

Comment 29 Fedora Update System 2010-01-28 00:50:14 UTC
dracut-004-4.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.


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