/etc/kernel/postinst.d/apt-auto-removal wants to remove all kernels except the latest one

[Cavsfan]

After installing a 3rd kernel currently 3.19.0-12-generic, the /etc/apt/apt.conf.d/01autoremove-kernels file looks normal listing the 3.19.0-11-generic and 3.19.0-12-generic with 3.19.0-10-generic listed to be autoremoved. But once autoremove is completed the machine requests to be rebooted and at that time the /etc/apt/apt.conf.d/01autoremove-kernels file lists the 3.19.0-12-generic and 3.19.0-10-generic kernels. So upon rebooting the 3.19.0-11-generic is requested to be autoremoved leaving only one kernel the latest one 3.19.0-12-generic.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: apt 1.0.9.7ubuntu3
ProcVersionSignature: Ubuntu 3.19.0-12.12-generic 3.19.3
Uname: Linux 3.19.0-12-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.17-0ubuntu1
Architecture: amd64
CurrentDesktop: MATE
Date: Sun Apr 5 17:03:01 2015
InstallationDate: Installed on 2015-04-02 (3 days ago)
InstallationMedia: Ubuntu-MATE 15.04 "Vivid Vervet" - Beta amd64 (20150401)
SourcePackage: apt
UpgradeStatus: No upgrade log present (probably fresh install)

[Cavsfan (cavsfan)]

After rebooting and autoremoving the 2nd oldest kernel the /etc/apt/apt.conf.d/01autoremove-kernels file reverts to listing the 3.19.0-11-generic and 3.19.0-12-generic kernels. So only one kernel, the latest 3.19.0-12-generic is left.

[Cavsfan (cavsfan)]

The workaround to keep the latest two kernels is to edit the /etc/apt/apt.conf.d/01autoremove-kernels file and change it to list the latest 2 kernels.

[Cavsfan (cavsfan)]

This has been happening on 3 different Vivid installs and 2 different flavors vanilla Ubuntu and Ubuntu Mate. It happens every time a new kernel is added without fail.

[bardo (81258541-0)]

me too (i confirm above to be reproducible on my machine with latest Vivid)

[Cavsfan (cavsfan)]

Please mark the bug as affecting you then.

[Alberto Salvia Novella (es20490446e)]

Leaving too much kernels triggers other bugs, as there can happen that there isn't enough space for them and make an upgrade to fail:
<https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1412097>

So make sure there will be enough space in a mobile device for two kernels.

[Cavsfan (cavsfan)]

I agree you should not have too many kernels on your system but, you should always have 2 regardless. One for backup and one to use. I would expect autoremove to remove the 3rd oldest kernel but not the only other kernel on the system. Which is the case as the last 2 kernel installs did the exact same thing as the 3.19.0-12-generic did: it wanted to remove the backup kernel leaving only one. /etc/kernel/postinst.d/apt-auto-removal is broken and should not do this.

[Cavsfan (cavsfan)]

This just happened on Trusty 14.04.2 LTS when 3.13.0-52-generic was installed on my computer.

[Cavsfan (cavsfan)]

Since this happens on every version from 14.04 to 15.10 is the problem that it think my PC is a phone? There should be a way to distinguish whether the system is a phone or a pc/laptop. Maybe phones should keep one kernel but I believe PC/laptops should be able to retain 2 kernels. The /etc/kernel/postinst.d/apt-auto-removal should not be triggered when the kernel components of one old kernel are deleted. That is without even using auto-removal; just deleting the kernel but it does trigger it.

[Cavsfan (cavsfan)]

This continues on even in Linux Mint as well as Ubuntu.
I don't think /etc/kernel/postinst.d/apt-auto-removal should be triggered when you delete a kernel no matter if it's the17th, 3rd, or 2nd to last kernel.
It is triggered when you just manually delete kernels:
sudo apt-get purge linux-headers-3.19.0-20 linux-headers-3.19.0-20-generic linux-image-3.19.0-20-generic linux-image-extra-3.19.0-20-generic

Or when you do sudo apt-get autoremove.

It should not be triggered except after a new kernel installation and that is all.

I still have to manually edit /etc/apt/apt.conf.d/01autoremove-kernels after autoremoving the 3rd kernel back or I will be left with one kernel.

[schamane (schamane)]

A better workaround seems to be to just run
'''
/etc/kernel/postinst.d/apt-auto-removal $(uname -r)
'''
before `apt-get autoremove`.

[Cavsfan (cavsfan)]

How can you run that when
'''
/etc/kernel/postinst.d/apt-auto-removal
'''
is automagically run at the end of
'''
entering sudo apt-get purge <4 kernel modules>.
...
let alone when auto-remove is run.
'''
you will never get the chance.

[Christian Bachmaier (chkis)]

I have this on all my three 14.04 LTS machines.

[Ben Coleman (oloryn)]

I agree with cavsfan that /etc/kernel/postinst.d/apt-auto-removal should not be triggered when you delete a kernel. What is happening is that /etc/apt/apt.conf.d/01autoremove-kernels is being set to prevent kernel[0] and kernel[-2] from being autoremoved, instead of kernel[0] and kernel[-1].

Take a recent situation. After the installation of kernel 3.19.0-28, the kernels 3.19.0-25, 3.19.0-26, and 3.19.0-28 are installed, and /etc/apt/apt.conf.d/01autoremove-kernels is set to prevent 3.19.0-26 and 3.19.0-28 from being removed.

When you run the autoremove in this situation, 3.19.0-25 is removed. If /etc/kernel/postinst.d/apt-auto-removal is triggered during this removal, it will mark as not-for-autoremoval (according to the comments at the top of apt-auto-removal):

* the currently booted version - this will be 3.19.0-28
* the kernel version we've been called for - this will be 3.19.0-25 (which is the kernel we've just removed - why are we marking for non-auto-removal a kernel which has already been removed?)
* the latest kernel version - this will be 3.19.0-28
* the second-latest kernel version, if the booted kernel version is already the latest and this script is called for that same version - this doesn't apply, as this script isn't being called for the latest version, it's being called for the version we're deleting.

The result is that /etc/apt/apt.conf.d/01autoremove-kernels is set to prevent 3.19.0-25 and 3.19.0-28 from being autoremoved, while the system actually contains 3.19.0-26 and 3.19.0-28. Autoremove will, in this case, want to remove 3.19.0-26, leaving only 3.19.0-28.

I think the fact that having a kernel removal trigger /etc/kernel/postinst.d/apt-auto-removal will result in marking for non-auto-removal a kernel that is already removed alone indicates that something is not being done correctly. Either don't trigger /etc/kernel/postinst.d/apt-auto-removal on a kernel remove, or tweak /etc/kernel/postinst.d/apt-auto-removal to handle the fact that the kernel it's being called for is being deleted, not added (perhaps don't do criteria 2 (the kernel version we've been called for) and do criteria 4 (tweak criteria 4's conditions to have it apply on a deletion).

[Cavsfan (cavsfan)]

This just happened to me on Xubuntu 15.10 when 4.2.0-11-generic was installed. It wanted to leave me with one kernel.
You can refer to these two posts for the detail:

http://ubuntuforums.org/showthread.php?t=2251168&page=4&p=13361806#post13361806

http://ubuntuforums.org/showthread.php?t=2251168&page=4&p=13361833#post13361833

[oshunluvr (stuartksmith)]

For what it's worth, it seems it might be HOW the script is being called. Testing the apt-auto-removal script here (Kubuntu 15.04) with kernels 3.19.0-29-generic, 3.19.0-30-generic, and 3.19.0-31-generic installed and after a reboot to load -31:

1) Noticed the call to autoremove 3.19.0-30-generic.
2) Read /etc/apt/apt.conf.d/01autoremovekernels and saw -29 and -31 listed as "NeverAutoRemove"
3) Manually removed 3.19.0-29-generic.
4) Ran "sudo /etc/kernel/postinst.d/apt-auto-removal"
5) Re-read /etc/apt/apt.conf.d/01autoremovekernels and saw only -31 listed as "NeverAutoRemove"
6) Ran "sudo /etc/kernel/postinst.d/apt-auto-removal 3.19.0-31-generic"
7) Re-read /etc/apt/apt.conf.d/01autoremovekernels and saw -30 and -31 listed as "NeverAutoRemove"

So it worked when called properly in that case. I thought it possible that part of the problem is it's being called with the wrong kernel version.

I re-installed -25 and -21 along with -30 and -31. This resulted in -25 and -31 in the never remove list.
But again: When apt-auto-removal is re-run with -31, the never remove list changes to -30 and -31.

[Cavsfan (cavsfan)]

I also found a work around: once the new kernel is installed and it's wanting to reboot, delete the 3rd oldest kernel or autoremove it before rebooting and then the /etc/apt/apt.conf.d/01autoremovekernels file will contain the 3 kernels, which is better than having one.

[Jarno Suni (jarnos)]

I think apt-get autoremove may even delete the current kernel, if you run /etc/kernel/postinst.d/apt-auto-removal, boot to an older kernel and then run apt-get autoremove. However, maybe that is not big issue, since there is still another kernel that you can boot next time (if you haven't removed it manually).

[Jarno Suni (jarnos)]

It is hard to know, if /etc/kernel/postinst.d/apt-auto-removal is called in conjunction with removing a kernel or installing a kernel. The kernel in question, whose version is passed as a command line argument, has "install" as desired action according to dpkg at the time of calling the script anyway. It would be logical that the state had been updated by that time, as the script is a post installation script.

[Jarno Suni (jarnos)]

The attached script leaves more kernels than one. It keeps some automatically installed kernels, even if there are also newer manually installed kernels such as upstream kernels installed. (https://wiki.ubuntu.com/Kernel/MainlineBuilds)

[Cavsfan (cavsfan)]

I run an alias to do my updating and it's this:
sudo apt-get update && sudo apt-get upgrade && sudo apt-get autoclean
When the update happens and there is a kernel waiting to be dist-upgraded I believe the
/etc/apt/apt.conf.d/01autoremovekernels file has been manipulated to include parts of the wrong kernel
Then when autoclean runs it deletes parts of that kernel rendering it useless.
Thus when a reboot happens, the wrong kernel is wanting to be deleted, again triggering
/etc/kernel/postinst.d/apt-auto-removal and you end up with one kernel.
/etc/kernel/postinst.d/apt-auto-removal should not be triggered as many times as it is. As I've mentioned a few
times after rebooting and purging kernels it causes you to have just one.

I took out the autoremove part and if I delete the oldest of the 3 kernels before the first reboot, it gets it right.
But, when you reboot before purging the 3rd kernel it will keep on until you have one.

[Jarno Suni (jarnos)]

Cavsfan, try to replace /etc/kernel/postinst.d/apt-auto-removal by the one I uploaded.

[Cavsfan (cavsfan)]

Thanks! I did that.
We'll see when the next kernel comes through in updates.

[Jarno Suni (jarnos)]

To make sure current kernel is not autoremoved, /etc/kernel/postinst.d/apt-auto-removal should be run during startup, that is before running "apt-get autoremove" during uptime.

[Jarno Suni (jarnos)]

I did it like this: http://askubuntu.com/a/713879/21005

[Cavsfan (cavsfan)]

Jarnos, I can confirm that your /etc/kernel/postinst.d/apt-auto-removal and adding the cron job resolves this problem.
I installed the 4.3.0-5-generic kernel and rebooted and then manually purged the 4.3.0-1-generic and it gave some erroneous errors about not being able to find the DKMS modules to delete for that kernel. But after rebooting again there were no dkms modules and the 4.3.0-2-generic and 4.3.0-5-generic are all that are on my system.

Attached is the output of the error messages although the kernel and DKMS modules for 4.3.0-1-generic are confirmed to be gone.

[Jarno Suni (jarnos)]

cavsfan, why didn't you just use "sudo apt-get autoremove --purge" to purge the extra kernel? Anyway, it is odd that the system required image packages to be removed before header packages.

[Cavsfan (cavsfan)]

Jarnos, I have always had a text file with the kernels listed on it and when I have 3 I delete the 3rd one leaving me 2.
This has been good since 2009. Since it wasn't asking me to autoremove anything I just entered:
sudo apt-get purge linux-headers-4.3.0-1 linux-headers-4.3.0-1-generic linux-image-4.3.0-1-generic linux-image-extra-4.3.0-1-generic
I've just always done it that way.

[Jarno Suni (jarnos)]

Cavsfan, I had similar error during removal of a linux.image-extra package: you can see it in the log I added to http://askubuntu.com/q/718966/21005 Maybe removing the kernel package before header packages would have resulted no such an error. BTW, I think you cut the output so that it does not show removing of linux-image-4.3.0-1-generic, that would be later in the output.

[Robert Euhus (euhus-liste1)]

The problem is that on purge/removal the linux-image-extra package runs all the kernel post-*install*-hooks in /etc/kernel/postinst.d (as its postrm hook), including the /etc/kernel/postinst.d/apt-auto-removal hook. The 'to-be-removed'-version of the kernel is given as an argument and thereby added to the list /etc/apt/apt.conf.d/01autoremove-kernels of kernels which shall not be autoremoved. Which at this point is clearly wrong, since we are probably just right now removing the respective kernel (linux-image) version as well.

This bug was introduced as a fix to #1375310 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1375310).

A fix is not so obvious for me, as running some /etc/kernel/postinst.d/ hooks might be required upon removal of a specific version of the linux-extra-image, if the corresponding linux-image package is not going to be removed. But just running blindly all kernel-postinst hooks on removal of a package does not really seem like a good idea to me.

Regards, Robert.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jarno Suni (jarnos)]

Robert Euhus, even if the kernel-to-be-removed is added to the never-autoremove list by /etc/kernel/postinst.d/apt-auto-removal when removing the linux-image-extra package by apt-get autoremove, the respective linux-image package will be removed successfully thereafter. But it does not work, if you remove the linux-image-extra package manually by apt-get remove (--purge), and thereafter try to remove the linux-image package by apt-get autoremove, unless you run the apt-auto-removed script in between.

[Jarno Suni (jarnos)]

The attached script now tries to detect, whether it is called in conjunction with kernel installation or in conjunction with kernel removal. It uses dpkg-query for that. Maybe it could be done more easilly by giving the information to the script as a command-line argument by apt-get? The script also contains minor improvements. Does not use apt-mark anymore, unlike my previous script; apt-mark is a bit slow and unnecessary IMO. BTW Isn't it excessive that the script checks for kfreebsd and gnumach kernels?

[Robert Euhus (euhus-liste1)]

Jarno Suni, thanks for the reply.

First I would like to stress, that I still don't think that running all the KERNELS postINSTALL hooks while REMOVING the -extra package is the right thing todo. The only thing I can see that is really needed is the recreation of the initrd on installation and revmoval of that package (please correct me if I'm wrong!). So I think this is the only thing that should be done. Even recreating the GRUB config is unnessecary and a waste of time.

So working around this in the /etc/kernel/postinst.d/apt-auto-removal script is imho not the right way to do this.

That being said, this seems like the only available option right now.

I have taken a closer look at your "Fixed again" script and made some adjustments (comparing with apt 1.0.1ubuntu2.10 from 14.04):
- The version you have uploaded does not run properly, because some backslash-escapes for line breaks are missing (leading to "broken pipe" error).
- In the check if the kernel given in argument is desired to be removed the "exit" from the awk statement causes another broken pipe if the match is not the last kernel. It is not needed, so I removed it.
- The awk regex for creating the "list" of installed kernel versions is wrong ( only ' ' instead of '[ ]+' ), so the list is always empty. I don't see the advantage of using DPKG_QUERY here compared to the original which just uses DPKG. So to keep changes minimal I have reverted it to the old version.
- The shortened check if we have more than two kernels to keep already may lead to keeping one more kernel (3 in total) than in the original, which is fine by me.
- Again to keep changes (diff) minimal I have reordered the versions for the "kernel" variable like they are in the original.
- The use of dpkg-query looks somehow awkward to me (but maybe it's just me....).

I'll attach my updated version of the /etc/kernel/postinst.d/apt-auto-removal script

I have just run a few tests and it seems to work better than the original for now. I'll do some more testing right now.....

Regards,
Robert.

[Robert Euhus (euhus-liste1)]

Hi all,

sorry, the apt-auto-removal script attached above contained some debug echo statements. Which were harmless, but unnessecary.

Testing and thinking a bit more about the problem I have come to the conclusion, that upon removal of a linux-image-extra package the only right thing to do is not to touch the list of kernels not for auto-remove (/etc/apt/apt.conf.d/01autoremove-kernels) at all. We should just leave it the way it is.

Reasoning: consider the following example:
- We have linux-image{,-extra}-1, linux-image{,-extra}-2 and linux-image{,-extra}-3 installed.
- We now remove linux-image-extra-2 ; now we have two possible cases:
  - a) linux-image-2 is not going to be removed, so we should not remove it from the list
  - b) linux-image-2 is removed afterwards, in which case it would not matter, if we had removed it from the list.
Either way we have no way of knowing what will happen to the linux-image-2 package, while we are removing the linux-image-extra-2 package. So the only sensible thing is imho not touching the list in this case at all.
This is what the updated script in my attachment does now.

Moreover, looking at this case from another perspective, it looks like it would be a good thing to recreate the list at the time of the removal of the linux-image-2 package! At this point it would be nice to prevent linux-image-3 AND linux-image-1 from being auto-removed later on. .... but this would be another bug report, I guess.

Even even updating this list upon installation of an linux-image-extra package is questionable, since again we have no way of knowing, what the user had in mind. Of course, the linux-image needs to be installed (since it is a dependency), but maybe we are just installing all the -extra packages for all the installed kernels? It probably doesn't do too much harm in this case, but it is not very useful either.

I think, that this shows again, that executing all of the kernel-post-install hooks while acting on the rather unrelated -extra package is not the best way. Since recreating the initrd is the only thing we need, this is the only thing we should do on installation and removal of the -extra package!

So I see the updated /etc/kernel/postinst.d/apt-auto-removal script in the attachment not really as a solution to this problem, but more as a workaround for the broken linux-image-extra package install- and remove- hooks.

Regards,
Robert.

[Jarno Suni (jarnos)]

Robert Euhus, as for #36,
-Strange, no such broken pipe error due to missing backslash-escape occured, when I tried the script I uploaded.
- You are correct, the awk regex for creating the "list" needs one more space, because the abbreviated status of a package seems to contain three characters, last of which is space (' '), if there is no error flag in the package status. (BTW the db:Status-Abbrev is not available in 12.04, but according to the tags, the fix is needed for 14.04 and later.) As for the advantage of using dpkg-query over dpkg -l , for the former you can define output format, whereas grepping dpkg's output, which contains header lines and some extra information is not a good practice IMO.
- As of the broken pipe due to exit in awk script, which awk you are using?
Does this give broken pipe in your system?
dpkg-query -W -f='${Package}\n' | awk '/dpkg/{print $1; exit}'
(It doesn't in mine.)

[Jarno Suni (jarnos)]

This seems to work for me. I changed some things based on feedback from Robert Euhus (and a little bit more). I don't see a problem in updating the kernel list in case a linux-image-extra package is being removed; the list does not change then, but this updates also, when a linux-image package is being removed, when it may be necessary to update the list.

[Jarno Suni (jarnos)]

Oh, now I remember why I added "xargs apt-mark showauto" in the pipe in the first script attached to comment #22: if you manually add some newer kernels for e.g. testing something, you may not want system to automatically remove the latest kernels available from the usual Ubuntu repository, and consequently loose a meta package such as linux-image-generic that enables kernel updates. In case user has installed an LTS Enablement Stack, automatic removal should keep the meta kernel package for that.

[Cavsfan (cavsfan)]

Thanks for the attention to this issue that effects every debian version including Mint back to Trusty 14.04.
I copied your version 4 script into my /etc/kernel/postinst.d/apt-auto-removal.
I will post the entire output resulting from the next kernel that gets added.
I have a 64 bit version of Xubuntu Xenial Xerus (development branch) 16.04 at present.
I like your notes in this version:
# 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.
That is exactly how I've always thought it should work.

[Jarno Suni (jarnos)]

Cavsfan, the comment was copied from the original script; it may not be accurate with this one. I think the normal case after installing a kernel with this script is three kernels in the never-auto-remove list. There may probably be four kernels installed then (before autoremoving). If that is too much, running the script without command line arguments as a startup script as root helps (combined with regular autoremoving). That also prevents the running kernel from being autoremoved, in case you boot a kernel that is not protected by the never-auto-remove list. The script may keep even more kernels from getting autoremoved, if there are ones that are marked as manually installed, but you can control that by using apt-mark.

[Cavsfan (cavsfan)]

Jarno, I did notice that those commands were in the original script after I posted that.
I got the 4.3.0-6-generic installed in Xubuntu 16.04 just a while ago and your script worked flawlessly.
I had 3 kernels: 4.3.0-2-generic, 4.3.0-5-generic and 4.3.0-6-generic after installation and the 01autoremove-kernels file contained just the last 2 both before and after rebooting. The output is attached

[Cavsfan (cavsfan)]

Then I performed a sudo apt autoremove and the 4.3.0-2-generic was removed.
The 01autoremove-kernels did not change and still contains the last 2 kernels, which is good.
The output is attached.

It gave an erroneous error about the kernel header for 4.3.0-2-generic not being found but since it was removing that kernel that should not have displayed. But, the problem seems to be solved.

[Jarno Suni (jarnos)]

In contrary to what I told in #40, there is no fear that autoremove would remove the latest kernel that some meta package depends on. (Though the possibility is there, if there is no manually installed meta package that recursively depends on the kernel.) So "xargs apt-mark showauto" is not necessary for that, but you may want to keep it anyway, as it protects some older kernel from being autoremoved. That might be useful in case the installation of the latest kernel fails or booting the latest kernel fails (and there are manually installed newer kernels around). I am sorry about the confusion.

[Cavsfan (cavsfan)]

Got the 4.3.0-7-generic kernel on Xubuntu 16.04 in today's updates and the 01autoremove-kernels file
contains the last 3 kernels, which I'm fine with. I'll purge the 3rd oldest one. I prefer purging them
manually instead of using autoremove because autoremove leaves the "Residual Config" files for the image
and image-extra packages. The contents of 01autoremove-kernels after installing and rebooting is attached.

[Cavsfan (cavsfan)]

Manually purged the 4.3.0-5-generic kernel and that left the 4.3.0-6-generic and 4.3.0-7-generic kernels in the 01autoremove-kernels file. Which is great.

My only question is why does it require a reboot when the 3rd oldest kernel is deleted? I don't think this should be happening either.

[Jarno Suni (jarnos)]

As for #46, you could have ran `sudo /etc/kernel/postinst.d/apt-auto-removal ; sudo apt-get autoremove --purge` after reboot. I don't know, if you can configure unattended upgrade to do purging, as well.

As for #47, it is the matter of Bug #1458204

[Jarno Suni (jarnos)]

Simplify the script by using grep instead of awk in one check. During removal, the kernel package is apparently in half-installed state (H), so check for that (although [^c]} should work, too).

[Cavsfan (cavsfan)]

The installation of the 4.4.0-2-generic in Xenial 16.04 went well, It left 3 kernels in 01autoremove-kernels so I manually purged the 3rd oldest one. Now there are 2 there. I updated my /etc/kernel/postinst.d/apt-auto-removal with version 5 above.

[Cavsfan (cavsfan)]

I let 3 kernels remain on my Xubuntu 16.04 pc: 4.3.0-7-generic, 4.4.0-2-generic
and 4.4.0-4-generic. Just to see what would happen.
Today when 4.4.0-6-generic kernel came through in regular updates and
when it installed and I rebooted.
I again checked for updates via cli and it wanted to autoremove the
4.3.0-7-generic kernel which is great.

[Cavsfan (cavsfan)]

Today when updating via cli 4.4.0-2-generic kernel was waiting to be autoremoved. So after getting the updates I autoremoved that kernel. This left me with 2 kernels 4.4.0-4-generic and 4.4.0-6-generic which is precisely how it is supposed to work.

I think this is working great now.

[Cavsfan (cavsfan)]

This is working as it should work now. Is there any timeline on when it will be put out to the masses?
I install a kernel and before rebooting I purge the 3rd kernel back like I've always done.
If you autoremove the kernel it leaves the residual config files, which have to purged with a command
like this dpkg -l | grep "^rc" | cut -d " " -f 3 | xargs sudo dpkg --purge

[Jarno Suni (jarnos)]

Seems to be fixed in Xenial (apt 1.2.10ubuntu1); at least two kernels are always kept, if available.

[Jarno Suni (jarnos)]

Upstream commit: https://anonscm.debian.org/cgit/apt/apt.git/commit/debian/apt.auto-removal.sh?id=3196dae8e92407b3aa8e12779a8ed7db998ebdc4

[Mathew Hodson (mhodson)]

Autoremoval issues for Trusty were solved in Bug #1429041