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?


8 Answers 8


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
  • 36
    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, 2014 at 16:15
  • 11
    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, 2014 at 6:31
  • 4
    my simple one liner: apt-get remove `dpkg --list 'linux-image*' |grep ^ii | awk '{print $2}'\ | grep -v \`uname -r\``
    – gcb
    Mar 1, 2015 at 20:49
  • 32
    sudo apt-get autoremove should suffice (usually leaving you with the last 3 kernels)
    – mbx
    Feb 24, 2016 at 16:01
  • 10
    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. Sep 20, 2016 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, 2014 at 6:32
  • 2
    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, 2015 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, 2015 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, 2016 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, 2016 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: Oct 21, 2016 at 4:26
  • I had to fix broken packages first with askubuntu.com/a/304388/284313 After that your solution worked. Oct 21, 2016 at 4:42
  • 3
    I think this should be the accepted solution as of now. Aug 5, 2017 at 0:33
  • 3
    this is much safer than the accepted answer. i think apt-get autoremove --purge should be sufficient, though. Aug 28, 2017 at 17:12
  • 2
    Maybe things have changed. I get this error message: E: Command line option --keep is not understood in combination with the other options
    – Houman
    Jan 24, 2023 at 19:38

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
  • 2
    this was the only one that worked....great solution
    – John
    Oct 20, 2017 at 10:29
  • 2
    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. Aug 15, 2018 at 18:32
  • definitely worthy of an upvote - thank you @Amos
    Feb 8, 2020 at 15:29

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).

  • 8
    This is a good idea, but doesn't work if you want to have full-disk encryption for your root partition. Nov 9, 2017 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, 2019 at 3:50

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .