We have had a few threads around here discussing why windows users are hesitant to switch to Linux for their main OS. This thread's subject is one that I believe remains on that list. Linux in general does a very poor job of addressing the storage of ancient kernels as the OS updates. Over time that becomes problematic as is the case for me at this time. I am trying to locate a simple to learn and then teach way for a Linux user to purge/clean some space in /boot. I am currently playing with 14.04 and there have been numerous kernel updates so that now my /boot is too full to access additional system updates. I can easily see the current kernel by "uname -r" in a terminal so there is no question as to which the system is using. Is there a gui (maybe synaptic like) approach where a user could EASILY see the contents of their /boot, and then delete/purge the older kernel stuff so not enough space flags could be handled? My external drives are LUKS/lvm WDE so the only data in plain view is /boot. If there is no gui approach what would be the EASIEST terminal method to list the contents of /boot? Once detected, would a sudo apt-get purge of unneeded contents do the trick or which is the best method? I am actually surprised this subject has not been addressed in an automatic way via normal updates. Windows does beat Linux on this one!!
I just use Synaptic. Look at "Kernel and modules". I generally keep the latest 4-5 kernel packages, plus 1-2 older ones. The rest I "Mark for complete removal" and remove.
Brings up an interesting feature that used to be in PCLInuxOS. Don't know if it's still there. Used to be after install of new kernel next reboot the new kernel would be added to the OS selection screen. So I'd keep the old kernel if after booting & using the new kernel for 1-2 weeks it was troublesome. Otherwise I'd delete the old kernel & rename the new kernel in the boot menu. Really quite convenient.
I do use Synaptic and it works well. I didn't know if there was something more idiot proof for some newer users that are driving me crazy. Synaptic while cool, can wipe your stuff into oblivion if you click the wrong items. You guys are confirming what I sort of expected; there is no real automatic way where a new user can't kill themselves. Mirimir you are more conservative with keeping old kernels. I do a "uname -r" for the current and then keep two plus that one. I am not even sure why I keep that second older one but I do. Have you ever needed to use a kernel from say 3 updates ago? LOL!!
zapjb, I don't think that feature would work on my end since everything is LUKS/lvm encrypted. I only see the cryptsetup password box and nothing else, which is how I like it. LOL!!
I've never needed to revert to an old kernel, but I'm a cautious sort, so I save as much as I reasonably can. Even with dm-crypt/LUKS, you can drop into initramfs and play with /boot, and then reboot. Or you can boot a LiveCD to configure /boot.
Linux "in general" is not correct. There are distros that make it easy to control the number of stored kernels. Well, purging old kernels with Synaptic is a bit inconvenient. But you can try the following script which I used when I was still running Ubuntu. It worked well. Code: #!/bin/bash echo " " echo "The following kernel is CURRENTLY used: " uname -r echo " " echo " The following OLD kernels and headers are installed: " dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' 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
Ime if a user can't figure out Synaptic after a couple minutes they're going to have trouble with any Linux Distro. After all sometimes the OK buttons & Cancel buttons are switched. Just that blows a lot of Windows users minds. LOL
I've never had trouble with kernel updates screwing up Ubuntu even in 9 years (the exception being when I had Proposed enabled...a long, long time ago...). So, once, after a kernel update, I reach Desktop, and wireless establishes a connection, into synaptic I go and bye bye older kernel. After all, we're talking over 200 mbs per older kernel here on a 64 bit system. If everything is working fine why keep it? Later...
Yes, I agree. However, I've seen cases where users simply didn't know that they had to remove old kernels manually or just forgot about them. Some of them had 20 or even more old versions on their system consuming several gigabytes. Executing above script once in a while makes it very easy to get rid of them.
I really enjoyed going through this thread. Have you guys ever gotten into a place where you are helping ex-windows users with Ubuntu and find the "dependency thing" is too much!! As pointed out above; if you can't handle synaptic what gives? These guys need to go it alone. tlu, thanks for the script!!
Launch synaptic and install the "bleachbit" (cleanup app w/ GUI) from Debian reposities. Also install "ncdu" (tiny 80kb, ncurses directory usage cli util) and "localepurge" (it's tiny). Bleachbit will help you to identify, and selectively cleanup, various tpyes of cruft which may be bloating your boot partition. You should run bleachbit twice, once as your normal user, again logged (sudo, gksu, whatever) as root. (run as normal user cannot clean many paths, run as root will miss cleaning your ~home) Open a console (terminal emulator), cd / and run ncdu. It enables you to walk/traverse your directories (left arrow goes up, right arrow {or enter} browses the currently focused subdir) so that you can learn where the space-hogging dirs/files are. Note: ncdu doesn't delete anything; you need to do so separately, manually. Depending on which file manager you have (spacefm, nautilus, pcmanfm), you might be able to use that just as easily... ...but ncdu automatically sorts largest to smallest, making it fast to "walk around" quickly just using the arrow keys. One thing (type of thing) missed by bleachbit you'll find by doing this is "theme cache files". You may have installed/uninstalled various desktop themes throughout your usage, and the cache files (some are upwards of 60Mb each) are typically not cleaned up (deleted) upon uninstalling the theme. If you've ever used a packagekit-powered software manager app (Mint Software Center, Ubuntu SoftwareCentre, KDE has one also) those apps are terrible in that they never perform any housekeeping. Thumbnails for every blessed app you've ever browsed within the \SCentre\ app are cached, somewhere, in some dir on your drive. "localepurge", once installed, will prevent installation of extra lang files during future deb package installations. However, it does not cleanup anything already there. I don't have my list at hand and I can't recall where, aside from /usr/local/docs (?) the bloaty language files are pathed, but I can tell you this ~~ it's worth hunting them down. If you've been using your system for a while & have installed (and/or uninstalled) many apps from deb packages, you'll probably find that upwards of 360Mb (nearly half a gig!) of your Debian system is comprised of useless (to you) foreign language manpages/docs. You will probably notice these other dirs during your use of ncdu. For instance, under the python or perl (maybe each of 'em) dir, there's a HUGE "unicode" subdir, with 60Mb+ lang files pathed there. Ummm, bleachbit _will_ catch/cleanup some of these lang files, but it will probbly miss 100Mb or so that you can track down manually. Some iconsets may occupy 50Mb+ on your drive. If you're not using 'em (and installed apps don't depend on 'em)(asinine, but many apps DO depend on gnome iconset)... buh-bye. Both used and unused themes, walk their dirs and check; some ship with 10-30Mb worth of hi-res desktop wallpaper images that you'll never use. I'm not defending the status quo, just trying to make sense of why things are as they are. Older kernel(s) are not automatically removed b/c you may discover an issue/problem when you boot to the updated kernel (and would pound the desk in frustration if you could not revert to booting the earlier kernel). Slop left after package uninstalls seems inexcusable, but there are so few package maintainers juggling 40k packages (x3: stable, testing, unstable/experimetal)(plus backports...) that they can't attend to details. If it builds, if it installs without breaking anything else... zoom, on to the next item in the queue...
