> Gesendet: Sonntag, 15. März 2015 um 19:58 Uhr > Von: "Kay Sievers" <k...@vrfy.org> > An: "Zbigniew Jędrzejewski-Szmek" <zbys...@in.waw.pl> > Cc: "Jan Janssen" <medhe...@web.de>, systemd-devel@lists.freedesktop.org > Betreff: Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable > based fsck indication > > On Sun, Mar 15, 2015 at 7:48 PM, Zbigniew Jędrzejewski-Szmek > <zbys...@in.waw.pl> wrote: > > On Sun, Mar 15, 2015 at 06:48:24PM +0100, Kay Sievers wrote: > > >> It is legacy and does not need new features. It worked in the past and > >> will continue to work in the future, but it does not need new > >> questionable and possibly unreliable or dangerous features. The recent > >> merging of fsckd was already the wrong thing to do. > > Calling it legacy does not make it go away. If we had a stable > > non-fsck-using > > filesystem available, we could start discussing removing fsck support. > > But we don't. It's one thing to remove stuff once we have something > > better, and completely different to remove support for widely used > > things. > > Nobody talks about things going away, we just should not add more > non-trivial legacy support, that is all. > > >> >> the kernel command line should be sufficient enough. > >> > The kernel command line is not a good fit for a few reasons. > >> > >> The kernel commandline woked fine in the past and will be fine today, > >> especially for such a legacy feature. > > Support for /forcefsck (or whatever it was called) was removed with the > > promise to provide a replacement which does not require touching the fs. > > Kernel commandline is just too unwieldy for users. > > Writing to the file system content to request a check, which would > happen when things are already inconsistent, is a really stupid idea. > > If the filesytem is too dumb to have that info in the superblock flags > to store, to request a forced fsck, it is the problem of the file > system to fix and nothing we need to solve in systemd. > > >> No, they are absolutely not. Changing the EFI flash comes with > >> unpredictable risks, the flash is not meant to or designed for be > >> written to during any normal operation. > > Requesting fsck is not a normal operation. > > It is just a normal system operation. It needs to be fixed properly if > needed, not with dirty work-arounds like this. > > > If the flash is suitable > > to be written whenever the kernel is updated, it should be also OK > > to request a fsck through it. For users of many distributions (and > > kernel developers certainly), requesting fsck is a much rarer operation. > > Nobody would write to the flash on kernel updates, we only possibly > write to the ESP filesystem. The flash is not meant for such use > cases, it is known to brick all sorts of machines, and not to be > mis-used for such features.
As far as I remember, the bricking mainly happened because the kernel was writing kilobytes (maybe megabytes) worth of crashdumbs. This feature only touches a couple of bytes. > >> To avoid any possible misunderstanding here: > >> > >> Systemd will not use the fragile EFI flash store to configure services > >> or request system operation modes. The kernel command line is good > >> enough here. > >> > >> You will not apply this patch. > > I'd prefer to have a discussion and reach conclusions, not the other > > way around. > > Sorry, there is nothing to discuss, systemd will not mis-use the > fragile firmware flash for normal operations, and especially not to > support legacy features. > > Kay Though, I do see the other reservations against this. Though, someone might wanna close https://bugs.freedesktop.org/show_bug.cgi?id=88330 then. Jan _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
