Tighten kernel metadata refresh for all distros

This commit is contained in:
Cirrus Codex
2026-05-18 13:55:20 -04:00
parent 95cb9efebc
commit eb41631bbf

View File

@@ -36,6 +36,7 @@ Validate CMC behavior across staged kernel upgrades on a cloned VM, including re
- When upgrading kernel versions, also upgrade/install the matching development/header packages for that same version. - When upgrading kernel versions, also upgrade/install the matching development/header packages for that same version.
- After each kernel upgrade and reboot, verify running kernel version and installed dev/header package versions all match. - 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. - 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 `apt update`, `dnf makecache`, `yum makecache`, or `zypper refresh`). If the refreshed view differs from a prior result, trust the refreshed live metadata and record that the earlier view was stale.
## Red Hat Preflight (Global, Manual Tasks Only) ## Red Hat Preflight (Global, Manual Tasks Only)
- Apply this section only when the test target is an actual Red Hat subscription-managed machine and the run is manually executed. - Apply this section only when the test target is an actual Red Hat subscription-managed machine and the run is manually executed.
@@ -91,6 +92,7 @@ Validate CMC behavior across staged kernel upgrades on a cloned VM, including re
3. Confirm source host is powered on for the inspection phase. If it is powered off, power it on. 3. Confirm source host is powered on for the inspection phase. If it is powered off, power it on.
4. SSH to the source host and check available kernel versions on the source before cloning. 4. SSH to the source host and check available kernel versions on the source before cloning.
5. Build source-host kernel candidate list from all available versions (include intermediate versions, not just the latest from `check-update`). 5. Build source-host kernel candidate list from all available versions (include intermediate versions, not just the latest from `check-update`).
- On package-managed distros, first force a fresh metadata refresh using the package manager's normal refresh command, then use the distro-appropriate tooling to list all available kernel candidates before selecting a target.
- On Ubuntu, prefer the generic kernel track first: use `apt-cache madison` and/or `apt list -a` for `linux-image-generic` and `linux-headers-generic` after `apt update`. - On Ubuntu, prefer the generic kernel track first: use `apt-cache madison` and/or `apt list -a` for `linux-image-generic` and `linux-headers-generic` after `apt update`.
- If the generic track returns no usable upgrade candidates, pause and ask the operator whether to continue with alternate Ubuntu kernel tracks. - If the generic track returns no usable upgrade candidates, pause and ask the operator whether to continue with alternate Ubuntu kernel tracks.
- When prompting for alternate Ubuntu tracks, display the other available kernel candidates, including `linux-image-generic-hwe-24.04` / `linux-headers-generic-hwe-24.04` when present, and wait for explicit operator confirmation before proceeding. - When prompting for alternate Ubuntu tracks, display the other available kernel candidates, including `linux-image-generic-hwe-24.04` / `linux-headers-generic-hwe-24.04` when present, and wait for explicit operator confirmation before proceeding.