I have run out of space on my boot drive, so I decided to remove old kernels. I found this page which describes exactly what I should do: Lubuntu Documentation: Remove Old Kernels.

I have deleted the oldest kernel manually and now it is okay, but I don’t understand one thing: at the end of the article there is some code that can delete all old kernel versions, but it is marked as for advanced users only.

I don’t really understand what the danger is here. It sounds silly, but they seem to say that there might be more than one kernel used by a specific machine at the same time.

Is it possible that different applications on my Ubuntu machine can use different kernels simultaneously? Why is deleting all old kernels automatically considered to be dangerous?

  • 8
    Actually, the article does not have the words "danger" and "unsafe" in it. How did you get to such a grossly exaggerated conclusion? Apr 10, 2015 at 12:17
  • 2
    A couple times I've upgraded to the latest kernel and removed my old kernel before rebooting, only to find that (on my particular system) the kernel didn't work and the system wouldn't boot. Now I do the reboot first and then remove the old kernel if all is well. Apr 10, 2015 at 15:53

4 Answers 4


Removing old kernels is not inherently unsafe, but if you remove all your kernels and reboot, you'll be left at an angry Grub screen. Fixing that takes significant know-how (like that but with an apt-get install linux-generic at the end).

The first time you do this is quite thrilling but the people looking to clean up their Grub menu or recover some disk space aren't looking for thrills.

The danger comes from users copy-pasting a block of code that —unbeknownst to them and without acknowledging the risks— doesn't apply. There are many examples of detecting old kernels and few are perfect. Even my latest effort still has its pitfalls. And we're talking about an issue that can be fixed; many posts on Ask Ubuntu could lead to permanent data loss if used incorrectly.

We try to safeguard against damage by signposting the risk to make users conscious of potential problems. In the best case scenarios, the user will be prepared and equipped to deal with a problem and in the worst case, at least they can't complain that they weren't warned.

  • 11
    Don't remove all of your kernels (obviously) but also don't remove the currently running kernel if you have just installed an updated kernel and have not yet rebooted. Why? If something breaks in the updated kernel, you can always select your previous kernel in Grub and get back to work. Otherwise, you will be stuck with an unbootable system and have to play the "LiveCD game" (not a fun game, BTW). Apr 10, 2015 at 21:40
  • 1
    That's almost as fun as dd if=/dev/zero of=/dev/sda bs=512 count=1. I don't remember what I was trying do to (something about multiple boot managers making my life annoying). I spent about seven hours with a LiveCD trying to repair my partition tables.
    – phyrfox
    Apr 10, 2015 at 23:29
  • 1
    Its just that easy, keep (at least) one kernel that is tested and definitely working. Someone - @NathanOsman - had to actually put it into words I guess. Second important lesson learned here, don't do things you don't know the consequences off. Apr 11, 2015 at 17:04
  • 1
    I wouldn't use the word "thrilling," but the feeling was an intense one when I did it.
    – MDeBusk
    Apr 14, 2015 at 1:29
  • Having fixed kernel issues in the past, I'm much happier to leave three kernels. I generally go with the currently running kernel, the newest kernel and the one right before the current one. This gives me the latest on reboot, the one known to work and the previous if that fails for some reason. That is probably overkill, but is CYA approved.
    – flickerfly
    Apr 15, 2015 at 14:23

The old kernels are part of packages. If you just remove /boot/vmlinuz-3.13.0-44-generic you will leave package crumbs all over.

First, find out which kernel you are running. Do NOT delete anything with this value is its name:

$ uname -r  

YMMV. Then, ask dpkg what it knows:

$ dpkg -l linux-*

Some of those packages can be removed, but what else is there? Using one line extracted (on MY system) from the output of the dpkg -l linux-*:

 ii  linux-image-3.13.0-44-generic       3.13.0-44.73           amd64                  Linux kernel image for version 3.13.0 on 64 bit x86 SMP

Now we will see what other packages have -3.13.0-44 in their names:

$ dpkg -l *-3.13.0-44*

Once you do a final check to ensure that the current kernel (uname -r) is NOT on the list of packages, you can start removing them through the package management system of your choice.


The last time I removed my old kernels, I borrowed an old code snippet. Well, this code snippet had required me to reboot after installing the new kernel, so I was left without a kernel. Luckily, I had caught this before rebooting, but as others said, I may have been left with the "angry grub screen".

Long story short, it's simply something that can be easily messed up, resulting in a bricked system that can be hard to recover.


It's not unsafe. Using Linux, you can do exactly what you want if you know the right commands.

In the /boot directory, you can do a simple ls -la to have a long listing as well as to find any hidden files or directories (which are not supposed to be there if there are any!!).

From this information, you can assess the dates and old versions' files. Do not remove all of them, but the oldest files which correspond to same version.

At some point, I was thinking that it might be possible that, if you have compiled your kernel from source, then you will need to tweak a new one. The .config file, which I don't think is the case as per your explanation, will stay there.

So, if it happens that after deleting the old files corresponding to a single version and after rebooting your machine, it might be possible that you encounter a kernel panic.

The simple solution is to boot the machine with a live USB or CD/DVD Linux. chroot into it, and re-build the kernel with tools like dracut.

You must log in to answer this question.

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