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

Clarify kernel test checklist verification wording

Browse Source
This commit is contained in:
Cirrus Codex
2026-05-19 08:54:43 -04:00
parent eacaaf0ac0
commit ce23fc48c4
1 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -79,7 +79,7 @@ Validate CMC behavior across staged kernel upgrades on a cloned VM, including re
- Do not power off, delete, or otherwise tear down the clone until the final latest-kernel migration/session validation is complete and recorded. The latest-kernel reboot or reinstall is not the end of the test.
## Execution Checklist
- Treat this checklist as the run ledger for the test. Check off each item only after the supporting evidence has been gathered.
- Treat this checklist as the run ledger for the test. Figuratively check off the items in the checklist to ensure we do and confirm each step.
- Do not skip ahead, collapse, or reorder checklist items.
- Do not begin teardown until every item below is checked complete.
- If any checklist item cannot be checked, stop the test and record the blocker.
@@ -88,7 +88,7 @@ Validate CMC behavior across staged kernel upgrades on a cloned VM, including re
- [ ] 2. Remove offline hosts in `skidamarink` using MCP offline-host cleanup.
- [ ] 3. Confirm source host is powered on for the inspection phase.
- [ ] 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 and refresh package metadata first.
- [ ] 5. Build source-host kernel candidate list from all available versions after a fresh package metadata refresh. On Ubuntu, inspect the generic track first, then confirm candidate availability with alternate package listing methods if needed before deciding whether the generic track is usable.
- [ ] 6. Apply the candidate scope rule: same major OS family only, with same minor stream preferred.
- [ ] 7. Verify at least 2 upgrade candidates exist in the filtered candidate list.
- [ ] 8. If fewer than 2 candidates, hard stop and end run before clone creation.
@@ -158,8 +158,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, 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.
- 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.
- 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:
- Include only kernels in the same major OS family as the current machine (no major-version upgrades).