Arch Linux

systemd merely writes to /sys/power/disk... if this doesn't work, it isn't a systemd problem.

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?

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.

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

Report it upstream, then. This isn't a packaging bug.

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

Well for me it is the systemd hook.

works: HOOKS="base udev autodetect ... resume filesystems"
does not work: HOOKS="base systemd autodetect ... resume filesystems"

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.

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.

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.

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/journal.org". 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.

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 arch-projects@archlinux.org if you'd like to take on options 1 or 2.

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.

FYI:
https://bugs.freedesktop.org/show_bug.cgi?id=75176