diff --git a/tests/cmc-upgrade-kernel-test.md b/tests/cmc-upgrade-kernel-test.md index 788e182..14c883a 100644 --- a/tests/cmc-upgrade-kernel-test.md +++ b/tests/cmc-upgrade-kernel-test.md @@ -37,6 +37,7 @@ Validate CMC behavior across staged kernel upgrades on a cloned VM, including re - On Red Hat-family systems, verify `kernel-devel-` and `kernel-headers-` availability (or documented distro-equivalent package names where applicable). - The first kernel upgrade attempt must not use the latest kernel in the filtered candidate list; reserve the latest kernel for the final kernel-upgrade stage. - When upgrading kernel versions, also upgrade/install the matching development/header packages for that same version. +- On Red Hat-family systems that use `grubby` (including Oracle Linux), explicitly set the selected kernel as the default before rebooting, then verify `grubby --default-kernel` returns the selected `/boot/vmlinuz-` path. If the default does not match, stop before reboot as blocker-fail. - After each kernel upgrade and reboot, verify running kernel version and installed dev/header package versions all match. - If kernel and dev/header package versions are mismatched at any point, stop immediately as blocker-fail and do not continue with remediation by assumption. - Before any kernel candidate discovery step on any distro, force a fresh package metadata refresh on the live host before evaluating available kernel builds. Use the distro's normal refresh command for the installed package manager (for example `dnf makecache`, `yum makecache`, or `zypper refresh`). For APT-based distros, use a hard APT refresh so stale or empty package-list files are rebuilt: `rm -rf /var/lib/apt/lists/* && apt-get clean && apt-get update`. If the refreshed view differs from a prior result, trust the refreshed live metadata and record that the earlier view was stale. @@ -127,6 +128,7 @@ Validate CMC behavior across staged kernel upgrades on a cloned VM, including re - [ ] 36. Select the first-upgrade target from the filtered candidate list. - [ ] 37. Verify matching dev/header packages are available for the first-upgrade target. - [ ] 38. Install the first-upgrade kernel and matching dev/header packages, then reboot. +- [ ] 38a. On Red Hat-family systems with `grubby` including Oracle Linux, set the first-upgrade kernel as the grubby default and verify `grubby --default-kernel` returns the selected `/boot/vmlinuz-` path before reboot. - [ ] 39. Query vCenter guest-tools again for the live clone IP after reboot. - [ ] 40. SSH to the rebooted clone and verify kernel plus dev/header package versions match the selected first-upgrade version. - [ ] 41. If versions do not match exactly, stop as blocker-fail. @@ -140,6 +142,7 @@ Validate CMC behavior across staged kernel upgrades on a cloned VM, including re - [ ] 49. Select the latest-upgrade target kernel from the filtered candidate list. - [ ] 50. Verify matching dev/header packages are available for the latest-upgrade target. - [ ] 51. Install the latest-upgrade kernel and matching dev/header packages, then reboot. +- [ ] 51a. On Red Hat-family systems with `grubby` including Oracle Linux, set the latest-upgrade kernel as the grubby default and verify `grubby --default-kernel` returns the selected `/boot/vmlinuz-` path before reboot. - [ ] 52. Query vCenter guest-tools again for the live clone IP after reboot. - [ ] 53. SSH to the rebooted clone and verify kernel plus dev/header package versions match the selected latest-upgrade version. - [ ] 54. If versions do not match exactly, stop as blocker-fail. @@ -215,6 +218,7 @@ The `Execution Checklist` above is the authoritative run ledger. Use the procedu 36. Select first-upgrade target from filtered candidate list (same major; same minor preferred), ensuring it is not the latest candidate. 37. Verify matching dev/header packages for the selected first-upgrade target are available. 38. Install selected first-upgrade kernel and matching dev/header packages, then reboot. + - On Red Hat-family systems with `grubby`, run `grubby --set-default /boot/vmlinuz-` and verify `grubby --default-kernel` returns that exact path before rebooting. 39. Query vCenter guest-tools again for the live clone IP after reboot. 40. SSH to the rebooted clone via the live vCenter IP and verify running kernel and installed dev/header package versions match the selected first-upgrade version. 41. If versions do not match exactly, stop as blocker-fail. @@ -230,6 +234,7 @@ The `Execution Checklist` above is the authoritative run ledger. Use the procedu 49. Select latest-upgrade target kernel from the filtered candidate list (same major required; same minor preferred). 50. Verify matching dev/header packages for the selected latest-upgrade target are available. 51. Install selected latest-upgrade kernel and matching dev/header packages, then reboot. + - On Red Hat-family systems with `grubby`, run `grubby --set-default /boot/vmlinuz-` and verify `grubby --default-kernel` returns that exact path before rebooting. 52. Query vCenter guest-tools again for the live clone IP after reboot. 53. SSH to the rebooted clone via the live vCenter IP and verify running kernel and installed dev/header package versions match the selected latest-upgrade version. 54. If versions do not match exactly, stop as blocker-fail.