Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
On Monday 2013-10-07 14:25, Karel Zak wrote: On Tue, Sep 10, 2013 at 04:55:19PM +0100, Colin Guthrie wrote: 'Twas brillig, and Tom Gundersen at 10/09/13 13:45 did gyre and gimble: On Tue, Sep 10, 2013 at 2:31 PM, Jan Engelhardt jeng...@inai.de wrote: On Tuesday 2013-09-10 13:52, Dave Reisner wrote: the FUSE program knows nothing about the systemd-specific nofail or x-*. Note that mount(8) does not strip nofail when call mount.type helpers. And that I would feel is a problem, because it would require that every mount helper out there be updated every time some special option is added. nofail is something that mount should strip, because it is IMHO specific to mount and/or the system boot, and not the helper. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
On Tue, Sep 10, 2013 at 04:55:19PM +0100, Colin Guthrie wrote: 'Twas brillig, and Tom Gundersen at 10/09/13 13:45 did gyre and gimble: On Tue, Sep 10, 2013 at 2:31 PM, Jan Engelhardt jeng...@inai.de wrote: On Tuesday 2013-09-10 13:52, Dave Reisner wrote: the FUSE program knows nothing about the systemd-specific nofail or x-*. We have nofail since 2007 in mount(8) (by patch from Suse:-), since 2009 in fsck(8) and since 2010 in swapon(8). Note that mount(8) does not strip nofail when call mount.type helpers. This should only be a problem if you directly use the FUSE mount helper. If you instead invoke mount with -t fuse.$fusetype, then this isn't an issue. mount(8) *does* understand these options and nicely strips them out before invoking the specific mount helper for you. If it were so that mount stripped them, I would not be reporting it, would I. Or maybe that is a feature of a future util-linux? # grep /mnt /etc/fstab /srv/www /mnt fuse.bindfs auto,nofail,group=company,perms=g+rw,create-for-group=www,create-with-perms=g+r:go-w 0 0 # mount /mnt fuse: unknown option `nofail' # rpm -q util-linux util-linux-2.21.2-10.2.1.x86_64 hmm... we have 2.24-rc1 now ;-) Hm, I thought that feature was part of 2.21... or perhaps your distro is still not using the libmount based mount? BTW, v2.24 is probably last release with old deprecated non-libmount based mount(8). I suspect this issue (libmount based mount) as this is what hit us a while back (I think our problem there was not using libmount in nfs-utils rather than mount itself, but my memory is fuzzy and I could be getting this wrong) It's really really bad idea to use old deprecated mount(8) on system with systemd. The old mount code is completely frozen in last years, no new features at all... Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
Hi, On Tue, Sep 10, 2013 at 2:41 AM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 06.09.13 14:53, Robert Schiele (rschi...@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? 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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
On Tuesday 2013-09-10 02:41, Lennart Poettering wrote: On Fri, 06.09.13 14:53, Robert Schiele (rschi...@gmail.com) wrote: 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. Opinions? Loosely related: Mount options are a problem with mount helpers. If you have, for example, a FUSE mount marked with nofail so that your boot phase does not get interrupted if it fails, attempting to manually mount it later on always fails, because the FUSE program knows nothing about the systemd-specific nofail or x-*. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
On Tue, Sep 10, 2013 at 01:40:32PM +0200, Jan Engelhardt wrote: On Tuesday 2013-09-10 02:41, Lennart Poettering wrote: On Fri, 06.09.13 14:53, Robert Schiele (rschi...@gmail.com) wrote: 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. Opinions? Loosely related: Mount options are a problem with mount helpers. If you have, for example, a FUSE mount marked with nofail so that your boot phase does not get interrupted if it fails, attempting to manually mount it later on always fails, because the FUSE program knows nothing about the systemd-specific nofail or x-*. This should only be a problem if you directly use the FUSE mount helper. If you instead invoke mount with -t fuse.$fusetype, then this isn't an issue. mount(8) *does* understand these options and nicely strips them out before invoking the specific mount helper for you. d ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
On Tue, Sep 10, 2013 at 1:52 PM, Dave Reisner d...@falconindy.com wrote: On Tue, Sep 10, 2013 at 01:40:32PM +0200, Jan Engelhardt wrote: On Tuesday 2013-09-10 02:41, Lennart Poettering wrote: On Fri, 06.09.13 14:53, Robert Schiele (rschi...@gmail.com) wrote: 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. Opinions? Loosely related: Mount options are a problem with mount helpers. If you have, for example, a FUSE mount marked with nofail so that your boot phase does not get interrupted if it fails, attempting to manually mount it later on always fails, because the FUSE program knows nothing about the systemd-specific nofail or x-*. This should only be a problem if you directly use the FUSE mount helper. If you instead invoke mount with -t fuse.$fusetype, then this isn't an issue. mount(8) *does* understand these options and nicely strips them out before invoking the specific mount helper for you. Right, and nofail and x-* are proper mount(8) options, and are not systemd specific at all. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
On Tuesday 2013-09-10 13:52, Dave Reisner wrote: the FUSE program knows nothing about the systemd-specific nofail or x-*. This should only be a problem if you directly use the FUSE mount helper. If you instead invoke mount with -t fuse.$fusetype, then this isn't an issue. mount(8) *does* understand these options and nicely strips them out before invoking the specific mount helper for you. If it were so that mount stripped them, I would not be reporting it, would I. Or maybe that is a feature of a future util-linux? # grep /mnt /etc/fstab /srv/www /mnt fuse.bindfs auto,nofail,group=company,perms=g+rw,create-for-group=www,create-with-perms=g+r:go-w 0 0 # mount /mnt fuse: unknown option `nofail' # rpm -q util-linux util-linux-2.21.2-10.2.1.x86_64 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
On Tue, 10.09.13 12:23, Robert Schiele (rschi...@gmail.com) wrote: Hi, On Tue, Sep 10, 2013 at 2:41 AM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 06.09.13 14:53, Robert Schiele (rschi...@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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
'Twas brillig, and Tom Gundersen at 10/09/13 13:45 did gyre and gimble: On Tue, Sep 10, 2013 at 2:31 PM, Jan Engelhardt jeng...@inai.de wrote: On Tuesday 2013-09-10 13:52, Dave Reisner wrote: the FUSE program knows nothing about the systemd-specific nofail or x-*. This should only be a problem if you directly use the FUSE mount helper. If you instead invoke mount with -t fuse.$fusetype, then this isn't an issue. mount(8) *does* understand these options and nicely strips them out before invoking the specific mount helper for you. If it were so that mount stripped them, I would not be reporting it, would I. Or maybe that is a feature of a future util-linux? # grep /mnt /etc/fstab /srv/www /mnt fuse.bindfs auto,nofail,group=company,perms=g+rw,create-for-group=www,create-with-perms=g+r:go-w 0 0 # mount /mnt fuse: unknown option `nofail' # rpm -q util-linux util-linux-2.21.2-10.2.1.x86_64 Hm, I thought that feature was part of 2.21... or perhaps your distro is still not using the libmount based mount? I suspect this issue (libmount based mount) as this is what hit us a while back (I think our problem there was not using libmount in nfs-utils rather than mount itself, but my memory is fuzzy and I could be getting this wrong) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
On Fri, 06.09.13 14:53, Robert Schiele (rschi...@gmail.com) wrote: In some situations it is desirable to set the fsck fix level from -a to -y. This for instance might be a reasonable decision on embedded systems where a user dealing with emergency mode is not available and we prefer the risk of destroying the file system by an incorrect fsck action over the risk of hanging in unhandled file system inconsistencies that could be fixed. The fix introduces a new kernel command line option fsck.fix=auto|yes|no with auto being the default and thus not changing default behavior to previous behavior. auto maps to the fsck option -a, yes maps to -y, and no maps to -n. --- 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... 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. Before systemd, was there any way to trigger this behaviour via configuration (be it kernel cmdline or configuration file)? 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. Opinions? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] make fsck fix mode a kernel command line option
In some situations it is desirable to set the fsck fix level from -a
to -y. This for instance might be a reasonable decision on embedded
systems where a user dealing with emergency mode is not available and
we prefer the risk of destroying the file system by an incorrect fsck
action over the risk of hanging in unhandled file system
inconsistencies that could be fixed.
The fix introduces a new kernel command line option
fsck.fix=auto|yes|no with auto being the default and thus not
changing default behavior to previous behavior. auto maps to the
fsck option -a, yes maps to -y, and no maps to -n.
---
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.
Robert
src/fsck/fsck.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index f298cf7..0beddb1 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -40,6 +40,11 @@
static bool arg_skip = false;
static bool arg_force = false;
static bool arg_show_progress = false;
+static enum {
+FSCK_FIX_AUTO,
+FSCK_FIX_YES,
+FSCK_FIX_NO
+} arg_fixmode = FSCK_FIX_AUTO;
static void start_target(const char *target) {
DBusMessage *m = NULL, *reply = NULL;
@@ -122,6 +127,12 @@ static int parse_proc_cmdline(void) {
arg_force = true;
else if (strneq(w, fsck.mode=skip, l))
arg_skip = true;
+else if (strneq(w, fsck.fix=auto, l))
+arg_fixmode = FSCK_FIX_AUTO;
+else if (strneq(w, fsck.fix=yes, l))
+arg_fixmode = FSCK_FIX_YES;
+else if (strneq(w, fsck.fix=no, l))
+arg_fixmode = FSCK_FIX_NO;
else if (startswith(w, fsck))
log_warning(Invalid fsck parameter. Ignoring.);
#ifdef HAVE_SYSV_COMPAT
@@ -326,7 +337,17 @@ int main(int argc, char *argv[]) {
}
cmdline[i++] = /sbin/fsck;
-cmdline[i++] = -a;
+switch (arg_fixmode) {
+case FSCK_FIX_AUTO:
+cmdline[i++] = -a;
+break;
+case FSCK_FIX_YES:
+cmdline[i++] = -y;
+break;
+case FSCK_FIX_NO:
+cmdline[i++] = -n;
+break;
+}
cmdline[i++] = -T;
cmdline[i++] = -l;
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
