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]
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!
*** This bug has been marked as a duplicate of bug 1795422 ***