I have 200 MB assigned for the /boot partition. Whenever I try to update the kernel, I receive an error message that basically states /boot is full.

What can I do to cleanup /boot and remove/backup the older kernels?


Command line method:

First check your kernel version, so you won't delete the in-use kernel image, running:

uname -r

Now run this command for a list of installed kernels:

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

and delete the kernels you don't want/need anymore by running this:

sudo apt-get remove linux-image-VERSION

Replace VERSION with the version of the kernel you want to remove.

When you're done removing the older kernels, you can run this to remove ever packages you won't need anymore:

sudo apt-get autoremove

And finally you can run this to update grub kernel list:

sudo update-grub
  • 34
    sudo dpkg --list 'linux-image*' | grep ^ii makes it a little easier to see just the installed kernels. Also I think the update-grub is harmless but not strictly necessary, that is run automatically when you uninstall a kernel. – Nelson Mar 5 '14 at 16:15
  • 9
    Use sudo dpkg --list 'linux-image*' | grep ^ii | awk '{print $2}' | sort | egrep "[0-9]-generic" | head -n -3 | tr '\n' ' '; echo "" to get the list of package names to be used with sudo apt-get remove. head -n -3 is used to keep 3 most recent kernels left in the system. – Sithsu Nov 16 '14 at 6:31
  • 2
    my simple one liner: apt-get remove `dpkg --list 'linux-image*' |grep ^ii | awk '{print $2}'\ | grep -v \`uname -r\`` – gcb Mar 1 '15 at 20:49
  • 28
    sudo apt-get autoremove should suffice (usually leaving you with the last 3 kernels) – mbx Feb 24 '16 at 16:01
  • 6
    This is a good answer, but I doubt it can work in most (if not all) cases: the issue is that /boot is full, so apt-get will fail with some error code or other. The answer below is a bit "hackier" (I must confess I had to steel myself to issue that rm -rf in /boot) but the only one that is likely to work in this situation. – Marco Massenzio Sep 20 '16 at 6:55

NOTE: this is only if you can't use apt to clean up due to a 100% full /boot

If apt-get isn't functioning because your /boot is at 100%, you'll need to clean out /boot first. This likely has caught a kernel upgrade in a partial install which means apt has pretty much froze up entirely and will keep telling you to run apt-get -f install even though that command keeps failing.

Get the list of kernel images and determine what you can do without. This command will show installed kernels except the currently running one sudo dpkg --list 'linux-image*'|awk '{ if ($1=="ii") print $2}'|grep -v `uname -r`. Note the two newest versions in the list. You don't need to worry about the running one as it isn't listed here. You can check that with uname -r.

Craft a command to delete all files in /boot for kernels that don't matter to you using brace expansion to keep you sane. Remember to exclude the current and two newest kernel images. Example: sudo rm -rf /boot/*-3.2.0-{23,45,49,51,52,53,54,55}-*. You can also use a range with the syntax {80..84}.

sudo apt-get -f install to clean up what's making apt grumpy about a partial install.

If you run into an error that includes a line like "Internal Error: Could not find image (/boot/vmlinuz-3.2.0-56-generic)", then run the command sudo apt-get purge linux-image-3.2.0-56-generic (with your appropriate version).

Finally, sudo apt-get autoremove to clear out the old kernel image packages that have been orphaned by the manual boot clean.

Suggestion, run sudo apt-get update and sudo apt-get upgrade to take care of any upgrades that may have backed up while waiting for you to discover the full /boot partition.

Suggestion2, Review https://help.ubuntu.com/community/AutomaticSecurityUpdates and consider setting Unattended-Upgrade::Remove-Unused-Dependencies to true in /etc/apt/apt.conf.d/50unattended-upgrades. This will be the equivalent of running autoremove after each security updates to be sure you clean out unused kernels but will also remove other things it thinks are unused saving you from this problem in the future.

  • 3
    This way I have the latest for the next reboot and then the one before just in case something breaks in that one. Usually I have plenty of room so it doesn't hurt to have a few and it satisfies my paranoia for not having enough backup options in any given scenario. – flickerfly Apr 22 '14 at 6:32
  • 1
    I have never had a problem caused by unattended upgrades. I can imagine scenarios where this could be an issue mostly around dependencies being lost on non-deb packaged installs Say you install php, decide to uninstall it and install a newer version from source. This version has dependencies provided by the previous install, but apt is unaware that it is still required. Next time you run auto-remove those dependencies will be gone. If automated, this could be a bit confusing. If you don't install outside the repositories I believe it to be totally safe. – flickerfly Apr 15 '15 at 13:08
  • 3
    After seeing this in several vsphere virtual servers (where kernels were being automatically upgraded but not removed afterward), I wrote a python script to automate it. I'd love to have more eyes on it – EvanK Sep 29 '15 at 23:39
  • 2
    If you use dpkg --purge on a full boot you'll get the following $ sudo dpkg --purge linux-image-3.13.0-65-generic dpkg: dependency problems prevent removal of linux-image-3.13.0-65-generic: linux-image-extra-3.13.0-65-generic depends on linux-image-3.13.0-65-generic. dpkg: error processing package linux-image-3.13.0-65-generic (--purge): dependency problems - not removing Errors were encountered while processing: linux-image-3.13.0-65-generic – flickerfly Feb 12 '16 at 22:58
  • 1
    After cleaning up /boot apt-get install -f still wouldn't work. Using df -i I found out that I was also running out of inodes on / because of the huge amount of files for the source code of older kernels in /usr/src – Kristofer May 25 '16 at 9:37

There is documentation about this at https://help.ubuntu.com/community/RemoveOldKernels

In summary: Use

sudo apt-get autoremove --purge
# and/or:
sudo purge-old-kernels

The purge-old-kernels tool can be installed via sudo apt install byobu. Here is the description from its man-page:

This program will remove old kernel and header packages from the system, freeing disk space. It will never remove the currently running kernel. By default, it will keep at least the latest 2 kernels, but the user can override that value using the --keep parameter.

If you want a copy-paste solution, ReSearchIT Eng suggested the following:

sudo apt install -y byobu
sudo purge-old-kernels -y --keep 1
sudo apt-get -y autoremove --purge
  • 3
    In my case apt isn't working due to a pending kernel and the suggested fix is a catch-22: – James Bowery Oct 21 '16 at 4:26
  • I had to fix broken packages first with askubuntu.com/a/304388/284313 After that your solution worked. – James Bowery Oct 21 '16 at 4:42
  • 3
    I think this should be the accepted solution as of now. – Fran Marzoa Aug 5 '17 at 0:33
  • 3
    this is much safer than the accepted answer. i think apt-get autoremove --purge should be sufficient, though. – Woodrow Barlow Aug 28 '17 at 17:12

I found that it is far easier to abandon the small partition and move /boot to the root. This also prevents any out of space issues in the future.

First move your data from the boot partition to root (run as sudo -s):

cp -a /boot /boot2
umount /boot
rmdir /boot
mv /boot2 /boot

Remove (or comment) the /boot entry in /etc/fstab:

vim /etc/fstab

Update grub and make sure everything is correct:


apt should now be able to upgrade without problems.

This leaves an unused 200mb partition (which you could use for something else if you find it worth the trouble).

  • 5
    This is a good idea, but doesn't work if you want to have full-disk encryption for your root partition. – Paŭlo Ebermann Nov 9 '17 at 12:41
  • Yes there are cases where /boot should be a separate partition. Another example was that Grub was previously unable to load from an LVM partition. – Bastion Aug 15 '19 at 3:50

Removing old Kernels (to free space on /boot) see: http://askubuntu.com/questions/89710/how-do-i-free-up-more-space-in-boot

sudo apt-get purge $(dpkg -l linux-{image,headers}-"[0-9]*" | awk '/ii/{print $2}' | grep -ve "$(uname -r | sed -r 's/-[a-z]+//')")

Then run

sudo apt-get update
  • 1
    this was the only one that worked....great solution – John Oct 20 '17 at 10:29
  • Best answer! This is the only solution that worked for me; autoremove is stupid; it tries to reinstall any kernels with unmet dependencies before it officially removes them. I was going in circles running out of space over and over again. This answer is gold. – Lonnie Best Aug 15 '18 at 18:32
  • definitely worthy of an upvote - thank you @Amos – CRTLBREAK Feb 8 '20 at 15:29

sudo apt-get autoremove

This removes all but last 2 kernels. Tested on Ubuntu 16.04 LTS when /boot was at 100% capacity and apt-get upgrade failed it's last kernel upgrade. The kernel autoremove is iterative, so if you've got several kernels, they'll be removed one at a time. So be patient.


Why do it by hand when you can do it with a tool? You know you're going to need it again in 30 seconds, because it takes 30 seconds for them to push a new kernal update these days =P

I recommend using this tool, bootnukem

git clone https://github.com/erichs/bootnukem.git
cd bootnukem
sudo ./install.sh


sudo bootnukem --dry-run

Remove --dry-run once you confirm it looks safe


the short answer is to use my script: ubuntu-kernel-cleanup

Not the answer you're looking for? Browse other questions tagged or ask your own question.