Is there some maximum value of old kernels that the automatic update mechanism installs, and after that, starts uninstalling old kernels? Or, is the number of kernels being installed likely to grow without bound, leaving it up to me to manually uninstall old kernels (say, maybe leaving one or two old kernels as a backup for safeties sake)? My fear here is that the number of installed kernels will build up to the point of causing the filesystem in which they are stored to run out of file space, and who knows what weird sorts of failures at boot time that will cause later on if not addressed now.

Thanks,
bgoodr

You have to uninstall the kernels you no longer require, but they do not take up much space on your HDD.

Most people will keep at least one previous kernel, in case an update causes problems (in my experience, they don't).

In any case, after 10 or so kernel upgrades, it'll be time to move to the next distro release, so maybe best not to worry about it

Yes, I agree. Thanks!

bgoodr

Unless he's using debian testing or unstable ofcourse, where you can just upgrade for ever.

If he's using debian testing or unstable, I'd expect him to be able to answer his own question
Fair comment though!

Well, he's Distribution: say Lenny.
To the op, the kernels don't just magically get updated, you do that yourself by accepting or starting the install. Therefore you also are expected to take care of removing not wanted ones.

Let me get this straight: Since I'm using Debian testing, it is as if apt-get dist-upgrade were to be executed automatically, and that the kernels will accrue without bound, leaving it up to me to periodically purge the old kernel packages.

If that is correct, then I can live with that. But, I would have expected http://www.debian.org/devel/testing to describe such behavior without forcing me to post "question spam" into this forum.

bg

That's not what I meant. I meant that debian testing and unstable allow you to upgrade basically forever, without doing a single big release upgrade. Oh well, in practise you get these packagelumps when a new stable gets out, but it's still not a reinstall.

As far as I know, Debian will never automatically uninstall a kernel. The exception that proves the rule is that if you get a new version of the same kernel release (because of a security-related patch), then that will overwrite the other version. So if you have 2.6.26.1-686, and the 2.6.26-1 kernels get a security patch, then your kernel will get overwritten. However, if you are in Lenny, and 2.6.27-4 becomes the new kernel, then 2.6.26-1 will not be removed. I've never read an official reason why not, but here's my guess: sometimes new kernels mess up existing systems or have regressions in terms of performance. In such a case, it's very smart to have a back-up, in case you need to "downgrade" (so to speak). After a reasonable amount of experience with a new kernel, I think you are safe to uninstall anything from current-2 back.

That said, there's nothing intrinsically wrong with keeping old ones unless your /boot partition is very small. If it is and it fills up, then you will have problems booting into regular user mode. (There's a small amount of extra space reserved for root to protect you from being completely locked out of your system, as I recall.) In any case, I can't see any reason to keep even four or five old kernels, much less ten.

As for automatic upgrades: you will get an automatic kernel upgrade if you have one of the dummy/virtual kernel packages installed. An example of those is linux-image-2.6-686. That package doesn't install any particular kernel. Instead it's a hook: it brings in whatever kernel in the -686 series is current in your sources. So if you were in Lenny going back a bit, at one point that would have dragged in 2.6.22-x-686, then 2.6.24-x-686, etc. Right now, it's pointing at 2.6.26-1. I'm not sure if the plan is to release Lenny with that or try for a 2.6.27 (or even 28) before release.

You can see what kernels you have installed - to check if you have a virtual kernel and to clean up - by running this command: If you've been installing kernel-headers along with the kernels (say to build modules for graphics or wireless), you should remove those when you remove the corresponding kernel. The command to search for those is parallel:Hope this helps.

Yes that does help a lot. I will need to continue to use apt-get for package management since that is what I started with, and got burned pretty badly last year for attempting to mix apt-get with aptitude, but I get your point.

Thanks for everyones help!
bgoodr

Fair enough. Just so you know, you can always safely do searches from aptitude or apt-get (or Synaptic or any other package manager), no matter which you use for installation. The searches just look for available packages or packages on your sytem; they don't change anything.

I've already run into that problem of filling up the boot partition because there were so many old / custom kernels hanging around.

I now proactively remove all the old kernels from my systems, keeping only my current running kernel and the previous working kernel. anything older than that is hunted down and purged, then the headers for it are purged, then I search for modules related to that kernel and they get removed as well.

Even if you are not running Sid, you can have a system that you roll from one version of stable to the next, and the kernels will eventually start to add up.

In addition to the searches suggested above.
aptitude search ~ilinux-image
aptitude search ~ilinux-headers

I also check the modules and sources directories. No need to keep modules and junk around for kernels i've already removed.
ls -al /lib/modules
ls -al /usr/src

Thanks. See also some related info in the other thread.

bgoodr

For us lazy types, it would be nice to have something like the fedora option which tells the system how many kernels you would like to be kept. My fear is always that someday I will accidentally remove the incorrect kernel.

Please define "incorrect kernel" [That one I really, really wanted to keep?]

Seriously, if it is annoying you, isn't this something that is crying out for you to write a script for?

Run it once at every boot (you only reboot when you add a new kernel, right? )

Psloppy pseudocode for said script follows:

keep=5; do find the kernels available | sort by date | count | if <= keep then done and exit cleanly, else rm the oldest until done

There are many ways of doing this (with and without paranoid error-checking, and sensible reporting), and you do not have to follow the recursive outline I have suggested.

Maybe fedora have already written such a script, and in true linux tradition it just needs a few minor changes (or maybe none at all) for your distro.

Sorry, I don't have the time to do this for you, and this is not high on my list of priorities at the moment, but it might be a fun little project with a high satisfaction-quotient. Feel free to post your efforts here, or even in a new thread.

I shouldn't have to warn you to take a system backup before you start playing with kernel-removing scripts:

Oops! Recursion went wrong.
All kernels gone.

Have fun!