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:
add "rd_NO_LUKS" to the kernel command line, if your root device is not encrypted, otherwise add "rd_LUKS_UUID=<uuid of root>"
*** Bug 531991 has been marked as a duplicate of this bug. ***
*** Bug 532598 has been marked as a duplicate of this bug. ***
*** Bug 530411 has been marked as a duplicate of this bug. ***
Please can the default be that only the encrypted devices that the user wants loaded do load.
rd_LUKS_UUID argument handling was bugged... stay tuned. Also anaconda will add rd_LUKS_UUID to the kernel command line in future versions.
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"?
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
dracut-003-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/dracut-003-1.fc12
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
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.
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.
(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?
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.
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.
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?
Hi Tomas, I'd like to try your cryptroot-ask.sh. Could you, please, provide some instructions how to use it? :)
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
(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.
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?
(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.
(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? :)
(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.
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 :)
dracut-004-4.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/dracut-004-4.fc12
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?
crypttab is copied to initramfs when it's generated.
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
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.