You click the button to upgrade Ubuntu, wait for the checks to finish, and then the upgrade stops with a frustrating message: not enough free disk space on /boot. Your main drive may have tens of gigabytes free, so the warning feels unfair. The problem is that /boot is often a small separate partition with its own strict limit, and it fills up quietly over months as old kernels pile up inside it.
The good news is that this is one of the most common upgrade problems on Ubuntu, and it is usually fixed in about ten minutes. You do not need to reinstall anything or resize partitions. You just need to clear out old kernel files that Ubuntu no longer uses, then restart the upgrade.
Quick Answer
To fix an Ubuntu upgrade failing with not enough free disk space on /boot, remove old unused kernels with sudo apt autoremove --purge so Ubuntu keeps only the current kernel and one fallback. Check the result with df -h /boot to confirm space is free. Then run the upgrade again, and it should pass the disk space check and continue normally.
Why the /boot Partition Fills Up
Every time Ubuntu installs a kernel update, it places several files for that kernel in /boot: the kernel image itself, an initial ramdisk file that can be quite large, and supporting files. A single kernel can easily use 100 to 300 megabytes there, especially on systems with large initramfs files.
Ubuntu is supposed to remove old kernels automatically, keeping only the newest one or two. In practice, kernels installed manually, kernels marked as manually installed, or interrupted cleanups can leave many old versions behind. If your /boot partition is only 512 megabytes or 1 gigabyte, which is common on older installs and encrypted setups, just three or four leftover kernels can fill it completely.
On some systems /boot is not a separate partition at all, but a folder on the main drive. In that case the error means your main drive really is nearly full, and you need to free general disk space instead. The command df -h shows you which situation you are in: look for a separate line mounted at /boot.
Step 1: Check How Full /boot Really Is
Open a terminal and run df -h /boot. The output shows the size of the partition, how much is used, and how much is available. If the Use percentage says 100 percent, or the available space is only a few megabytes, you have confirmed the diagnosis.
Next, see what is taking the space by running ls -lh /boot. You will likely see repeating groups of files with different version numbers, such as vmlinuz-6.8.0-41-generic and vmlinuz-6.8.0-45-generic. Each version number is one kernel. The highest number is normally the newest, and the one you are currently running is shown by uname -r. Never remove the kernel that uname -r reports, because that is the one your running system depends on right now.
Step 2: Let Ubuntu Remove Old Kernels Automatically
The safest cleanup is the built-in one, because Ubuntu knows which kernels are safe to remove and which ones to keep.
- Open a terminal.
- Run
sudo apt updateto refresh the package lists. - Run
sudo apt autoremove --purgeand review the list it shows you. - Confirm with
Yif the list contains old kernel packages, which have names likelinux-image-...andlinux-headers-.... - Run
df -h /bootagain to see how much space you recovered.
On a healthy system this single command frees hundreds of megabytes. Ubuntu keeps the kernel you are running plus the newest installed one as a fallback, and removes the rest.
Step 3: If autoremove Removes Nothing
Sometimes autoremove reports that there is nothing to do, yet /boot is still full. This usually means the old kernels are marked as manually installed, so the automatic tool leaves them alone, or a failed past removal left stray files behind.
First, list the kernel packages Ubuntu knows about with dpkg --list | grep linux-image. Compare the versions with the output of uname -r. Every version except the running one and the newest one is a candidate for removal. You can remove a specific old kernel with sudo apt purge linux-image-VERSION-generic linux-headers-VERSION-generic, replacing VERSION with the exact version string. Work through the old versions one or two at a time, and check df -h /boot as you go.
If you have an encrypted system, there may also be a small EFI partition to consider, but do not delete files from it by hand. Stick to removing kernel packages through apt, which updates all the related boot files correctly. For stubborn cases where manual file cleanup is genuinely needed, our separate guide on cleaning old kernels manually when the boot partition is full walks through the careful last-resort steps.
Step 4: Free Extra Space If /boot Shares the Main Drive
If df -h showed no separate /boot partition, the folder shares space with your whole system, so general cleanup is the fix. These quick wins usually free more than enough:
- Empty the Trash and clear old downloads you no longer need.
- Run
sudo apt cleanto clear the local cache of downloaded package files. - Remove old snap revisions with the guidance in Ubuntu documentation, since disabled snap versions can quietly use gigabytes.
- Check your largest folders with the Disk Usage Analyzer application and deal with anything unexpectedly huge, such as old virtual machine images.
The official Ubuntu guide to recovering lost disk space gives more detail on each of these cleanup options if you need to dig deeper.
Step 5: Restart the Upgrade
Once df -h /boot shows comfortable free space, close the terminal and start the upgrade again in the same way you started it before, either through Software Updater or with sudo do-release-upgrade in the terminal. This time the pre-upgrade check should pass. Leave the machine plugged in and connected while the upgrade runs, and avoid starting other heavy work until it finishes and you have restarted.
If the installer still complains despite plenty of free space, restart the computer first so you are running the newest kernel, then run sudo apt autoremove --purge one more time. After a restart, the previously running kernel often becomes removable, which frees another large chunk of space.
How to Stop /boot Filling Up Again
Prevention is simple once you know the cause. Let Ubuntu manage kernels by avoiding manual kernel installs unless you truly need them. Run sudo apt autoremove every month or two as part of normal housekeeping, especially right after a kernel update and a restart. Ubuntu also includes an unattended cleanup setting that removes old kernels automatically, and it is enabled by default on modern releases, so problems usually return only when kernels were installed outside the normal update path.
The Ubuntu community guide to removing old kernels explains the automatic settings and safe manual options if you want the full background.
Common Mistakes
The most dangerous mistake is deleting files from /boot directly with a file manager or with rm as a first step. Package files removed that way leave the package database thinking the kernel is still installed, which creates confusing errors later. Always remove kernels through apt purge or autoremove first, and treat direct file deletion as a last resort only.
Another common mistake is removing the currently running kernel. Always run uname -r and keep that exact version untouched. Also keep the newest installed kernel, even if you are not running it yet, because it is your fallback if the next restart has a problem.
People also often try to resize the /boot partition to make the problem go away permanently. Resizing boot partitions is risky, can break the bootloader, and is unnecessary for almost everyone. Cleaning old kernels solves the real issue in minutes with none of that risk.
Finally, do not ignore the warning and force the upgrade to continue. An upgrade that runs out of space halfway through writing a new kernel can leave the system unable to boot, which is far harder to fix than the original cleanup.
Conclusion
The not enough free disk space on /boot error looks alarming, but it almost always means one simple thing: too many old kernels are sitting in a small partition. Check the space with df -h /boot, clear the backlog with sudo apt autoremove --purge, remove specific old versions by package name if needed, and then start the upgrade again. A quick cleanup now and then will keep the problem from coming back at the next release.
Frequently Asked Questions
How much free space does the Ubuntu upgrade need on /boot?
It varies by release, but the upgrade tool tells you the exact figure in its warning message. As a rough guide, having at least 500 megabytes free on /boot is usually comfortable, since a new kernel and its initramfs need a few hundred megabytes during installation.
Is it safe to remove old kernels?
Yes, as long as you keep the kernel you are currently running, shown by uname -r, and ideally the newest installed one as a fallback. Removing older versions through apt is a normal, supported maintenance task.
Why does autoremove say nothing to remove when /boot is full?
The old kernels may be marked as manually installed, which tells Ubuntu to leave them alone, or leftover files may exist without matching packages. Listing installed kernel packages and purging specific old versions by name usually solves it.
Can I just make the /boot partition bigger?
Technically yes, but it is risky and rarely necessary. Resizing a boot partition can break booting if anything goes wrong. Removing old kernels frees the same space in minutes and is the recommended fix.
Will freeing space on my home folder help this error?
Only if /boot is a folder on your main drive rather than its own partition. Check with df -h /boot. If it lists a separate device, only cleaning the kernels on that partition will help.
Leave a Reply