GNU bug report logs - #75808
[PATCH] [PATCH] gnu: system: Disable EFI pstore backend by default

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75808 in the body.
You can then email your comments to 75808 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Roman Riabenko <roman <at> riabenko.com>
To: guix-patches <at> gnu.org
Cc: Roman Riabenko <roman <at> riabenko.com>
Subject: [PATCH] [PATCH] gnu: system: Disable EFI pstore backend by default
Date: Fri, 24 Jan 2025 18:01:54 +0200

* gnu/system.scm (%default-kernel-arguments): Add efi_pstore.pstore_disable=1.

Change-Id: Id0294fa90ccbf3bacbb55a22aeb4f0a863efe22c
---

This patch disables one of the backends for the persistent storage driver pstore
in the Linux kernel, in particular the backend which allows it to save data to
EFI variables storage in UEFI NVRAM, such as error log "dump" files.

This reduces writes to UEFI to reduce the chances of it wearing out or
malfunctioning for other reasons, as well as prevents situations when the efivar
is full and cannot take new variables, which is known to cause
"Could not prepare Boot variable: No space left on device" errors on computers
with some UEFI implementations which are susceptible to such problems, typically
on relatively older machines. The user is confronted by the issue at the later
stages of guix system reconfiguration when the new boot entry is created. It may
be difficult to recover from because the exact cause depends on UEFI. Sometimes
it is enough to remove dumps from efivars. Disabling the EFI pstore backend is
expected to reduce the chances of unaware users running into issues with UEFI
and failing to boot their Guix Systems.

Sophisticated users may still enable the backend by removing the option from the
kernel arguments, either in the system configuration or in GRUB.

The above is my summary of what was previously discussed in guix-help mailing
list: <https://lists.gnu.org/archive/html/help-guix/2025-01/msg00173.html>.

Disclosure: I have ran into this issue recently. I am a guix user who researched
the topic but not a developer.

To be sure, I reconfigured the system with this patch and it worked as expected
by adding the kernel argument.

 gnu/system.scm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gnu/system.scm b/gnu/system.scm
index 8df871f255..5785cfdd9a 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -761,6 +761,9 @@ (define %default-kernel-arguments
   ;; Default arguments passed to the kernel.
   (list (string-append "modprobe.blacklist="
                        (string-join %default-modprobe-blacklist ","))
+        ;; Avoiding susceptible UEFIs failures from efivars used for pstore, see
+        ;; <https://lists.gnu.org/archive/html/help-guix/2025-01/msg00173.html>.
+        "efi_pstore.pstore_disable=1"
         "quiet"))
 
 (define* (operating-system-directory-base-entries os)

base-commit: 13367c6c47f5a4962dde6fab480ea14cd0ac536c
-- 
2.47.1

Message #8 received at 75808 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Roman Riabenko <roman <at> riabenko.com>,
 Christophe Pisteur <christophe.pisteur <at> fsfe.org>,
 znavko--- via <help-guix <at> gnu.org>,
 Felix Lechner <felix.lechner <at> lease-up.com>,
 Wilko Meyer <w <at> wmeyer.eu>, Efraim Flashner <efraim <at> flashner.co.il>
Cc: 75808 <at> debbugs.gnu.org
Subject: Re: Could not prepare Boot variable
Date: Mon, 27 Jan 2025 20:55:49 -0500

On Wed, Jan 22, 2025 at 10:06:19AM +0200, Efraim Flashner wrote:
> While I like the adherence to upstream's decisions and not doing
> downstream development through patches, in this case we should try to
> remove the footgun that has bit us multiple times in the past.
>
> What if we leave the kernel config as-is but add
> efi_pstore.pstore_disable=1 as a default kernel argument during boot?

I've pushed the patch in #75808 to the 'kernel-updates' branch as commit
4f30f754e7f12b81cb8b9d9cc5bc24ad83c41681 in order to test the build on
our build farm. It will appear here shortly:

https://ci.guix.gnu.org/jobset/kernel-updates

I do wonder about the right place to make this change. Currently we can
make special changes to the kernel configuration in two ways:

1) at build time, in ((gnu packages linux) default-extra-linux-options)
2) at run time, in ((gnu system) %default-kernel-arguments)

In both cases, the system administrator can override the setting during
boot.

Is there a good reason to choose one or the other? If not, I'm inclined
to choose the former (build time), since that is where the bulk of these
special changes are currently made. It seems icky to have two lists. We
can leave the list of run-time settings for things cannot be configured
at build time, like modprobe blacklisting.

Your thoughts?

PS, I sent this message twice because I forgot to CC the patch tracker
and I want this message to appear there too.

Message #11 received at 75808 <at> debbugs.gnu.org (full text, mbox):

From: Felix Lechner <felix.lechner <at> lease-up.com>
To: Leo Famulari <leo <at> famulari.name>
Cc: Roman Riabenko <roman <at> riabenko.com>, Wilko Meyer <w <at> wmeyer.eu>,
 Christophe Pisteur <christophe.pisteur <at> fsfe.org>,
 Efraim Flashner <efraim <at> flashner.co.il>, znavko--- via <help-guix <at> gnu.org>,
 75808 <at> debbugs.gnu.org
Subject: Re: Could not prepare Boot variable
Date: Tue, 28 Jan 2025 07:27:59 -0800

Hi Leo,

On Mon, Jan 27 2025, Leo Famulari wrote:

> Your thoughts?

You should choose whichever is easier and more intuitive for you.

If you go with build time, which I find reasonable, please consider that
the change from vanilla is less visible to users and should therefore be
documented better.

Kind regards
Felix

Message #14 received at 75808 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Felix Lechner <felix.lechner <at> lease-up.com>
Cc: Roman Riabenko <roman <at> riabenko.com>, Wilko Meyer <w <at> wmeyer.eu>,
 Christophe Pisteur <christophe.pisteur <at> fsfe.org>,
 Efraim Flashner <efraim <at> flashner.co.il>, znavko--- via <help-guix <at> gnu.org>,
 75808 <at> debbugs.gnu.org
Subject: Re: Could not prepare Boot variable
Date: Tue, 28 Jan 2025 12:10:31 -0500

On Tue, Jan 28, 2025 at 07:27:59AM -0800, Felix Lechner wrote:
> If you go with build time, which I find reasonable, please consider that
> the change from vanilla is less visible to users and should therefore be
> documented better.

Do you have something in mind to improve documentation of this change? A
Guix news entry, perhaps?

Message #17 received at 75808 <at> debbugs.gnu.org (full text, mbox):

From: Felix Lechner <felix.lechner <at> lease-up.com>
To: Leo Famulari <leo <at> famulari.name>
Cc: Roman Riabenko <roman <at> riabenko.com>, Wilko Meyer <w <at> wmeyer.eu>,
 Christophe Pisteur <christophe.pisteur <at> fsfe.org>,
 Efraim Flashner <efraim <at> flashner.co.il>, znavko--- via <help-guix <at> gnu.org>,
 75808 <at> debbugs.gnu.org
Subject: Re: Could not prepare Boot variable
Date: Tue, 28 Jan 2025 11:12:45 -0800

Hi Leo,

On Tue, Jan 28 2025, Leo Famulari wrote:

> A Guix news entry, perhaps?

A news entry is probably a good idea, although I was thinking about the
manual.  Maybe a new section entitled "Kernel Options" in Chapter 11
"System Configuration" right after "Bootloader Configuration?"

With Initrd section before it, the order would remain in reverse of the
boot process and de-emphasize the somewhat esoteric topic of kernel
options, if you also think that's appropriate.

Kind regards
Felix

Message #20 received at 75808 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Felix Lechner <felix.lechner <at> lease-up.com>
Cc: Roman Riabenko <roman <at> riabenko.com>, Wilko Meyer <w <at> wmeyer.eu>,
 Christophe Pisteur <christophe.pisteur <at> fsfe.org>,
 Efraim Flashner <efraim <at> flashner.co.il>, znavko--- via <help-guix <at> gnu.org>,
 75808 <at> debbugs.gnu.org
Subject: Re: Could not prepare Boot variable
Date: Tue, 28 Jan 2025 14:51:06 -0500

On Tue, Jan 28, 2025 at 11:12:45AM -0800, Felix Lechner wrote:
> A news entry is probably a good idea, although I was thinking about the
> manual.  Maybe a new section entitled "Kernel Options" in Chapter 11
> "System Configuration" right after "Bootloader Configuration?"
> 
> With Initrd section before it, the order would remain in reverse of the
> boot process and de-emphasize the somewhat esoteric topic of kernel
> options, if you also think that's appropriate.

I see. I'm probably not going to do this, but others are welcome to
pitch in! I don't see why we need to document this particular kernel
option in the manual, compared to the thousands of others.

Message #23 received at 75808 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Roman Riabenko via Guix-patches via <guix-patches <at> gnu.org>
Cc: Roman Riabenko <roman <at> riabenko.com>, 75808 <at> debbugs.gnu.org
Subject: Re: [bug#75808] [PATCH] gnu: system: Disable EFI pstore backend by
 default
Date: Tue, 28 Jan 2025 15:38:40 -0500

[Message part 1 (text/plain, inline)]

On Fri, Jan 24, 2025 at 06:01:54PM +0200, Roman Riabenko via Guix-patches via wrote:
> * gnu/system.scm (%default-kernel-arguments): Add efi_pstore.pstore_disable=1.

As discussed in the help-guix thread, here is a patch that makes this
change via the build-time configuration system rather than the run-time
command line.

https://lists.gnu.org/archive/html/help-guix/2025-01/msg00201.html

[0001-gnu-system-Disable-EFI-pstore-backend-by-default.patch (text/plain, attachment)]

Message #31 received at 75808-done <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: 75808-done <at> debbugs.gnu.org
Subject: Re: [PATCH] gnu: system: Disable EFI pstore backend by default
Date: Mon, 3 Feb 2025 16:25:09 -0500

I pushed this fix as commit 616ae36e0f557cecb4abe58c5b0973b9428d25e0.

I decided to effect the change using the Guile
'default-extra-linux-options' interface to the build-time kernel
configuration.

Thanks to everyone involved for helping debug and suggest fixes.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.