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

[Kay Sievers]

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.

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

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

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

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.

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

Kay