Bug 1029790 - dracut cannot handle encrypted partitions with a key file on the root file system
dracut cannot handle encrypted partitions with a key file on the root file sy...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dracut (Show other bugs)
20
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: dracut-maint
Fedora Extras Quality Assurance
RejectedBlocker
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-13 03:38 EST by Juan Orti
Modified: 2014-11-10 07:27 EST (History)
8 users (show)

See Also:
Fixed In Version: dracut-037-10.git20140402.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-04-05 22:36:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Juan Orti 2013-11-13 03:38:48 EST
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 05:28:09 EST
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 06:54:21 EST
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 2013-11-13 09:03:54 EST
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 13:51:18 EST
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 09:30:15 EST
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 12:16:10 EST
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 04:56:35 EDT
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 00:02:42 EDT
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-05 22:36:46 EDT
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 07:27:53 EST
Status: ON_QA → CLOSED

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