Bug 1040811

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.