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

[Zbigniew Jędrzejewski-Szmek]

On Sun, Mar 15, 2015 at 06:48:24PM +0100, Kay Sievers wrote:
> On Sun, Mar 15, 2015 at 4:44 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
> > On Sun, Mar 15, 2015 at 03:23:19PM +0100, Kay Sievers wrote:
> >> On Sun, Mar 15, 2015 at 11:56 AM, Jan Janssen <medhefgo at web.de> wrote:
> >> > ---
> >> >  man/systemctl.xml                  | 26 ++++++++++++++++
> >> >  shell-completion/bash/systemctl.in |  8 ++++-
> >> >  shell-completion/zsh/_systemctl.in |  2 ++
> >> >  src/fsck/fsck.c                    | 63 +++++++++++++++++++++++++++++++++++++
> >> >  src/shared/efivars.h               | 21 +++++++++++--
> >> >  src/systemctl/systemctl.c          | 64 +++++++++++++++++++++++++++++++++-----
> >>
> >> Fsck is really something from the past, it should not be extended
> >> beyond its current support.
> > Filesystems which require fsck are in wide use and will be in wide use
> > for the forseeable future.
> 
> 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.

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

> > and yet another is that changing the commandline is a problem in the
> > scheme in which kernel+initrd+cmdline are signed together.
> 
> Such kernels will just not be used with a rootfs that needs fsck. It
> makes no sense to sign andn seal the kernel for a legacy unsigned file
> system.
OK. 

> > EFI variables are the right solution for EFI systems.
> 
> 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. 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.

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

> >> Using non-volatile EFI variables for normal system operations does not
> >> sound right, we should not start using that fragile subsystem for
> >> things like this
> > Volatile indeed sounds better. Are there volatile variables which are survive
> > a reboot but are then erased automatically?
> 
> No, there is only volatile (in RAM from the bootloader to the OS), or
> non-volatile (writing to the flash).
Thank you for the explanation.

Zbyszek