Description of problem: Reproduced in a VM that freshly installed+updated F35 cannot hibernate, it will do a normal boot ignoring the stored data in swap. It may be related to swap in encrypted LVM. I have tried it on Fedora-MATE_Compiz-Live-x86_64-35-1.2.iso, please do not ask me to reproduce it on Fedora-Workstation-Live-x86_64-35-1.2.iso . Version-Release number of selected component (if applicable): systemd-249.7-2.fc35.x86_64 How reproducible: Always. Steps to Reproduce: Install F35 as: Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 1050623 1048576 512M 83 Linux = /boot /dev/sda2 1050624 67108863 66058240 31.5G 83 Linux = LVM LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root f35lvm -wi-ao---- 11.98g swap f35lvm -wi-ao---- <19.50g Actual results: Dec 1 17:59:47 f35 dracut-cmdline[319]: Using kernel command line parameters: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.15.5-200.fc35.x86_64 root=/dev/mapper/f35lvm-root ro resume=/dev/mapper/f35lvm-swap rd.lvm.lv=f35lvm/root rd.luks.uuid=luks-b1f2a5bb-7e31-4741-b50b-14a3e957e772 rd.lvm.lv=f35lvm/swap Dec 1 17:59:57 f35 swapon[914]: swapon: /dev/mapper/f35lvm-swap: software suspend data detected. Rewriting the swap signature. Expected results: Resumed hibernate. Additional info: I guess there is some failure activating: systemd-hibernate.service systemd-hibernate-resume@.service
"resume=/dev/mapper/f35lvm-swap" is present, so it should work, strange. Please attach the full boot logs: boot with 'systemd.log-level=debug' on the kernel command line, and then attach 'journalctl -b'.
Created attachment 1844685 [details] journalctl -b after systemd.log-level=debug
In the past hibernation worked for me. But I was using LUKS root partition + LUKS swap partition without LVM. Also it was <=F34 (I cannot guarantee I did use hibernate on F34 although I probably did). Also it was a different laptop but that should be unrelated. So I suspect the change nonLVM->LVM did cause it (or F34->F35 upgrade).
Dec 04 12:00:22 f35.jankratochvil.net systemd[1]: blockdev@dev-mapper-f35lvm\x2droot.target: Failed to load configuration: No such file or directory It seems that the blockdev@.target file is missing from the initrd. This is not an immediate problem, because that unit file has just one line of effective configuration, but it's sloppy. You don't have systemd-hibernate-resume installed, and IIUC, dracut uses it's own implementation. Can you attach 'lsinitrd' output? I suspect you don't have the 'resume' module enabled in the initrd.
Created attachment 1844862 [details] lsinitrd initramfs-5.15.6-200.fc35.x86_64.img
(In reply to Zbigniew Jędrzejewski-Szmek from comment #4) > It seems that the blockdev@.target file is missing from the initrd. True, you can check the output. > You don't have systemd-hibernate-resume installed, and IIUC, dracut uses > it's own implementation. I do not know how to fix that - so that it works for a newly installed distro, can you suggest?
(In reply to Jan Kratochvil from comment #6) > (In reply to Zbigniew Jędrzejewski-Szmek from comment #4) > > It seems that the blockdev@.target file is missing from the initrd. > > True, you can check the output. What I was trying to say: it's a (small) bug in the dracut initrd generation logic. It should include this unit file if it's referred to by other units. In practice it probably doesn't matter because the unit only sets StopWhenUnneeded=yes, and the dracut initrd doesn't care too much about block devices becoming unused. > > You don't have systemd-hibernate-resume installed, and IIUC, dracut uses > > it's own implementation. > > I do not know how to fix that - so that it works for a newly installed > distro, can you suggest? It's not an error, just an observation. I don't remember all the dracut internals, so I had to figure out if it still uses a home-grown implementation. OK, so you don't have the 'resume' module enabled in your initrd. I guess that regenerating the module with that enabled will resolve the issue. There doesn't seem to be anything broken from the systemd side. I'll reassing this to dracut for additional comments.
*** This bug has been marked as a duplicate of bug 1795422 ***