Hide Forgot
Description of problem: Dracut does not properly unlock and then mount a btrfs root filesystem that consists of multiple encrypted devices. Version-Release number of selected component (if applicable): 009-11.fc15 How reproducible: Mostly Steps to Reproduce: 1. Install Fedora on a LUKS encrypted btrfs partition 2. Create new LUKS encrypted partition (with same password) and format btrfs 3. Add rd_LUKS_UUID for new partition to grub 4. Add new partition to / (btrfs device add ... /) 5. Reboot Actual results: Depending on how the devices are discovered with udev, dracut may try to mount / before all devices are unlocked and ready. Expected results: Mount / successfully everytime. Additional info: There seems to be a race condition between when udev rules get triggered, which populate "initqueue" and when hooks are run (e.g. "settled/blocksymlink.sh"). The latter seems to terminate the processing of hooks, which in this case, stops crypt-ask-...sh from running.
Created attachment 502373 [details] Patch to hack in a fix to the problem described This patch is in no way a suggestion on the correct way to fix to this problem. This patch merely fixes it and better illustrates the issue.
Created attachment 502644 [details] Updated patch I realized that I accidentally attach an old version of my patch, which does not work in all cases. Here's an updated one.
Hmm, what is your kernel command line? maybe you should specify the root device by UUID or LABEL
With the 2.6.38.7-30 update, this is my command line: root=UUID=765c5685-b762-4255-9063-3d01aad2831b rd_LUKS_UUID=luks-fd20a1f3-8eef-4e16-ab50-cb5dfcfe0cea rd_LUKS_UUID=luks-8b0f5a60-8f11-4d46-895d-7c319103ad89 rd_LUKS_UUID=luks-a9763636-9ced-47af-b627-e9cc94d3d155 rd_LUKS_UUID=luks-ea9bfa78-cfd7-48ed-b410-e1b489fa53c4 rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet I see that the update has included the change that you've suggested. I'm not sure if this will fix everything... it looks like there should still be a problem with the btrfs udev rule. That rule will run a btrfs filesystem scan, and if the other disks of the filesystem are not present (i.e. luks unlocked), it should still error out... but I'll do some reboots and report back.
I've confirmed that the problem still exists using the latest kernel/initramfs, which uses "root=UUID=...". I still needed to apply my patch to make it boot reliably.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Does it work for you in F16?
I have not installed F16 as of yet. Although for my F15 installation, I moved to a setup where I have 3 drives that are encrypted, then RAID0'd on md0, then running ext4. The same problem exists for me with this setup as with my previous described above, and my patch (removing the btrfs stuff) fixes it as well. I'll try to reproduce this with F16 as well, but I'm not sure when I'll get a chance to upgrade. I would guess that unless some major changes were done to dracut in F16, the problem still exists... but that's me only guessing.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping