On Mon, 25.08.14 02:16, Ivan Shapovalov ([email protected]) 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 '[email protected]' 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 [email protected] 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
