On Fri, 15.08.14 13:54, Ivan Shapovalov (intelfx...@gmail.com) wrote: > On Friday 15 August 2014 at 11:32:59, Lennart Poettering wrote: > > On Fri, 15.08.14 13:02, Ivan Shapovalov (intelfx...@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?
Actually systemd-remount-fs.service uses After=local-fs-pre.target anyway, so ordering before l-f-p.t should be enough. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel