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? If you had a pointer to some documentation how to do this that would be great. Alternatively if you know of another service that is doing similar information forwarding a pointer to that one would be also good, such that I could implement this in a similar fashion. Robert _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
