How do I fix "gzip: stdout: No space left on device"?

This error occurs when the /boot partition (or root filesystem) is full during apt updates or kernel installations. The fix involves freeing disk space by removing old kernels and packages that are no longer needed.

What causes "gzip: stdout: No space left on device"?

/boot partition is full with old kernel images Multiple kernel versions installed simultaneously Limited /boot partition size (50-100 MB is too small for modern kernels)

Is the "gzip: stdout: No space left on device" error serious?

Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

How to fix gzip: stdout: No space left on device in APT

Quick fix

Fixes gzip: stdout: No space left on device

df -h

Check disk space on /boot partition
List installed kernels
Remove old kernel images
Run apt-get autoremove to clean up

What this error means

The "gzip: stdout: No space left on device" error appears when `apt-get`, `apt-get upgrade`, or `dpkg --configure` tries to compress and write files (typically kernel initramfs images) but there is no available space on the filesystem. On most Debian/Ubuntu systems, the /boot partition is small (often 100-500 MB) and is used exclusively for kernel images and bootloader files. When you install new kernel versions, the system creates new initramfs images using gzip compression. If the /boot partition is full, gzip cannot write its output and fails with this error. The most common scenario: You have several older kernel versions installed, each taking 20-50 MB of space in /boot. When a new kernel arrives via apt update/upgrade, there's no room for both the new kernel and the old ones.

Typical symptoms

apt-get upgrade fails with 'gzip: stdout: No space left on device'
Error message shows 'E: mkinitramfs failure cpio 141 gzip 1'
System cannot install kernel updates
Running df -h shows /boot at 100% capacity
apt-get autoremove does not work or fails silently
New package installations fail during dependency resolution

Common causes

/boot partition is full with old kernel images
Multiple kernel versions installed simultaneously
Limited /boot partition size (50-100 MB is too small for modern kernels)
Unclean package installation left temporary files
System has not been cleaned up after multiple kernel updates
Inode exhaustion on /boot (rare but possible with many small files)

How to fix "gzip: stdout: No space left on device"

1Check disk space on /boot partition

First, determine how much space is available and what is consuming it:

bash

df -h

Look for the /boot line. If it shows 100% or close to it (e.g., "/dev/sda1 228M 218M 0 100% /boot"), you need to free space immediately.

bash

df -h | grep boot

Also check inode usage:

bash

df -i /boot

If the IUse% is 100%, you have an inode problem rather than disk space.

2List installed kernels

See which kernel versions are currently installed:

bash

dpkg -l 'linux-image-*' | grep '^ii'

This lists all installed kernel images. You'll see output like:

bash

ii  linux-image-5.15.0-76-generic   5.15.0-76.83~20.04.1   amd64
ii  linux-image-5.15.0-78-generic   5.15.0-78.85~20.04.1   amd64
ii  linux-image-5.15.0-84-generic   5.15.0-84.93~20.04.1   amd64

Typically, you only need the currently running kernel and perhaps the previous one. All others are safe to remove.

Find your currently running kernel:

bash

uname -r

3Remove old kernel images

Remove all but the currently running kernel. Replace X.X.X-XX with an old kernel version:

bash

sudo apt-get remove linux-image-5.15.0-76-generic

Or remove multiple old kernels at once:

bash

sudo apt-get remove linux-image-5.15.0-76-generic linux-image-5.15.0-78-generic

After removing each kernel, you should see space freed. Verify with:

bash

df -h | grep boot

Remove kernels until /boot is below 80% capacity.

4Run apt-get autoremove to clean up

Once you've freed enough space, clean up dangling dependencies and old kernel-related packages:

bash

sudo apt-get autoremove

This removes:
- Unused kernel headers
- Unused linux-modules packages
- Other orphaned dependencies

Then clean the package cache:

bash

sudo apt-get clean

Verify /boot space again:

bash

df -h | grep boot

5Complete the interrupted installation

If apt-get upgrade was interrupted, complete the installation:

bash

sudo apt-get -f install

Or finish a stalled dpkg configuration:

bash

sudo dpkg --configure -a

Then retry the upgrade:

bash

sudo apt-get upgrade

6Set up automatic kernel cleanup

Prevent this issue in the future by automatically removing old kernels when new ones arrive.

Option 1: Using apt-get autoremove automatically

Enable Debian's automatic cleanup by editing /etc/apt/apt.conf.d/50unattended-upgrades:

bash

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

Ensure this line is uncommented:

bash

Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

Option 2: Using ubuntu-kernel-purge (Ubuntu only)

bash

sudo apt install ubuntu-kernel-purge

This tool automatically purges old kernel versions while keeping the current and at least one backup kernel.

Option 3: Manual cron job

Create a daily cleanup job:

bash

sudo crontab -e

Add this line:

bash

0 2 * * * apt-get autoremove -y >> /var/log/kernel-cleanup.log 2>&1

This runs autoremove daily at 2 AM.

7Enlarge /boot partition if needed

If you frequently run out of space despite removing kernels, your /boot partition is too small. This is a more advanced fix.

Check current /boot size:

bash

lsblk
# or
fdisk -l | grep boot

Resize the partition (requires downtime and can be risky):

Option A: Merge /boot with root filesystem (recommended for new systems)
- This requires reinstalling or using complex partition tools
- Not recommended unless you're rebuilding the system

Option B: Expand the existing /boot partition
- Requires live USB/boot media
- Use tools like GParted or fdisk
- Extends the partition and filesystem

For new installations: Use a larger /boot partition (500 MB to 1 GB). Most modern installers default to only 100-200 MB.

bash

# View recommended size (modern kernels)
ls -lah /boot/

Sum of all kernel versions typically = 50 MB × (number of kernels). For 3-5 kernels, allocate 500 MB minimum.

Advanced notes

### Understanding /boot Partition Design

The /boot partition exists because:
1. Bootloader (GRUB) needs a known location to find kernels
2. Some systems require /boot to be on the first disk sectors
3. Kernel images are large (30-50 MB each) and compress slowly

Modern kernels are much larger than kernels from 10 years ago. A partition sized for old kernels will quickly fill with new ones.

### Inode Exhaustion

If df -i /boot shows 100% IUse, you have too many small files, not too little space:

bash

# Find what's consuming inodes
find /boot -type f | wc -l

# Check inode size
sudo tune2fs -l /dev/sda1 | grep "Inode size"

Solutions:
- Remove old kernels (most reliable)
- Reformat /boot with larger inode size (destructive)
- Migrate /boot to root filesystem (advanced)

### Debian Bug History

Debian has a known issue (#929424) where update-initramfs stores temporary files in /boot instead of /tmp. This was fixed in later versions. If you're on an old Debian/Ubuntu release, upgrade to get the fix:

bash

sudo apt-get update && sudo apt-get upgrade

### SELinux on CentOS/RHEL

If you're using CentOS or RHEL with SELinux enabled, the issue may also involve security contexts:

bash

# Check if SELinux is the issue
sudo setenforce 0
sudo apt-get -f install  # or equivalent yum command

# If this works, the issue is SELinux, not disk space

### Container/VM Considerations

If running in a container or VM:
- Disk space may be artificially limited
- Check host filesystem: docker exec container_name df -h
- Expand the VM disk if necessary
- In Docker, prune old images/layers: docker system prune

Frequently asked questions

What does "gzip: stdout: No space left on device" mean?: The "gzip: stdout: No space left on device" error appears when apt-get, apt-get upgrade, or dpkg --configure tries to compress and write files (typically kernel initramfs images) but there is no available space on the filesystem. On most Debian/Ubuntu systems, the /boot partition is small (often 100-500 MB) and is used exclusively for kernel images and bootloader files. When you install new kernel versions, the system creates new initramfs images using gzip compression.
How do I fix "gzip: stdout: No space left on device"?: This error occurs when the /boot partition (or root filesystem) is full during apt updates or kernel installations. The fix involves freeing disk space by removing old kernels and packages that are no longer needed.
What causes "gzip: stdout: No space left on device"?: /boot partition is full with old kernel images Multiple kernel versions installed simultaneously Limited /boot partition size (50-100 MB is too small for modern kernels)
Is the "gzip: stdout: No space left on device" error serious?: Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

How to fix gzip: stdout: No space left on device in APT

Quick fix

What this error means

Typical symptoms

Common causes

How to fix "gzip: stdout: No space left on device"

Advanced notes

Frequently asked questions

Related errors

Official resources & further reading