Bug 1020398

Summary: cannot find all encrypted disks needed to boot
Product: [Fedora] Fedora Reporter: Tim Flink <tflink>
Component: systemdAssignee: systemd-maint
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: dracut-maint, harald, johannbg, jonathan, lnykryn, msekleta, plautrba, systemd-maint, vpavlin, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-24 16:23:52 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:
Attachments:
Description Flags
journalctl output
none
rdosreport
none
output of blkid -o udev
none
boot.log from successful boot with rd.debug none

Description Tim Flink 2013-10-17 15:15:51 UTC 
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
Comment 1 Tim Flink 2013-10-17 15:16:29 UTC 
Created attachment 813389 [details]
journalctl output
Comment 2 Tim Flink 2013-10-17 15:16:54 UTC 
Created attachment 813390 [details]
rdosreport
Comment 3 Tim Flink 2013-10-17 15:17:36 UTC 
Created attachment 813391 [details]
output of blkid -o udev
Comment 4 Tim Flink 2013-10-17 15:45:01 UTC 
Created attachment 813421 [details]
boot.log from successful boot with rd.debug
Comment 5 Harald Hoyer 2013-10-18 12:30:42 UTC 
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 ?
Comment 6 Tim Flink 2013-10-24 16:23:52 UTC 
(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.