On Fri, Dec 31, 2021 at 05:23:13PM +0800, Pingfan Liu wrote:
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).
Thanks for reviewing the patch set! For [8/13], I realize there were two bugs about updating /etc/default/grub and they has been fixed in v5.
Reviewed-by: Pingfan Liu piliu@redhat.com
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-found... [2] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1171 [3] https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org/... [4] https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org/...
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