pstore Compression and Truncated Crash Logs: Verify the Complete Decode Path

A file in the crash archive can be unreadable for two very different reasons: the reader cannot decode its representation, or the desired messages were never retained. Increasing storage does not diagnose either one. For upstream Linux v6.12, trace the writer, backend marker, recovery kernel, and collected bytes as one compatibility chain. The checks here are a proposed workflow, not a claim that a particular board or upgrade combination has passed testing.

Pin both kernels before interpreting a file

Give each incident two build identities: the kernel that produced the crash and the kernel that booted afterward to expose the record. They can differ during an update or rollback. Keep the deployed configuration for each, the backend name, the reset mechanism, the original filename, and the collection tool’s version. A recovery-kernel version alone cannot establish the writer’s compression behavior.

Make a small incident worksheet with fields for writer build, reader build, record type, original length, compression state, decode result, and completeness result. Leave unknown values explicitly unknown. Otherwise a support script may convert “not examined” into “uncompressed,” and every later interpretation inherits that unsupported assumption.

Use the v6.12 compression contract

Linux v6.12 uses CONFIG_PSTORE_COMPRESS and zlib deflate. Older advice about selecting several pstore crypto compressors does not describe this version’s Kconfig. Check the exact product tree for downstream modifications before applying upstream expectations. Linux v6.12 pstore configuration.

# Read-only checks; unavailable files require saved build evidence
uname -r
cat /proc/cmdline
cat /sys/module/pstore/parameters/compress
dmesg | grep -Ei 'pstore|ramoops|deflate|inflate|compression'

In this version, the compress parameter recognizes deflate and none; unsupported names fall back to deflate with a diagnostic. Only dmesg records use this compression path. The code uses raw deflate, so a gzip command failing is not itself evidence of corrupt storage. v6.12 pstore compression implementation.

A v6.12 recovery kernel using pstore.compress=none also lacks the initialized decompression path; verify reader settings when an old compressed record remains encoded. Inspect configuration and startup evidence together. An enabled build option is a capability, not a guarantee that every record was compressed. Keep the observed runtime state and the record’s own representation separate in your worksheet.

Identify the representation actually collected

Ramoops stores a compressed-versus-plain marker in its dmesg header and passes that state to pstore during recovery. The filesystem appends .enc.z when a record remains marked compressed. Successfully decoded files are therefore different from an untouched physical-memory image, even when both are called “raw logs” by an archive script. ramoops record handling and pstore filename construction.

Name the acquisition layer accurately: retained region dump, pstore-exposed file, or postprocessed text. Preserve the original bytes from that layer and their hash before attempting a conversion. Do not rename a file to remove its suffix merely to make an uploader accept it. Put a friendlier display name in metadata instead.

Separate decode failure from missing content

Use two result fields. Decode status can be plain, decoded, unsupported, malformed, or not attempted. Completeness can be verified against a reference, visibly incomplete, or unknown. A plain file ending on a line boundary can still lack the causal messages; a binary file may be intact but require the appropriate decoder.

For an offline reader, document the expected format and impose limits on input bytes, output bytes, CPU time, and trailing data. Do not repeatedly try unrelated codecs until something printable appears. If the file includes an ECC notice outside the compressed payload, preserve that notice and account for the payload boundary. Treat disagreement between the marker, decoder, and resulting text as a failed case that needs investigation.

Compare missing lines with an independent serial capture or a synthetic numbered reference when available. Ask whether the absent message was emitted before the crash, whether it entered the captured window, and whether later collection transformed it. If no reference exists, report uncertainty instead of calling a successful decompression a full recovery.

Test upgrade and rollback directions independently

Construct a matrix with writer builds as rows and recovery builds as columns. Include the currently deployed version, proposed replacement, and supported rollback version. Exercise a known plain record and a known compressed record for each relevant pair. For older product branches, inspect their actual codec configuration rather than assuming the v6.12 reader supports every historical representation.

Keep a synthetic fixture set in a controlled test repository: short text, long repetitive text, text with less repetition, a deliberately truncated compressed stream, and a valid stream with missing source lines. The last two cases should produce different findings. Test the collector’s bytes as well as the kernel-exposed file, because transport or text conversion can create an additional failure.

These fixtures test software behavior without inducing a production panic. Any real crash test belongs on an isolated development target with an approved recovery procedure. Preserve pre-test records before a reset sequence so that the test does not erase the incident being investigated.

Make the handover machine-readable

• Record writer and reader identities with exact configuration references.
• Retain the acquisition layer, original name, length, and hash.
• Store compression state separately from filename guesses.
• Record decoder version, bounded output, and any error or ECC notice.
• Keep completeness status independent of decoder success.
• Require evidence for every supported upgrade and rollback pair.

The release decision is then concrete: either the complete decode chain is demonstrated for the supported transitions, or the team names the missing compatibility case and its recovery procedure. Compression ratio alone is not an acceptance result, and a readable archive is not automatically a complete account of the crash.