Clean up old kernels

majpooper · Post by **majpooper** » Sun Nov 20, 2016 5:42 pm

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/

Cosmo. · Post by **Cosmo.** » Sun Nov 20, 2016 5:50 pm

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.

Post by **Pierre** » Sun Nov 20, 2016 9:32 pm

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.

ostracized · Post by **ostracized** » Mon Nov 21, 2016 3:18 am

WARNING: use with extreme caution:

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

</warning>

/boot is now free, yay!

ostracized · Post by **ostracized** » Mon Nov 21, 2016 4:23 am

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$";
  };

Website · Post by **Moem** » Mon Nov 21, 2016 5:17 am

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.

ostracized · Post by **ostracized** » Mon Nov 21, 2016 5:22 am

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.

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.

Pjotr · Post by **Pjotr** » Mon Nov 21, 2016 6:28 am

This should work as well (it'll remove all kernels except your current kernel and the two latest old ones):

Code: Select all

sudo apt-get install byobu

Followed by:

Code: Select all

sudo purge-old-kernels

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.

ostracized · Post by **ostracized** » Mon Nov 21, 2016 7:02 am

Pjotr wrote:But in Linux Mint we normally have no need for this, because we have such a fine kernel tool in Update Manager.

Another interesting way to remove individual kernels. But I'm still at a loss on if 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 · Post by **Pjotr** » Mon Nov 21, 2016 8:03 am

Note that you can tell purge-old-kernels the number of old kernels it has to preserve. From its man page:

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)

It might be advisable, in cases of space shortage, to use the parameter --keep 1 or even --keep 0.

ostracized · Post by **ostracized** » Tue Nov 22, 2016 6:41 am

Pjotr wrote:But in Linux Mint we normally have no need for this, because we have such a fine kernel tool in Update Manager.

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

Fred Barclay wrote:Summons please for insight?

Also regarding autoremove, I did a simulated run 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 · Post by **Fred Barclay** » Tue Nov 22, 2016 12:45 pm

ostracized wrote: @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.

It doesn't have mint-meta-codecs-core.

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

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.

ostracized · Post by **ostracized** » Tue Nov 22, 2016 1:03 pm

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.

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.

ostracized · Post by **ostracized** » Tue Nov 29, 2016 11:36 pm

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.

ostracized · Post by **ostracized** » Wed Nov 30, 2016 5:53 pm

It's also worth mentioning here that 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.

scorp123 · Post by **scorp123** » Tue Dec 13, 2016 9:32 am

Pjotr wrote:
Code: Select all
sudo purge-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...

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 }'

This will spit out a list of all installed kernel packages and you can tell the old ones from the new ones by having the lower kernel release number in the name.

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

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

... 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 · Post by **Pjotr** » Tue Dec 13, 2016 9:44 am

scorp123 wrote:
Pjotr wrote:
Code: Select all
sudo purge-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...

The tool 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

scorp123 · Post by **scorp123** » Tue Dec 13, 2016 10:38 am

Pjotr wrote: The tool 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/
...

Wooooot!?

That's ... odd

Uhhhhm, ok then?

ostracized · Post by **ostracized** » Tue Dec 13, 2016 12:54 pm

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.

scorp123 · Post by **scorp123** » Thu Dec 15, 2016 7:55 am

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

Hmmm, doesn't seem to impact /boot. But good catch I'll check /usr/src, looks like there are some leftovers.

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

"df" shows that I have 377 MB free on /boot:

Code: Select all

> df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       464M   59M  377M  14% /boot

Soooo ... let's feed the list above to "apt" and get rid of the whole bunch:

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.

Soooo ... doesn't look like these residual files are taking up any space at all?

Linux Mint Forums

Clean up old kernels

Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels

Re: Clean up old kernels