Clean up old kernels
Forum rules
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Clean up old kernels
I have half a dozen old kernels sitting around on my system - my current kernel has been working judt fine for several weeks so I thought I would clean the old ones up by removing them. Yes I can go into the update manager and remive them one by one and most likely do so. But I was wondering if anyone could tell what is going on here when I try and delet them wholesale.
majpooper@1150z ~ $ sudo aptitude purge $OLDCONF
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
E: Could not get lock /var/cache/apt/archives/lock - open (11: Resource temporarily unavailable)
E: Unable to lock directory /var/cache/apt/archives/
majpooper@1150z ~ $ sudo aptitude purge $OLDKERNELS
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
E: Could not get lock /var/cache/apt/archives/lock - open (11: Resource temporarily unavailable)
E: Unable to lock directory /var/cache/apt/archives/
majpooper@1150z ~ $ sudo aptitude purge $OLDCONF
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
E: Could not get lock /var/cache/apt/archives/lock - open (11: Resource temporarily unavailable)
E: Unable to lock directory /var/cache/apt/archives/
majpooper@1150z ~ $ sudo aptitude purge $OLDKERNELS
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
E: Could not get lock /var/cache/apt/archives/lock - open (11: Resource temporarily unavailable)
E: Unable to lock directory /var/cache/apt/archives/
Re: Clean up old kernels
It seems, that another program for the package management (e.g. software manager, synaptic, driver manager) is open. Only one program - inclusive command line tools - can have access to it.
You should really use the update manager for the job. And you should at least keep the original kernel, just in case.
You should really use the update manager for the job. And you should at least keep the original kernel, just in case.
Re: Clean up old kernels
you can use Package Manager AKA synaptic - to highlight / mark them all,
& then click on remove - completely.
that will also free up a large slice of disk space, as well.
& then click on remove - completely.
that will also free up a large slice of disk space, as well.
Please edit your original post title to include [SOLVED] - when your problem is solved!
and DO LOOK at those Unanswered Topics - - you may be able to answer some!.
Re: Clean up old kernels
WARNING: use with extreme caution:
</warning>
/boot is now free, yay!
Code: Select all
dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d;/^linux-\(headers\|image\)/!d' | xargs sudo apt-get -y purge
/boot is now free, yay!
Re: Clean up old kernels
Btw, I'm curious (looking at my own /boot partition) if anyone knows, how often does
apt autoremove
run and looking at the file /etc/apt/apt.conf.d/01autoremove, does this have to do with anything?:
Code: Select all
NeverAutoRemove
{
"^firmware-linux.*";
"^linux-firmware$";
};
Re: Clean up old kernels
So how do you use a command 'with extreme caution'?
I know how to use a command, I know how NOT to use it, but I have no idea how to use it with extreme caution.
I know how to use a command, I know how NOT to use it, but I have no idea how to use it with extreme caution.
If your issue is solved, kindly indicate that by editing the first post in the topic, and adding [SOLVED] to the title. Thanks!
Re: Clean up old kernels
Basically, don't use it unless you'd like to risk the consequences of purging all previous kernels in 1 shot except the current running one as requested by OP (as I'm sure many of you aren't going to take that risk.) I'm currently investigating why autoremove isn't doing this by default in LM18.Moem wrote:So how do you use a command 'with extreme caution'?
I know how to use a command, I know how NOT to use it, but I have no idea how to use it with extreme caution.
- Pjotr
- Level 24
- Posts: 20142
- Joined: Mon Mar 07, 2011 10:18 am
- Location: The Netherlands (Holland) 🇳🇱
- Contact:
Re: Clean up old kernels
This should work as well (it'll remove all kernels except your current kernel and the two latest old ones):
Followed by:
At least it does so in Ubuntu 16.04.
But in Linux Mint we normally have no need for this, because we have such a fine kernel tool in Update Manager.
Code: Select all
sudo apt-get install byobu
Code: Select all
sudo purge-old-kernels
But in Linux Mint we normally have no need for this, because we have such a fine kernel tool in Update Manager.
Tip: 10 things to do after installing Linux Mint 21.3 Virginia
Keep your Linux Mint healthy: Avoid these 10 fatal mistakes
Twitter: twitter.com/easylinuxtips
All in all, horse sense simply makes sense.
Keep your Linux Mint healthy: Avoid these 10 fatal mistakes
Twitter: twitter.com/easylinuxtips
All in all, horse sense simply makes sense.
Re: Clean up old kernels
Another interesting way to remove individual kernels. But I'm still at a loss on ifPjotr wrote:But in Linux Mint we normally have no need for this, because we have such a fine kernel tool in Update Manager.
apt autoremove
is ever scheduled, at least in LM18. It's potentially a problem because an encrypted LVM takes up about half of /boot and when you have no automatic mechanism to clean up these old kernels, you're not going to be able to install in the future unless you manually do some cleaning.There's a mechanism in our infamous
unattended-upgrades
package called Unattended-Upgrade::Remove-Unused-Dependencies
that's supposed to do some cleaning including old kernels, but that's apparently commented out and not a current default configuration for some reason. The current default configuration apparently is Unattended-Upgrade::Remove-New-Unused-Dependencies
and is set to true -- somehow this change didn't get translated into LM18?- Pjotr
- Level 24
- Posts: 20142
- Joined: Mon Mar 07, 2011 10:18 am
- Location: The Netherlands (Holland) 🇳🇱
- Contact:
Re: Clean up old kernels
Note that you can tell purge-old-kernels the number of old kernels it has to preserve. From its man page:
It might be advisable, in cases of space shortage, to use the parameter
Code: Select all
purge-old-kernels(1) byobu purge-old-kernels(1)
NAME
purge-old-kernels - remove old kernel and header packages from the sys‐
tem
SYNOPSIS
purge-old-kernels [--keep N] [*]
DESCRIPTION
This program will remove old kernel and header packages from the sys‐
tem, 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. Any addi‐
tional parameters will be passed directly to apt-get(8).
This program requires administrative access.
EXAMPLE
sudo purge-old-kernels --keep 3 -qy
SEE ALSO
apt-get(8)
--keep 1
or even --keep 0
.Tip: 10 things to do after installing Linux Mint 21.3 Virginia
Keep your Linux Mint healthy: Avoid these 10 fatal mistakes
Twitter: twitter.com/easylinuxtips
All in all, horse sense simply makes sense.
Keep your Linux Mint healthy: Avoid these 10 fatal mistakes
Twitter: twitter.com/easylinuxtips
All in all, horse sense simply makes sense.
Re: Clean up old kernels
You know I'm not sure this method actually purges selected kernels because after clicking "remove", they show up in the residual config in synaptic (where you can then mark them for a "complete removal".)Pjotr wrote:But in Linux Mint we normally have no need for this, because we have such a fine kernel tool in Update Manager.
Also regarding autoremove, I did a simulated runFred Barclay wrote:Summons please for insight?
apt-get -s autoremove
, and found something disturbing: all my vlc packages are marked for auto-removal but I have a theory why: during my removal of some of the apps I never use like xplayer, xplayer-mozilla, banshee, adobe-flashplugin, etc, somewhere along the line my mint-meta-codecs-core
package also got removed, which depends vlc. This is probably why my video thumbnails no longer work as well. As far as apt is concerned, I believe it considers vlc an orphan and marked it auto-removable. Glad I did this (and also glad that unattended-upgrades also fails. )@Fred: I know you're on LMDE and use autoremove frequently...does that version of Mint have
mint-meta-codecs-core
? I'd be interested in also knowing if you have your version of vlc marked as a "manual" install from your custom multimedia repos and autoremove hence leaves these packages alone.I think I'll stick with manually purging kernels for now.
- Fred Barclay
- Level 12
- Posts: 4185
- Joined: Sat Sep 13, 2014 11:12 am
- Location: USA primarily
Re: Clean up old kernels
It doesn't have mint-meta-codecs-core.ostracized wrote: @Fred: I know you're on LMDE and use autoremove frequently...does that version of Mint havemint-meta-codecs-core
? I'd be interested in also knowing if you have your version of vlc marked as a "manual" install from your custom multimedia repos and autoremove hence leaves these packages alone.
Code: Select all
$ dpkg -l | grep codecs
ii firmware-ivtv 0.43 all Binary firmware for iTVC15-family MPEG codecs (ivtv and pvrusb2 drivers)
ii libwscodecs1:amd64 2.2.1+ga6fbd27-1~bpo8+1 amd64 network packet dissection codecs library -- shared library
ii w64codecs:amd64 1:20071007-dmo2 amd64 win64 binary codecs
Re: Clean up old kernels
Hm well it can't be marked as "auto removable" because that qualifies it to be removed after autoremove? "local or obsolete"? Curious to see which category your synaptic places it in. So I guess this does come to a vlc orphan issue for those of us on regular editions. I honestly can't remember when mint-meta-codecs-core was removed...my best guess was when I was annoyed with all the unnecessary firefox plugins so it probably triggered upon removal of xplayer-mozilla.Fred Barclay wrote:VLC (which is installed from the http://www.deb-multimedia.org repo) is also not marked as manually installed. Normally I would use the VLC from Debian Stable's repos but this is a fresh install of LMDE and I haven't had time to switch vlc's source yet.
Re: Clean up old kernels
Well I gotta say autoremove still remains a mystery to me -- especially in Mint. I checked my netbook which has Lubuntu 16.04 -- turns out all the previous kernels (minus the most recent 2) were indeed marked as "auto removable" and no other concerning items were marked as such so I went ahead and did the command and /boot on the machine is now at 24% used versus 80%. (Over a gig in total from other non-related packages were removed as well.) The process did take a few minutes, but I think that was to be expected on a 6 year-old netbook. Rebooted, no problems.
Now obviously I'm not going to be running this command on LM18 as described a few posts up, but what I found interesting is that none of the old kernels in Mint are marked as "auto removable" (unlike in Lubuntu) so running this command would be useless anyway...if the goal was to free up /boot. I suspect that this has to do with Mint's retention of "perpetual kernel installs" and willingness to boot to any arbitrary one at will.
Other than mine (which I honestly don't know will 100% work) and @Pjotr's suggestions, I don't know what the "safe" suggestion would be in Mint. Probably @Pjotr.
Now obviously I'm not going to be running this command on LM18 as described a few posts up, but what I found interesting is that none of the old kernels in Mint are marked as "auto removable" (unlike in Lubuntu) so running this command would be useless anyway...if the goal was to free up /boot. I suspect that this has to do with Mint's retention of "perpetual kernel installs" and willingness to boot to any arbitrary one at will.
Other than mine (which I honestly don't know will 100% work) and @Pjotr's suggestions, I don't know what the "safe" suggestion would be in Mint. Probably @Pjotr.
Re: Clean up old kernels
It's also worth mentioning here that
If we suddenly get a rash of "my /boot partition is full" complaints right about now, we would know the following things are all true (I'm still guessing but suspect this is the case):
1. the user started out with a fresh install of Mint 18 at the end of June (and has been running since then.)
2. the user started out (and still has) an encrypted LVM.
3. the user meticulously updated all available kernels when they were released (including today's
No other changes and we know that since
byobu
is a fully-fledged text-based window manager, almost like openbox even, that comes with it's own modified gnome-terminal and keyboard shortcuts (including the Fn-* ones.) At first I was a bit concerned about this, but I'm assuming here that these shortcuts will not be used outside of a "byobu terminal," with the idea in mind that you're ssh'ing into multiple boxes at once. (And any byobu server would need gnome-terminal
in the first place, which I don't believe is included in any version of Mint.)If we suddenly get a rash of "my /boot partition is full" complaints right about now, we would know the following things are all true (I'm still guessing but suspect this is the case):
1. the user started out with a fresh install of Mint 18 at the end of June (and has been running since then.)
2. the user started out (and still has) an encrypted LVM.
3. the user meticulously updated all available kernels when they were released (including today's
4.4.0-51
update.)No other changes and we know that since
4.4.0-21
, the number of stored kernels since then + an encrypted LVM = ~the size /boot right about now (~512MB.) If so, direct them to this thread and @Ptjor's suggestion.Re: Clean up old kernels
Why the installation of "byobu" ...? Sorry, I didn't quite get that. For the removal of old kernels "byobu" isn't really needed... Sorry if I missed the part where you explained it, maybe I didn't have enough coffees...Pjotr wrote:Code: Select all
sudo purge-old-kernels
What I do -- and I am not saying it's the "best" method, it's just the method I personally prefer -- is this:
Code: Select all
sudo dpkg -l linux* | grep ^ii | awk '{ print $2 }'
Example:
Code: Select all
> sudo dpkg -l linux* | grep ^ii | awk '{ print $2 }'
[sudo] password for sysadm:
linux-base
linux-firmware
linux-generic
linux-headers-4.4.0-53
linux-headers-4.4.0-53-generic
linux-headers-4.4.0-51
linux-headers-4.4.0-51-generic
linux-headers-generic
linux-image-4.4.0-53-generic
linux-image-extra-4.4.0-53-generic
linux-image-4.4.0-51-generic
linux-image-extra-4.4.0-51-generic
linux-image-generic
linux-libc-dev:amd64
linux-sound-base
Code: Select all
sudo apt-get remove linux-headers-4.4.0-51 linux-headers-4.4.0-51-generic linux-image-4.4.0-51-generic linux-image-extra-4.4.0-51-generic
... and that would remove the old kernel 4.4.0-51 packages in this example and free up ca. 300 MB of space. The "advantage" (if I may call it that) is that I can specifically remove the old kernel versions I don't want anymore and select which others I'd like to keep.
I personally prefer doing things this manual way.
- Pjotr
- Level 24
- Posts: 20142
- Joined: Mon Mar 07, 2011 10:18 am
- Location: The Netherlands (Holland) 🇳🇱
- Contact:
Re: Clean up old kernels
The toolscorp123 wrote:Why the installation of "byobu" ...? Sorry, I didn't quite get that. For the removal of old kernels "byobu" isn't really needed... Sorry if I missed the part where you explained it, maybe I didn't have enough coffees...Pjotr wrote:Code: Select all
sudo purge-old-kernels
purge-old-kernels
is part of (dependent on) byobu
. From the author (Dustin Kirkland, Ubuntu core developer):
https://insights.ubuntu.com/2016/06/16/ ... k-space-2/
Key quote:
You’ll already have the purge-old-kernels command in Ubuntu 16.04 LTS (and later), as part of the byobu package. In earlier releases of Ubuntu, you might need to install bikeshed
Tip: 10 things to do after installing Linux Mint 21.3 Virginia
Keep your Linux Mint healthy: Avoid these 10 fatal mistakes
Twitter: twitter.com/easylinuxtips
All in all, horse sense simply makes sense.
Keep your Linux Mint healthy: Avoid these 10 fatal mistakes
Twitter: twitter.com/easylinuxtips
All in all, horse sense simply makes sense.
Re: Clean up old kernels
Wooooot!? That's ... oddPjotr wrote: The toolpurge-old-kernels
is part of (dependent on)byobu
.
From the author (Dustin Kirkland, Ubuntu core developer):
https://insights.ubuntu.com/2016/06/16/ ... k-space-2/
...
Uhhhhm, ok then?
Re: Clean up old kernels
scorp123 wrote: So here I'd issue a command like...Code: Select all
sudo apt-get remove linux-headers-4.4.0-51 linux-headers-4.4.0-51-generic linux-image-4.4.0-51-generic linux-image-extra-4.4.0-51-generic
remove
!= purge
so you may simply end up with these kernels in the residual config section in synaptic (waiting for a "complete removal", aka purge) before free space in /boot is realized. It's worth doing a df -h |grep boot
before and after your command to see if in fact that's the case. I'm not 100% on this and like I said, autoremove did the job in Lubuntu in freeing up space in /boot for the appropriately-marked "auto removable" packages and kernels but Mint does not mark old kernels as such so these extra steps are necessary.Re: Clean up old kernels
Hmmm, doesn't seem to impact /boot. But good catch I'll check /usr/src, looks like there are some leftovers.ostracized wrote:remove
!=purge
so you may simply end up with these kernels in the residual config section in synaptic (waiting for a "complete removal", aka purge) before free space in /boot is realized...
My /boot is on a separate partition (... traditions + old habits ...) and really really small (... traditions ...). It would be full by now. Thankfully it isn't.
EDIT:
OK, yes ... there are leftovers that can be shown via
dpkg -l linux* | grep ^rc
, e.g.Code: Select all
> dpkg -l linux* | grep ^rc | awk '{ print $2 }'
linux-image-4.4.0-21-generic
linux-image-4.4.0-28-generic
linux-image-4.4.0-31-generic
linux-image-4.4.0-34-generic
linux-image-4.4.0-36-generic
linux-image-4.4.0-38-generic
linux-image-4.4.0-42-generic
linux-image-4.4.0-43-generic
linux-image-4.4.0-45-generic
linux-image-4.4.0-47-generic
linux-image-4.4.0-51-generic
linux-image-extra-4.4.0-21-generic
linux-image-extra-4.4.0-28-generic
linux-image-extra-4.4.0-31-generic
linux-image-extra-4.4.0-34-generic
linux-image-extra-4.4.0-36-generic
linux-image-extra-4.4.0-38-generic
linux-image-extra-4.4.0-42-generic
linux-image-extra-4.4.0-43-generic
linux-image-extra-4.4.0-45-generic
linux-image-extra-4.4.0-47-generic
linux-image-extra-4.4.0-51-generic
Code: Select all
> df -h /boot
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 464M 59M 377M 14% /boot
Code: Select all
> sudo apt-get --purge remove `dpkg -l linux* | grep ^rc | awk '{ print $2 }'`
[sudo] password for sysadm:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
linux-image-4.4.0-21-generic* linux-image-4.4.0-28-generic* linux-image-4.4.0-31-generic* linux-image-4.4.0-34-generic*
linux-image-4.4.0-36-generic* linux-image-4.4.0-38-generic* linux-image-4.4.0-42-generic* linux-image-4.4.0-43-generic*
linux-image-4.4.0-45-generic* linux-image-4.4.0-47-generic* linux-image-4.4.0-51-generic* linux-image-extra-4.4.0-21-generic*
linux-image-extra-4.4.0-28-generic* linux-image-extra-4.4.0-31-generic* linux-image-extra-4.4.0-34-generic* linux-image-extra-4.4.0-36-generic*
linux-image-extra-4.4.0-38-generic* linux-image-extra-4.4.0-42-generic* linux-image-extra-4.4.0-43-generic* linux-image-extra-4.4.0-45-generic*
linux-image-extra-4.4.0-47-generic* linux-image-extra-4.4.0-51-generic*
0 upgraded, 0 newly installed, 22 to remove and 8 not upgraded.
After this operation, 0 B of additional disk space will be used.