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
Created attachment 1331004 [details] journal
Created attachment 1331005 [details] rdsosreport.txt
Created attachment 1331006 [details] rpm-qa
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.
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.
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
Fix proposed upstream, https://github.com/dracutdevs/dracut/pull/288
*** This bug has been marked as a duplicate of bug 1491847 ***
*** Bug 1491847 has been marked as a duplicate of this bug. ***
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/
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.
dracut-046-3.1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-a986f116b0
dracut-046-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-f7109f3f6c
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
(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.
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.