Bug 1705522

Summary: resume from hibernation times out on disk unlock screen after 90 seconds (even with systemd.device-timeout=0)
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: systemdAssignee: systemd-maint
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 30CC: awilliam, brian.murrell, galileo, lnykryn, mihai, msekleta, redhat-bugzilla, s, stefan.hoelldampf, susuresh, systemd-maint, zbyszek
Target Milestone: ---Keywords: CommonBugs
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: https://fedoraproject.org/wiki/Common_F30_bugs#encrypted-resume-delay
Fixed In Version: systemd-243.7-1.fc31 systemd-241-14.git18dd3fb.fc30 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-02-15 02:17:21 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
system journal
none
fstab none

Description Kamil Páral 2019-05-02 12:51:18 UTC 
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
Comment 1 Kamil Páral 2019-05-02 12:52:25 UTC 
Created attachment 1561604 [details]
system journal
Comment 2 Kamil Páral 2019-05-02 12:52:31 UTC 
Created attachment 1561605 [details]
fstab
Comment 3 Adam Williamson 2019-09-17 01:14:06 UTC 
Kamil, I assume this still affects F31?

systemd folks, any news on a fix for this?
Comment 4 Kamil Páral 2019-09-17 12:23:29 UTC 
Yes, F31 is still affected.
Comment 5 Dragan 2019-11-05 17:25:20 UTC 
6 moths have passed and apparently no one cares ...
Comment 6 Brian J. Murrell 2019-11-22 20:28:36 UTC 
This continues to happen on F31.

Would the component owner please comment?
Comment 7 Brian J. Murrell 2019-11-22 20:53:49 UTC 
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.
Comment 8 Adam Williamson 2019-11-22 21:18:33 UTC 
I agree that looks relevant. Zbigniew, is it backportable?
Comment 9 Brian J. Murrell 2019-11-22 21:26:34 UTC 
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?
Comment 10 Kamil Páral 2019-11-25 08:27:56 UTC 
(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.
Comment 11 Zbigniew Jędrzejewski-Szmek 2019-12-03 18:57:25 UTC 
(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
Comment 12 Fedora Update System 2020-02-06 15:27:32 UTC 
FEDORA-2020-f8e267d6d0 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-f8e267d6d0
Comment 13 Zbigniew Jędrzejewski-Szmek 2020-02-06 18:05:14 UTC 
Sorry for the delay. This should be fixed by the updates in F30+.
Comment 14 Fedora Update System 2020-02-07 01:03:55 UTC 
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
Comment 15 Kamil Páral 2020-02-07 12:45:20 UTC 
Zbigniew, is there a fix for F31 as well?
Comment 16 Fedora Update System 2020-02-11 20:38:59 UTC 
FEDORA-2020-87abf68a78 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-87abf68a78
Comment 17 Fedora Update System 2020-02-12 01:57:37 UTC 
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
Comment 18 Kamil Páral 2020-02-12 09:20:46 UTC 
(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.
Comment 19 Fedora Update System 2020-02-15 02:17:21 UTC 
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.
Comment 20 Fedora Update System 2020-02-21 01:17:45 UTC 
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.