On Thursday 14 August 2014 at 12:56:10, Lennart Poettering wrote: > On Thu, 14.08.14 09:20, Ivan Shapovalov (intelfx...@gmail.com) wrote: > > > The udev rule should be possible (provided that udevd does not need rootfs > > remounted read-write -- I'd like to preserve some decency towards > > initrd-less > > systems), but udev is a framework for handling events, whereas we don't have > > any events here: such symlink can be derived from kernel command-line alone, > > statically. > > udev is totally fine with read-only everything. It just needs writable > /run. > > > Yes, a udev rule would allow to create a symlink which is tracked by > > systemd, > > so the dev-disk-resume.device appears and then it can be easily After='ed > > from the resume unit, but... really, is udev the proper tool for this? > > The symlink thing we already do in a very similar way for the gpt auto root > logic (see > 60-persistent-storage.rules) already, so there's prior art.
Understood. So there's a helper (ata_id) ran by IMPORT which sets ID_PART_GPT_AUTO_ROOT, and then this variable is used to match against... Looks beautiful, but here's a slightly another case. In context of hibernation/resume, the path to device node is already explicitly specified as a kernel cmdline parameter, and it could be anything from /dev/sdXY to /dev/disk/by-label/foo, so we can't use a helper to translate that path into a per-device flag (pathes for devices are generated after running helpers). So, IIUC, using udev is not an option here. Did I miss anything? If I didn't, are you OK with the "generator + templated unit" approach? > > > 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. Seems like there's at least systemd-remount-fs.service that also needs to be taken into account... Thanks, -- Ivan Shapovalov / intelfx / > > That's pretty much exactly how the got auto root thing works... > > Lennart > >
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
