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

[Andrei Borzenkov]

В Sun, 15 Mar 2015 19:48:10 +0100
Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl> пишет:

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

Why? If you need to run fsck on root filesystem you need console
access. Running it blind makes no sense. If you have console access you
can also modify kernel command line. Except when you are using sealed
bundle ... but it is explicitly excluded here.

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

That is rather an argument to *not* store kernel in ESP :)