92afdc48d6
The gitlab issue https://gitlab.freedesktop.org/gpiccoli/kdumpst/-/issues/19
was first reported by Saurabh, regarding GPU drivers getting included on
the kdump initrd. We've managed to improve the code a bit, but the solution
we proposed there was both wrong (for initcpio) *and* incomplete.
The user Ethanell reopened the issue, mentioning that even after the
patch that allegedly fixed the problem, they were getting amdgpu driver
included in the kdump initrd. That was the "wrong" portion of the fix:
in my naivety, I thought we could just remove the modules in the kdump
install hook. But...happens that initcpio works with a lazy approach: some
install hooks execute add_module(), and that signals to the later effective
inclusion of the modules by mkinitcpio; so in other words, the kdump
install hook was deleting no modules at all.
Special thanks to Foxboron and noclaf for the discussion about that on
IRC, which was very enlightening.
Now, the proper approach is simple: just to skip hooks that add the GPU
drivers, like plymouth and kms. Also took the opportunity to include the
microcode hook in the ban list, since we don't want kernel updating CPU
ucode in case of the microcode packages were updated (would be rare, but
why not save a bit of space dropping that?). Finally, I've removed the
GPU drivers delete code from the initcpio kdump install hook, since it
was a nop in the end.
That's it, right? No. Still there's the part two of my statement above:
the prior approach was wrong, but not only, it was also *incomplete*. That
is due to cases like Ethanell's: users that manually include GPU drivers
in their initramfs images, for things like crypto or splash screen. It's
also hard or better saying, *impossible*, to guess all hooks that add GPU
drivers to the initramfs.
So to cover manual inclusions or other hooks, we also add hereby extra
kdump command-line flags to avoid the DRM and some GFX drivers probe
during the kdump kernel boot. In order to not grow the drivers ban list
too much, my attempt was to add common in-tree GPU drivers, but also block
the DRM init call. Hopefully this time this is enough to disable GFX on kdump!
Fixes: 4767b8095f ("initramfs: Fix the removal of GPU drivers from the minimal initrd")
Reported-by: Ethanell (@flifloo)
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
71 lines
3.4 KiB
Bash
71 lines
3.4 KiB
Bash
#!/bin/sh
|
|
#
|
|
# SPDX-License-Identifier: LGPL-2.1-or-later
|
|
#
|
|
# Copyright (c) 2021 Valve
|
|
# Maintainer: Guilherme G. Piccoli <gpiccoli@igalia.com>
|
|
#
|
|
# Configuration settings for kdump/pstore. After _any_ change in this
|
|
# file, it's required to re-create the kdump minimal initramfs by running:
|
|
# /usr/lib/kdumpst/kdumpst-load.sh create-initrd
|
|
#
|
|
#
|
|
# Pstore-RAM settings
|
|
# If USE_PSTORE_RAM is set to 1, Kdump won't be loaded. Instead, the Pstore
|
|
# RAM backend will be configured. In order to have success, this operation
|
|
# relies in having an available RAM buffer on /proc/iomem with at least
|
|
# PSTORE_MEM_AMOUNT (decimal, bytes) in size. Also, kernel must be able to
|
|
# allocate a contiguous memory amount of PSTORE_RECORD_SZ (decimal, bytes).
|
|
# If there is no such RAM buffer, there is a possibility to make use of
|
|
# the crash kernel area for that. There are risks: such memory area could
|
|
# have its address mapped differently across kernel updates; also if both
|
|
# pstore and the kdump kernel are loaded, that memory region will be for
|
|
# sure corrupted by the kexec panic load - so, kind of a last resource.
|
|
USE_PSTORE_RAM=1
|
|
PSTORE_MEM_AMOUNT=4194304
|
|
PSTORE_RECORD_SZ=1048576
|
|
PSTORE_RAM_USE_CRASH_MEM=0
|
|
#
|
|
#
|
|
# Mount-related options
|
|
# since the link is not present so early in the system boot. MOUNT_FOLDER
|
|
# MOUNT_FOLDER is the the place in which both pstore and kdump logs will
|
|
# be stored, as well as the kdump initrd and some ancillary data. This
|
|
# directory should be in an accessible filesystem (read/write) and if such
|
|
# folder doesn't exist, it'll be created.
|
|
MOUNT_FOLDER="/var/crash/kdumpst"
|
|
#
|
|
#
|
|
# Kdump controlling settings
|
|
# Currently we only do local storage log collection (no network/iscsi dumps).
|
|
# If FULL_COREDUMP is !=0, we collect a full compressed vmcore, which might
|
|
# require a lot of disk space. The MAKEDUMPFILE_*_CMD settings refer to
|
|
# tunings on makedumpfile - we rely on zstd compression and maximum page
|
|
# exclusion for the full vmcore, mimic'ing Debian/Ubuntu kdump. We also
|
|
# base on Debian/Ubuntu for the KDUMP_CMDLINE_APPEND option - this contains
|
|
# the kernel parameters we append in the /proc/cmdline for the kdump kernel;
|
|
# the most important parameters are nr_cpus=1 (to save RAM memory usage and
|
|
# avoid some potential issues with SMP) and reset_devices (some drivers
|
|
# rely on that for proper kdump).
|
|
FULL_COREDUMP=1
|
|
MAKEDUMPFILE_COREDUMP_CMD="-z -d 31"
|
|
MAKEDUMPFILE_DMESG_CMD="--dump-dmesg"
|
|
KDUMP_APPEND_CMDLINE="panic=-1 oops=panic fsck.mode=force fsck.repair=yes nr_cpus=1 reset_devices initcall_blacklist=drm_core_init module_blacklist=amdgpu,i915,nouveau"
|
|
#
|
|
#
|
|
# GRUB-related settings
|
|
# GRUB_AUTOSET determines if the kdumpst loader tool should try to
|
|
# automatically set grub.cfg in order to reserve memory for kdump (if
|
|
# needed, i.e., when pstore is not in use) - keep it as '1' for enabling
|
|
# the mechanism (this is the default). GRUB_BOOT_FILE is the full path of
|
|
# grub.cfg file - this is used in the config update step plus for syncing
|
|
# purposes. GRUB_CFG_FILE is the config file we edit in order to add/remove
|
|
# the crashkernel parameter. Finally, GRUB_CMDLINE holds the change to be
|
|
# made in the grub config file, specially the crashkernel memory reservation
|
|
# (notice that a trailing space is required in this line, so we avoid
|
|
# messing with other kernel parameters).
|
|
GRUB_AUTOSET=1
|
|
GRUB_BOOT_FILE="/boot/grub/grub.cfg"
|
|
GRUB_CFG_FILE="/etc/default/grub"
|
|
GRUB_CMDLINE="crashkernel=256M "
|