apt autoremove no longer removes old system images

[joneall]

I have noticed for several weeks that apt autoremove (or apt-get autoremove) no longer removes old images.

$ ll /boot/vml*
lrwxrwxrwx 1 root root 24 nov. 19 07:44 /boot/vmlinuz -> vmlinuz-5.4.0-54-generic
-rw------- 1 root root 11678464 oct. 5 15:54 /boot/vmlinuz-5.4.0-51-generic
-rw------- 1 root root 11678464 oct. 15 12:33 /boot/vmlinuz-5.4.0-52-generic
-rw------- 1 root root 11678464 oct. 21 11:01 /boot/vmlinuz-5.4.0-53-generic
-rw------- 1 root root 11678464 nov. 5 19:11 /boot/vmlinuz-5.4.0-54-generic
lrwxrwxrwx 1 root root 24 nov. 19 07:44 /boot/vmlinuz.old -> vmlinuz-5.4.0-53-generic

(What are the links for?) I have found this discussion, which leads me to this.

$ less /etc/apt/apt.conf.d/01autoremove-kernels
// DO NOT EDIT! File autogenerated by /etc/kernel/postinst.d/apt-auto-removal
APT::NeverAutoRemove
{
"^linux-.*-5\.4\.0-53-generic$";
"^linux-.*-5\.4\.0-54-generic$";
"^kfreebsd-.*-5\.4\.0-53-generic$";
"^kfreebsd-.*-5\.4\.0-54-generic$";
"^gnumach-.*-5\.4\.0-53-generic$";
"^gnumach-.*-5\.4\.0-54-generic$";
"^.*-modules-5\.4\.0-53-generic$";
"^.*-modules-5\.4\.0-54-generic$";
"^.*-kernel-5\.4\.0-53-generic$";
"^.*-kernel-5\.4\.0-54-generic$";
};
/* Debug information:
# dpkg list:
rc linux-image-5.4.0-48-generic 5.4.0-48.52 amd64 Signed kernel image generic
ii linux-image-5.4.0-51-generic 5.4.0-51.56 amd64 Signed kernel image generic
ii linux-image-5.4.0-52-generic 5.4.0-52.57 amd64 Signed kernel image generic
ii linux-image-5.4.0-53-generic 5.4.0-53.59 amd64 Signed kernel image generic
iF linux-image-5.4.0-54-generic 5.4.0-54.60 amd64 Signed kernel image generic
ii linux-image-generic 5.4.0.54.57 amd64 Generic Linux kernel image
# list of installed kernel packages:
5.4.0-51-generic 5.4.0-51.56
5.4.0-52-generic 5.4.0-52.57
5.4.0-53-generic 5.4.0-53.59
5.4.0-54-generic 5.4.0-54.60
# list of different kernel versions:
5.4.0-54.60
5.4.0-53.59
5.4.0-52.57
5.4.0-51.56

,,, and more.

The discussion at the link suggests playing around with files and that sounds dangerous to me. Is there another way out? It may be that this is happening since I started letting Discover do the updates it suggests.

Why does it set these to neverautoremove? Will I have to remove them individually and, if so, how? Will this continue?

[GreyGeek]

It's probably to prevent you from sawing off the limb you're setting on.
Do "uname -a" to get a listing of the kernel you are currently running and then compare it with the list of kernels in that file you listed. You'll find the kernel you are currently running in that list. You can still remove a specific kernel by using apt, or better yet, muon,if your cli-foo isn't up to snuff.

[joneall]

It's probably to prevent you from sawing off the limb you're setting on.
Do "uname -a" to get a listing of the kernel you are currently running and then compare it with the list of kernels in that file you listed... You can still remove a specific kernel by using apt, or better yet, muon,if your cli-foo isn't up to snuff.

Thanks, I've already seen that I'm running version 54. Before, autoremove always kept the last 2 systems. Now it removes none.

I don't know muon. Or what "cli-foo" means. What apt command removes a kernel version? Even if it's listed to not be removed?

Thanks for your input.

[GreyGeek]

"cli-foo" is an attempt at humor. CLI is Command Line Interface (i.e., the terminal) and foo is from Kung-Foo, referring to master martial artists.

"apt remove somepgk" requires you to know the exact name of somepkg, otherwise the remove will fail. I don't have enough foo to know the exact package name of every package I want to install or remove so I use muon, which is KDE package manager. It is in the repository. You can add it using "sudo apt install muon" because the name is simple and easy to remember. Once it is installed it uses /etc/apt/sources.list to install the list of repositories in that file. When you run muon you can enter just a piece of the name in the search bar and it will list all the packages that contain the piece of name. From that list and the descriptions you can choose which one you want to install, upgrade, remove or purge. For example, if you enter "generic" (without the quotes) in the search bar and do the search you'll see a list of all the generic kernels. The ones that are installed will show "installed" in the status column. You can click on the column head to sort it. Or click again to resort it. Right mouse click on a particular kernel and a popup will give you the options. Chose one. Do that for as many kernels as you want to remove (except for the one you are running) and then click the "Apply" icon.

[jglen490]

I just looked at my 01autoremove-kernels file. It's a bit different from yours. When Discover pops a notification, I just do sudo apt update and sudo apt full-upgrade. Don't have any old kernels beyond the current plus next older. So, it could be Discover-related.

[jlittle]

When Discover pops a notification, I just do sudo apt update and sudo apt full-upgrade.

That's a bit like flying blind. After sudo apt update, I suggest something like

aptitude -F '%12p %t %V %d'  search '~U'

to see what's being updated. (Install aptitude if necessary.)

[chimak111]

IIRC, both apt and apt-get list the packages and wait for a [Y/n] response unless one uses -y or --assume-yes to force a non-interactive mode.

[joneall]

So, it could be Discover-related.

That's something I was beginning to suspect, since I only have used Discover for a few weeks now.

So is there a way to get rid of the older images, keeping only the last two like autoremove seems to do, and I will stop using Discover?

Btw, is there any functional difference between apt, apt-get and aptitude?

[chimak111]

...
Btw, is there any functional difference between apt, apt-get and aptitude?

https://debian-handbook.info/browse/...t.apt-get.html goes into much detail.

[jlittle]

IIRC, both apt and apt-get list the packages and wait for a [Y/n] response

That's a raw and unformatted list of package names and old and new versions. With some packages I've no idea what they're about, and even when I do it's easy to miss them in the mess of version numbers. apt list --upgradable is better, each package is on a new line, but there's no description.

[jglen490]

That's a bit like flying blind. After sudo apt update, I suggest something like

aptitude -F '%12p %t %V %d'  search '~U'

to see what's being updated. (Install aptitude if necessary.)

There is an implied distrust of the the update/upgrade process. If you want to know "what" is being update, sudo apt upgrade gives a list and an opportunity to go with yes or no to actually install. If you want to know "why" about the update, then that presumes you don't know "what" already exists.

Not knowing what you have may imply having a some PPAs that could be presenting unknown materials. Or, having an installation that runs significantly outside the box. Either way, you're not increasing your risk by simply running the updates/upgrades.

On the other hand, if you are running mostly inside the box, running the updates/upgrades also does not present an increased risk.

Bottom line, while I've had some updates that were less stable than I thought they might be, those instabilities were usually resolved within a short time. However, I have never denied a routine upgrade from being installed through either apt-get or apt. Denying an upgrade presents more risk overall than accepting an upgrade.