I'm running an updated F20 x86_64 install, booting with UEFI (no secure boot) and the following disk layout: /dev/sda - contains vg with encrypted lv for swap /dev/sdb - contains nothing used for fedora install /dev/sdc1 - ESP /dev/sdc2 - /boot as unencrypted ext4 /dev/sdc3 - / as encrypted ext4 /dev/sdc4 - /home as encrypted ext4 When I boot with normal boot args, I end up in the dracut emergency shell with errors about not being able to find disks required for boot. [ 195.269110] river.tirfa.net dracut-initqueue[327]: Warning: /dev/disk/by-uuid/98b5df21-c4e6-44db-bec6-93e2b53dc751 does not exist [ 195.269548] river.tirfa.net dracut-initqueue[327]: Warning: /dev/mapper/luks-c626b926-7b66-41fd-9f1d-31ee2df530e1 does not exist [ 195.269931] river.tirfa.net dracut-initqueue[327]: Warning: /dev/mapper/luks-c626b926-7b66-41fd-9f1d-31ee2df530e1 does not exist When I do some digging around, it turns out that the "non-existant" disks are the unlocked sdc3 and sdc4 partitions. To make things even more interesting, if I add rd.debug to the boot args, my system boots to gdm without issue (reproduced twice). Version-Release number of selected component (if applicable): dracut-034-8.git20131008.fc20 Command line: BOOT_IMAGE=/vmlinuz-3.11.5-300.fc20.x86_64 root=UUID=98b5df21-c4e6-44db-bec6-93e2b53dc751 ro vconsole.font=latarcyrheb-sun16 rd.lvm.lv=vg_storage/lv_swap vconsole.keymap=us rd.luks.uuid=luks-b0755693-19e0-4bbd-9091-5f7fa3e36d4f rd.luks.uuid=luks-c626b926-7b66-41fd-9f1d-31ee2df530e1 rhgb quiet LANG=en_US.UTF-8
Created attachment 813389 [details] journalctl output
Created attachment 813390 [details] rdosreport
Created attachment 813391 [details] output of blkid -o udev
Created attachment 813421 [details] boot.log from successful boot with rd.debug
strange... [ 1.220850] river.tirfa.net systemd[1]: Expecting device dev-disk-by\x2duuid-c626b926\x2d7b66\x2d41fd\x2d9f1d\x2d31ee2df530e1.device... but it is never found although: /dev/disk/by-uuid: lrwxrwxrwx 1 root 0 10 Oct 17 08:07 c626b926-7b66-41fd-9f1d-31ee2df530e1 -> ../../sdc3 Can you run without rd.debug, but with "systemd.log_level=debug" and attach the rdsosreport ?
(In reply to Harald Hoyer from comment #5) > Can you run without rd.debug, but with "systemd.log_level=debug" and attach > the rdsosreport ? Bah, I completely missed your comment until today. Apologies on the delay. Of course, now that I'm trying to debug again, I can't reproduce it anymore. I'm closing this bug for now but will re-open if I start hitting the issue again.