[systemd-devel] Implementing resume from hibernation as a systemd unit file

Ivan Shapovalov intelfx100 at gmail.com
Fri Aug 15 02:54:06 PDT 2014

On Friday 15 August 2014 at 11:32:59, Lennart Poettering wrote:	
> On Fri, 15.08.14 13:02, Ivan Shapovalov (intelfx100 at gmail.com) wrote:
> Ah, well, if the resume= switch is supposed to simply carry the finished
> device node path, and nothing we still have to translate into one, then
> of course the entire udev rules step is unnecessary, and you can just
> write this out directly from the generator.

Yes, that's how it happens now.

> > > > Actually, the main question is how to order the resume unit. It needs to run
> > > > before any real filesystems are mounted (speaking in terms of initrd) AND before
> > > > rootfs is remounted read-write (speaking in terms of initrd-less system), but
> > > > after whatever is needed to make the device node appear.
> > > 
> > > You could turn this into a generator, that pulls the switch from the
> > > kernel cmdline, and generates a service that orders itself before
> > > local-fs-pre.taret and after the device you need. The device you need
> > > you give a stable name via an udev rule. 
> > 
> > So is "Before=local-fs-pre.target" a sufficient ordering for such resume unit?
> > 
> > Again, the resume unit must be started before any filesystems are (re)mounted
> > read-write, either from initrd or not.
> Yes. That should be enough.
> > Seems like there's at least systemd-remount-fs.service that also needs to be
> > taken into account...
> That only runs after the transition into the host OS.

I'd like to make this work both with initramfs and without one (provided that
the rootfs has been mounted read-only by using 'ro' kernel cmdline parameter).

In this case, what are the needed orderings?

Ivan Shapovalov / intelfx /

> Lennart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140815/e2efc2af/attachment.sig>

More information about the systemd-devel mailing list