Can’t Upgrade Ubuntu? Fix “Low Disk Space on /boot”

Can’t upgrade Ubuntu because /boot is full? Safely remove old kernels with autoremove, fix a broken apt when /boot hit 100%, and prevent it recurring.

Low Disk Space on boot

Last updated: July 2026

Every kernel update leaves the previous kernel installed as a fallback. On systems with a small separate /boot partition (common: 512 MB–1 GB, especially with LVM or full-disk encryption), a few months of updates fill it, and upgrades start failing with “You have low disk space on /boot” or unpacking errors.

First, see what’s going on

df -h /boot                 # how full is it?
uname -r                    # kernel you are RUNNING — never remove this one
dpkg -l 'linux-image*' | grep ^ii

The normal fix: autoremove

sudo apt autoremove --purge

Ubuntu keeps the running kernel plus one previous and removes the rest. Nine times out of ten, done — df -h /boot should drop to comfortable levels.

When apt itself is broken because /boot hit 100%

The nasty variant: an update died mid-install, dpkg is in a broken state, and autoremove refuses to run because… there’s no space. Bootstrap it manually:

# 1. identify your running kernel — PROTECT this version
uname -r          # e.g. 6.8.0-45-generic

# 2. delete the initrd of ONE old kernel (NOT the running one) to free space
sudo rm /boot/initrd.img-6.8.0-38-generic

# 3. let dpkg finish what it started
sudo dpkg --configure -a
sudo apt -f install

# 4. now clean up properly
sudo apt autoremove --purge

Deleting a single old initrd.img-* file is safe as long as it’s not your running kernel — step 4 removes those kernel packages cleanly anyway.

Remove a specific stubborn kernel

sudo apt purge linux-image-6.8.0-38-generic linux-headers-6.8.0-38-generic
sudo update-grub

purge (not just remove) also clears the config files that otherwise linger in /boot.

Prevent it recurring

Unattended-upgrades already runs autoremove for kernels on modern Ubuntu, but on servers I add a monthly cron as a belt-and-braces:

echo '0 3 1 * * root apt-get -y autoremove --purge' | sudo tee /etc/cron.d/kernel-cleanup

(New to cron syntax? See the crontab scheduling guide.) If your /boot is under 512 MB, consider resizing it during the next reinstall — modern kernels plus initrd barely fit three generations in that space.

What not to do: never rm -rf /boot/* or delete vmlinuz files wholesale, and never remove the running kernel — that’s the difference between a full partition and an unbootable machine. 

Comments

comments