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

[Kay Sievers]

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.

>> 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