[systemd-devel] [RFC] [PATCHv3 0/3] resume: implement support for resuming from hibernation

[Lennart Poettering]

On Mon, 25.08.14 02:16, Ivan Shapovalov (intelfx100 at gmail.com) wrote:

> This patchset allows systemd to parse resume= kernel command line parameter
> and initiate resume from the specified device.
> 
> It adds:
> - a 'systemd-resume' tool which takes path to a device node and
>   writes its major:minor to /sys/power/state;
> - a corresponding 'systemd-resume at .service' templated unit;
> - a 'systemd-resume-generator' generator which parses the kernel command line
>   and instantiates the unit as necessary.
> 
> This functionality already exists in-kernel, but only for "/dev/sdXY"-style
> pathes. Implementing it in userspace allows to use arbitrary udev-created
> symlinks, e. g. persistent block device pathes ("/dev/disk/by-foo/bar").
> 
> Userspace parsing of resume= kernel command line parameter has been
> traditionally done in initramfs via shell scripts (for Arch Linux, this is
> "resume" mkinitcpio hook), so I feel that this feature has its place within
> systemd.
> 
> Due to the nature of hibernation, the resume unit must be activated before
> any modifications to filesystems take place. This can happen only in initramfs
> before mounting anything.
> 
> So, first patch orders all non-root fsck after local-fs-pre.target, which in
> turn allows to order the resume unit before those fsck instances.
> 
> Second and third patches add the tool, the unit and the generator.
> 
> There are some issues with this implementation.
> 
> - legacy usr.mount is not automatically ordered after local-fs-pre.target,
>   so systemd-resume at .service has to be manually ordered before it;

Not following here. We do not really support /usr split out unless it is
already mounted in the initrd. But in the initrd its called
"sysroot-usr.mount"... To me this doesn't look like something to do here?

> - systemd-udevd.service, which is needed for creating persistent block device
>   symlinks, is transitively ordered after systemd-remount-fs.service via at
>   least systemd-udev-hwdb-update.service and systemd-sysusers.service.
>   Hence, if these units are present, an ordering cycle happens and resume is
>   impossible.

Hmm? What's the cycle precisely? Not following?

Lennart

-- 
Lennart Poettering, Red Hat