Bug 1495635 - systemd times out when waiting to unlock disks, falling to dracut shell
Summary: systemd times out when waiting to unlock disks, falling to dracut shell
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
: 1491847 (view as bug list)
Depends On:
Blocks: F27FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2017-09-26 11:21 UTC by Kamil Páral
Modified: 2017-11-02 09:07 UTC (History)
20 users (show)

Fixed In Version: dracut-046-4.fc27
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-13 23:30:00 UTC
Type: Bug


Attachments (Terms of Use)
journal (59.22 KB, text/plain)
2017-09-26 11:21 UTC, Kamil Páral
no flags Details
rdsosreport.txt (65.28 KB, text/plain)
2017-09-26 11:22 UTC, Kamil Páral
no flags Details
rpm-qa (52.92 KB, text/plain)
2017-09-26 11:22 UTC, Kamil Páral
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1508794 0 unspecified CLOSED systemd/dracut doesn't wait for mediacheck to finish 2021-02-22 00:41:40 UTC

Internal Links: 1508794

Description Kamil Páral 2017-09-26 11:21:36 UTC
Description of problem:
History repeats itself and systemd again times out when waiting to unlock disks on boot. It happens after 90 seconds. This has the following consequences:

1. If the user starts the computer or reboots it and goes for a coffee, she sees a black command line screen when she returns saying that something is terribly wrong with the computer.

2. When the user schedules a distribution upgrade from F25/F26 to F27, and obviously doesn't sit all the time staring at the screen, when she returns and expects an upgraded system, there is a black command line screen saying that something is terribly wrong with the computer.

Version-Release number of selected component (if applicable):
systemd-234-7.fc27.x86_64

How reproducible:
always

Steps to Reproduce:
1. install an encrypted F27 system
2. start the system and wait for 90 seconds at the disk unlock screen
3. see being placed in a dracut rescue shell

Comment 1 Kamil Páral 2017-09-26 11:21:53 UTC
Created attachment 1331004 [details]
journal

Comment 2 Kamil Páral 2017-09-26 11:22:01 UTC
Created attachment 1331005 [details]
rdsosreport.txt

Comment 3 Kamil Páral 2017-09-26 11:22:08 UTC
Created attachment 1331006 [details]
rpm-qa

Comment 4 Kamil Páral 2017-09-26 11:24:14 UTC
CC Jiri Eischmann, who reported this to me in the first place. Three (out of three) of his colleagues saw this problem after distribution upgrade and thought it's a problem connected to it.

Comment 5 Kamil Páral 2017-09-26 11:31:47 UTC
This is a conditional violation of:
"A system installed without a graphical package set must boot to a working login prompt without any unintended user intervention, and all virtual consoles intended to provide a working login prompt must do so. "
https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria#Expected_installed_system_boot_behavior
Also
And
"In all of the above cases, if any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s) when provided with the correct passphrase(s)."
https://fedoraproject.org/wiki/Fedora_27_Alpha_Release_Criteria#Expected_installed_system_boot_behavior

If you wait a while before decrypting disks, the system fails to fulfill the criteria. Proposing as a Final blocker, because it doesn't affect everyone and can be quite easily worked around (just reboot), if you know how.

Comment 6 Michal Sekletar 2017-09-27 11:00:01 UTC
This issue can be fixed in dracut. Right now dracut generates timeout.conf drop-in for rootfs in order to prevent timeout of the start job for the device unit. Drop-in contains,
[Unit]
JobTimeoutSec=0

Since the introduction of "JobRunningTimeoutSec" option in systemd [1] this is not sufficient. Once start jobs for device units are queued they immediately transition to running state and hence JobRunningTimeoutSec is applied. In order to fix this, we need to generate different drop-in. I have modified dracut locally and following drop-in does the trick,

[Unit]
JobRunningTimeoutSec=0

The irony is that JobRunningTimeoutSec was introduced to help alleviate some issues around device unit timeouts. AFAICT, we also need DefaultJobRunningTimeoutSec in order for this to be actually useful. Users wouldn't need to generate device drop-ins or add x-systemd.device-timeout=0 on fstab entries because they could just set default timeout applied *only* to device units since JobTimeoutSec=0 (infinity) for all other units.

[1] https://github.com/systemd/systemd/commit/a2df3ea4ae058693bc7bf203d144e8af3c9493d2

Comment 7 Michal Sekletar 2017-09-27 11:50:17 UTC
Fix proposed upstream,

https://github.com/dracutdevs/dracut/pull/288

Comment 8 Joachim Frieben 2017-10-01 07:42:14 UTC

*** This bug has been marked as a duplicate of bug 1491847 ***

Comment 9 Kamil Páral 2017-10-02 09:01:08 UTC
*** Bug 1491847 has been marked as a duplicate of this bug. ***

Comment 10 Kamil Páral 2017-10-02 16:47:06 UTC
Discussed at blocker review meeting [1]:

AcceptedBlocker (Final) - This violates boot-related criteria when the system is encrypted and is not unlocked quickly enough.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-10-02/

Comment 11 Zbigniew Jędrzejewski-Szmek 2017-10-11 16:12:15 UTC
This is also independently fixed in systemd 235. If an update with 235 is submitted for F27, this will be another solution, and if not, the patch can always be backported.

Comment 12 Fedora Update System 2017-10-12 09:00:21 UTC
dracut-046-3.1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-a986f116b0

Comment 13 Fedora Update System 2017-10-12 12:20:09 UTC
dracut-046-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-f7109f3f6c

Comment 14 Fedora Update System 2017-10-13 06:24:56 UTC
dracut-046-4.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-f7109f3f6c

Comment 15 Kamil Páral 2017-10-13 10:17:13 UTC
(In reply to Fedora Update System from comment #13)
> dracut-046-4.fc27 has been submitted as an update to Fedora 27.
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-f7109f3f6c

Verified fixed.

Comment 16 Fedora Update System 2017-10-13 23:30:00 UTC
dracut-046-4.fc27 has been pushed to the Fedora 27 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.