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

[Lennart Poettering]

On Mon, 25.08.14 21:52, Ivan Shapovalov (intelfx100 at gmail.com) wrote:

> > > - 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?
> 
> Theoretically it is possible to have initramfs's /usr split out.
> I know that it sounds crazy, but if someone will do this, they will lose their
> data if usr.mount not properly handled.

initrd cannot have their data split out. I am completely happy about
breaking this, should it exist (which I doubt).

> If either "systemd-udev-hwdb-update.service" or "systemd-sysusers.service"
> becomes part of the transaction (== becomes included in the initramfs),
> it becomes impossible for "systemd-resume at .service" to start after
> "systemd-udevd.service". The outcome can vary:
> 
> - a 90 second wait for dev-disk-by\x2dfoo-bar.device and dependency failure
>   (if "After=systemd-udevd.service" has not been specified);
>
> - an ordering cycle and removal of "systemd-resume at .service" from transaction
>   (if "After=systemd-udevd.service" has been specified, just as it is now).
> 
> Both situations are very unlikely (who would add usr.mount to initramfs? who
> would add systemd-sysusers.service to initramfs?), but nevertheless possible.

Hmm, let me see, so you are basically saying that udev wants to run
after sysusers, and sysusers shall run after the file systems are
mounted, and that systemd-resume at .service wants to run before that, but
needs to wait until the devices have popped up, which they won't until
udev is started?

So, I am pretty sure we don#t want an explicit After= order here between
dbus and systemd-resume at .service...

Hmm, but yuck, I don't see a nice way to fix this for good. Grrr.

I'd probably just merge this as is, and let people who are crazy enough
to run sysuers or hwdb-update in the initrd, to figure this out. Let's
just wait until this pops up...

Lennart

-- 
Lennart Poettering, Red Hat