Description of problem: If I start a previously-hibernated system and doesn't immediately input my disk decryption password on the corresponding plymouth screen, but instead e.g. go for a coffee and type the password several minutes later, the system will no longer be resumed from hibernation, but instead started fresh (and previously unsaved work lost). The journal shows: May 02 16:34:57 phoenix systemd[1]: Starting Cryptography Setup for luks-e31caabd-b498-4d5c-86d5-f5b4f51c0065... May 02 16:34:57 phoenix systemd[1]: Started Forward Password Requests to Plymouth. ... May 02 16:36:25 phoenix systemd[1]: dev-mapper-phoenix\x2dswap.device: Job dev-mapper-phoenix\x2dswap.device/start timed out. May 02 16:36:25 phoenix systemd[1]: Timed out waiting for device /dev/mapper/phoenix-swap. May 02 16:36:25 phoenix systemd[1]: Dependency failed for Resume from hibernation using device /dev/mapper/phoenix-swap. May 02 16:36:25 phoenix systemd[1]: systemd-hibernate-resume@dev-mapper-phoenix\x2dswap.service: Job systemd-hibernate-resume@dev-mapper-phoenix\x2dswap.service/start failed with result 'dependency'. May 02 16:36:25 phoenix systemd[1]: dev-mapper-phoenix\x2dswap.device: Job dev-mapper-phoenix\x2dswap.device/start failed with result 'timeout'. ... It seems the timeout is set to 90 seconds. If you don't provide your password in 90 seconds, resume is no longer attempted. My fstab looks like: /dev/mapper/phoenix-root / ext4 defaults,discard,x-systemd.device-timeout=0 1 1 UUID=78be65cc-5467-4118-8523-5a6c16dd0988 /boot ext4 defaults,discard 1 2 UUID=B9F8-1D3F /boot/efi vfat umask=0077,shortname=winnt 0 2 /dev/mapper/phoenix-swap swap swap defaults,x-systemd.device-timeout=0 0 0 Note "systemd.device-timeout=0" for both swap and root. It doesn't seem to apply in this case. Version-Release number of selected component (if applicable): systemd-241-8.git9ef65cb.fc30.x86_64 How reproducible: always Steps to Reproduce: 1. install a system with disks encrypted 2. check that hibernation works well for you 3. hibernate your system using "systemctl hibernate" 4. boot the system, don't provide the password on plymouth screen yet 5. wait more than 2 minutes 6. provide the password 7. see that the system won't resume (your previous windows will not be restored), but will instead boot fresh
Created attachment 1561604 [details] system journal
Created attachment 1561605 [details] fstab
Kamil, I assume this still affects F31? systemd folks, any news on a fix for this?
Yes, F31 is still affected.
6 moths have passed and apparently no one cares ...
This continues to happen on F31. Would the component owner please comment?
I lied. I forgot this laptop is still only F30. https://github.com/systemd/systemd/commit/4b381a9ef65d68dc79760b093436a9c81f43fa5d looks relevant but only in perhaps 243 and newer. F30 still has only 241.
I agree that looks relevant. Zbigniew, is it backportable?
As an interim workaround, can one simply add resumeflags=x-systemd.device-timeout=86400 to one's kernel command args on an F30 system to get the desired behaviour?
(In reply to Brian J. Murrell from comment #7) > https://github.com/systemd/systemd/commit/ > 4b381a9ef65d68dc79760b093436a9c81f43fa5d looks relevant but only in perhaps > 243 and newer. F30 still has only 241. The problem is still present even in F31 with systemd-243.4-1.fc31.x86_64 (which should contain that PR). So the PR most probably doesn't fix the issue anyway.
(In reply to Adam Williamson from comment #8) > I agree that looks relevant. Zbigniew, is it backportable? It is, but as Kamil noted, it doesn't really solve the issue on its own. Also, I don't think it makes much sense. I opened a PR upstream, let's see where this goes: https://github.com/systemd/systemd/pull/14241
FEDORA-2020-f8e267d6d0 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-f8e267d6d0
Sorry for the delay. This should be fixed by the updates in F30+.
systemd-241-14.git18dd3fb.fc30 has been pushed to the Fedora 30 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-2020-f8e267d6d0
Zbigniew, is there a fix for F31 as well?
FEDORA-2020-87abf68a78 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-87abf68a78
systemd-243.7-1.fc31 has been pushed to the Fedora 31 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-2020-87abf68a78
(In reply to Fedora Update System from comment #16) > FEDORA-2020-87abf68a78 has been submitted as an update to Fedora 31. > https://bodhi.fedoraproject.org/updates/FEDORA-2020-87abf68a78 Great, I can confirm the problem is fixed on my machine.
systemd-243.7-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
systemd-241-14.git18dd3fb.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.