Kernel updates and autoremove previous kernel

[weha]

I usually remove the third oldest kernel keeping 2 kernels. In the past when I rebooted after a kernel update, synaptic showed the third oldest kernel under autoremove. I have always removed it (no reboot needed) and was left with the two most recent kernels.
Now it seems things have changed somewhat. I reboot after a kernel update, autoremove in synaptic shows the third oldest kernel for removal, I remove it but am then prompted to reboot once again. I reboot and synaptic now shows the second most recent kernel under autoremove. Removing it would only leave me with the latest kernel.
Bit of a nuisance, two reboots. Why, why, why.. ?

[claydoh]

I have always had autoremove (in the command line) suggest all but the current kernel, but I don't use synaptic. Never get prompted for reboot, either. Maybe Synaptic is falling behind in development love in Ubuntu? Or perhaps a default setting for it has changed.

[SteveRiley]

It all depends on how various metapackages might be installed.

On my system, linux-generic is manully installed. This is a simple meta package that depends on other packages to pull in the actual kernel and headers. Here's how the dependency tree looks:

linux-generic [COLOR="#B22222"](meta)[/COLOR]
  linux-headers-generic [COLOR="#B22222"](meta)[/COLOR]
    linux-headers-[i]latestversion[/i]-generic [COLOR="#B22222"](architecture-specific)[/COLOR]
      linux-headers-[i]latestversion[/i] [COLOR="#B22222"](all)[/COLOR]
  linux-image-generic [COLOR="#B22222"](meta)[/COLOR]
    linux-image-[i]latestversion[/i]-generic [COLOR="#B22222"](architecture-specific)[/COLOR]
    linux-image-extra-[i]latestversion[/i]-generic [COLOR="#B22222"](architecture-specific)[/COLOR]

linux-generic is the only package manually installed, and always depends on latestversion. All the others are automatically installed to satisfy dependencies. linux-headers-generic and linux-image-generic also always depend on latestversion.

When latestversion+1 comes out, linux-generic, linux-headers-generic, and linux-image-generic are replaced. This causes the corresponding actual latestversion+1 header and kernel packages to be installed. The left-over (and now previousversion) kernel and header packages are still marked as automatically installed, but they have no currently installed "parent" candidate, so the package manager will suggest autoremoving them.

Multiple versions of the meta packages cannot coexist. If you want to keep prior kernels, you can mark the actual kernel and header packages as manually installed; now, autoremove won't suggest them as candidates for removal. I'm not sure how to do that in Synaptic, as I use only command-line tools for managing packages. At the CLI, you'd type:

sudo apt-mark manual linux-headers-[i]savedversion[/i]-generic linux-headers-[i]savedversion[/i] \
linux-image-[i]savedversion[/i]-generic linux-image-extra-[i]savedversion[/i]-generic

You will need to do this each time there's a kernel upgrade.

[kubicle]

There actually should be some apt magic in place to keep at least two kernel versions installed.

When you install a kernel, /etc/kernel/postinst.d/apt-auto-removal should create /etc/apt/apt.conf.d/01autoremove-kernels which should mark at least two kernel versions as not autoremovable.

So I'd first check what is in /etc/apt/apt.conf.d/01autoremove-kernels?

[SteveRiley]

Hey, that's a nice feature. Had no idea it was there.

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

[weha]

I don't see the file contents SteveRiley shows in post #5. Where can I find it ?

To recap.

After update to 3.13.0-43 kernel, I had:-
3.13.0-43
3.13.0-41
3.13.0-40
Rebooted and Synaptic then showed -40 for autoremoval (as in the past). I removed -40 completely as I only want to keep 2 kernels (as in the past).
This should have been the end of it (no reboot required).
Now however, I am prompted to reboot again. I rebooted and Synaptic now shows -41 for autoremoval. (I didn't remove it).
Should I just use cli in future ?
Here is what it shows in /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\.13\.0-40-generic$";
   "^linux-image-3\.13\.0-43-generic$";
   "^linux-headers-3\.13\.0-40-generic$";
   "^linux-headers-3\.13\.0-43-generic$";
   "^linux-image-extra-3\.13\.0-40-generic$";
   "^linux-image-extra-3\.13\.0-43-generic$";
   "^linux-signed-image-3\.13\.0-40-generic$";
   "^linux-signed-image-3\.13\.0-43-generic$";
   "^kfreebsd-image-3\.13\.0-40-generic$";
   "^kfreebsd-image-3\.13\.0-43-generic$";
   "^kfreebsd-headers-3\.13\.0-40-generic$";
   "^kfreebsd-headers-3\.13\.0-43-generic$";
   "^gnumach-image-3\.13\.0-40-generic$";
   "^gnumach-image-3\.13\.0-43-generic$";
   "^.*-modules-3\.13\.0-40-generic$";
   "^.*-modules-3\.13\.0-43-generic$";
   "^.*-kernel-3\.13\.0-40-generic$";
   "^.*-kernel-3\.13\.0-43-generic$";
   "^linux-backports-modules-.*-3\.13\.0-40-generic$";
   "^linux-backports-modules-.*-3\.13\.0-43-generic$";
   "^linux-tools-3\.13\.0-40-generic$";
   "^linux-tools-3\.13\.0-43-generic$";
};

[kubicle]

I don't see the file contents SteveRiley shows in post #5. Where can I find it ?

that snippet is from /etc/kernel/postinst.d/apt-auto-removal

Here is what it shows in /etc/apt/apt.conf.d/01autoremove-kernels ...

You seem to have kernel versions 3.13.0-40 and 3.13.0-43 marked as not autoremovable, which:
1. probably means that you were running 3.13.0-40 when you installed 3.13.0-43, so those two kernels were chosen to be kept?
2. would explain why 3.13.0-41 is now autoremovable

However, there is something fishy going on as version 3.13.0-40 should not have been autoremovable as you described.

Try changing all the 0-40-generic entries into 0-41-generic in /etc/apt/apt.conf.d/01autoremove-kernels, that should mark 3.13.0-41 as not autoremovable for now, and see if the file updates properly the next time you install a new kernel.

[weha]

OK, thanks kubicle. I have done a find and replace and now there is nothing to autoremove.
(Something must have gone down the wrong hatch, strange as I had the same with two Xubuntu systems).
Your help much appreciated !

Edit: I think claydoh may have a point in saying that synaptic may be falling behind in development. I had a look at my wife's laptop running Xubuntu 14.04. She had kernels -43, -41, -40, -39 installed and showing in grub.cfg.
/etc/apt/apt.conf.d/01autoremove-kernels showed -43 and -41
I then removed first -39 and then -40 with Synaptic; /etc/apt/apt.conf.d/01autoremove-kernels now showed -43 and -40 ?
I was prompted to reboot; for some reason there was no autoremove entry in Synaptic. I did a find and replace in /etc/apt/apt.conf.d/01autoremove-kernels so that only the running and previous kernels were listed (-43 and -41).
I think I will use Muon for Kubuntu in future (or cli) and the native Xubuntu updater to see how it goes.

[SteveRiley]

I doubt Synaptic is the culprit here, as these are rules that APT is following. Synaptic is simply a GUI front-end for APT.

[oshunluvr]

Old thread (in my defense, I've only been using daily 15.04 for a few weeks), but I'm seeing this now. It's exactly as the OP described - new kernel installed, old kernel #3 shows as autoremoveable, remove said kernel, reboot, old kernel #2 is now autoremoveable.

Whatever the cause, it's not fixed. Weirdness is: 01autoremove-kernels" shows "NeverAutoRemove" on -16 and -20. -20 is the current and -16 has been removed for a while, -18 is installed and subject to autoremoval, but shouldn't be because it's the only other kernel installed.

Digging....

[SteveRiley]

Whatever the cause, it's not fixed. Weirdness is: 01autoremove-kernels" shows "NeverAutoRemove" on -16 and -20. -20 is the current and -16 has been removed for a while, -18 is installed and subject to autoremoval, but shouldn't be because it's the only other kernel installed.

I'd guess that whatever process is responsible for writing 01autoremove-kernels is malfunctioning. If you removed -16, then that process should have removed -16 from the file and placed -18 into the file. But that didn't happen. The absence of -18 in the file would appear to be the reason that autoremove will happen.

I've not personally encountered this as I don't use distro default kernels -- they're too old. Instead, I use the latest released (not any "rcn") kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/.