systemd-hibernate-resume-generator | Call to Hibernate failed: Not enough swap space for hibernation after unable to parse the resume_offset configuration line

[rsramkis]

systemd version the issue has been seen with

254

Used distribution

EndeavourOS \ Arch

Linux kernel version used

6.4.7-zen1-2-zen

CPU architectures issue was seen on

x86_64

Component

other

Expected behaviour you didn't see

The system should go into hibernation when I execute "systemctl hibernate" from terminal.

Unexpected behaviour you saw

On boot I saw the following errors in the journal after upgrading from systemd 253.7 to 254:

Aug 01 17:23:42 mani systemd-hibernate-resume-generator[100]: Failed to parse resume_offset=36151296..: Invalid argument
Aug 01 17:23:42 mani systemd-hibernate-resume-generator[100]: Failed to parse kernel command line, ignoring: Invalid argument

I then decided to test the Hibernation by starting it from terminal which failed:

❯ systemctl hibernate
Call to Hibernate failed: Not enough swap space for hibernation

Note that my swap\hibernation file is 7.5 GB where my physical memory is 16 GB. I did confirm the swap file was still active.

In order to get Hibernation to work again I downgraded to systemd build 253.7 (which was previously installed.

Steps to reproduce the problem

1. Upgrade from systemd 253.7 to 254 in the Arch Repository.
2. Reboot the system.
3. Check the journals and see the error reported:

Aug 01 17:23:42 mani systemd-hibernate-resume-generator[100]: Failed to parse resume_offset=36151296..: Invalid argument
Aug 01 17:23:42 mani systemd-hibernate-resume-generator[100]: Failed to parse kernel command

4. Try to hibernate from terminal and get the below error:

❯ systemctl hibernate
Call to Hibernate failed: Not enough swap space for hibernation

Workaround:
Use downgrade to roll back from systemd 254 to 253.7.

Additional program output to the terminal or log subsystem illustrating the issue

No response

[mrc0mmand]

Can you share the full kernel cmdline (i.e. cat /proc/cmdline). I think the issue is that since 760e99b we check the resume_offset= as well and your offset appears to have two trailing dots (probably a copy-paste artifact from the filefrag outuput?)

[rsramkis]

Hi @mrc0mmand

This is the output of the command:

❯ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-linux-zen root=UUID=715c2972-1a51-4d73-89a0-86ea7bb5aa7f rw resume=UUID=715c2972-1a51-4d73-89a0-86ea7bb5aa7f resume_offset=36151296.. apparmor=1 lsm=landlock,lockdown,yama,apparmor,bpf

The dots have been there for a long time (and were in the instructions when I first set it up). I will remove the dots and see what happens.

[rsramkis]

Looks like after I removed the two dots there was no issue for systemd-hibernate-resume-generator parsing the file. So 254 build must be handling this differently now (as the test system is almost 2 years old and only displayed this warning today).

[mrc0mmand]

Looks like after I removed the two dots there was no issue for systemd-hibernate-resume-generator parsing the file. So 254 build must be handling this differently now (as the test system is almost 2 years old and only displayed this warning today).

Yup, as I mentioned in my previous comment - systemd v254 includes 760e99b which means we now check if the resume_offset= is valid.