How do I free up more space in /boot?

Question

My /boot partition is nearly full and I get a warning every time I reboot my system. I already deleted old kernel packages (linux-headers...), actually I did that to install a newer kernel version that came with the automatic updates.

After installing that new version, the partition is nearly full again. So what else can I delete? Are there some other files associated to the old kernel images?

Here is a list of files that are on my /boot partition:

:~$ ls /boot/
abi-2.6.31-21-generic         lost+found
abi-2.6.32-25-generic         memtest86+.bin
abi-2.6.38-10-generic         memtest86+_multiboot.bin
abi-2.6.38-11-generic         System.map-2.6.31-21-generic
abi-2.6.38-12-generic         System.map-2.6.32-25-generic
abi-2.6.38-8-generic          System.map-2.6.38-10-generic
abi-3.0.0-12-generic          System.map-2.6.38-11-generic
abi-3.0.0-13-generic          System.map-2.6.38-12-generic
abi-3.0.0-14-generic          System.map-2.6.38-8-generic
boot                          System.map-3.0.0-12-generic
config-2.6.31-21-generic      System.map-3.0.0-13-generic
config-2.6.32-25-generic      System.map-3.0.0-14-generic
config-2.6.38-10-generic      vmcoreinfo-2.6.31-21-generic
config-2.6.38-11-generic      vmcoreinfo-2.6.32-25-generic
config-2.6.38-12-generic      vmcoreinfo-2.6.38-10-generic
config-2.6.38-8-generic       vmcoreinfo-2.6.38-11-generic
config-3.0.0-12-generic       vmcoreinfo-2.6.38-12-generic
config-3.0.0-13-generic       vmcoreinfo-2.6.38-8-generic
config-3.0.0-14-generic       vmcoreinfo-3.0.0-12-generic
extlinux                      vmcoreinfo-3.0.0-13-generic
grub                          vmcoreinfo-3.0.0-14-generic
initrd.img-2.6.31-21-generic  vmlinuz-2.6.31-21-generic
initrd.img-2.6.32-25-generic  vmlinuz-2.6.32-25-generic
initrd.img-2.6.38-10-generic  vmlinuz-2.6.38-10-generic
initrd.img-2.6.38-11-generic  vmlinuz-2.6.38-11-generic
initrd.img-2.6.38-12-generic  vmlinuz-2.6.38-12-generic
initrd.img-2.6.38-8-generic   vmlinuz-2.6.38-8-generic
initrd.img-3.0.0-12-generic   vmlinuz-3.0.0-12-generic
initrd.img-3.0.0-13-generic   vmlinuz-3.0.0-13-generic
initrd.img-3.0.0-14-generic   vmlinuz-3.0.0-14-generic

Currently, I'm using the 3.0.0-14-generic kernel.

Solution 1

You've a lot unused kernels. Remove all but the last kernels with:

sudo apt-get purge linux-image-{3.0.0-12,2.6.3{1-21,2-25,8-{1[012],8}}}

This is shorthand for:

sudo apt-get purge linux-image-3.0.0-12 linux-image-2.6.31-21 linux-image-2.6.32-25 linux-image-2.6.38-10 linux-image-2.6.38-11 linux-image-2.6.38-12 linux-image-2.6.38-8

Removing the linux-image-x.x.x-x package will also remove linux-image-x.x.x-x-generic.

The headers are installed into /usr/src and are used when building out-tree kernel modules (like the proprietary nvidia driver and virtualbox). Most users should remove these header packages if the matching kernel package (linux-image-*) is not installed.

To list all installed kernels, run:

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

One command to show all kernels and headers that can be removed, excluding the current running kernel:

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

It selects all packages named starting with linux-headers-<some number> or linux-image-<some number>, prints the package names for installed packages and then excludes the current loaded/running kernel (not necessarily the latest kernel!). This fits in the recommendation of testing a newer kernel before removing older, known-to-work kernels.

So, after upgrading kernels and rebooting to test it, you can remove all other kernels with:

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

Solution 2

Your boot partition is full. Since this is a kernel update, these files will be copied to the boot partition so you need to clean in out. Here is a blog post that will show you how to clear the old kernel images with one command. I'll give a basic synopsis of the method. Use this command to print out the current version of your kernel:

uname -r

Then use this command to print out all the kernels you have installed that aren't your newest kernel:

dpkg -l linux-{image,headers}-"[0-9]*" | awk '/^ii/{ print $2}' | grep -v -e `uname -r | cut -f1,2 -d"-"` | grep -e '[0-9]'

Make sure your current kernel isn't on that list. Notice how this is the majority of the final command (down below). To uninstall and delete these old kernels you will want to pipe these arguments to:

sudo apt-get -y purge

Now we can do everything we want by combining these last two commands into this unholy mess:

dpkg -l linux-{image,headers}-"[0-9]*" | awk '/^ii/{ print $2}' | grep -v -e `uname -r | cut -f1,2 -d"-"` | grep -e '[0-9]' | xargs sudo apt-get -y purge

And that one command will take care of everything for you. I will confirm that this does work perfectly but never trust anybody on the internet. :) For more info, the blog post gives a very good explanation of what each part of the command does so read through it so you are satisfied that it does what you want it to do.

Solution 3

sudo apt-get autoremove

This command is doing the job automatically.

Solution 4

The Synaptic Package Manager can be used to easily select and remove old kernel images.

If you don't already have Synaptic installed:

sudo apt-get install synaptic

Start the application and select the options shown.

You should be able to highlight all the "linux-" packages with the version "2.6.x" where x is between 31 to 38 according to the files in your /boot folder.

Right-click each of those linux packages and choose the option "Mark for Complete Removal". Finally click the apply button. This will remove all the files and any associated files. Your /boot folder should now be a bit tidier.

Solution 5

Thank you for your detailed post of your problem, this got me going in the right direction. Although it is useful to keep previous kernel files you can remove all of them in one go, check this post:
How to Remove All Unused Linux Kernel Headers, Images and Modules

Done via command line. If you are doing this via remote use something like WINSCP to open a terminal session and just paste it in, works very well.

Here it is copied from article link, I suggest you read the full article:

dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge

View more solutions

Comments

[Admin]

It's worth mentioning that not every Ubuntu installation will have a separate /boot partition - often it will all just be one big partition. This answer applies for those who do have a separate /boot partition. Those using LVM or "full disk" encryption need a separate /boot, otherwise it may be optional.

[Admin]

If anyone else has the same problem as me: after /boot has no space left "apt-get upgrade" will fail when re-generating initrd files for the kernels that are installed or that the update-initramfs script believes are installed by examining the contents of /var/lib/initramfs-tools. In this situation one cannot remove old kernels using apt-get because the fscking /boot partition has no space left on device. One can do this using "dpkg -P" followed by cleaning up the corresponding entry in /boot (to free space) and /var/lib/initramfs-tools (the initrd image will not be generated).

[Admin]

A key point for correct answers is that they tell you to remove the packages containing the older versions of the kernel. Many web pages that address this problem recommend directly removing the files in the /boot partition; that may work for a while, but you may eventually update a package that re-creates files that are missing for the kernel versions that have packages, thereby running you out of space.

[Admin]

help.ubuntu.com/community/RemoveOldKernels

[Admin]

All answers helped me greatly to understand, but the link that @jarno is sharing was what I actually did to solve this

[psusi]

You should either not have a separate /boot partition in the first place, or you should increase its size as 100mb is too small.

[user6722]

Moving /boot to my main partition isn't a solution for me since everything but /boot is encrypted. You couldn't know that from my question, sorry.

[T.J. Crowder]

Fantastic answer. One further piece of info would help: How can you tell (for sure) which of the kernels you're using? Presumably you can't just assume it's the last one... Edit: And it looks like the answer is uname -a. Probably best to ensure you don't have a pending restart-to-install-new-kernel pending (as I did; but I noted the mismatch between uname -a and the "latest" kernel).

[Lekensteyn]

The currently loaded kernel is indeed visible by executing uname -a. (you can extract the kernel version part with uname -r as often combined with sth like sudo apt-get install linux-headers-$(uname -r)). You can check the kernel that will be loaded on the next boot by checking the boot config, typically /boot/grub/grub.cfg.

[freddyb]

If only this answer was more generic with regards to other people's systems. Could you provide a line that automatically removes all but the newest kernel image?

[Lekensteyn]

@freddyb Done. Note that the commands prints/removes kernels other than the loaded/booted one.

[freddyb]

@Lekensteyn For me, the GUI warning that /boot is running full comes mostly after upgrades. So you say this would also remove the latest one, that hasn't been booted yet? :/

[Lekensteyn]

@freddyb That is right. If you want to remove all except for the latest version linux-image-XXX, simply replace $(uname -r | sed -r 's/-[a-z]+//') by linux-image-XXX where XXX is a version like 3.2.0-30

[Rinzwind]

As the name suggests, apt-get AUTOremove is an automated operation where the system takes its "best guess" what you are trying to achieve. It should not be used as a substitute for common sense system administration. The problem with this approach: If you (or an update) removes a package that is part of this dependency list the auto-remove function wants to remove all other packages in the dependency list, leaving you with a system without working desktop (and sometimes even with a completely broken system).

[Rinzwind]

Reference: 1 of many sources for this comment above: linuxquestions.org/questions/debian-26/…

[Michael]

+1 from 12.04 LTS: It worked perfectly. Thank you L!

[TiloBunt]

Thanks, I delete via: sudo dpkg --remove linux-headers-3.5.0-28*

[TiloBunt]

and sudo dpkg --remove linux-image-3.5.0-28* for the image, checked via df -h

[svandragt]

If apt-get purge fails because of unmet dependencies then you can follow the advice at askubuntu.com/questions/171209/…

[allprog]

Very thorough answer and still works... and still needed in 2014. Kinda ridiculous that it's still not automatically done by the GUI tools.

[Patrick Collins]

I just want to note that in my case, in addition to old kernels, this matched linux-libc-dev. I wasn't paying attention, and this purged build-essential along with all of the packages that depended on it, which was about 2 GB worth, and it was somewhat of a pain to fix. Be careful.

[Lekensteyn]

@PatrickCollins Yes, that's why you need to explicitly specify the -image- and -headers part as in linux-{headers,image}-*

[Paul]

@allprog, not everyone is running a GUI. I use Ubuntu for my servers and ssh in to maintain them.

[allprog]

@Paul Thanks for the note but I didn't say everyone should have GUI. But if there is a desktop with a GUI, and it takes care of updating and what not, then I would feel it kinda natural that I am offered with the option to automatically remove unused kernels.

[svandragt]

This is a good solution if the solutions above don't work due to having no space at all on the boot volume, or if you repeatedly have the "out of space" issue. Please read first why it's sometimes required to have a /boot partition though: (help.ubuntu.com/community/DiskSpace)

[psusi]

@svandragt, there basically is no reason left to need a /boot partition these days. About the only one left is if your bios is broken and can't see the whole disk, and any machine made in the last decade doesn't have such a limitation. Other legacy cases such as using raid or LVM are now handled properly by grub2.

[thomasrutter]

This is not a good way to remove packages. While this answer isn't very specific about why removing them the correct way failed, I'm sure if that information was given (in a separate question of course) we'd be able to try and figure out the cause of the problem.

[Frederick Nord]

this also matches linux-libc-dev:amd64

[ConfusedStack]

what will the unintended removal of "linux-libc-dev:amd64" cause?

[dward]

@FrederickNord thanks for the heads up. Fixed this. It would have caused some difficulties compiling c programs.

[byf-ferdy]

Why is this necessary? Why wont Ubuntu remove unused old kernels itself? Wouldn't that be way more comfortable for new users?

[Lekensteyn]

@byf-ferdy The kernel is an essential part of the OS, if the newest version somehow does not fully work with your hardware, then you can still select a different one to boot from. A nice feature would probably be something that removes all automatically installed kernels older than a month (except for the latest two).

[mchid]

if linux-image-generic is installed and new kernels were not installed explicitly, this will remove old kernels. Common sense is to not accept any changes to the system without reading them first. If common sense has been used prior to using this command then there will be no trouble.

[David Cahill]

There's a few reasons for having a separate boot partition. But I'm not sure the benefits are worth the increased complexity setup. 1. OS can benefit from faster boot via ext2. 2. Security can be increased by mounting /boot as RO. (rootkits, etc.), or even remain unmounted at os runtime. 3. grub (1) has (had) some issues with ext4 still. 4. Required for running lvm (grubv1). Though this does not apply to the default ubuntu setup.

[JayCouture.com]

I tried to install Ubuntu tweak and also going to the repository website. It says it is only for 13.10 and before. Do you have an updated version for 15.04?

[Rmano]

@JayCouture.com The version in the site is for 14.04 (the "for 13.10 and before" is a link to older releases). I ignore if there is a version for 14.10 or 15.04 .

[Chinmaya B]

@Rinzwind - This command emptied 250 mb of my disk space by removing old 'linux headers'

[Maykonn]

Best response ever!

[vp_arth]

I believe it was failed, because /boot partition was full. This commands try first to upgrade kernel to recent and crash with No space left on device while generating initrd.img

[iGadget]

@Lekensteyn - this would not be 'a nice feature', but an essential one. The fact that this isn't standard behavior is a bug that's been around for way too long: bugs.launchpad.net/ubuntu/+source/update-manager/+bug/105492‌​7

[mchid]

@Rinzwind Yeah, dist-upgrade is also a problem on debian but not ubuntu. Believe me, I have had that happen on Debian and was left with nothing to work from but not on Ubuntu.

[Mr Purple]

lsblk can be used to determine which partition is what

[rtome]

This did it nicely for me too. Simple and effective.

[Ryan]

I'm on 14.04. I have handled this situation in the past via the command line, but I decided to try this method today... for me, my linux images were located under installed (manual), not installed (local or obsolete)

[Vivek Subramanian]

sudo dpkg --remove is useful for removing unused kernels (source). Running the purge command above when I was critically low on space didn't work for me, but it did work after I removed one kernel manually.

[Hinz]

@Jonathan Leaders: could you please elaborate? It's August 2016 and it still works for me. In which circumstances did it fail for you?

[Lekensteyn]

Right, it still works for me. Maybe there was some other package that failed to install due to running out of space in /boot. Workaround: manually remove the files before running the apt command: rm /boot/vmlinuz-... where ... is an older kernel version that is about to be removed.

[Jonathan]

I am not sure why it didn't work for me, but i ended up using bootnukem and that worked github.com/erichs/bootnukem

[John McGehee]

Oh no. I can't install Synaptic because there is no space on /boot!

[FriendFX]

If you also think this is abug, vote here: bugs.launchpad.net/ubuntu/+source/update-manager/+bug/118369‌​2

[kgrittn]

WARNING, directly removing files can lead to problems, as an update of the linux-firmware package can recreate the initrd.img file for every version it thinks is installed based on package information. See: askubuntu.com/questions/865577/…

[user535733]

autoremove works if used before an out-of-space condition exists. However, once apt runs out of space and aborts (and the user finally notices the problem), it's too late to run autremove or any other apt-based solution. If that's the case for you, try one of the dpkg-based solutions.

[user535733]

Most users suffering from this problem checked the 'whole-disk encryption' option during install. They don't realize that whole-disk encryption requires lvm, and that lvm in 16.10 and earlier requires a separate /boot. These users don't have a realistic option to stop using a separate /boot.

[user535733]

Most sufferers of small separate /boot partitions chose 'whole disk encryption' upon install, which requires LVM. This solution will seems to cause more problems than it solves for those users.

[psusi]

@user535733, actually grub2 can boot directly from a LUKS encrypted partition. The installer however, still defaults to setting up a /boot partition. See launchpad.net/bugs/1062623

[user535733]

@psusi, agreed...and looks like it's implemented in 17.04. If somebody wants to write out simple instructions to eliminate the separate /boot partition for encrypted partitions in 16.10 and earlier, I will surely up-vote it.

[user149408]

@user535733 the usual case (at least the one I keep running into) is that there’s still some space on /boot, just not enough for another kernel package. In those cases the above has worked well. Feel free, though, to add the corresponding dpkg command. As for purge, no, it’s not a kind of ‘force-remove’. What it does, differently from remove, is that it deletes configuration files as well. Since/as long as kernel packages install no config files, remove and purge will do the same for kernel packages.

[user535733]

Added fourth bullet with the corresponding dpkg command.

[muru]

The post you're looking for is askubuntu.com/questions/171209/…

[Jonathan]

Why the downvote?

[Justin Case]

@muru Well, yes... I would suggest that the original poster would need this advice, too. Once /boot is full, these scripted versions which attempt to fix it also fail since, well, /boot is full.

[muru]

Well, there are two similar problems: a) where the system warns that your disk is getting full, but apt-get has enough space to go on, and b), where apt-get fails because the disk is too full. That's the other post.

[Cesar Bielich]

golden answer!!

[Samir Sadek]

After : df -k /boot Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda2 483946 127698 331263 28% /boot

[FlipMcF]

@JohnMcGehee fsck and parted should solve that issue for you.

[Jeff Puckett]

thanks, this is the life-saving final solution when nothing else works.

[A. Bergeron]

It worked very well for me, but make sure to update your system afterward with apt-get update. I think it reinstalls anything that wasn't supposed to be removed.

[Fabien]

I had some packages left which appeared as "rc" (configuration files left) with dpkg -l. I had to run sudo dpkg --purge on those packages. I was not able to run apt-get purge on them.

[naught101]

Along with @Fabien's good advice, it is possible that there are still left-over initrd.img files in /boot after running update-intiramfs. If this is the case, and all of the associated packages have been purged, try checking in /var/lib/initramfs-tools/ for config files matching those kernel versions, and remove them manually, then remove the initrd.img files from /boot, and then re-run update-initram-fs.

[Jesse Glick]

This command started behaving strangely for me recently—offering to install an unsigned image package corresponding to an obsolete kernel. I suspect adding ,modules is necessary.

[iWizard]

that is best and only right way to do it following rules

[wisbucky]

So satisfying to see ll /boot afterwards! /boot went down to 100MB (25%) used.

[Yajo]

Thanks, this served me too. I removed a few old kernels (not the one I was currently using) and then did the apt-get -f install. Also, don't forget later to do apt-get autoremove, to possibly remove other ones unneeded.

[DarkCygnus]

Great answer mate... in my case I also had "image-generic" files but one just has to adapt the regexp :) thank you

[tomi.lee.jones]

The year is 2021, and you still have to do this. Ridiculous.

[axolotl]

Linking to an arbitrary utility without any explanation of what it does and when should one use it ("Use at your own risk but it worked for me"). I would post this as a comment rather than an answer, hence, I imagine, someone downvoted it.

[user]

Currently this is suggested by Ubuntu (when trying to run software updater iirc).

[questionto42standswithUkraine]

removed my error: low disk space on boot volume boot has only 29.4 MB disk space left

[Admin]

command not found in both cases

[Admin]

I followed this and had a small error with the first commands, not the fault of this answer here, but my own fault. I could not boot anymore after this, being stuck at my OEM symbol on the screen when I ran the normal start item of the main menu. Solved this by choosing the right kernel for booting which I knew from the command at the top here. For more on this, see Ubuntu 20.04 black screen after installing, no booting. With that, I could come back here and run also the top commands, which now worked.

[Admin]

The comment above shall not put the answer here in a bad light! It worked in the end, and the mistakes were likely my own fault / a system setup problem on my side. I got it to work again, and I could clean the boot drive from its old kernels with the answer here. Perhaps just by chance, but I had also an error when I updated my system, and now there was just a kernel install left over after restart: 5.4.0-113 (from 5.4.0-100 before). It may be that the errors I had were just a follow-up of the update problems and had nothing to do with the commands here.

[Admin]

@questionto42standswithUkraine you have to install the utility first.