[systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication

[Jan Janssen]

> Gesendet: Sonntag, 15. März 2015 um 19:58 Uhr
> Von: "Kay Sievers" <kay at vrfy.org>
> An: "Zbigniew Jędrzejewski-Szmek" <zbyszek at in.waw.pl>
> Cc: "Jan Janssen" <medhefgo at web.de>, systemd-devel at 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
> <zbyszek at 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