[BUG] Standalone kernel packaging reads an unrelated shell authority catalog #59

New issue

Closed

opened 2026-09-17 13:25:30 +02:00 by erikinkinen · 0 comments

erikinkinen commented

2026-09-17 13:25:30 +02:00

Owner

Summary

The isolated native invocation diagnostic cannot reach QEMU in a fresh tool checkout. Image manifest preparation resolves a shell authority catalog from the ordinary component catalog, even though the selected diagnostic contains no shell. The same helper also hardcodes the ordinary catalog for other launch catalogs and a newly built registry.

Reproduction

Use Integration df8147dfa437194cd091747fd7147941bd2793c4 with the coherent isolated lifetime/invocation dependency catalog selecting signed Kernel a2b13de0d51387e9175035f6e191d3f2961cd70e. Start from a fresh tool checkout without ordinary image component checkouts. Build the six selected shared objects and prepare the native invocation kernel, then run scripts/run-native-kernel-vm.sh invocation with explicitly selected signing fixtures and installed build tools.

The first complete attempt fails deterministically at manifest preparation before QEMU starts. The kernel-only profile has no Exsh artifact or Exsh entry in its selected dependency catalog.

Expected and actual behavior

Expected: a kernel-only image uses its explicit diagnostic catalog and supplied registry without requiring authority catalogs for absent executables. Images containing shell or application artifacts must still require their applicable catalogs from the selected source graph.

Actual: exsh authority catalog is missing and exit 1. select_deployment_state_policy none supplies a nonempty shell capacity policy; dynlink_prepare_image_manifests treats that policy as a reason to resolve the shell through ordinary components.toml, independent of actual executable membership. Populating unrelated component directories would conceal the dependency rather than repair it.

Environment and identity

Integration: df8147dfa437194cd091747fd7147941bd2793c4; Kernel: a2b13de0d51387e9175035f6e191d3f2961cd70e; isolated graph: 15 original repository revisions, 16 Cargo manifests.
Target: freestanding x86-64; release kernel with owned-invocation diagnostics and development console; six original shared objects.
Rust 1.97.1 and explicit native assembler, archiver, Python and process owner. The preparation build and artifact metadata checks pass without warnings.
The intended scenario uses one TCG CPU and its unchanged 60-second deadline. No QEMU process or guest session starts, so there is no runtime result or complete boot-image digest.
Last known working standalone run for this newer graph is not established. Existing ordinary-image CI can mask the missing input by cloning its broader catalog first.

Evidence and prior checks

The original failure and cleanup result are retained. Every selected component checkout was clean and matched its exact commit before the attempt. Native kernel preparation completed; the standard runner reused that checked artifact and then refused the unrelated shell catalog.

Repair should carry the caller-selected component catalog into manifest preparation, select launch catalogs only for present executables, and preserve all validation for present artifacts. Add controls with no ordinary checkout, alternate catalogs, absent programs and missing required catalogs. Repeat actual invocation and lifetime diagnostics only after changed source is validated; preserve all original deadlines and assertions.

Caller-local query checkpoint — 17 September 2026: Repair is signed in Integration 75ebaa21e65542d5b553c1264f6e28c48ede0a44. Seven focused controls, all 165 helper commands, strict Rust matrices and both selected native scenarios pass without warnings. Original automatic CI 1647/1648 is still being classified; the first packaging refusal remains retained.

Original Integration regression classification — 17 September 2026: Original runs 1647–1650 are fully classified. Runs 1648, 1649 and 1650 each pass 408 of 486 scenarios and fail the same 78 known shell-layout refusals in issue 57. Run 1647 passes 407 and additionally repeats the existing ext4 quota timeout in issue 18. All twelve complete terminal logs total 52,533,051 bytes and contain no warnings. Rust and Markdown jobs pass. No additional failed scenario is identified; the complete catalogs remain failed. The separate local automatic-KVM preboot observation is tracked in issue 60.

The selected-catalog packaging defect is repaired in signed Integration 75ebaa21e65542d5b553c1264f6e28c48ede0a44; seven focused controls, all helper checks and matching standard-wrapper native images pass. Complete CI classification isolates the remaining failures to the separately tracked baseline. Close issue 59 for this bounded packaging defect only.

Tracking

Owning review: #12. Native diagnostic adoption: #1. Caller-local kernel query design: erix/kernel#1. This issue records a build-input regression, not native query acceptance.

## Summary The isolated native invocation diagnostic cannot reach QEMU in a fresh tool checkout. Image manifest preparation resolves a shell authority catalog from the ordinary component catalog, even though the selected diagnostic contains no shell. The same helper also hardcodes the ordinary catalog for other launch catalogs and a newly built registry. ## Reproduction Use Integration `df8147dfa437194cd091747fd7147941bd2793c4` with the coherent isolated lifetime/invocation dependency catalog selecting signed Kernel `a2b13de0d51387e9175035f6e191d3f2961cd70e`. Start from a fresh tool checkout without ordinary image component checkouts. Build the six selected shared objects and prepare the native invocation kernel, then run `scripts/run-native-kernel-vm.sh invocation` with explicitly selected signing fixtures and installed build tools. The first complete attempt fails deterministically at manifest preparation before QEMU starts. The kernel-only profile has no Exsh artifact or Exsh entry in its selected dependency catalog. ## Expected and actual behavior Expected: a kernel-only image uses its explicit diagnostic catalog and supplied registry without requiring authority catalogs for absent executables. Images containing shell or application artifacts must still require their applicable catalogs from the selected source graph. Actual: `exsh authority catalog is missing` and exit 1. `select_deployment_state_policy none` supplies a nonempty shell capacity policy; `dynlink_prepare_image_manifests` treats that policy as a reason to resolve the shell through ordinary `components.toml`, independent of actual executable membership. Populating unrelated component directories would conceal the dependency rather than repair it. ## Environment and identity - Integration: `df8147dfa437194cd091747fd7147941bd2793c4`; Kernel: `a2b13de0d51387e9175035f6e191d3f2961cd70e`; isolated graph: 15 original repository revisions, 16 Cargo manifests. - Target: freestanding x86-64; release kernel with owned-invocation diagnostics and development console; six original shared objects. - Rust 1.97.1 and explicit native assembler, archiver, Python and process owner. The preparation build and artifact metadata checks pass without warnings. - The intended scenario uses one TCG CPU and its unchanged 60-second deadline. No QEMU process or guest session starts, so there is no runtime result or complete boot-image digest. - Last known working standalone run for this newer graph is not established. Existing ordinary-image CI can mask the missing input by cloning its broader catalog first. ## Evidence and prior checks The original failure and cleanup result are retained. Every selected component checkout was clean and matched its exact commit before the attempt. Native kernel preparation completed; the standard runner reused that checked artifact and then refused the unrelated shell catalog. Repair should carry the caller-selected component catalog into manifest preparation, select launch catalogs only for present executables, and preserve all validation for present artifacts. Add controls with no ordinary checkout, alternate catalogs, absent programs and missing required catalogs. Repeat actual invocation and lifetime diagnostics only after changed source is validated; preserve all original deadlines and assertions. Caller-local query checkpoint — 17 September 2026: Repair is signed in Integration `75ebaa21e65542d5b553c1264f6e28c48ede0a44`. Seven focused controls, all 165 helper commands, strict Rust matrices and both selected native scenarios pass without warnings. Original automatic CI 1647/1648 is still being classified; the first packaging refusal remains retained. Original Integration regression classification — 17 September 2026: Original runs 1647–1650 are fully classified. Runs 1648, 1649 and 1650 each pass 408 of 486 scenarios and fail the same 78 known shell-layout refusals in [issue 57](https://git.erikinkinen.fi/erix/integration/issues/57). Run 1647 passes 407 and additionally repeats the existing ext4 quota timeout in [issue 18](https://git.erikinkinen.fi/erix/integration/issues/18). All twelve complete terminal logs total 52,533,051 bytes and contain no warnings. Rust and Markdown jobs pass. No additional failed scenario is identified; the complete catalogs remain failed. The separate local automatic-KVM preboot observation is tracked in [issue 60](https://git.erikinkinen.fi/erix/integration/issues/60). The selected-catalog packaging defect is repaired in signed Integration `75ebaa21e65542d5b553c1264f6e28c48ede0a44`; seven focused controls, all helper checks and matching standard-wrapper native images pass. Complete CI classification isolates the remaining failures to the separately tracked baseline. Close issue 59 for this bounded packaging defect only. ## Tracking Owning review: https://git.erikinkinen.fi/erix/integration/pulls/12. Native diagnostic adoption: https://git.erikinkinen.fi/erix/integration/issues/1. Caller-local kernel query design: https://git.erikinkinen.fi/erix/kernel/issues/1. This issue records a build-input regression, not native query acceptance.

erikinkinen added the

bug

phase-6

labels

2026-09-17 13:25:30 +02:00

erikinkinen referenced this issue from erix/kernel

2026-09-17 13:34:18 +02:00

[BUG] Query canary fixture assumes identical direct and scheduled entry stacks #16

erikinkinen closed this issue

2026-09-17 17:53:34 +02:00

erikinkinen referenced this issue

2026-09-17 18:12:34 +02:00