Announcement

**Qqmike** · Jul 10, 2015, 02:17 PM

I believe that's a conclusion I also came to recently (I have to try to find that thread). Strangely, the code that keeps "two most recent" kernels assumes the kernel numbering is sequential (through the positive integers) and assumes no integer is skipped (as in your case, 42 is skipped, but then your system is keeping 43 and 42 and sees 41 as being too old to keep!).

EDIT: I have corrected this stupid conclusion in Posts #3 & #4 below.

**Qqmike** · Jul 10, 2015, 02:28 PM

https://www.kubuntuforums.net/showth...l=1#post374549

You had also posted there. It didn't seem to be sequential integers numbering of kernel versions: it seems to be the most recently INSTALLED kernel versions. See that post in the link.
My experiment:
Say you got the following installed, in sequential time order:
first you installed 53, then 52 then 54 got installed last. So 54 is the most recently installed, 52 is the second most recently installed. It keeps the two most recently installed versions: 54 and 52; it deletes 53! You can also examine that file mentioned in the post, /etc/apt/apt.conf.d/01autoremove-kernels to see what it intends to keep.

**Qqmike** · Jul 10, 2015, 02:32 PM

Right now, mine says it will keep 57 and 55. So nothing to do with sequential integer numbering. It goes by the time they were installed.

/etc/apt/apt.conf.d/01autoremove-kernels

Code:

// DO NOT EDIT! File autogenerated by /etc/kernel/postinst.d/apt-auto-removal
APT::NeverAutoRemove
{
   "^linux-image-3\.13\.0-55-generic$";
   "^linux-image-3\.13\.0-57-generic$";
   "^linux-headers-3\.13\.0-55-generic$";
   "^linux-headers-3\.13\.0-57-generic$";
   "^linux-image-extra-3\.13\.0-55-generic$";
   "^linux-image-extra-3\.13\.0-57-generic$";
   "^linux-signed-image-3\.13\.0-55-generic$";
   "^linux-signed-image-3\.13\.0-57-generic$";
   "^kfreebsd-image-3\.13\.0-55-generic$";
   "^kfreebsd-image-3\.13\.0-57-generic$";
   "^kfreebsd-headers-3\.13\.0-55-generic$";
   "^kfreebsd-headers-3\.13\.0-57-generic$";
   "^gnumach-image-3\.13\.0-55-generic$";
   "^gnumach-image-3\.13\.0-57-generic$";
   "^.*-modules-3\.13\.0-55-generic$";
   "^.*-modules-3\.13\.0-57-generic$";
   "^.*-kernel-3\.13\.0-55-generic$";
   "^.*-kernel-3\.13\.0-57-generic$";
   "^linux-backports-modules-.*-3\.13\.0-55-generic$";
   "^linux-backports-modules-.*-3\.13\.0-57-generic$";
   "^linux-tools-3\.13\.0-55-generic$";
   "^linux-tools-3\.13\.0-57-generic$";
};

**Snowhog** · Jul 10, 2015, 03:28 PM

There is still something a miss however. This is the commentary by the author of the apt-auto-removal script:

# Author: Steve Langasek <steve.langasek@canonical.com>
#
# Mark as not-for-autoremoval those kernel packages that are:
# - the currently booted version
# - the kernel version we've been called for
# - the latest kernel version (determined using rules copied from the grub
# package for deciding which kernel to boot)
# - the second-latest kernel version, if the booted kernel version is
# already the latest and this script is called for that same version,
# to ensure a fallback remains available in the event the newly-installed
# kernel at this ABI fails to boot
# In the common case, this results in exactly two kernels saved, but it can
# result in three kernels being saved. It's better to err on the side of
# saving too many kernels than saving too few.
#
# We generate this list and save it to /etc/apt/apt.conf.d instead of marking
# packages in the database because this runs from a postinst script, and apt
# will overwrite the db when it exits.

But that is not what apt wants to do here, today. IF I were to permit apt to do what it says:

Code:

The following packages will be REMOVED:
  linux-image-3.16.0-41-generic* linux-image-extra-3.16.0-41-generic*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.

I would be left with only one installed kernel. I guess the problem revolves around "# - the second-latest kernel version". The decider logic in /etc/apt/apt.conf.d/01autoremove-kernels must be wrong, else it would not be identifying my "second installed" kernel for removal. My /etc/apt/apt.conf.d/01autoremove-kernels:

Code:

paul@tanagra:~$ cat /etc/apt/apt.conf.d/01autoremove-kernels
// DO NOT EDIT! File autogenerated by /etc/kernel/postinst.d/apt-auto-removal
APT::NeverAutoRemove
{
   "^linux-image-3\.16\.0-39-generic$";
   "^linux-image-3\.16\.0-43-generic$";
   "^linux-headers-3\.16\.0-39-generic$";
   "^linux-headers-3\.16\.0-43-generic$";
   "^linux-image-extra-3\.16\.0-39-generic$";
   "^linux-image-extra-3\.16\.0-43-generic$";
   "^linux-signed-image-3\.16\.0-39-generic$";
   "^linux-signed-image-3\.16\.0-43-generic$";
   "^kfreebsd-image-3\.16\.0-39-generic$";
   "^kfreebsd-image-3\.16\.0-43-generic$";
   "^kfreebsd-headers-3\.16\.0-39-generic$";
   "^kfreebsd-headers-3\.16\.0-43-generic$";
   "^gnumach-image-3\.16\.0-39-generic$";
   "^gnumach-image-3\.16\.0-43-generic$";
   "^.*-modules-3\.16\.0-39-generic$";
   "^.*-modules-3\.16\.0-43-generic$";
   "^.*-kernel-3\.16\.0-39-generic$";
   "^.*-kernel-3\.16\.0-43-generic$";
   "^linux-backports-modules-.*-3\.16\.0-39-generic$";
   "^linux-backports-modules-.*-3\.16\.0-43-generic$";
   "^linux-tools-3\.16\.0-39-generic$";
   "^linux-tools-3\.16\.0-43-generic$";
};
paul@tanagra:~$

**Qqmike** · Jul 10, 2015, 03:40 PM

Yeah, something is amiss. But I think you may have solved the original problem I had when I started that thread I linked to above, when you said this:

IF I were to permit apt to do what it says ... I would be left with only one installed kernel.

THAT was my original problem -- I noticed I had only ONE kernel in my /boot directory! Something subtle--like what you pointed out--happened that I didn't notice until to checked one day to find myself sitting on just one kernel to boot.

You've hit upon a flaw in the system-logic here, that's a "for sure." Being aware of it now, I am just very careful not to upset things.

I also noticed this: let's say you somehow end up with 55 and 52, but you should have 55 and 54. So, like you said somewhere, you install the one that's missing: you manually install 54. Then MY rule applies! If you clean things out, you will likely delete the most recently installed, which would be the 54, leaving you with 55 and the very old one 52.

I tested this, it's not theory. But the factor here is this subtle, logical thing you have figured out. Instead of protecting you with too many kernels, it can also leave you with too few or with a new one and a rather old one.

**Snowhog** · Jul 10, 2015, 03:56 PM

I just emailed the ~~developer~~author of the apt-auto-removal script. Hopefully he will reply with some insight as to what is going on.

**Feathers McGraw** · Jul 10, 2015, 05:38 PM

I see this too. I always thought it was the intended behavior but maybe not having read the comments in that script - I quite often install new kernels (up to 3 total), reboot, and autoremove two leaving just the current one.

**Snowhog** · Jul 12, 2015, 01:31 PM

Received the following reply from the author on Friday:

This output shows that the autoremove-kernels script calculated that two
kernels should be kept: 3.16.0-39, and 3.16.0-43. This implies that you
were running the 3.16.0-39 kernel, installed the 3.16.0-41 kernel as part of
an upgrade but never rebooted to it, then installed the 3.16.0-43 kernel as
part of another upgrade.

That all looks normal. But why the 3.16.0-39 kernel would then have been
removed from the system is a mystery to me.

I recommend filing a bug report against the apt package in Launchpad for
this issue.

**Qqmike** · Jul 12, 2015, 01:38 PM

Thanks for the update.

Announcement

Circumstances under which apt WILL remove second of only two installed kernels

Circumstances under which apt WILL remove second of only two installed kernels

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment