Bug 1082256 - Dracut fails to mount the system drive (encrypted + LVM)
Summary: Dracut fails to mount the system drive (encrypted + LVM)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 20
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-29 21:13 UTC by Jordan
Modified: 2014-04-06 02:37 UTC (History)
3 users (show)

Fixed In Version: dracut-037-10.git20140402.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-06 02:37:53 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Layouts of the disk's partitions (123.74 KB, image/png)
2014-03-29 21:13 UTC, Jordan
no flags Details

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.


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