Bug 1982641

Summary:	Fedora Workstation instance fails to wake up from hibernation
Product:	[Fedora] Fedora	Reporter:	Libor Pechacek <lpechacek>
Component:	dracut	Assignee:	dracut-maint-list
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	34	CC:	dracut-maint-list, dtardon, jonathan, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-12-06 09:35:17 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:

Description Libor Pechacek 2021-07-15 10:41:03 UTC

Description of problem:
It is possible to hibernate a system with `systemctl hibernate`, provided that swap space is properly configured. However, the system fails to restore its state on the next boot.

Version-Release number of selected component (if applicable):
systemd-248-2.fc34.x86_64
dracut-053-4.fc34.x86_64
kernel-5.11.12-300.fc34.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Install a system with a real swap partition on the disk.
2. Issue `systemctl hibernate` on the shell command line.
3. Power up the system.

Actual results:
The system comes up anew, losing all data that weren't saved before the hibernation. This happens even if I disable the zram based swap partition before hibernation.

Expected results:
The system state is restored.

Additional info:
Package versions, kernel command line (contains "resume=" parameter), partition layout.

[user@dhcp72 ~]$ rpm -q systemd dracut kernel
systemd-248-2.fc34.x86_64
dracut-053-4.fc34.x86_64
kernel-5.11.12-300.fc34.x86_64

[user@dhcp72 ~]$ cat /proc/cmdline 
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.11.12-300.fc34.x86_64 root=UUID=c709e8cb-64f9-4d5c-b547-b39c7db78cc5 ro rootflags=subvol=root resume=UUID=2d295c17-12b8-438b-b9b9-21e0fabbd76f rhgb quiet

[user@dhcp72 ~]$ lsblk -f
NAME   FSTYPE FSVER LABEL                 UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                           
├─sda1 ext4   1.0                         42bc1d7b-69b4-4154-91ec-69cf75949fbb  744,6M    17% /boot
├─sda2 swap   1                           2d295c17-12b8-438b-b9b9-21e0fabbd76f                [SWAP]
└─sda3 btrfs        fedora_localhost-live c709e8cb-64f9-4d5c-b547-b39c7db78cc5    4,4G    49% /home
sr0                                                                                           
zram0                                                                                         [SWAP]

Comment 1 Libor Pechacek 2021-07-15 10:46:44 UTC

For the record, I filed the bug against Dracut as it has the "resume" module built-in. The resume can be initiated by the kernel in case it recognizes the partition during its startup. However, if the corresponding storage drivers are initialized only from initrd, then it's Dracut that triggers the resume from userspace. Attempting to initiate a resume after the root file system is mounted is a recipe for a disaster. That said, initrd looks like the best place to perform the system state restoration. Feel free, however, to change the OS component and/or reassign the bug as you like. Thanks!

Comment 2 David Tardon 2021-12-06 09:35:17 UTC


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