Bug 1040811 - dracut enters infinite loop at boot when unactivated LUKS volumes exist
Summary: dracut enters infinite loop at boot when unactivated LUKS volumes exist
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 20
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-12-12 07:14 UTC by James Ralston
Modified: 2014-04-06 02:36 UTC (History)
3 users (show)

Fixed In Version: dracut-037-10.git20140402.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-04-06 02:36:58 UTC

Attachments (Terms of Use)

Description James Ralston 2013-12-12 07:14:19 UTC
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:


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):


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.

Comment 1 Harald Hoyer 2013-12-13 10:31:12 UTC
True. Let me try to reproduce this, so I can debug, what is going on.

Comment 2 Fedora Update System 2014-04-02 08:56:48 UTC
dracut-037-10.git20140402.fc20 has been submitted as an update for Fedora 20.

Comment 3 Fedora Update System 2014-04-03 04:03:02 UTC
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:
then log in and leave karma (feedback).

Comment 4 Fedora Update System 2014-04-06 02:36:58 UTC
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.

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