Bug 1029790
| Summary: | dracut cannot handle encrypted partitions with a key file on the root file system | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Juan Orti <jorti> | ||||
| Component: | dracut | Assignee: | dracut-maint | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 20 | CC: | awilliam, dracut-maint, harald, jonathan, jorti, mruckman, robatino, rohara | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | RejectedBlocker | ||||||
| Fixed In Version: | dracut-037-10.git20140402.fc20 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-04-06 02:36:46 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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. 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. 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. 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? 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 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/ 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. Status: ON_QA → CLOSED |
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