anthony.wen/cds-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Tighten APT metadata refresh for kernel test

Browse Source
This commit is contained in:
Cirrus Codex
2026-05-19 16:15:09 -04:00
parent 1ad1e7a266
commit 0f16007a97
1 changed files with 5 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
tests/cmc-upgrade-kernel-test.md
View File

@@ -39,7 +39,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.
- 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 `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.
- 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.
## 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.
@@ -174,7 +174,8 @@ The `Execution Checklist` above is the authoritative run ledger. Use the procedu
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`).
- 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, inspect the generic kernel track first after `apt update`, using more than one discovery method before concluding what is available. Use `apt-cache madison`, `apt list -a`, and `apt-cache policy` for `linux-image-generic` and `linux-headers-generic`; if needed, repeat those checks for `linux-generic` and the relevant HWE meta packages.
- On APT-based distros, use `rm -rf /var/lib/apt/lists/* && apt-get clean && apt-get update` instead of a plain `apt update` so stale or empty package-list files are rebuilt before kernel discovery.
- On Ubuntu, inspect the generic kernel track first after the hard APT refresh, using more than one discovery method before concluding what is available. Use `apt-cache madison`, `apt list -a`, and `apt-cache policy` for `linux-image-generic` and `linux-headers-generic`; if needed, repeat those checks for `linux-generic` and the relevant HWE meta packages.
- If the refreshed generic-track view still 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.
6. Candidate scope rule:
@@ -210,7 +211,7 @@ The `Execution Checklist` above is the authoritative run ledger. Use the procedu
32. Create local migration from 10GB source disk to 11GB destination disk using `cirrusdata`.
33. If migration session creation fails (including API/service errors such as 5xx), hard stop as blocker-fail.
34. Wait for initial sync completion.
35. Check available kernels again using full candidate listing (not latest-only output).
35. Check available kernels again using full candidate listing (not latest-only output). Refresh package metadata first; on APT-based distros, use the hard APT refresh command from step 5.
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.
@@ -225,7 +226,7 @@ The `Execution Checklist` above is the authoritative run ledger. Use the procedu
47. Post-uninstall cleanup checkpoint:
- Run MCP host cleanup for `skidamarink`.
- Remove the cloned VM host entry specifically via MCP (target only this test clone host), regardless of whether CDC currently reports it as online or offline.
48. Check available kernels.
48. Check available kernels. Refresh package metadata first; on APT-based distros, use the hard APT refresh command from step 5.
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.