Bug 1020398 - cannot find all encrypted disks needed to boot
cannot find all encrypted disks needed to boot
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-17 11:15 EDT by Tim Flink
Modified: 2013-10-24 12:23 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-24 12:23:52 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)
journalctl output (68.89 KB, text/plain)
2013-10-17 11:16 EDT, Tim Flink
no flags Details
rdosreport (145.89 KB, text/plain)
2013-10-17 11:16 EDT, Tim Flink
no flags Details
output of blkid -o udev (2.54 KB, text/plain)
2013-10-17 11:17 EDT, Tim Flink
no flags Details
boot.log from successful boot with rd.debug (35.55 KB, text/plain)
2013-10-17 11:45 EDT, Tim Flink
no flags Details

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

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