Bug 1082256

Summary: Dracut fails to mount the system drive (encrypted + LVM)
Product: [Fedora] Fedora Reporter: Jordan <fedorabug.50.chimai>
Component: dracutAssignee: dracut-maint-list
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: dracut-maint-list, harald, jonathan
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
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:37:53 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:
Description Flags
Layouts of the disk's partitions none

Description Jordan 2014-03-29 21:13:47 UTC
Created attachment 880214 [details]
Layouts of the disk's partitions

Description of problem:
When I switch on my computer (F20 system, installed on a SSD with LVM + encryption), there is a 50% chance that it wont boot. Instead of asking me the password to decrypt the drive, the system will stay stuck for a few minutes and then fall back to the emergency shell.

I get the following warnings:

dracut-initqueue[228]: Warning: Could not boot.
dracut-initqueue[228]: Warning: /dev/fedora_tokyo/root does not exist
dracut-initqueue[228]: Warning: /dev/fedora_tokyo/root does not exist
dracut-initqueue[228]: Warning: /dev/fedora_tokyo/swap does not exist
dracut-initqueue[228]: Warning: /dev/fedora_tokyo/swap does not exist
dracut-initqueue[228]: Warning: /dev/mapper/fedora_tokyo-root does not exist
dracut-initqueue[228]: Warning: /dev/mapper/fedora_tokyo-root does not exist
dracut-initqueue[228]: Warning: /dev/mapper/fedora_tokyo-root does not exist
dracut-initqueue[228]: Warning: /dev/mapper/fedora_tokyo-swap does not exist

The system also generates a file "/run/initframfs/rdsosreport.txt" with potentially interesting info but I haven't been able to mount a USB key to save it (I'm a bit of a CLI noob).

Version-Release number of selected component (if applicable):
Dracut: 034-64.git20131205.fc20.1
Linux: 3.13.7-200.fc20.x86_64
The problem has existed since I installed F20, a month or so after its release.

How reproducible:
More or less 50% of the times I boot up, but without any predictability.

Steps to Reproduce:
1. Boot a computer with F20 on an encrypted drive
2. Watch the Plymouth "bubble" fill without asking for a password to decrypt the drive
3. Wait a few minutes before being switched to the emergency mode (shell with "dracut:/#")

Actual results:
System does not boot sometimes. Must be powered off and then rebooted, sometimes several times in a row, before 

Expected results:
System should boot every time.

Additional info:
HP Pavilion g7 laptop.
Intel® Core™ i3-2310M CPU @ 2.10GHz × 4
64-bit
Intel® Sandybridge Mobile + AMD/ATI Seymour [Radeon HD 6400M/7400M Series]

SSD: 256 GB Disk 
/dev/sda
Model: M4-CT256M4SSD2 (040H)
Assessment: Disk is OK

See attachment for disk layout.
Partioning: Master Boot Record

Comment 1 Harald Hoyer 2014-04-01 06:39:13 UTC
What is your kernel command line?

# cat /proc/cmdline

Comment 2 Jordan 2014-04-01 11:55:18 UTC
cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.13.7-200.fc20.x86_64 root=/dev/mapper/fedora_tokyo-root ro rd.lvm.lv=fedora_tokyo/swap vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-05c66645-73e1-4eea-b15f-020126f1bab0 rd.lvm.lv=fedora_tokyo/root rhgb quiet LANG=en_US.UTF-8

Comment 3 Harald Hoyer 2014-04-01 13:12:16 UTC
try instead of:
rd.luks.uuid=luks-05c66645-73e1-4eea-b15f-020126f1bab0 rd.lvm.lv=fedora_tokyo/root

this:

rd.luks.uuid=05c66645-73e1-4eea-b15f-020126f1bab0 rd.lvm.vg=fedora_tokyo

Also what is the output of:

# cat /etc/crypttab
# lsinitrd -f /etc/crypttab

Comment 4 Jordan 2014-04-01 21:36:00 UTC
[root@tokyo jordan]# cat /etc/crypttab
luks-05c66645-73e1-4eea-b15f-020126f1bab0 UUID=05c66645-73e1-4eea-b15f-020126f1bab0 none

[root@tokyo jordan]# lsinitrd -f /etc/crypttab
luks-05c66645-73e1-4eea-b15f-020126f1bab0 /dev/disk/by-uuid/05c66645-73e1-4eea-b15f-020126f1bab0 none

I'm not sure what you mean by "try instead [...] fedora_tokyo"? I'm a bit of a newbie.

Comment 5 Fedora Update System 2014-04-02 08:57:44 UTC
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 6 Fedora Update System 2014-04-03 04:04:13 UTC
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 7 Fedora Update System 2014-04-06 02:37:53 UTC
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.