Zander671/kdumpst
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

kdump: Refactor devnode setting / derivation

Browse Source 
Thanks to Emil (@xexaxo) suggestion, we hereby implement a less fragile
way of obtaining the "/home" mount point. Emil suggested that instead of
using device name directly, we could use the generic link, as in:
"/dev/disk/by-partsets/shared/home".

In principle the change would be simple, but it proved to be a bit tricky
due to the early boot stage kdump executes - in such point we don't have
this link available, so we need to rely in the full device name directly
on kdump collection. We achieve that by saving this information in the
kdump initrd - this is not completely safe, see the CAVEAT below.

Also, we improved kdump loading script by using "findmnt", a less
fragile / more elegant way of getting the "/home" mount point.

CAVEAT: NVMe multipathing introduced a "randomness" level to device
naming on Linux, so "nvme0n1" could be "nvme1n1" in some boots, if we
have more than one device. There is a kernel parameter to avoid that
("nvme_core.multipath=0"), see [0] for more information.
Due to this reason, we could in theory have different NVMe device
names between regular kernel boot and the kdump one, hence causing a
failure in kdump collection.
But this is pretty much safe since we don't have multiple NVMe
devices, also we could disable multipath in kernel config
(CONFIG_NVME_MULTIPATH) or use the above cmdline.

[0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1792660/

Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
This commit is contained in:
Guilherme G. Piccoli
2022-02-22 19:02:08 -03:00
parent e77d43c08f
commit 725d6d7149
5 changed files with 37 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
README.md
View File

@ -93,6 +93,16 @@
# https://lists.archlinux.org/pipermail/aur-general/2022-January/036767.html
# https://aur.archlinux.org/packages/makedumpfile/#comment-843853
#
# (e) NVMe multipathing introduced a "randomness" level to device naming on
# Linux, so "nvme0n1" could be "nvme1n1" in some boots, if we have more than
# one NVMe device. There's a kernel parameter to avoid that
# ("nvme_core.multipath=0"). So, since we rely in getting the NVMe device name
# to be used in kdump during the regular boot process, we could in theory have
# different names between regular kernel boot and the kdump one, hence causing
# a failure in kdump collection. But this is pretty much safe now since we
# don't have multiple NVMe devices, also we could disable multipath in kernel
# config (CONFIG_NVME_MULTIPATH) or use the above cmdline.
#
#
# TODOs
# ###########################################################################
@ -103,10 +113,8 @@
# images - it happens due to our package installing files on directory
# "/usr/lib/dracut/modules.d" which triggers the unfortunate initramfs rebuild.
#
# * We have a "fragile" way of determining a mount point required for Kdump;
# this is something to improve maybe, in order to make the Kdump more reliable.
# Also in the list of fragile things, VDF parsing is...complicated. Something
# that would be nice to improve as well.
# * VDF parsing would benefit from some improvement, it's at least "fragile"
# for now, to be generous...but that seems a bit complicated.
#
# * Pstore ramoops back-end has some limitations that we're discussing with
# the kernel community - right now we can only collect ONE dmesg and its