[systemd-devel] [PATCH] make fsck fix mode a kernel command line option

Lennart Poettering lennart at poettering.net
Tue Sep 10 07:35:29 PDT 2013


On Tue, 10.09.13 12:23, Robert Schiele (rschiele at gmail.com) wrote:

> 
> Hi,
> 
> On Tue, Sep 10, 2013 at 2:41 AM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Fri, 06.09.13 14:53, Robert Schiele (rschiele at gmail.com) 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.


More information about the systemd-devel mailing list