Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#37028 - [systemd] 207 hibernation does not work

Attached to Project: Arch Linux
Opened by Edvinas Klovas (w0rm) - Monday, 23 September 2013, 07:42 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 19 February 2014, 13:42 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 10
Private No


Description: systemd hibernation does not work with systemd 207-5. When booting the system after it hibernated, it always gives a fresh boot. It works fine on systemd 204-3.

Additional info:
* systemd 207-5

Steps to reproduce:
This task depends upon

Closed by  Dave Reisner (falconindy)
Wednesday, 19 February 2014, 13:42 GMT
Reason for closing:  Deferred
Additional comments about closing:  No one seems to understand the actual bug here. Still isn't a systemd bug, either.
Comment by Dave Reisner (falconindy) - Monday, 23 September 2013, 21:57 GMT
systemd merely writes to /sys/power/disk... if this doesn't work, it isn't a systemd problem.
Comment by Edvinas Klovas (w0rm) - Tuesday, 24 September 2013, 10:38 GMT
The only packages that I upgrade are systemd and systemd-sysvcompat from 204-3 to 207-5 version. No other changes, besides running mkinitcpio. Is it a problem with hooks then?
Comment by Dave Reisner (falconindy) - Tuesday, 24 September 2013, 12:56 GMT
You tell me -- are you not using the resume hook? Is the resume hook not writing the resume device to /sys/power/resume? Are you hibernating suspending before hibernating and maybe the block devices major:minor in /sys/power/resume is no longer the device you want to be the resume device?

There's a lot of things that might go wrong here, but systemd isn't one of them.
Comment by Stanislav (Stanislav_pythonist) - Thursday, 26 September 2013, 14:23 GMT
Confirm this bug. It appeared after upgrade to systemd 207. I have resume hook now and before upgrade. My hooks:
HOOKS="systemd autodetect modconf block filesystems keyboard fsck resume"

I also tried this
HOOKS="base systemd autodetect modconf block filesystems keyboard fsck resume"
Result doesn't change

If it any help, result of:
cat /sys/power/disk
[platform] shutdown reboot suspend
Comment by Dave Reisner (falconindy) - Thursday, 26 September 2013, 14:28 GMT
Report it upstream, then. This isn't a packaging bug.
Comment by Stanislav (Stanislav_pythonist) - Thursday, 26 September 2013, 14:48 GMT
Can it be due to improperly configuration of kernel? Some bugs in kernel was fixed since systemd updates to 207 and may be some changes can indirectly cause this? I don't know, this is just my thoughts
Comment by wombalton (wombalton) - Saturday, 28 September 2013, 09:20 GMT
Well for me it is the systemd hook.

works: HOOKS="base udev autodetect ... resume filesystems"
does not work: HOOKS="base systemd autodetect ... resume filesystems"
Comment by Dave Reisner (falconindy) - Saturday, 28 September 2013, 13:06 GMT
So then there's no bug here and it has nothing at all to do with systemd. The resume hook relies on the shell version of /init provided by base.
Comment by James (thx1138) - Wednesday, 13 November 2013, 17:54 GMT
  • Field changed: Percent Complete (100% → 0%)
1) still broken with systemd-208-2

2) the justification for closing does not address the circumstances of the bug - "resume" fails with or without the "base" hook - resume fails with the systemd hook, but not with the udev hook.

3) the claim that systemd itself is not the cause of the bug seems to suggest that the problem is with "mkinitcpio", and you are the mkinitcpio maintainer.
Comment by Dave Reisner (falconindy) - Wednesday, 13 November 2013, 17:56 GMT
This will continue to be "broken" with systemd 209, and 210, and 211.... There's nothing to fix in systemd itself.

The "fix" does not need to be in mkinitcpio either. The fact that we setup the resume device in early userspace is a historical artifact.

Patches welcome. I do not use this feature, nor do I have any personal interest in fixing it.
Comment by James (thx1138) - Friday, 15 November 2013, 17:51 GMT
So far, I notice in the log that the hibernate file is saved, but there is a "can't find or can't load" error message on reboot, when using the systemd hook.

One solution to a "systemd initramfs" is to simply use dracut, which works.

$ sudo yaourt -S dracut
$ sudo vim /etc/dracut.conf
$ sudo dracut -f /boot/initramfs-linux.img

But then, after some random update, about a month ago, I get boot-pauses, and then sometimes, after the "Welcome to Arch Linux!" log message, boot-hangs, when systemd is suppose to start, unless the "debug" boot parameter is added to the kernel command line. This is with either mkinitcpio or with dracut. Ha! Like some "quantum physics" event, the problem cannot be seen when it being observed! Some people have had some luck with disabling the journal, by "sudo mv /var/log/journal /var/log/". The systemd pauses and hangs may or may not be a distinct problem from the mkinitcpio systemd hook hibernation problem.

Of course, if the swap partition is not accessible for some reason with early systemd, when the hibernate file is being searched-for, then resume is going to fail with the "can't load" error message. Maybe there's a sequencing issue, accessing the swap partition.
Comment by Dave Reisner (falconindy) - Friday, 15 November 2013, 18:33 GMT
I already regret reopening this. Here's the current situation, since I'm not sure you understand what this bug is about:

mkinitcpio has 2 different /init binaries: one provided by the "base" hook (a shell script) and the other provided by the "systemd" hook (systemd itself). These DO NOT cooperate with each other -- the last of these two in the HOOKS variable of /etc/mkinitcpio.conf will win. Based on which binary you're using, your experience will vary. This is why packages like lvm2 now provide an "lvm2" hook as well as an "sd-lvm2" hook.

If you use the "base" hook with the "resume" hook, the resume= kernel commandline parameter will be read and the appropriate sysfs file written to to setup the resume device. If you use the "systemd" hook, then the script provided by the "resume" hook will never be run. Ever. This is the basis for the misunderstanding in this bug report.

Therefore: If you want the resume hook to work with the systemd hook, you need to go write code. You have a few options:

1) Write a generalized solution for running the shell based hooks under systemd.
2) Write an sd-resume hook which replicates the functionality of the resume hook.
3) Write some other method of writing the resume device major:minor to /sys/power/resume which doesn't take place in early userspace. I'd bet that, for a lot of systems, you might even be able to get away with using tmpfiles.d for this.

Git formatted patches against mkinitcpio can be sent to if you'd like to take on options 1 or 2.
Comment by James (thx1138) - Friday, 15 November 2013, 20:01 GMT
Ah! Thanks for that clarification Dave. That helps. The operation of the different hooks really was unclear, and nothing to do with the udev hook, in this case. Perhaps something to add to the mkinitcpio documentation.
Comment by test0 (test0) - Wednesday, 19 February 2014, 13:30 GMT