Whenever you get a kernel update for Ubuntu, old kernels and headers are not automatically removed (I'm not sure if other distros do that). And sudo apt-get autoremove doesn't help either. Thus, you have to do it manually which is not very comfortable. So I looked for a solution which makes this task easier and satisfies one condition: It should be possible to keep a specified number of old kernels just in case that the new one causes trouble. I found some suggestions on these sites: https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels http://tuxtweaks.com/2010/10/remove-old-kernels-in-ubuntu-with-one-command/ http://askubuntu.com/questions/88936/how-to-remove-old-kernel-versions-automatically http://blog.opperschaap.net/2011/02/04/removing-old-kernels-in-debian-or-ubuntu/ https://bazaar.launchpad.net/~bikeshed/bikeshed/trunk/view/head:/purge-old-kernels http://ubuntu.5.x6.nabble.com/Distro-provided-mechanism-to-clean-up-old-kernels-td4476631.html After looking through those suggestions, I've decided to use the following simple script: Code: #!/bin/bash echo "The following kernels and headers are installed: " dpkg -l linux-headers* linux-image* | awk '/^ii/{ print $2}' echo " " # Attention: KEEP=1 will only keep the currently running kernel, KEEP=2 will keep the current kernel plus ONE old kernel (incl. headers) etc. etc. KEEP=2 OLDKERNELS=$(ls -tr /boot/vmlinuz-* | head -n -${KEEP} | cut -d- -f2- | awk '{print "linux-image-" $0}') OLDHEADERS=$(ls -tr /boot/vmlinuz-* | head -n -${KEEP} | cut -d- -f2- | sed 's/-generic//g' | awk '{print "linux-headers-" $0}') for c in $OLDKERNELS; do dpkg-query -s "$c" >/dev/null 2>&1 && PURGE="$PURGE $c" done if [ -z "$PURGE" ]; then echo "Nothing to do!" exit 0 fi sudo apt-get -q remove --purge $OLDKERNELS $OLDHEADERS I'm open for suggestions to improve that script, of course. Please tell me what you think. EDIT: Script modified. If the number of installed kernels is <= the KEEP value, you'll get the message "Nothing to do!".
Mrk, headers ARE removed by the script. Regarding debug and modules - wouldn't they removed via the dependencies?
I'm not sure that I understand. Everything the script tries do is to automate the process of removing old kernels and headers. It does that by 1. determining which kernels (and headers) are installed, and 2. by telling apt-get which of them to purge while obeying the KEEP value. I might have a mental block - but what does that have to do with /usr? I mean, if you're manually removing your old kernels and headers with apt-get, you're not interested in /usr, either, are you?
OK, we might be talking about different things. Are you trying to purge the old kernel installs or just remove the /boot component? Because kernel installations also include headers and debug info that goes under /lib and /usr, which might also no longer be necessary if you remove the older kernel instances. Mrk
Just for the record, by default the number of kernels kept is 3 in Scientific Linux (and I suppose in other RHEL clones). To change the number kept edit the installonly_limit= line in /etc/yum.conf. Rather painless.
Old kernels are eventually purged from the system. GRUB will simply use whatever kernel has been given priority to boot.
Anwsering this in a general sense, not specially at tlu... What about any older kernels that have caused trouble ? IMHO if you think manually removing kernels is too difficult, you should not trust an automated script either,, there are cases where even the last 2 versions are bad for specific hardware configurations, especially people who rely on 3rd party drivers. Centos/Redhat has a strong/ adherence to ABI/API stability, but in the Debian world (and as Ubuntu imports from Debian and adds it own patches to further complicate things) there are official versions that do not have the guarantee (testing/unstable/experimental) of ABI/API stability, so its harder to have a keep the most recent 3 kernel versions (espcially as you can upgrade between stable to testing and testing to unstable). The script may work for you, but definitely not good advice to use for anyone who does not have the understanding to know a good kernel from a bad one. Cheers, Nick
Interesting aspects, Nick. However, from my experience, for a given Ubuntu version there are usually only minor kernel changes mainly caused by fixing vulnerabilities (unless you intall, e.g., the LTS Enablement Stack for Ubuntu 12.04 which changes the kernel from 3.2 to 3.5.). That's why a kernel update is normally a must. The only (very rare) problems I remember were caused by misconfiguration by the maintainers - and they were fixed after a couple of hours or after one day at the latest.
Installation of the LTS EnablementStack upgrades Ubuntu Precise LTS 12.04.02 to 12.04.03! Recommended!
The only confirmed bug is the xserver-xorg symlink is missing on reboot - after installing the stack, its recommended to purge the xorg configuration files and to reconfigure xserver-x-org-lts-quantal before rebooting. Apparently the display manager can't find the X11 file hence the bug.