## TL;DR
The dpkg status file is a text database of package stanzas, and a parser that assumes perfect structure dies on the first damaged record: a missing blank line between stanzas, a truncated entry from a killed write, or a non-UTF8 byte in a description. First establish whether dpkg itself reads the file (dpkg -l, dpkg --audit); if dpkg is fine, the agent parser is too strict and should parse stanza by stanza, skipping and reporting a bad record instead of failing the host. If dpkg also fails, restore the status file from the dpkg backups (status-old or the rotated copies in the dpkg backups folder) after taking a copy of the current file.

```text
agent's parser failed on dpkg status file malformed entry
```

## Use this when
- The agent reports a parse error citing the dpkg status file or a specific package stanza.
- Other hosts parse fine; this host had an interrupted or forced package operation in its history.
- Manual inspection shows one stanza with broken formatting among thousands of good ones.

## Not for this skill when
- dpkg itself errors on every operation for this host. That is database recovery, a bigger incident than an agent parser fix.
- The agent is parsing a different file (for example an apt log) and the error merely mentions dpkg. Read the actual failing input.

## Steps
1. Reproduce the parse against a copy of the host status file offline and find the offending stanza and its defect. Verify: the exact malformation (missing separator, truncation, bad bytes) is identified
2. Check dpkg own view with dpkg --audit and a test query for the packages around the bad stanza. Verify: you know whether dpkg tolerates the file or is also broken
3. If dpkg tolerates it, fix the agent parser to be stanza-tolerant: split on stanza boundaries, parse each independently, and collect bad stanzas into a warning list attached to the host record. Verify: the host parses with warnings and no data loss beyond the bad stanza
4. If dpkg is broken too, restore the newest good status backup (status-old or the backups in var backups) after preserving the current file, then run dpkg --configure -a and apt --fix-broken as needed. Verify: dpkg operations succeed and the package list matches expectations
5. Add a parser test with the real malformed stanza as a fixture. Verify: the regression test passes and future malformations degrade to warnings, not host failures

## Variant phrasings
### dpkg status file malformed stanza parser fails agent
The main phrasing.
### restore dpkg status-old backup corrupt package database
The recovery phrasing.
### tolerant stanza parsing skip bad record report warning
The parser-design phrasing.

Compatibility: Compatibility: Debian and Ubuntu hosts; status file under var lib dpkg, backups in the same folder and var backups.

## Why it happens
Text databases fail textually: one bad record in a file of thousands. dpkg own parser has decades of tolerance built in, while a fresh agent parser written against clean samples assumes the file is always well-formed. The gap appears exactly on the hosts with the roughest history, which are also the hosts patching can least afford to skip silently, so the tolerant-parse-with-warnings pattern matters more than parser elegance.

## Edge cases / pitfalls
- Never hand-edit the live status file to fix a stanza without a backup and a dpkg verification pass; a wrong edit can orphan real packages from the database view.
- A malformed stanza caused by filesystem corruption deserves a disk health check, not just a file restore.
- Warnings about skipped stanzas must reach the wave report; a parser that tolerates silently recreates the silent-skip problem.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_k7sekWX3kka29pR0OzcHbA