Why do some old kernels still stay?

19 Antworten [Letzter Beitrag]
Ra
Ra
Offline
Beigetreten: 07/23/2014

There's a forum thread called "Old kernels" that i would like to continue, but it's closed. Why?
In my case, i've upgraded to kernel 3.13.0-68 recently and run apt-get dist-upgrade twice in the last few weeks, before and after that upgrade. I've also run autoremove and autoremove --purge.
But still, not only kernel 67, but also 65 and 63 are still shown as installed by Synaptic. Do i really have to remove them manually in Synaptic? Or do i need them for something?
This is Trisquel mini.

ADFENO
Offline
Beigetreten: 12/31/2012

Perhaps some one more expert on this situation could help you, but as I
see it, it's way better to leave this untouched because you'll never
know if there's something that went wrong with the compilation/build of
the last kernel package that you download.

I can tell this myself, when I tried to install GNU+Linux-libre GuixSD
on my personal computer and got a kernel panic in the automated build of
the system kernel. On top of that, I forgot to learn how to tell
GNU+Linux-libre GuixSD so as to make it's GRUB installation to look for
other systems in other partitions, and I almost lost the ability to use
my already working Trisquel installation and all my personal data.

Luckly, I have my mother's computer which, despite running non-free
software, allowed me to at least put a copy of Trisquel on a USB device
to reinstall Trisquel's copy of GRUB. But I still haven't learned how to
tell GuixSD's copy of GRUB how to recognize other operating systems.
Besides, I have never done such manual work with GRUB.

So, believe me or not, someday you'll thank yourself for keeping at
least one older version of the kernel installed. :D

Another example COULD BE (I'm not sure) that strange bug with
applications using the Qt interface (which afected, for example, VLC and
Mumble). Where, at least for me, updating to the latest kernel from
Trisquel's repository solved the problem, that I was having with the
previous version. Under that situation, I could also have selected the
oldest entry related to Trisquel on the GRUB menu to see if the bug
would persist, but I decided to update once again just to make sure, and
so I was lucky. :D

onpon4
Offline
Beigetreten: 05/30/2012

Topics get closed automatically after some period of inactivity.

Keeping the older kernel until you're sure the new one works (which you can't check until you reboot and use the newer kernel) is a good idea. After that, there's no particular reason to keep the old kernel. But there's no particular way to automatically detect whether the new kernel "works"; it could be that it boots, but causes a particular piece of hardware to stop working because of a newly introduced bug, for example. So making the process of removing old kernels manual is unavoidable.

suitsmeveryfine
Offline
Beigetreten: 08/15/2014

I agree that it's a good idea to keep at least one older kernel that you know that you can boot the system with but I see no point in keeping several 3.13.x versions installed. Personally I try to run the very latest (stable) kernel with the latest long-term-support version as backup (both in the 4.x series). I also try not to upgrade both of these at the same time.

Do i really have to remove them manually in Synaptic?

Yes, I believe so (but not necessarily in synaptic; you can also use the command line). Maybe Trisquel doesn't auroremove kernels to be on the safe side, because the consequences are so bad if, for some reason, you don't have a working kernel to boot with any linger.

GNUser
Offline
Beigetreten: 07/17/2013

I have a similar issue.
I have linus 3.13 and 3.4 installed. Everytime there is an update on 3.13, it messes my grub confguration.
Since I don't use it, I want to remove it all. Just keep the 3.4.
I have tried following these instructions https://askubuntu.com/questions/2793/how-do-i-remove-or-hide-old-kernel-versions-to-clean-up-the-boot-menu
But I noticed that I have no "linux-headers" for 3.4. I am afraid that removing the 3.13 headers will make it impossible to boot the 3.13.

can anyone confirm this? I am using synaptic.

vita_cell
Offline
Beigetreten: 07/19/2015

Linus is Linus Torvalds (human beings don't have versions).

I am not sure, but headers are optional I think.
If something goes wrong, and you can not to boot, you can install/reinstall/uninstall any synaptic's package (yes, including kernel) from booted LiveUSB/CD mounting temporary folder.

Magic Banana

I am a member!

I am a translator!

Offline
Beigetreten: 07/24/2010

The headers are indeed optional (and not installed by default, in Trisquel 7 at least). I think they are useless unless you compile modules for the kernel.

GNUser
Offline
Beigetreten: 07/17/2013

Ok, thanks.

moxalt
Offline
Beigetreten: 06/19/2015

> Everytime there is an update on 3.13,
> it messes my grub confguration.

This shouldn't happen. Care to elaborate?

Magic Banana

I am a member!

I am a translator!

Offline
Beigetreten: 07/24/2010

It is normal: by default, GRUB is configured to always use the latest kernel image and 'sudo update-grub' is automatically run after you install such an image.

moxalt
Offline
Beigetreten: 06/19/2015

That is indeed normal behaviour. I do not consider that having my GRUB
configuration 'messed up'. My question still stands: in what way do kernel
updates mess up his GRUB configuration? Even though it runs an update-grub,
this does not affect the contents of /etc/default/grub, the primary
configuration interface designed for the users. I have a
customised /etc/default/grub- kernel updates do not overwrite my configuration
in any way. They merely update GRUB to use the latest kernel.

GNUser
Offline
Beigetreten: 07/17/2013

I use the 3.4 kernel, and because the 3.13 updates more frequently it gets picked as the latest. Also, I have it set to default to choose the option 1 (advanced options) and the next option has to be changed everytime a new 3.13 is added. But I will remove 3.13

So, I don't have to worry too much right? Just remove the linux-kernel-image packages of 3.13 and the headers, 3.4 will work ok, right?

Magic Banana

I am a member!

I am a translator!

Offline
Beigetreten: 07/24/2010

I see no reason why the 3.4 image would stop booting.

Magic Banana

I am a member!

I am a translator!

Offline
Beigetreten: 07/24/2010

You can remove the 3.13 kernels. One single kernel is enough (assuming you are sure it boots!). The package manager would prevent you from removing all kernel images.

Ra
Ra
Offline
Beigetreten: 07/23/2014

To make my point clearer: I understand it's good to keep an older kernel, and it's ok to delete the even older ones by command line, if there's one single command that really does all the work. But why has dist-upgrade deleted kernel 66 (and probably others), but not 65 and 63 as well?

vita_cell
Offline
Beigetreten: 07/19/2015

You can delete everything of kernels that you don't using. You can keep the previous version if you feel more security. Sometimes when upgrading, autoremove command removes old/useless packages, but somethimes it doesn't autoremove previos kernel version. I must to remove the previous one manually. Can be some fail-proof system, and this is very fine for newbie user.

alimiracle
Offline
Beigetreten: 01/18/2014

BTW, can I remove the old kernels
by remove it from /boot?

lembas
Offline
Beigetreten: 05/13/2010

No, that will remove only the binary itself missing all the modules etc.

To see what all your currently used kernel package contains, use this commanddpkg -L linux-image-$(uname -r)|less

For sighted people who prefer GUIs you can check the package contents also using the Synaptic package manager. (Painstakingly locate an installed linux-image package, right click, properties, installed files.)

Magic Banana

I am a member!

I am a translator!

Offline
Beigetreten: 07/24/2010

It is not that painful: just search "linux-image" and click on the header of the "S" (for "Status") column to get the installed packages at the beginning of the list.

lembas
Offline
Beigetreten: 05/13/2010

True true, still so much more work compared to the one-liner. Trying to illustrate why the CLI beats the GUI sometimes. :)