Bug 1240331

Summary: System often fails to boot after entering LUKS passphrase
Product: [Fedora] Fedora Reporter: Vratislav Podzimek <vpodzime>
Component: systemdAssignee: systemd-maint
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: aanm90, johannbg, jsynacek, lnykryn, msekleta, s, systemd-maint, 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: 2016-07-19 15:13:13 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
journal from the failed boot
none
output of 'mount' on the failed boot
none
journal from a successful boot
none
output of 'mount' on a successful boot
none
output of lsblk
none
list of partitions by uuid none

Description Vratislav Podzimek 2015-07-06 15:20:49 UTC
Description of problem:
When I enter the (correct) passphrase in the LUKS prompt during boot, the boot often (4 out of 5 boots) never reaches the final state and system doesn't boot into GDM. The reason are two dev-disk-by\x2duuid... services (for both of my partitions) that fail. This is really weird, because one of the partitions is /boot which is used very early in the boot process and the other one is the LUKS partition I'm prompted to enter the passphrase for. So the disk is correctly initialized and the partitions are recognized just fine. Seems like some race-condition or something like that in udev. But that's just my "amateur" guess.

Version-Release number of selected component (if applicable):
systemd-219-18.fc22.x86_64

How reproducible:
80%

Steps to Reproduce:
1. try to boot a system with encrypted LVM setup
2. enter passphrase

Actual results:
system never finishes the boot

Expected results:
system boots just fine

Additional info:
It seems that waiting for quite a long time (> 3 minutes) before entering the LUKS passphrase help (maybe something times out?).

Comment 1 Vratislav Podzimek 2015-07-06 15:21:23 UTC
Created attachment 1048856 [details]
journal from the failed boot

Comment 2 Vratislav Podzimek 2015-07-06 15:21:57 UTC
Created attachment 1048864 [details]
output of 'mount' on the failed boot

Comment 3 Vratislav Podzimek 2015-07-06 15:22:41 UTC
Created attachment 1048865 [details]
journal from a successful boot

Comment 4 Vratislav Podzimek 2015-07-06 15:23:27 UTC
Created attachment 1048867 [details]
output of 'mount' on a successful boot

Comment 5 Vratislav Podzimek 2015-07-06 15:24:12 UTC
Created attachment 1048868 [details]
output of lsblk

Comment 6 Vratislav Podzimek 2015-07-06 15:24:59 UTC
Created attachment 1048869 [details]
list of partitions by uuid

Comment 7 Jan Synacek 2015-07-29 10:32:28 UTC
What struck my eyes are these two errors:

Jul 06 11:33:04 localhost.localdomain systemd[866]: /usr/lib/systemd/system-generators/anaconda-generator failed with error code 1.
...
Jul 06 11:33:25 localhost.localdomain systemd-udevd[946]: error opening USB device 'descriptors' file

The first looks like it doesn't have to do anything with this issue, but you might want to check.
The second error is quite suspicious and might be a problem. I didn't find any other relevant information in the logs, though, so it's hard to say what caused it and why the device units suddenly start failing.

Comment 8 André Martins 2015-08-29 01:40:11 UTC
I'm also getting "Ago 29 02:31:48 localhost.localdomain systemd[721]: /usr/lib/systemd/system-generators/anaconda-generator failed with error code 1." every time I boot. I'm also using LUKS so let me known if I can help you with something.

Comment 9 Vratislav Podzimek 2015-11-26 10:12:33 UTC
I removed the anaconda-generator, but it didn't help at all.

Comment 10 Fedora End Of Life 2016-07-19 15:13:13 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.