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. - 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 ## 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 skip ahead, collapse, or reorder checklist items.
- Do not begin teardown until every item below is checked complete. - 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. - 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. - [ ] 2. Remove offline hosts in `skidamarink` using MCP offline-host cleanup.
- [ ] 3. Confirm source host is powered on for the inspection phase. - [ ] 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. - [ ] 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. - [ ] 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. - [ ] 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. - [ ] 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. 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 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, 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 generic track returns no usable upgrade candidates, pause and ask the operator whether to continue with alternate Ubuntu kernel tracks. - 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. - 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: 6. Candidate scope rule:
- Include only kernels in the same major OS family as the current machine (no major-version upgrades). - Include only kernels in the same major OS family as the current machine (no major-version upgrades).