Bug 920885 - Systemd[1]: Job dev-mapper-luks-uuid.device/stop timed out.
Summary: Systemd[1]: Job dev-mapper-luks-uuid.device/stop timed out.
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: cryptsetup
Version: 17
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Milan Broz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-13 00:59 UTC by Ryan Spinuzzi
Modified: 2013-03-18 18:38 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-18 17:08:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Boot Log (14.38 KB, text/x-log)
2013-03-13 01:01 UTC, Ryan Spinuzzi
no flags Details
Crypttab (539 bytes, application/octet-stream)
2013-03-13 01:01 UTC, Ryan Spinuzzi
no flags Details
Dmesg (65.87 KB, text/plain)
2013-03-13 01:02 UTC, Ryan Spinuzzi
no flags Details
Dmsetup Info (1.24 KB, text/plain)
2013-03-13 01:03 UTC, Ryan Spinuzzi
no flags Details
Dracut Log (341.63 KB, text/x-log)
2013-03-13 01:04 UTC, Ryan Spinuzzi
no flags Details
Fstab (915 bytes, application/octet-stream)
2013-03-13 01:04 UTC, Ryan Spinuzzi
no flags Details
Grub Configuration (6.02 KB, application/octet-stream)
2013-03-13 01:05 UTC, Ryan Spinuzzi
no flags Details
Message Log (646.18 KB, application/octet-stream)
2013-03-13 01:06 UTC, Ryan Spinuzzi
no flags Details
Time Out Error (902.27 KB, image/jpeg)
2013-03-13 01:29 UTC, Ryan Spinuzzi
no flags Details
Yum Log (53.12 KB, text/x-log)
2013-03-13 01:30 UTC, Ryan Spinuzzi
no flags Details

Description Ryan Spinuzzi 2013-03-13 00:59:06 UTC
Description of problem:
On March 10th 2013 I rebooted my Fedora 17 Machine only to find out that cryptsetup would not unlock my encrypted home lvm.

When the computer boots plymouth will allow me to enter my password for the encrypted luks devices.  cryptsetup will unlock all three of my physical drives, and the root & swap lvm but not the home lvm.  The root lvm will get mounted upon boot but nothing else.

During the boot when it gets to the loading random seeds part the boot process will load the random seeds then will time out loading the home lvm and then drop into a emergency shell.  Logging into this emergency shell I am provided with my root lvm, swap lvm and access to my other filesystems, but not the home lvm.

I can run # cryptsetup luksOpen /dev/sdb2 /dev/mapper/luks-uuid
the drive will get unlocked, and then I can mount it and have access to my home lvm.  I still wont have a functioning system, because most of the service wont start such as the network service so I cant really do anything.

Some things I have tried and have had no luck:
(Suggested from the #fedora irc)
https://bugzilla.redhat.com/show_bug.cgi?id=894242
https://bugzilla.redhat.com/show_bug.cgi?id=896010

Bug # 896010 Comment #c34
Gilboa Davara mentions that there is an issue with multiple encrypted drives with lvms, and manually mounting does not help.

I tried the suggested workaround adding enforcing=0 and removing rhgb and quite from the grub config file with no luck in the end.

I had tried the proposed fix (the fedup update) and that did not do anything, as I would expect it to do on a system with no network access.
 
I imaged my machine and then download the Fedora 18 DVD and tried to upgrade Fedora and nothing changed, except the amount of work I had to do to try to get a running system updating repos and downloading updates to get a system with network access.

No matter what I have tried nothing has worked which is why I filed this bug, plus I was asked to do so from members of the #fedora irc.Description of problem:
On March 10th 2013 I rebooted my Fedora 17 Machine only to find out that cryptsetup would not unlock my encrypted home lvm.

When the computer boots plymouth will allow me to enter my password for the encrypted luks devices.  cryptsetup will unlock all three of my physical drives, and the root & swap lvm but not the home lvm.  The root lvm will get mounted upon boot but nothing else.

During the boot when it gets to the loading random seeds part the boot process will load the random seeds then will time out loading the home lvm and then drop into a emergency shell.  Logging into this emergency shell I am provided with my root lvm, swap lvm and access to my other filesystems, but not the home lvm.

I can run # cryptsetup luksOpen /dev/sdb2 /dev/mapper/luks-uuid
the drive will get unlocked, and then I can mount it and have access to my home lvm.  I still wont have a functioning system, because most of the service wont start such as the network service so I cant really do anything.

Some things I have tried and have had no luck:
(Suggested from the #fedora irc)
https://bugzilla.redhat.com/show_bug.cgi?id=894242
https://bugzilla.redhat.com/show_bug.cgi?id=896010

Bug # 896010 Comment #c34
Gilboa Davara mentions that there is an issue with multiple encrypted drives with lvms, and manually mounting does not help.

I tried the suggested workaround adding enforcing=0 and removing rhgb and quite from the grub config file with no luck in the end.

I had tried the proposed fix (the fedup update) and that did not do anything, as I would expect it to do on a system with no network access.
 
I imaged my machine and then download the Fedora 18 DVD and tried to upgrade Fedora and nothing changed, except the amount of work I had to do to try to get a running system updating repos and downloading updates to get a system with network access.

No matter what I have tried nothing has worked which is why I filed this bug, plus I was asked to do so from members of the #fedora irc.

UUID = My home lvm UUID

Version-Release number of selected component (if applicable):
cryptsetup-1.5.1-1.fc17
plymouth-0.8.5-0.2012.04.27.4.fc17
systemd-

How reproducible:
Not sure

Steps to Reproduce:
I do not know how to reproduce this, but I can provide you with the events that took place prior to this error.  I am not sure if they are even relevant so don't get mad if there not, I am just trying to help.

1. Ran yum update
2. Ran yum install midsport-firmware-1.2.9-fc17.noarch
3. Rebooted my computer

Actual results:


Expected results:
Fedora 17 should boot as it normally would.

Additional info:
I am about 99% sure that the steps to reproduce are not the cause.  I in fact have absolutely no idea how this happened.  I provided those steps because that is the only thing I had done before this issue happened.  I did not change any configuration files (me personally, not my system), or do anything other then use Google Chrome to search Google, Thunderbird to check my email, and messing around with lmms and my new midi keyboard (mentioned because of step 2).

My last reboot prior to this issue was March 03 2013 after yum had updated my kernel to 3.7.9-104

UUID = My home lvm UUID

Version-Release number of selected component (if applicable):
cryptsetup-1.5.1-1.fc17.x86_64
plymouth-0.8.5-0.2012.04.27.4.fc17.x86_64
systemd-44-24.fc17.x86_64

How reproducible:
Not sure

Steps to Reproduce:
I do not know how to reproduce this, but I can provide you with the events that took place prior to this error.  I am not sure if they are even relevant so don't get mad if there not, I am just trying to help.

1. Ran yum update
2. Ran yum install midsport-firmware-1.2.9-fc17.noarch
3. Rebooted my computer

Actual results:


Expected results:
Fedora 17 should boot as it normally would.

Additional info:
I am about 99% sure that the steps to reproduce are not the cause.  I in fact have absolutely no idea how this happened.  I provided those steps because that is the only thing I had done before this issue happened.  I did not change any configuration files (me personally, not my system), or do anything other then use Google Chrome to search Google, Thunderbird to check my email, and messing around with lmms and my new midi keyboard (mentioned because of step 2).

My last reboot prior to this issue was March 03 2013 after yum had updated my kernel to 3.7.9-104

Again not sure how this helps but I filed this like I was asked.

Comment 1 Ryan Spinuzzi 2013-03-13 01:01:08 UTC
Created attachment 709249 [details]
Boot Log

Comment 2 Ryan Spinuzzi 2013-03-13 01:01:56 UTC
Created attachment 709250 [details]
Crypttab

Comment 3 Ryan Spinuzzi 2013-03-13 01:02:38 UTC
Created attachment 709251 [details]
Dmesg

Comment 4 Ryan Spinuzzi 2013-03-13 01:03:35 UTC
Created attachment 709252 [details]
Dmsetup Info

Comment 5 Ryan Spinuzzi 2013-03-13 01:04:22 UTC
Created attachment 709253 [details]
Dracut Log

Comment 6 Ryan Spinuzzi 2013-03-13 01:04:57 UTC
Created attachment 709254 [details]
Fstab

Comment 7 Ryan Spinuzzi 2013-03-13 01:05:33 UTC
Created attachment 709255 [details]
Grub Configuration

Comment 8 Ryan Spinuzzi 2013-03-13 01:06:18 UTC
Created attachment 709256 [details]
Message Log

Comment 9 Ryan Spinuzzi 2013-03-13 01:29:31 UTC
Created attachment 709259 [details]
Time Out Error

Comment 10 Ryan Spinuzzi 2013-03-13 01:30:29 UTC
Created attachment 709260 [details]
Yum Log

Comment 11 Ryan Spinuzzi 2013-03-13 01:35:05 UTC
systemd-44-24.fc17.x86_64

Comment 12 Alasdair Kergon 2013-03-13 02:35:56 UTC
Have you tried taking the relevant packages from rawhide?   Given the number of changes going on and the number of problems reported, I doubt it's worth investigating this with f17 or a pure f18.

"I can run # cryptsetup luksOpen /dev/sdb2 /dev/mapper/luks-uuid
the drive will get unlocked"

So cryptsetup itself is working in isolation.  But I know there were some initial problems when systemd started doing some of the work itself internally.

Comment 13 Ryan Spinuzzi 2013-03-18 17:08:03 UTC
No I have not tried anything from the rawhide because there is no network access to the machine when it is in the emergency shell.

Yes the drive works in isolation.

Whatever the issue was is no longer there because I backed up the data, formatted the hard drive and start from scratch.

As stated before this report was pointless because it will never be resolved.  I did as I was asked and filed this report

I am closing this bug due to the fact I no longer have a broken machine to try to fix, and it will never be resolved.

Comment 14 Alasdair Kergon 2013-03-18 18:38:36 UTC
(The report is not completely useless: if it's not an isolated instance, it's there for anyone else searching for similar symptoms to find and perhaps help.)


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