Bug 2028195

Summary: systemctl hibernate ignores the resume data
Product: [Fedora] Fedora Reporter: Jan Kratochvil <jan>
Component: dracutAssignee: dracut-maint-list
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 35CC: dracut-maint-list, dtardon, fedoraproject, filbranden, flepied, jamacku, jan, jonathan, lnykryn, msekleta, ryncsn, ssahani, s, systemd-maint, yuwatana, 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:19: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
journalctl -b after systemd.log-level=debug
none
lsinitrd initramfs-5.15.6-200.fc35.x86_64.img none

Description Jan Kratochvil 2021-12-01 17:10:10 UTC 
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
Comment 1 Zbigniew Jędrzejewski-Szmek 2021-12-04 10:34:08 UTC 
"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'.
Comment 2 Jan Kratochvil 2021-12-04 11:04:28 UTC 
Created attachment 1844685 [details]
journalctl -b after systemd.log-level=debug
Comment 3 Jan Kratochvil 2021-12-04 11:33:42 UTC 
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).
Comment 4 Zbigniew Jędrzejewski-Szmek 2021-12-06 07:50:18 UTC 
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.
Comment 5 Jan Kratochvil 2021-12-06 08:34:43 UTC 
Created attachment 1844862 [details]
lsinitrd initramfs-5.15.6-200.fc35.x86_64.img
Comment 6 Jan Kratochvil 2021-12-06 08:36:49 UTC 
(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?
Comment 7 Zbigniew Jędrzejewski-Szmek 2021-12-06 08:52:05 UTC 
(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.
Comment 8 David Tardon 2021-12-06 09:19:21 UTC 

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