On Tue, 10.09.13 12:23, Robert Schiele ([email protected]) wrote: > > Hi, > > On Tue, Sep 10, 2013 at 2:41 AM, Lennart Poettering > <[email protected]> wrote: > > On Fri, 06.09.13 14:53, Robert Schiele ([email protected]) wrote: > >> I was choosing the interface described above since according to my > >> observation this seems closest to how interfaces were constructed in > >> this area before. I am open to suggestions though for better > >> interfaces if someone comes up with one. Additionally I was not sure > >> whether the "no" option is practically useful but since it doesn't > >> seem completely out of place for me I included it for completeness. > > > > Hmm, if I get this right, then you'd set this for your images > > unconditionally? In that case it probably shouldn't be a kernel cmdline > > parameter but rather some kind of configuration file setting > > somewhere... > > Yes, that's what I had in mind first but then didn't find something > similar in related code and thought the idea might not be the style it > is typically done in systemd code. But now that you say that's the way > you would go I am happy to get back to this idea. > > > We generally try to empty out the kernel cmdline, so that it doesn't > > need any params by default, and is solely used for one-time overrides by > > the admin. > > Sounds perfectly resonable to me. > > > Before systemd, was there any way to trigger this behaviour via > > configuration (be it kernel cmdline or configuration file)? > > Well, in our old proprietary boot scripts we had that hard coded but > with the introduction of systemd I wanted to move away from this hard > coded stuff. > > > One possibility might be to add a new extended mount option (i.e. as > > listed in fstab's fourth column) that systemd > > would interpret. i.e. "x-systemd.yesfsck" or so. That sounds much nicer, > > since it would be naturally persistent, and per-mount point. > > Yes, that sounds good to me. I am just not sure how the proper > information flow should be implemented in systemd. If my understanding > of your idea is correct the setting would go into the mount service > file and thus could be read by the code for the mount service. The > mount service needed to forward this information to the automatically > created fsck service though. Is there a way to forward this > information or how would the fsck service get access to that?
Well, there is a way to pass that information on, but it is admittedly not pretty. Look how the fsck passno is currently passed fromt he mount point to the fsck. See mount_add_device_links() in src/core/mount.c. There we copy the passno into a newly loaded fsck unit. And we we probablöy should have a new bool for the fsckyes thingy here that is copied over at the same place... Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
