On Tue, Nov 26, 2013 at 11:25 PM, Thomas Bächler <[email protected]> wrote: > Am 26.11.2013 19:00, schrieb Tom Gundersen: >> On Tue, Nov 26, 2013 at 5:09 PM, Dave Reisner <[email protected]> wrote: >>> On Tue, Nov 26, 2013 at 04:35:13PM +0100, Thomas Bächler wrote: >>>> Am 26.11.2013 16:22, schrieb Dave Reisner: >>>>> I'll ask Harald about this -- Dracut uses a very similar mechanism (but >>>>> a bit more complex/convoluted). >>>> >>>> Nobody said this was easy to solve. >>>> >>> Consider the patch shelved for now. It's not something I care about -- >>> just thought I'd take a stab at fixing it for others. >> >> Well now I got interested ;-) >> >> Could this be solved (in a systemd world) by a systemd generator >> (running in the initramfs of course) generating a one-shot service >> which does the RUN from your udev rule, but which is ordered between >> the <hibernation>.device and local-fs-pre.target? > > This should work, but we have to be careful that everything that touches > file systems is ordered After=local-fs-pre.target. > > I would not put this into udev, but use a service file.
Sure, that's what I meant. > Simply have a > service ordered Before=local-fs-pre.target, which binds to the > hibernation device (generated from the resume= option). I have no idea > what happens if you add another job to systemd in the middle of booting > up - and doing everything with a service file seems cleaner to me. > > FYI, [email protected] currently has no ordering to > local-fs-pre.target, this may lead to races between resuming and fsck. Ok. Something to keep in mind. -t
