kexec-tools/spec/kdumpctl_reset_crashkernel_spec.sh

226 lines
7.6 KiB
Bash
Raw Normal View History

unit tests: add tests for "kdumpctl reset-crashkernel" 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>
2022-01-04 07:24:34 +00:00
#!/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)
current_kernel=5.15.6-100.fc34.x86_64
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'
unit tests: fix test failures "The param /boot/boot/vmlinuz-xxx is incorrect" 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>
2023-09-14 07:27:48 +00:00
# the boot loader entries are for a system without a boot partition, mock
# mountpoint to let grubby know it
Mock mountpoint
exit 1
End
unit tests: add tests for "kdumpctl reset-crashkernel" 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>
2022-01-04 07:24:34 +00:00
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
unit tests: fix test failures "The param /boot/boot/vmlinuz-xxx is incorrect" 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>
2023-09-14 07:27:48 +00:00
/usr/sbin/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 "$@"
unit tests: add tests for "kdumpctl reset-crashkernel" 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>
2022-01-04 07:24:34 +00:00
}
# The mocking breaks has_command. Mock it as well to fix the tests.
has_command() {
[[ "$1" == grubby ]]
}
unit tests: add tests for "kdumpctl reset-crashkernel" 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>
2022-01-04 07:24:34 +00:00
Describe "Test the kdump dump mode "
uname() {
if [[ $1 == '-m' ]]; then
echo -n x86_64
elif [[ $1 == '-r' ]]; then
echo -n $current_kernel
fi
}
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"
The line 3 of output should not include crashkernel=$ck
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
Context "--kernel=ALL"
grubby --args crashkernel=$ck --update-kernel ALL
Specify 'kdumpctl should warn the user that crashkernel has been udpated'
When call reset_crashkernel --kernel=ALL
The error should include "Updated crashkernel=$kdump_crashkernel for kernel=$kernel1"
The error should include "Updated crashkernel=$kdump_crashkernel for kernel=$kernel2"
End
Specify 'kernel1 should have crashkernel updated'
When call grubby --info $kernel1
The line 3 of output should include crashkernel="$kdump_crashkernel"
End
Specify 'kernel2 should have crashkernel updated'
When call grubby --info $kernel2
The line 3 of output should include crashkernel="$kdump_crashkernel"
End
End
Context "--kernel=/boot/one-kernel to update one specified kernel"
grubby --args crashkernel=$ck --update-kernel ALL
Specify 'kdumpctl should warn the user that crashkernel has been updated'
When call reset_crashkernel --kernel=$kernel1
The error should include "Updated crashkernel=$kdump_crashkernel for kernel=$kernel1"
End
Specify 'kernel1 should have crashkernel updated'
When call grubby --info $kernel1
The line 3 of output should include crashkernel="$kdump_crashkernel"
End
Specify 'kernel2 should have the old crashkernel'
When call grubby --info $kernel2
The line 3 of output should include crashkernel=$ck
End
End
End
Describe "FADump" fadump
uname() {
if [[ $1 == '-m' ]]; then
echo -n ppc64le
elif [[ $1 == '-r' ]]; then
echo -n $current_kernel
fi
}
kdump_crashkernel=$(get_default_crashkernel kdump)
fadump_crashkernel=$(get_default_crashkernel fadump)
Context "when no --kernel specified"
grubby --args crashkernel=$ck --update-kernel ALL
grubby --remove-args=fadump --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
Context "--kernel=ALL --fadump=on"
grubby --args crashkernel=$ck --update-kernel ALL
Specify 'kdumpctl should warn the user that crashkernel has been udpated'
When call reset_crashkernel --kernel=ALL --fadump=on
The error should include "Updated crashkernel=$fadump_crashkernel for kernel=$kernel1"
The error should include "Updated crashkernel=$fadump_crashkernel for kernel=$kernel2"
End
Specify 'kernel1 should have crashkernel updated'
When call grubby --info $kernel1
The line 3 of output should include crashkernel="$fadump_crashkernel"
End
Specify 'kernel2 should have crashkernel updated'
When call get_grub_kernel_boot_parameter $kernel2 crashkernel
The output should equal "$fadump_crashkernel"
End
End
Context "--kernel=/boot/one-kernel to update one specified kernel"
grubby --args crashkernel=$ck --update-kernel ALL
grubby --args fadump=on --update-kernel $kernel1
Specify 'kdumpctl should warn the user that crashkernel has been updated'
When call reset_crashkernel --kernel=$kernel1
The error should include "Updated crashkernel=$fadump_crashkernel for kernel=$kernel1"
End
Specify 'kernel1 should have crashkernel updated'
When call grubby --info $kernel1
The line 3 of output should include crashkernel="$fadump_crashkernel"
End
Specify 'kernel2 should have the old crashkernel'
When call get_grub_kernel_boot_parameter $kernel2 crashkernel
The output should equal $ck
End
End
Context "Update all kernels but without --fadump specified"
grubby --args crashkernel=$ck --update-kernel ALL
grubby --args fadump=on --update-kernel $kernel1
Specify 'kdumpctl should warn the user that crashkernel has been updated'
When call reset_crashkernel --kernel=$kernel1
The error should include "Updated crashkernel=$fadump_crashkernel for kernel=$kernel1"
End
Specify 'kernel1 should have crashkernel updated'
When call get_grub_kernel_boot_parameter $kernel1 crashkernel
The output should equal "$fadump_crashkernel"
End
Specify 'kernel2 should have the old crashkernel'
When call get_grub_kernel_boot_parameter $kernel2 crashkernel
The output should equal $ck
End
End
Context 'Switch between fadump=on and fadump=nocma'
grubby --args crashkernel=$ck --update-kernel ALL
grubby --args fadump=on --update-kernel ALL
Specify 'fadump=on to fadump=nocma'
When call reset_crashkernel --kernel=ALL --fadump=nocma
The error should include "Updated crashkernel=$fadump_crashkernel for kernel=$kernel1"
The error should include "Updated crashkernel=$fadump_crashkernel for kernel=$kernel2"
End
Specify 'kernel1 should have fadump=nocma in cmdline'
When call get_grub_kernel_boot_parameter $kernel1 fadump
The output should equal nocma
End
Specify 'fadump=nocma to fadump=on'
When call reset_crashkernel --kernel=ALL --fadump=on
The error should include "Updated fadump=on for kernel=$kernel1"
End
Specify 'kernel2 should have fadump=on in cmdline'
When call get_grub_kernel_boot_parameter $kernel1 fadump
The output should equal on
End
End
End
End