Bug 75176 - Support for mkinitcpio resume hook / resume= kernel parameter
Summary: Support for mkinitcpio resume hook / resume= kernel parameter
Status: RESOLVED NOTOURBUG
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: famo
QA Contact:
URL: https://bugs.archlinux.org/task/37028
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-18 21:21 UTC by famo
Modified: 2014-02-23 17:27 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description famo 2014-02-18 21:21:56 UTC
The mkinitcpio systemd hook currently doesn't support the resume hook and thus not the resume=/dev/sdX kernel parameter.

This means with the inclusion of systemd hook in mkinitcpio.conf, the resume hook is ignored which leads to unexpected behavior, extensive error triaging and frustration.

Therefore I suggest that either:
a) systemd adds support for the resume hook (best solution)
or
b) systemd provides it own means to support the resume= kernel parameter

Thanks for consideration.


See also:
https://bugs.archlinux.org/task/37028
Comment 1 Zbigniew Jedrzejewski-Szmek 2014-02-19 05:19:01 UTC
resume= is usually supported by systemd in the initramfs. Please assume that we are unfamiliar with mkinitcpio, and explain what change you'd like to see in systemd.
Comment 2 Sascha Shaw 2014-02-20 15:30:12 UTC
Maybe I can shed some light on the issue: mkinitcpio is a set of scripts that creates initial ramdisk environments in Arch Linux and related Distributions. Hooks, in this context, are shell scripts that add modules, binaries and other files to the ramdisk. There seems to be a problem (for some if not all Arch users) with resuming from hibernation when 'systemctl hibernate' is used in conjunction with the 'resume=' kernel parameter. I have not been using hibernation in a while, but it looks like the problem was introduced with systemd 207.

I will try to condense the multitude of message board posts and workarounds, once I get home from work, to see what has to be done.
Comment 3 Sascha Shaw 2014-02-20 15:32:00 UTC
By the way, the bug at the Arch linux bugtracker was closed for the following reason:

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 4 famo 2014-02-20 21:02:43 UTC
I'm no expert on this, but my understanding is this so far:

In the mkinitcpio.conf is a hook (i.e. a shell script), called "systemd". I assumed that this script is managed / maintained by systemd. (?) 

Besides the "systemd" script, there is also "resume" script, which writes the resume device into /sys/power/resume .

The problem is now that with the "systemd" script, the "resume" script isn't accounted for and thus resume device is never written to /sys/power/resume thus hibernation doesn't work as expected.
Comment 5 Zbigniew Jedrzejewski-Szmek 2014-02-20 21:13:01 UTC
(In reply to comment #4)
> In the mkinitcpio.conf is a hook (i.e. a shell script), called "systemd". I
> assumed that this script is managed / maintained by systemd. (?) 
No, we don't do anything like that.

> Besides the "systemd" script, there is also "resume" script, which writes
> the resume device into /sys/power/resume .
Not ours either.

> The problem is now that with the "systemd" script, the "resume" script isn't
> accounted for and thus resume device is never written to /sys/power/resume
> thus hibernation doesn't work as expected.
Sorry, but this is something that lives somewhere else.
Comment 6 famo 2014-02-23 17:27:02 UTC
@(In reply to comment #5)
> Sorry, but this is something that lives somewhere else.

Ok, noted.


@Sascha:
I was so bold to put you in CC. :-)

Could you get some information on what has to be done?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.