Hide Forgot
Description of problem: I successfully installed the F20 beta, creating my root volume on a btrfs subvolume that resides on top of a LUKS-encrypted partition. The system has a UEFI BIOS, and the disk has a GPT label. anaconda added the following item to /boot/efi/EFI/fedora/grub.cfg: rd.luks.uuid=luks-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx This seems silly, because according to the documentation I've been able to find, dracut's normal behavior is to activate every device it can, and there was only one LUKS volume. Anyway, after the install, I created another LUKS-encrypted partition, created a LVM physical volume on top of the LUKS partition, created a volume group, created a "swap" logical volume, and added the logical volume to /etc/fstab. I additionally added the new LUKS volume to /etc/crypttab. I did *not* bother to update GRUB_CMDLINE_LINUX in /etc/default/grub, because the new LUKS volume (obviously) didn't contain the root filesystem. However, I discovered that no new kernel updates I installed after I created the second LUKS volume would boot. They would get as far as asking me for the password for the LUKS volume that contained the root filesystem, but would hang immediately afterward. Booting with the "rdshell" option didn't work; dracut didn't give me a shell. But booting with "rdinitdebug" showed that dracut was stuck in an infinite loop, attempting to do something with the new LUKS volume I created, failing, waiting 0.5 seconds, and then retrying. After experimentation, I determined that if I removed the rd.luks.uuid= argument (the one that named the LUKS volume that contained the root volume), this avoided dracut's infinite loop. Similarly, if I added rd.luks.uuid= arguments for both LUKS volumes, that also avoided the loop. But if I specified only the rd.luks.uuid= argument for the volume that contains the root volume, and the infinite loop triggers. Adding another LUKS volume to an existing system shouldn't cause dracut to enter an infinite loop at boot. Version-Release number of selected component (if applicable): dracut-034-64.git20131205.fc20.x86_64 How reproducible: Do a fresh install onto a LUKS volume, boot it, then create another LUKS volume and update /etc/crypttab. Then rebuild the initramfs image and reboot.
True. Let me try to reproduce this, so I can debug, what is going on.
dracut-037-10.git20140402.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/dracut-037-10.git20140402.fc20
Package dracut-037-10.git20140402.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dracut-037-10.git20140402.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-4704/dracut-037-10.git20140402.fc20 then log in and leave karma (feedback).
dracut-037-10.git20140402.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.