12:25 a.m.
On Mon, Feb 28, 2022 at 05:26:02PM +0800, Tao Liu wrote:
On Mon, Feb 21, 2022 at 08:57:44PM +0800, Coiby Xu wrote:
> 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-...
>
> Signed-off-by: Coiby Xu <coxu(a)redhat.com>
> ---
> spec/kdumpctl_reset_crashkernel_spec.sh | 216 ++++++++++++++++++
> spec/support/bin/@grubby | 3 +
> ...846f63134c7295458cf36300ba5b-0-rescue.conf | 8 +
> ...58cf36300ba5b-5.14.14-200.fc34.x86_64.conf | 8 +
> ...458cf36300ba5b-5.15.6-100.fc34.x86_64.conf | 8 +
> spec/support/grub_env | 3 +
> 6 files changed, 246 insertions(+)
> create mode 100644 spec/kdumpctl_reset_crashkernel_spec.sh
> create mode 100755 spec/support/bin/@grubby
> create mode 100644
spec/support/boot_load_entries/e986846f63134c7295458cf36300ba5b-0-rescue.conf
> create mode 100644
spec/support/boot_load_entries/e986846f63134c7295458cf36300ba5b-5.14.14-200.fc34.x86_64.conf
> create mode 100644
spec/support/boot_load_entries/e986846f63134c7295458cf36300ba5b-5.15.6-100.fc34.x86_64.conf
> create mode 100644 spec/support/grub_env
>
> diff --git a/spec/kdumpctl_reset_crashkernel_spec.sh
b/spec/kdumpctl_reset_crashkernel_spec.sh
> new file mode 100644
> index 0000000..de6d40a
> --- /dev/null
> +++ b/spec/kdumpctl_reset_crashkernel_spec.sh
> @@ -0,0 +1,216 @@
> +#!/bin/bash
> +Describe 'kdumpctl reset-crashkernel [--kernel] [--fadump]'
> + Include ./kdumpctl
> + kernel1=/boot/vmlinuz-5.15.6-100.fc34.x86_64
> + kernel2=/boot/vmlinuz-5.14.14-200.fc34.x86_64
> + ck=222M
> + KDUMP_SPEC_TEST_RUN_DIR=$(mktemp -d /tmp/spec_test.XXXXXXXXXX)
> +
> + setup() {
> + cp -r spec/support/boot_load_entries $KDUMP_SPEC_TEST_RUN_DIR
> + cp spec/support/grub_env $KDUMP_SPEC_TEST_RUN_DIR/env_temp
> + }
> +
> + cleanup() {
> + rm -rf $KDUMP_SPEC_TEST_RUN_DIR
> + }
> +
> + BeforeAll 'setup'
> + AfterAll 'cleanup'
> +
> + grubby() {
> + # - --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
> + @grubby --no-etc-grub-update --grub2 --bad-image-okay
--env=$KDUMP_SPEC_TEST_RUN_DIR/env_temp -b $KDUMP_SPEC_TEST_RUN_DIR/boot_load_entries
"$@"
> + }
> +
> + Describe "Test the kdump dump mode "
> + kdump_crashkernel=$(get_default_crashkernel kdump)
> + Context "when --kernel not specified"
> + grubby --args crashkernel=$ck --update-kernel ALL
> + Specify 'kdumpctl should warn the user that crashkernel has been
udpated'
> + When call reset_crashkernel
> + The error should include "Updated crashkernel=$kdump_crashkernel"
> + End
> +
> + Specify 'Current running kernel should have crashkernel updated'
> + When call grubby --info $kernel1
> + The line 3 of output should include crashkernel=$kdump_crashkernel
> + End
> +
> + Specify 'Other kernel still use the old crashkernel value'
> + When call grubby --info $kernel2
> + The line 3 of output should include crashkernel=$ck
> + End
> + End
There are a few issues:
1) I encountered the following error for this test:
1.1) Example aborted (exit status: 1)
kdump: kernel 5.14.17-301.fc35.x86_64 doesn't exist
kdump: no running kernel found
The issue is when calling reset_crashkernel, it will call
_find_kernel_path_by_release, then call _grubby_kernel_str=$(grubby
--info ALL | ..., grubby will encounter the permission issue
when run as non-root:
$ grubby --info ALL
grep: /boot/grub2/grubenv: Permission denied
Should it be mocked, instead of actually reading the local
drive for the file?
2) In 1st test, after reset_crashkernel is called, it actually checks the
following:
expected "The param /boot/vmlinuz-5.14.17-301.fc35.x86_64+debug is incorrect
The param /boot/vmlinuz-5.14.17-301.fc35.x86_64+debug is incorrect
The param /boot/vmlinuz-5.14.17-301.fc35.x86_64+debug is incorrect
The param /boot/vmlinuz-5.14.17-301.fc35.x86_64+debug is incorrect
kdump: Updated crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M for
kernel=/boot/vmlinuz-5.14.17-301.fc35.x86_64+debug. Please reboot the system for the
change to take effect.
The param /boot/vmlinuz-5.14.17-301.fc35.x86_64 is incorrect
The param /boot/vmlinuz-5.14.17-301.fc35.x86_64 is incorrect
The param /boot/vmlinuz-5.14.17-301.fc35.x86_64 is incorrect
The param /boot/vmlinuz-5.14.17-301.fc35.x86_64 is incorrect
kdump: Updated crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M for
kernel=/boot/vmlinuz-5.14.17-301.fc35.x86_64. Please reboot the system for the change to
take effect." to include "Updated
crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M"
The /boot/vmlinuz-5.14.17-301* is the kernel of my local drive. The 1st
test will pass, however as the string indicates, will the test actually
make changes to local grub configuration?
3) I didn't quite understand the test.
"grubby --args crashkernel=$ck --update-kernel ALL" will update
boot_load_entries
files with crashkernel=222M, then reset_crashkernel() is called, do you
want to update boot_load_entries files with original crashkernel value?
"grubby --args crashkernel=$ck --update-kernel ALL" is used to reset
the crashkernel values of all kernels to a initial state i.e. crashkernel=$ck.
Then "grubby --info $kernel1" and then "grubby --info $kernel2",
according
to the description, kernel1 is "running kernel", kernel2 is "other
kernel",
is it the case of your machine status? Because I only have
5.14.17-301.fc35.x86_64 kernel on my machine, so kernel1 and kernel2 are
all "other kernel" to me, thus the test fails for me...
Thanks for running the unit-tests to catch these issues! The root cause of
these issues is I haven't faked the current running kernel. In v1, I've
mocked `uname -r` so the current running kernel is faked.
--
Best regards,
Coiby