Old Kernels

GTP

Well-Known Member
Reaction score
9,186
Location
Adelaide, Australia
I'm running out of space on my /boot partition. If I can clean it up I'll move it to /root instead.
What's the safest way to remove old/installed/unused kernels?

dpkg --list 'linux-image*' lists about 30 but I'm not sure which are safe to delete.

A web search just recommends installing bikeshed, byobu or others.
I don't want to install bikeshed, bootnukem or other "tweak" software.


It's on a Mint "Sonya" laptop. I can delete them manually I guess but is there a quick and simple command line option that will remove all unused and installed kernels but leave the one in use currently (4.10.0.37)?

man purge-old-kernels has no entries about it either.
 
I'm running out of space on my /boot partition. If I can clean it up I'll move it to /root instead.
What's the safest way to remove old/installed/unused kernels?

dpkg --list 'linux-image*' lists about 30 but I'm not sure which are safe to delete.

A web search just recommends installing bikeshed, byobu or others.
I don't want to install bikeshed, bootnukem or other "tweak" software.


It's on a Mint "Sonya" laptop. I can delete them manually I guess but is there a quick and simple command line option that will remove all unused and installed kernels but leave the one in use currently (4.10.0.37)?

man purge-old-kernels has no entries about it either.

https://mintguide.org/system/622-purge-old-kernels-safe-way-to-remove-old-kernels.html

I just used this on my Mint 18.1 and worked fine.

sudo apt-get install -y bikeshed byobu

sudo purge-old-kernels


purge-old-kernels is part of the byobu package. Need to install the above. Just run those commands in that order.
 
Thanks but as I stated above I wanted to do it without installing extra packages that may cause instability in the system.
I guess the only alternative is to do it manually. :(
 
Thanks but as I stated above I wanted to do it without installing extra packages that may cause instability in the system.
I guess the only alternative is to do it manually. :(
This seems like the Windows version of "well I could use MS Office, but I would rather just use notepad since it came with Windows" or "I could use Fab's, but I would rather do it manually". Why not use a tool if there is one available? You could always uninstall those packages when done as well if you wanted.
 
  • Like
Reactions: NJW
I would just fire up Synaptic and search package names for linux-image, and uninstall whatever you don't want (usually all but the one that's running and the most recent one or two older than it). You may or may not have to manually uninstall the header packages also; don't remember if they'll be autoremovable after the kernel image packages are gone.

Not quite as simple as one shell command to get them all at once, but way faster & easier than uninstalling them one at a time manually.
 
You could have checked your previous post ... o_O

There is an automatic mechanism to remove all-but-one old kernels. It's active in Debian, but not, apparently, in Mint. I'll hunt it out when I have a moment.
 
  • Like
Reactions: GTP
You could have checked your previous post ... o_O

There is an automatic mechanism to remove all-but-one old kernels. It's active in Debian, but not, apparently, in Mint. I'll hunt it out when I have a moment.
My previous post gives command line options to remove one at a time or all unused. I was after a command I could use to remove all but, say, the last three.
I didn't really want to install packages that risked the stability of the system, but it saved time, worked and made the client happy.
 
Automatic removal of kernels depends on their installed flags, which, for simplicity, may be 'automatically installed' or 'manually installed'. Any packages that are automatically installed (usually because they are dependencies of something else) can be removed with apt-get autoremove when they are no longer required – for example, when the dependent package is removed.

Unfortunately – though probably for predictable stability reasons – Mint installs a specific kernel at install time. Updates to the kernel are offered through the Update Manager and if/when they are installed (they are optional, by default), they are flagged as 'manually installed'. The upshot of this is that the automatic removal cannot touch them – both the manual apt-get autoremove command and the automatic kernel removal routine are prevented from touching kernel packages.

There is a meta-package (a package which contains nothing of itself, simply having dependencies of a group of other packages to be installed together) for the 'latest kernel', but this is not installed in a default Mint installation. If you add it manually with apt-get install linux-generic or through synaptic, future kernel updates should be handled automatically, keeping the current in-use image and the one-version-older image available.

This is the default arrangement in Debian, which is why Debian doesn't have the problem of filling up its /boot directory. On the other hand, if Debian breaks, you do get to keep both pieces, though it's not a big chore to recover from a kernel update problem (the previous working version is still bootable).
 
Automatic removal of kernels depends on their installed flags, which, for simplicity, may be 'automatically installed' or 'manually installed'. Any packages that are automatically installed (usually because they are dependencies of something else) can be removed with apt-get autoremove when they are no longer required – for example, when the dependent package is removed.

Unfortunately – though probably for predictable stability reasons – Mint installs a specific kernel at install time. Updates to the kernel are offered through the Update Manager and if/when they are installed (they are optional, by default), they are flagged as 'manually installed'. The upshot of this is that the automatic removal cannot touch them – both the manual apt-get autoremove command and the automatic kernel removal routine are prevented from touching kernel packages.

There is a meta-package (a package which contains nothing of itself, simply having dependencies of a group of other packages to be installed together) for the 'latest kernel', but this is not installed in a default Mint installation. If you add it manually with apt-get install linux-generic or through synaptic, future kernel updates should be handled automatically, keeping the current in-use image and the one-version-older image available.

This is the default arrangement in Debian, which is why Debian doesn't have the problem of filling up its /boot directory. On the other hand, if Debian breaks, you do get to keep both pieces, though it's not a big chore to recover from a kernel update problem (the previous working version is still bootable).
Thanks for that very informative information.
On this system all updates to the kernel are through mintUpdate and just lately they seem to very frequent.
I Always wondered why the autoremove command didn't remove kernel packages, now I know.
I'm wondering if all this can be avoided on future installs by not having a separate /boot partition?
I'll install linux-generic and go from there. :)
 
Been some time since I've run into this problem. But, in the past, I've just booted into safe mode and just manually cleaned up boot.
 
  • Like
Reactions: GTP
I'm wondering if all this can be avoided on future installs by not having a separate /boot partition?
There is no 'best' solution, of course, but I have never found the need to have more than two partitions (/ and /home) on my own machines. Having a separate home makes it trivial to back up by imaging the system and home directory/ies individually, or reinstall or upgrade by reformatting the root partition, though that is much less necessary these days.

For Mint installs for clients, I use the same partition scheme. It's only more recent versions of Mint that expose kernel updates in the Update Manager by default. They used to be below the threshold that the end-user sees there, but not so now, so the bloat of the /boot directory will be a thing in the future. I think I'll be installing the linux-generic package from the start, which should be the end of it.

Kernel updates have always been quite frequent, but historically there was not a great need to apply them. Now that the kernel is much bigger and includes many built-in modules by default, an update may fix something that would previously have only needed a separate package update and module reload. Add to that the greater security scrutiny and suddenly it becomes more important to keep the kernel up to date. Gone are the days when you could reasonably keep the same kernel version for several years (specialised applications aside) and I think Mint will have to deal with this soon.

But, in the past, I've just booted into safe mode and just manually cleaned up boot.
It can be safely done from within a running multi-user environment. You have to override a lot of safeguards to break or remove the running kernel. Of course, changing to a new kernel does require a reboot anyway, for most of us.
 
This partitioning scheme is on a client laptop. I don't partition this way, someone else set it up like that.
I normally only have 2 partitions + swap. On future client installs - rather than follow their partioning scheme - I'll just do it like I would.

So: on say, a 500GB disk I would have a 100GB /root, a 5GB swap and the rest as /home.
I know 100GB for /root is maybe a bit big but people love to download stuff to try out.
Most don't uninstall old packages so they just accumulate.
By the time they start to have issues I can clean it up manually, removing the detritus etc.
I know there are some "diehard's" that say you should keep /var, /boot, /root, /etc and /sbin on separate partitions, but I think it's more trouble than it's actual benefits.
I think, (like you suggested) I will just install the linux-generic package from the start as well, and use my partitioning scheme. (unless, of course, the client wants it their way!)
 
I know 100GB for /root is maybe a bit big but people love to download stuff to try out.
That's an understatement! My main workstation has a 29 GB root partition, of which 21 GB is in use. That includes 11 GB of locally cached packages for LAN distribution (similar to WSUS for Windows).

I normally use what the Mint installer suggests, around 12 GB (? from memory). Also consider not caching installed packages – see this HTG page, for example. I don't know if the Mint Update Manager honours that apt setting though.

Edit: yes, it does. You can also clean the cache manually with apt-get clean.
 
Last edited:
Yes, I run a few cammands together to cleanup the package cache.

sudo apt-get autoclean && sudo apt-get autoremove && sudo apt-get clean

Works fine for me.

Handy tip re disabling caching altogether in Synaptic! ;)
 
Not really, as they do different things.

https://askubuntu.com/questions/316...en-the-options-autoclean-autoremove-and-clean

clean: clean clears out the local repository of retrieved package files. It removes everything but the lock file from /var/cache/apt/archives/ and /var/cache/apt/archives/partial/. When APT is used as a dselect(1) method, clean is run automatically. Those who do not use dselect will likely want to run apt-get clean from time to time to free up disk space.

autoclean: Like clean, autoclean clears out the local repository of retrieved package files. The difference is that it only removes package files that can no longer be downloaded, and are largely useless. This allows a cache to be maintained over a long period without it growing out of control. The configuration option APT::Clean-Installed will prevent installed packages from being erased if it is set to off.

autoremove: is used to remove packages that were automatically installed to satisfy dependencies for some package and that are no more needed.
 
Back
Top