A RAUC casync Index Is Not the Complete Update: Qualify Chunk-Store Availability Before Rollout

A reachable casync index bundle does not prove that the device can obtain all image data required for installation. Qualify the combination of index, actual local seed and accessible chunk stores. The decisive negative test withholds a chunk needed by the selected index and absent from every enabled local source.

This guide is pinned to RAUC 1.13’s casync integration, using the casync path rather than assuming identical desync behavior. It proposes deployment and fault fixtures only. No chunk store was changed and no installation was executed. The objective is install-time availability, not a generic progress display or an artifact-deletion policy.

1. Inventory the objects the release actually needs

The 1.13 casync guide describes conversion into a bundle containing index files and a separate chunk-store directory. By default, the store is derived from the bundle location using the .castr extension; configuration can choose another location. Required data may also come from a seed, normally an active slot of the same class.

Create a release dependency record containing the signed index-bundle identity, selected image indices, effective chunk-store configuration, helper implementation and version, target-slot class and qualified seed states. If some images were left conventional during conversion, include their full payload requirements separately.

The record must describe the effective configuration on the device. A deployment manifest saying “chunks uploaded” is insufficient if the service resolves a different store path, uses a different mirror, or runs under credentials that cannot access it.

2. Establish which seed is really usable

In tagged v1.13 update_handler.c, the casync path selects an active same-class slot when available. It can continue without a seed when none is usable; blob seeding excludes character devices in this implementation. The store is passed separately to the extractor, and helper failure is propagated. The desync branch skips this seed-preparation path.

Therefore, record observed seed selection rather than assuming that every A/B product supplies the expected previous image. A recovery boot, changed slot mapping or unavailable seed mount can alter which bytes must be fetched. The same index may need different network data on two devices.

For each supported starting state, identify the chunks obtainable locally and the remaining required set. This is a qualification inventory, not a claim that every chunk needs a network request. If a local source already supplies a chunk, making its remote copy unavailable may have no visible effect.

3. Test chunk access through the real service path

Use a non-sensitive development release and an isolated store. Confirm that the exact helper, service identity, DNS path, proxy and trust configuration can obtain required chunks. A successful bundle inspection or browser download tests only part of that route.

Keep TLS and normal bundle verification enabled. Redact signed access strings and credentials from logs while retaining status classes, object identities and bounded failure reasons. Confirm that any configured additional stores and caches are included in the test inventory, because they can conceal a failing primary store.

The versioned guide also warns that a streaming-enabled RAUC build cannot remotely download a plain casync bundle through that streaming path. Qualify a supported bundle format and target configuration before diagnosing missing chunks. A format rejection and a chunk-store availability failure are different problems.

4. Construct a meaningful missing-chunk fixture

1. Create a small approved test image and its corresponding index through the qualified build process.
2. Select a chunk referenced by the target index and verify that the chosen starting seed does not provide it.
3. Confirm that no enabled cache, additional seed or alternate store provides the same chunk.
4. In a private disposable store fixture, make only that needed chunk unavailable while leaving the index bundle reachable.
5. Run the intended installation path on a recoverable test device and capture the bounded failure result.
6. Restore the fixture’s required data through the test setup and repeat to establish the successful control.

Do not delete or corrupt chunks in a shared or production store to create this test. Preserve the original fixture and user data. The recovery plan must account for installation having started before the missing chunk is encountered; a late data failure does not imply that no target bytes were written.

Use the index and seed inspection facilities of the pinned toolchain to establish absence. A unique filename or a changed source file does not by itself prove that every resulting chunk is unique or missing from the seed.

5. Interpret outcomes by dependency

Controlled condition	Expected interpretation
Index unavailable	Bundle acquisition or validation cannot establish the intended installation input
Index available, needed unseeded chunk unavailable	Installation must report failure rather than success with missing image content
Remote chunk unavailable, same chunk supplied by seed	Success can be legitimate; this does not prove the store is healthy
Seed unavailable, complete store reachable	More data may be fetched; test resource and duration budgets separately
Wrong helper or store configuration	Integration mismatch, not evidence that the index is self-contained
Failure after target writing begins	Preserve actual target/recovery state; do not label it a harmless preflight rejection

Observe final installer status and the product’s recovery behavior, not only HTTP status counts. A helper error must remain visible to the orchestrator. Subsequent retry eligibility depends on the updater’s qualified state, not on the store becoming reachable again.

6. Cover starting states without overpromising

Build a matrix across the supported previous releases, recovery boot modes and seed-availability cases. Include a deliberately weak seed and, where supported, a no-seed case. These tests bound the deployment assumptions more effectively than repeating the newest-to-newest update on a development board.

Record measured bytes and timing only when an actual target run produces them. Do not assume a universal saving from the similarity of release labels. Store availability, seed scanning and destination writes can affect different parts of the operation.

Hypothetical misleading success

A lab gateway updates successfully while one remote chunk is unavailable because its current image supplies that chunk. An older field device lacks the same data and fails even though it can download the identical signed index bundle.

The corrected qualification uses the older seed and a controlled missing-needed-chunk fixture. The release gate then requires evidence for both the bundle and the chunk dependencies of every supported starting-state class. That gives an honest availability claim without confusing a small index file with the complete update.