On Sat, 09 Apr 2022 14:05:28 +0200, Andrei Borzenkov wrote:

In Tumbleweed EFI pstore backend is active due to

P: /devices/platform/efivars.0

L: 0

E: DEVPATH=/devices/platform/efivars.0

E: MODALIAS=platform:efivars

E: SUBSYSTEM=platform

E: USEC_INITIALIZED=25091896

E: ID_PATH=platform-efivars.0

E: ID_PATH_TAG=platform-efivars_0

uefi:~ # modinfo platform:efivars

filename: /lib/modules/5.17.1-1-kvmsmall/kernel/drivers/firmware/efi/efi-pstore.ko.zst

alias: platform:efivars

uefi:~ # cat /sys/module/efi_pstore/parameters/pstore_disable

N

uefi:~ # grep PSTORE /boot/config-5.17.1-1-kvmsmall

CONFIG_EFI_VARS_PSTORE=m

# CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE is not set

so dumps get written to NVRAM but nothing cleans them up - systemd provides systemd-pstore service, but it is part of systemd-experimental package that is not installed by default.

Should EFI pstore backend be enabled by default? It is explicitly disabled in SUSE/Leap

if (!backend && !strcmp(psi->name, "efi")) {

pr_info("Efi pstore disabled, enforce via pstore.backend=efi");

pr_info("On a broken BIOS, this can severely harm your system");

pr_info("Only enable efi based pstore when you know what you are doing");

return -EINVAL;

}

Good point. I heard already a few people hitting those problems (filling up pstore via dumps), so I'm for forward-porting the SLE patch. Moreover, aligning such basic behavior between TW and SLE is a good thing, in general. Care to open a bugzilla entry? thanks, Takashi

On 09.04.22 14:05, Andrei Borzenkov wrote:

so dumps get written to NVRAM but nothing cleans them up - systemd provides systemd-pstore service, but it is part of systemd-experimental package that is not installed by default.

Should EFI pstore backend be enabled by default? It is explicitly disabled in SUSE/Leap

Hi, this is a dangerous setting, because some systems do not boot anymore, if you fill up the available space. bsc#1197802 is about this or a very closely related issue.     Regards         Oliver