Bug 1029790 - dracut cannot handle encrypted partitions with a key file on the root file system
Summary: dracut cannot handle encrypted partitions with a key file on the root file sy...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 20
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: dracut-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-13 08:38 UTC by Juan Orti Alcaine
Modified: 2014-11-10 12:27 UTC (History)
8 users (show)

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


Attachments (Terms of Use)
rdsosreport (134.28 KB, text/plain)
2013-11-13 08:38 UTC, Juan Orti Alcaine
no flags Details

Description Juan Orti Alcaine 2013-11-13 08:38:48 UTC
Created attachment 823292 [details]
rdsosreport

Description of problem:
I have upgraded a system with fedup from F19 to F20 and I cannot boot with the generated initramfs.

I have a ext4 /boot, a unencrypted btrfs root partition, and the rest of partitions including swap are on Luks and LVM. In F19 it booted perfectly without asking for a Luks password (I have the keyfiles in /etc), but now, it reaches the target basic system and hangs for about 5 minutes and after that I get the dracut emergency shell. If I choose in grub a F19 kernel to boot, it boots ok.

In the emergency shell it says it cannot find my LVM volume group (it is inside a luks partition, which is closed).
dracut-initqueue[223]: Warning: Could not boot.
dracut-initqueue[223]: Warning: /dev/mapper/vg_raid0-swap does not exist

I have extracted the initramfs and compared them with the ones generated by F19. In F20, the initramfs has this /etc/crypttab:
luks-0f938c6d-4be4-486d-9f09-d04898e90e88 /dev/disk/by-uuid/0f938c6d-4be4-486d-9f09-d04898e90e88 /etc/luks_keys/keyfile

In F19, the initramfs has no /etc/crypttab file

In the real root partition I have this:
luks-e959dcb0-4bff-4d4b-9efc-2f729e7e2a1e UUID=e959dcb0-4bff-4d4b-9efc-2f729e7e2a1e /etc/luks_keys/keyfile
luks-24562ce1-cac4-44aa-a3ab-52d2c46d6925 UUID=24562ce1-cac4-44aa-a3ab-52d2c46d6925 /etc/luks_keys/keyfile
luks-0f938c6d-4be4-486d-9f09-d04898e90e88 UUID=0f938c6d-4be4-486d-9f09-d04898e90e88 /etc/luks_keys/keyfile

The kernel commandline is:
root=UUID=5094ab56-5ea8-40c3-8e2c-d3a09a6fd537 ro rootflags=subvol=root rd.md=0 rd.lvm=0 rd.dm=0 vconsole.keymap=es  rd.luks=0 vconsole.font=latarcyrheb-sun16 crashkernel=128M radeon.audio=1 rhgb quiet

Version-Release number of selected component (if applicable):
dracut-034-19.git20131021.fc20.x86_64
dracut-config-rescue-034-19.git20131021.fc20.x86_64
dracut-network-034-19.git20131021.fc20.x86_64
kernel-3.11.7-300.fc20.x86_64
fedup-0.7.3-7.fc20.noarch

Comment 1 Fedora Blocker Bugs Application 2013-11-13 10:28:09 UTC
Proposed as a Blocker for 20-final by Fedora user jorti using the blocker tracking app because:

 After upgrading a perfectly working F19 system with "fedup --network 20", I get an unbootable system because dracut cannot figure out how to mount my Luks partitions.

Comment 2 Harald Hoyer 2013-11-13 11:54:21 UTC
dracut wants to open all swap devices, to be able to resume from suspend.

If the swap partition is decrypted with a key file, the boot fails, because dracut does not copy the key file to the initramfs.

Comment 3 Juan Orti Alcaine 2013-11-13 14:03:54 UTC
After removing the swap partition and rebuilding the dracut image, it boots fine.
Something has changed in the dracut logic, because this setup worked in F19.

Comment 4 Adam Williamson 2013-11-13 18:51:18 UTC
Discussed at 2013-11-13 blocker review meeting - http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-13/f20-final-blocker-review-1.2013-11-13-17.01.log.txt . Agreed to delay determination while we ask Harald for clarification as to whether he considers this intended behaviour or a bug, and if it's a bug, how serious it is. Harald?

Comment 5 Harald Hoyer 2013-11-14 14:30:15 UTC
Well, it would affect everybody with a keyfile for /usr or swap devices and that are not very many.

But I will do the following:

a) do not wait for crypt devices, which cannot be decrypted
b) relax the conditions in the initramfs to continue, even if a swap device could not be found

Comment 6 Mike Ruckman 2013-11-14 17:16:10 UTC
Discussed in 2013-11-14 Blocker Review Meeting [1]. This was voted as a RejectedBlocker as this does not affect a large enough user base to guarantee a blocker. We still would like to see this fixed before release. If the fix is ready during freeze period, please propose for a freeze exception.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-14/

Comment 7 Fedora Update System 2014-04-02 08:56:35 UTC
dracut-037-10.git20140402.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/dracut-037-10.git20140402.fc20

Comment 8 Fedora Update System 2014-04-03 04:02:42 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:
https://admin.fedoraproject.org/updates/FEDORA-2014-4704/dracut-037-10.git20140402.fc20
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2014-04-06 02:36:46 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.

Comment 10 Harald Hoyer 2014-11-10 12:27:53 UTC
Status: ON_QA → CLOSED


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