rpms/kexec-tools
7
0
Fork 0
Code Issues Pull Requests Releases Activity
1,684 Commits 9 Branches 67 Tags 6.6 MiB
4841bc6a6d
Commit Graph

2 Commits

Author SHA1 Message Date
Coiby Xu
8bf11dc3f6 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-10-10 08:40:26 +08:00
Coiby Xu
e00b45d75f 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-04-14 11:45:08 +08:00