Re: [PATCH v4 00/13] crashkernel=auto: support fadump and remove crashkernel.default

On Tue, Dec 28, 2021 at 08:38:47AM +0800, Coiby Xu wrote: After fixing some trivial issue, For the series, except [8/13] which I am not sure about some sed expression (I will take more time to verify it).

Reviewed-by: Pingfan Liu <piliu(a)redhat.com&gt; > v4: > - fixes suggested by Philipp > - fix the bug of always turning fadump off in "kdumpctl reset-crashkernel" > - no duplicate "echo -n" > - "&>/dev/null" replaced by "grep -q" > - wording improvements > - no longer check if the kernel path returned from "grubby --info" > physically exists so setting up crashkernel would work for osbuild > - fix the bug that couldn't switch between --fadump=on and > --fadump=nocma using "kdumpctl reset-crashkernel" > - add comments for "kdumpctl reset-crashkernel" to improve code > readability > > v3: > - fixes suggested by Philipp > - fix incorrect usage of kdump_get_arch_recommend_crashkernel > - s/get_default_crashkernel/get-default-crashkernel > - no longer depends on grubby --update-kernel=ALL to update all > kernels' command line parameter and using a single loop to simplify > the code > - indentation issue fix > - commit message improvement > - update crashkernel-howto.txt as suggested by Dave > - CoreOS suppport > - makes "kdumpctl reset-crashkernel" work for CoreOS > - kdumpctl can't be run in RPM scriplet, disable it for > CoreOS > - set up kernel crashkernel for osbuild > > v2: > - no longer address the swiotlb memory requirement when SME is enabled > - automatically reset crashkernel to default value only when the value > is set by kexec-tools before. So the crashkernel option to added to > kdump.conf is replaced auto_reset_crashkernel option instead > - multiple fixes suggested by Philipp including regex improvement, typo > fixes, grubby kernel path check and commit message improvements > - address the case where a kernel path is not > /boot/vmlinuz-{KERNEL_RELEASE} > - "kdumpctl fadump" dropped. Support fadump via > "kdumpctl reset-crashkernel [--fadump=[on|off|nocma]]" instead > > The crashkernel=auto implementation in kernel space has been rejected > upstream [1]. The current user space implementation [2] [3] ships a > crashkernel.default but hasn't supported fadump. Meanwhile the > crashkernel.default implementation seems to be overly complex, > - the default kernel crashkernel value rarely changes. This is no > need to ship the same crashkernel.default default for every kernel > package of a architecture; > - when deciding the value of crashkernel for a new kernel, the > crashkernel.default of installed kernels and running kernel > is took into consideration (for the details, check > 92-crashnernel.install). > > According to Kairui [4], crashkernel.default per kernel package is to > accommodate kernel difference, for example, different kernels could be > built with different configurations thus different crashkernel values > are needed. But these should be minor cases and may not be sufficent to > justify the complexity of 92-crashkernel.install. Currently, we don't > know how a kernel debug/feature config would affect the crashkernel > value. Even if a kernel config may require much larger crashkernel, we > can address it in kexec-tools later. > > There are are known cases that could lead to a larger crashkernel > including enabling SME, LUKS encryption and etc. But this patch set > would put them aside since they may be took care of in the kernel > space instead. > > So this patch set would simply add support for fadump and move the > default kernel crashkernel from kernel package to kexec-tools, > - provide "kdumpctl get-default-crashkernel" for kdump-anaconda-addon > to get the default kernel crashkernel values for a specific > architecture (fadump is supported as well) > - re-write "kdumpctl reset-crashkernel" to support fadump > - introduce auto_reset_crashkernel which determines whether to reset > kernel crashkernel to new default value or not when kexec-tools updates > the default crashkernel value > > Because the kernel hook /usr/lib/kernel/install.d/20-grub.install would > make the installed kernel inherit the kernel cmdline of current running > kernel i.e. /proc/cmdline, we only need to reset crashkernel when > kexec-tools increases the default crashkernel values. > > > [1] https://lore.kernel.org/linux-mm/20210507010432.IN24PudKT%25akpm@linux-fo... > [2] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1171 > [3] https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.o... > [4] https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.o... > > > Coiby Xu (13): > update default crashkernel value > factor out kdump_get_arch_recommend_crashkernel > provide kdumpctl get-default-crashkernel for kdump_anaconda_addon and > RPM scriptlet > add a helper function to read kernel cmdline parameter from grubby > --info > add helper functions to get dump mode > add helper functions to get kernel path by kernel release and the path > of current running kernel > fix incorrect usage of rpm-ostree to update kernel command line > parameters > rewrite reset_crashkernel to support fadump and to used by RPM > scriptlet > introduce the auto_reset_crashkernel option to kdump.conf > try to reset kernel crashkernel when kexec-tools updates the default > crashkernel value > reset kernel crashkernel for the special case where the kernel is > updated right after kexec-tools > set up kernel crashkernel for osbuild in kernel hook > update crashkernel-howto > > 92-crashkernel.install | 135 +--------------- > crashkernel-howto.txt | 123 +++------------ > kdump-lib.sh | 60 ++++--- > kdump.conf | 7 + > kdump.conf.5 | 6 + > kdumpctl | 345 ++++++++++++++++++++++++++++++++++++++--- > kdumpctl.8 | 19 ++- > kexec-tools.spec | 15 ++ > 8 files changed, 421 insertions(+), 289 deletions(-) > > -- > 2.31.1 >