## TL;DR
No space left during apt work is about the filesystem holding var: old kernel images in boot, the apt archive cache of downloaded .debs, and journal and log growth are the usual tenants. Check both bytes and inodes with df and df -i, clear the apt cache, remove old kernels with apt autoremove, and trim journals.

```text
var lib dpkg no space left on device apt failed
```

## Use this when
- apt upgrade or dpkg configure fails with No space left on device mentioning dpkg or var.
- df shows the root or var filesystem at 100 percent, or df -i shows inodes exhausted.
- The host has been auto-updating kernels for a long time.

## Not for this skill when
- The full filesystem is unrelated to package management (for example a data mount). Free that with its owner, not with apt cleanup.
- Space is fine now because a log rotated; find what filled it or it will recur mid-upgrade again.

## Steps
1. Run df -h and df -i and identify the exact filesystem and whether bytes or inodes are exhausted. Verify: the constrained filesystem and resource are named
2. Clear the downloaded package cache with apt clean. Verify: the var cache apt archives folder drops to near zero
3. Remove old kernels and stale dependencies with apt autoremove --purge after confirming the running kernel is not the removal target. Verify: the boot folder holds only the current and one fallback kernel
4. Trim logs: journalctl --vacuum-size to a sane cap and clear any runaway application logs you find by size. Verify: the var log usage is back to normal levels
5. Retry the apt operation that failed, then run dpkg --configure -a if the interruption left packages pending. Verify: the upgrade completes and dpkg audit is clean

## Variant phrasings
### no space left on device apt dpkg var full fix
The main phrasing.
### apt autoremove old kernels boot full ubuntu
The kernel-accumulation phrasing.
### df inodes exhausted apt fails small files
The inode variant phrasing.

Compatibility: Compatibility: Debian and Ubuntu servers and VMs; separate var and boot partitions are the highest-risk layouts.

## Why it happens
Package operations write in several places at once: downloaded .debs in the apt cache, unpacked files across the system, dpkg status backups, and initramfs images per kernel in boot. A layout that was generous at install becomes tight after a year of kernel updates, and apt fails mid-transaction, which is the worst time to discover it. Byte-free but inode-full happens with many small cache or session files and confuses admins who only check df -h.

## Edge cases / pitfalls
- Automate apt clean and kernel autoremove in the image or config management; manual cleanup does not scale.
- If var is a separate small partition, long-term the fix is resizing or re-laying out the disk, not repeated purges.
- A process holding a deleted-but-open log file keeps the space consumed; lsof for deleted files finds the phantom usage.

## Provenance

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