[PATCH] [PATCH] gnu: system: Disable EFI pstore backend by default

  • Done
  • quality assurance status badge
Details
3 participants
  • Felix Lechner
  • Leo Famulari
  • Roman Riabenko
Owner
unassigned
Submitted by
Roman Riabenko
Severity
normal

Debbugs page

Roman Riabenko wrote 2 months ago
(address . guix-patches@gnu.org)(name . Roman Riabenko)(address . roman@riabenko.com)
20250124160840.3114-1-roman@riabenko.com
* 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

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(+)

Toggle diff (18 lines)
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
Leo Famulari wrote 1 months ago
Re: Could not prepare Boot variable
(address . 75808@debbugs.gnu.org)
Z5g5JY-9lE9HRNST@jasmine.lan
On Wed, Jan 22, 2025 at 10:06:19AM +0200, Efraim Flashner wrote:
Toggle quote (7 lines)
> 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:


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.
Felix Lechner wrote 1 months ago
(name . Leo Famulari)(address . leo@famulari.name)
87frl3556o.fsf@lease-up.com
Hi Leo,

On Mon, Jan 27 2025, Leo Famulari wrote:

Toggle quote (2 lines)
> 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
Leo Famulari wrote 1 months ago
(name . Felix Lechner)(address . felix.lechner@lease-up.com)
Z5kPh0UwO8imI85y@jasmine.lan
On Tue, Jan 28, 2025 at 07:27:59AM -0800, Felix Lechner wrote:
Toggle quote (4 lines)
> 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?
Felix Lechner wrote 1 months ago
(name . Leo Famulari)(address . leo@famulari.name)
874j1i69ci.fsf@lease-up.com
Hi Leo,

On Tue, Jan 28 2025, Leo Famulari wrote:

Toggle quote (2 lines)
> 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
Leo Famulari wrote 1 months ago
(name . Felix Lechner)(address . felix.lechner@lease-up.com)
Z5k1KmpZisuHnUhG@jasmine.lan
On Tue, Jan 28, 2025 at 11:12:45AM -0800, Felix Lechner wrote:
Toggle quote (8 lines)
> 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.
Leo Famulari wrote 1 months ago
Re: [bug#75808] [PATCH] gnu: system: Disable EFI pstore backend by default
(name . Roman Riabenko via Guix-patches via)(address . guix-patches@gnu.org)
Z5lAUDa9qwSLYW0L@jasmine.lan
On Fri, Jan 24, 2025 at 06:01:54PM +0200, Roman Riabenko via Guix-patches via wrote:
Toggle quote (2 lines)
> * 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.

From c55c77f0758bc35b2543987b8cf3d78af5282a56 Mon Sep 17 00:00:00 2001
Message-ID: <c55c77f0758bc35b2543987b8cf3d78af5282a56.1738096695.git.leo@famulari.name>
From: Roman Riabenko <roman@riabenko.com>
Date: Tue, 28 Jan 2025 13:50:29 -0500
Subject: [PATCH] gnu: system: Disable EFI pstore backend by default

This commit 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 changing the option via 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

* gnu/packages/linux.scm (default-extra-linux-options): Enable the kernel
build-time configuration option CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE.

Change-Id: Id0294fa90ccbf3bacbb55a22aeb4f0a863efe22c
Co-authored-by: Leo Famulari <leo@famulari.name>
---
gnu/packages/linux.scm | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

Toggle diff (24 lines)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index f236aefed5..ba735c4921 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -920,7 +920,11 @@ (define (default-extra-linux-options version)
("CONFIG_VIRTIO_MMIO" . m)
("CONFIG_FUSE_FS" . m)
("CONFIG_CIFS" . m)
- ("CONFIG_9P_FS" . m)))
+ ("CONFIG_9P_FS" . m)
+ ;; Disable the EFI pstore storage backend to avoid causing
+ ;; unrecoverable failures on some EFI systems:
+ ;; https://lists.gnu.org/archive/html/help-guix/2025-01/msg00173.html
+ ("CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE" . #t)))
(define (config->string options)
(string-join (map (match-lambda

base-commit: 97fb1887ad10000c067168176c504274e29e4430
prerequisite-patch-id: fb8199eb3a9afa9d787a86b2cf7f408992d7e9a1
prerequisite-patch-id: bfa219db9b8e6aa9a58d2f395dd6ef85ff5bc856
prerequisite-patch-id: f9e40dd45ac4ce149a5d41317488a2485514e8ad
--
2.47.1
Leo Famulari wrote 1 months ago
Re: [PATCH] gnu: system: Disable EFI pstore backend by default
(address . 75808-done@debbugs.gnu.org)
Z6E0Nfcj2hop6JWP@jasmine.lan
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.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 75808@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 75808
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help