Gremlins removing kernels: where did they go?

[Qqmike]

In 14.04 (64-bit, UEFI mode), now and then I look at the old kernels in /boot and manually remove all but the two most recent. For the past few times I've done this, I see nothing in /boot except the most recent kernel, right now it is vmlinuz-3.13.0-54, the initrd, and the related files. Where did all the past kernels go (I have not cleaned this for many, many months). (I re-booted, and the GRUB menu offers nothing but the -54 kernel, no previous kernels.)



How could these be disappearing? The only thing Bleachbit is doing is: autoclean, autoremove, and clean. That wouldn't remove old kernels, would it? I see no setting in Muon that applies to this.

In particular, I have no fallback kernel to use in case the new one has a problem.



Very strange.

[Qqmike]

Hmmm. Just looked at Muon History, and I do see where the older kernel was removed. I'll bet I am not paying attention when Muon offers a kernel upgrade! I'll bet I am simply, quickly checking OK when Muon offers me the choice to remove old kernel(s). I'll pay attention next time. Anyone else notice this? Must be a new feature because in the past, kernels piled up quickly, no option to remove old ones when installing new ones.

[life0riley]

I haven't noticed this since I always update from the terminal. It would be nice to have it remove all but a few when updating from the terminal, but since this isn't implemented I assume most don't want that. Fedora removes the old kernels automatically and keeps the three latest whether updating from terminal or GUI.

[ronw]

Muon may do something different, but apt attempts to keep track of this.

$ 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-4-amd64$";
   "^linux-image-4\.0\.0-1-amd64$";
   "^linux-headers-3\.16\.0-4-amd64$";
   "^linux-headers-4\.0\.0-1-amd64$";
   "^linux-image-extra-3\.16\.0-4-amd64$";
   "^linux-image-extra-4\.0\.0-1-amd64$";
   "^linux-signed-image-3\.16\.0-4-amd64$";
   "^linux-signed-image-4\.0\.0-1-amd64$";
   "^kfreebsd-image-3\.16\.0-4-amd64$";
   "^kfreebsd-image-4\.0\.0-1-amd64$";
   "^kfreebsd-headers-3\.16\.0-4-amd64$";
   "^kfreebsd-headers-4\.0\.0-1-amd64$";
   "^gnumach-image-3\.16\.0-4-amd64$";
   "^gnumach-image-4\.0\.0-1-amd64$";
   "^.*-modules-3\.16\.0-4-amd64$";
   "^.*-modules-4\.0\.0-1-amd64$";
   "^.*-kernel-3\.16\.0-4-amd64$";
   "^.*-kernel-4\.0\.0-1-amd64$";
   "^linux-backports-modules-.*-3\.16\.0-4-amd64$";                                                                     
   "^linux-backports-modules-.*-4\.0\.0-1-amd64$";                                                                      
   "^linux-tools-3\.16\.0-4-amd64$";                                                                                    
   "^linux-tools-4\.0\.0-1-amd64$";                                                                                     
};

[vinnywright]

In 14.04 (64-bit, UEFI mode),


How could these be disappearing? The only thing Bleachbit is doing is: autoclean, autoremove, and clean. That wouldn't remove old kernels, would it? I see no setting in Muon that applies to this.

Very strange.

if Bleachbit is running apt-get autoremove then ,yes, this would remove old kernels ,,,,but apt usually leaves 2 ,,,,

VINNY

[Qqmike]

This suggests apt-get autoremove will keep the two most recent kernels:
http://askubuntu.com/questions/56348...my-old-kernels

My /etc/apt/apt.conf.d/01autoremovekernels suggests it is keeping the two most recent:

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

But I can't beleive Bleachbit would be programmed to delete all kernels except most recent without telling you?
More digging ...

[Qqmike]

I can't find anything more recent than 2/2011 with Bleachbit (when it did not remove old kernels):
http://bleachbit.sourceforge.net/forum/old-kernels

[GreyGeek]

There is (was?) an option in Settings to remove old kernels

[life0riley]

Gremlins removing kernels: where did they go?

There is (was?) an option in Settings to remove old kernels

I'll have to look for that. Would this apply to updates using apt?

[Qqmike]

I don't see it.

[InsideJob]

It's easier to just use a kernel from this year and lock the old kernel using Synaptic. All this vidiot proofing is more than a little annoying IMHO. When I upgrade it says:

The following packages have been kept back:
  linux-generic linux-headers-generic linux-image-generic linux-signed-generic linux-signed-image-generic
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.

Kernel 4.0 from Canonical's PPA works fine with Kubuntu 14.04, though it says "vivid" instead of "trusty" or whatever. A couple more weeks and 4.1 should be out. 3.13 just plain sux... bluetooth doesn't even work.

[vinnywright]

the nvidia dkms module did not want to build for me on the vmlinuz-4.0.0-040000-generic kernel .

I did not try to trouble shoot it yet .

and yes the default for apt-get autoremove is to keep the last 2 kernels ,,,,,,,,,,is Bleachbit using apt-get autoremove ?

VINNY

[Qqmike]

,is Bleachbit using apt-get autoremove ?

That's the question, I don't know. For now, I disabled it in Bleachbit. Next kernel update, I will know more about all this, as I'll pay attention to everything then. If I'm not feeling too goofy.

[Snowhog]

I have experienced unwanted kernel removal after an update > dist-upgrade > autoremove sequence, even though I had just two installed kernels. My settings in /etc/apt/ (?) for how many kernels to keep reflect two (active and prior).

When I've had it occur, I just reinstall the previous kernel. What I now do, when a kernel update or new kernel gets installed, is NOT to run the autoremove during that session. I'll reboot first, then update and dist-upgrade again, followed by the autoremove. That has resulted in keeping the two installed kernels (for me).

[life0riley]

It's easier to just use a kernel from this year and lock the old kernel using Synaptic. All this vidiot proofing is more than a little annoying IMHO. When I upgrade it says:

The following packages have been kept back:
  linux-generic linux-headers-generic linux-image-generic linux-signed-generic linux-signed-image-generic
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.

Kernel 4.0 from Canonical's PPA works fine with Kubuntu 14.04, though it says "vivid" instead of "trusty" or whatever. A couple more weeks and 4.1 should be out. 3.13 just plain sux... bluetooth doesn't even work.

0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded

How do you update from the terminal?