[systemd-devel] [RFC] [PATCHv3 0/3] resume: implement support for resuming from hibernation
intelfx100 at gmail.com
Mon Aug 25 11:23:51 PDT 2014
On Monday 25 August 2014 at 20:07:28, Lennart Poettering wrote:
> 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).
OK. Removed "Before=usr.mount" for v4.
> > 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?
Yes, I've meant exactly this.
> 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...
So, do you want me to leave "After=systemd-udevd.service" or remove it?
(An ordering cycle or a waiting timeout?)
Ivan Shapovalov / intelfx /
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 213 bytes
Desc: This is a digitally signed message part.
More information about the systemd-devel