Currently _crashkernel_add can't deal with larger memory ranges like
terabyte. For example, '_crashkernel_add "128G-1T:4G" "0"' actually
returns empty result. This patch allows _crashkernel_add to address
terabyte, petabyte and exabyte memory ranges.
Fixes: 64f2827a ("kdump-lib: Harden _crashkernel_add")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Currently, some tests failed with "The param /boot/boot/vmlinuz-xxx is
incorrect", for example,
[root@fedora kexec-tools]# shellspec spec/kdumpctl_manage_reset_spec.sh
Examples:
1) kdumpctl reset-crashkernel [--kernel] [--fadump] Test the kdump dump mode --kernel=ALL kdumpctl should warn the user that crashkernel has been udpated
When call reset_crashkernel --kernel=ALL
1.1) The error should include Updated crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M for kernel=/boot/vmlinuz-5.15.6-100.fc34.x86_64
expected "The param /boot/boot/vmlinuz-5.15.6-100.fc34.x86_64 is incorrect
The param /boot/boot/vmlinuz-5.15.6-100.fc34.x86_64 is incorrect
kdump: Updated crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M for kernel=/boot/boot/vmlinuz-5.15.6-100.fc34.x86_64. Please reboot the system for the change to take effect.
The param /boot/boot/vmlinuz-5.14.14-200.fc34.x86_64 is incorrect
The param /boot/boot/vmlinuz-5.14.14-200.fc34.x86_64 is incorrect
kdump: Updated crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M for kernel=/boot/boot/vmlinuz-5.14.14-200.fc34.x86_64. Please reboot the system for the change to take effect.
The param /boot/boot/vmlinuz-0-rescue-e986846f63134c7295458cf36300ba5b is incorrect
The param /boot/boot/vmlinuz-0-rescue-e986846f63134c7295458cf36300ba5b is incorrect
kdump: Updated crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M for kernel=/boot/boot/vmlinuz-0-rescue-e986846f63134c7295458cf36300ba5b. Please reboot the system for the change to take effect." to include "Updated crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M for kernel=/boot/vmlinuz-5.15.6-100.fc34.x86_64"
# spec/kdumpctl_reset_crashkernel_spec.sh:69
This happens because when a system has a boot partition, grubby
automatically prefixes a path with "/boot". The current boot loader
entries used for tests already has the prefix "/boot" in the path and
prefixing a path again will cause the above problem.
grubby uses "mountpoint -q /boot" to tell if there is a boot partition.
This patch mocks mountpoint so grubby knows the boot loader entries
are for a system without a boot partition.
Note this patch also avoids another error seen in the setup phase of the
test "The param /boot/vmlinuz-xxx is incorrect". I believe this error is
a bug of "grubby --update-kernel" in testing mode because running the
grubby in normal mode actually works and "grubby --info=/boot/vmlinuz-*"
also works in testing mode,
[root@fedora support]# grubby --no-etc-grub-update --grub2 --bad-image-okay --env=grub_env -b boot_load_entries --args crashkernel=333M --update-kernel=/boot/vmlinuz-5.15.6-100.fc34.x86_64
The param /boot/vmlinuz-5.15.6-100.fc34.x86_64 is incorrect
[root@fedora support]# grubby --no-etc-grub-update --grub2 --bad-image-okay --env=grub_env -b boot_load_entries --info=/boot/vmlinuz-5.15.6-100.fc34.x86_64
index=0
kernel="/boot/boot/vmlinuz-5.15.6-100.fc34.x86_64"
[root@fedora support]]# grubby --args crashkernel=333M --update-kernel=/boot/vmlinuz-6.0.7-301.fc37.x86_64 && echo "succeed"
succeed
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
The test case for parse_config creates a default kdump.conf in the pwd.
This fails when the pwd is read only. Thus move the default kdump.conf
to /tmp just like it is done for the "bad" kdump.conf. This also allows
to reuse the temporary file used for the "bad" case.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
_crashkernel_add currently always assumes the good case, i.e. that the
value of the crashkernel parameter has the correct syntax and that the
delta added is a number. Both doesn't have to be true when the values
are provided by users. Thus add some additional checks.
Furthermore require the delta to have a explicit unit, i.e. no longer
assume that is in megabytes, i.e. 100 -> 100M.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
With multiple kernel variants on the same architecture, e.g. the 4k and
64k kernel on aarch64, we can no longer assume that the crashkernel
value for the currently running kernel will work for all installed
kernels. This also means that we can no longer update the grub config as
we don't know which value to set it to. Thus get the crashkernel value
for each kernel and stop updating the grub config.
While at it merge the _new_fadump and _fadump_val variables and remove
_read_kernel_arg_in_grub_etc_default which has no user.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
_update_kernel_cmdline handles two cmdline parameters at once. This does not
only make the function itself but also its callers more complicated than
necessary. For example in _update_crashkernel the fadump gets "updated" to
the value that has been read from grubby. Thus simplify
_update_kernel_cmdline to only update one parameter at once.
While at it shorten some variable named in the callers.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
After introducing 64k variant kernel on aarch64, an example kernel name
looks like "vmlinuz-5.14.0-316.el9.aarch64+64k". To match the plus
symbol, it demands an escape charater.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
This help function can manipulate the crashkernel cmdline by adding an
number for each item. Also a basic test case for _crashkernel_add() is
provided in this patch.
Credit to Philipp, who contributes the original code.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
The function is pretty broken right now. To start with the -o/--omit
option allows a quoted, space separated list of modules. But using 'set'
breaks quotation and thus only considers the first element in the list.
Furthermore dracut uses getopt internally. This means that it is also
possible to pass the list via --omit=.
Fix the function by making use of getopt for parsing the dracut_args.
While at it also add a test cases to cover the functions.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
prepare_cmdline is totally broken. For example if the remove list ($2)
is empty it removes all white spaces or if a parameter has a quoted
value containing a white space it only removes the first part of the
parameter up to the first space. Thus add a test case that shows what the
function should do in order to fix it in subsequent patches.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Now, kdump.conf is generated by gen-kdump-conf.sh, hence adapting
check_config to run that script firstly then check the generated file.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
This test prevents the mistake of adding an option to kdump.conf
without changing check_config as is the case with commit 73ced7f
("introduce the auto_reset_crashkernel option to kdump.conf").
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
kdump_get_conf_val allows to retrieves config value defined in
kdump.conf and it also supports sed regex like
"ext[234]\|xfs\|btrfs\|minix\|raw\|nfs\|ssh".
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
This commit adds a relatively thorough test suite for
kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot]
as implemented in commit 140da74 ("rewrite reset_crashkernel to support
fadump and to used by RPM scriptlet").
grubby have a few options to support its own testing,
- --no-etc-grub-update, not update /etc/default/grub
- --bad-image-okay, don't check the validity of the image
- --env, specify custom grub2 environment block file to avoid modifying
the default /boot/grub2/grubenv
- --bls-directory, specify custom BootLoaderSpec config files to avoid
modifying the default /boot/loader/entries
So the grubby called by kdumpctl is mocked as
@grubby --grub2 --no-etc-grub-update --bad-image-okay --env=$SPEC_TEST_DIR/env_temp -b $SPEC_TEST_DIR/boot_load_entries "$@"
in the tests. To be able to call the actual grubby in the mock function [1],
ShellSpec provides the following command
$ shellspec --gen-bin @grubby
to generate spec/support/bins/@grubby which is used to call the actual grubby.
kdumpctl has implemented its own version of updating /etc/default/grub
in _update_kernel_cmdline_in_grub_etc_default. To avoiding writing to
/etc/default/grub, this function is mocked as outputting its name and
received arguments similar to python unitest's assert_called_with.
[1] https://github.com/shellspec/shellspec#execute-the-actual-command-within-a-mock-function
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
AfterAll is an example group hook [1] which would be run after the group
tests are executed. Use this hook to clean up the files created by mktemp.
[1] https://github.com/shellspec/shellspec#beforeall-afterall---example-group-hook
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
