Re: Distro-provided mechanism to clean up old kernels
On Mon, Apr 30, 2012 at 10:27 PM, Tim Gardner wrote: > Dustin, > > There is a blueprint started for cleaning old kernels. Perhaps you should > add your thoughts to it. > > https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-clean-old-kernels Perfect, thanks, Tim. I'm subscribed and will attend the session. -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
Dustin, There is a blueprint started for cleaning old kernels. Perhaps you should add your thoughts to it. https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-clean-old-kernels rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
FYI, I have committed a version of a script and a manpage, purge-old-kernels, to lp:bikeshed: * http://bazaar.launchpad.net/~bikeshed/bikeshed/trunk/view/head:/purge-old-kernels * http://bazaar.launchpad.net/~bikeshed/bikeshed/trunk/view/head:/purge-old-kernels.1 It's based on the logic that Kees posted here. However, it will also: - always keep your currently running kernel + to remove your current current, reboot into a newer one, and then re-run the script - default to saving your 2 newest kernels + but that can be easily overridden at run time with --keep N - passes through any other parameters to apt-get + defaults to interactive prompt by apt-get, override with -y For example: $ sudo purge-old-kernels --keep 3 -qy Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: linux-headers-3.2.0-23-generic linux-headers-3.2.0-21 linux-headers-3.2.0-22 linux-headers-3.2.0-23 libcrypto++9 linux-headers-3.2.0-21-generic libnekohtml-java linux-headers-3.2.0-22-generic Use 'apt-get autoremove' to remove them. The following packages will be REMOVED: linux-image-2.6.38-10-generic* linux-image-3.0.0-10-generic* linux-image-3.0.0-11-generic* linux-image-3.0.0-16-generic* linux-image-3.0.0-7-generic* linux-image-3.0.0-8-generic* linux-image-3.0.0-9-generic* linux-image-3.2.0-17-generic* linux-image-3.2.0-18-generic* linux-image-3.2.0-19-generic* linux-image-3.2.0-20-generic* linux-image-3.2.0-21-generic* 0 upgraded, 0 newly installed, 12 to remove and 0 not upgraded. After this operation, 1,801 MB disk space will be freed. ... $ sudo apt-get autoremove -y Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: libcrypto++9 libnekohtml-java linux-headers-3.2.0-21 linux-headers-3.2.0-21-generic linux-headers-3.2.0-22 linux-headers-3.2.0-22-generic linux-headers-3.2.0-23 linux-headers-3.2.0-23-generic 0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded. After this operation, 207 MB disk space will be freed. This cleaned out 2GB of old kernels and headers on my system. If we can decide on an appropriate package where this can land, I'm happy to clean it up and push it there. Otherwise, it can ship in bikeshed or in its own standalone package. Note, I'd *love* to SRU this to older supported Ubuntu's, once this lands in Quantal. Cheers! :-Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On Mon, Feb 20, 2012 at 03:27:33PM +0100, Martin Pitt wrote: > Tim Edwards [2012-02-17 11:49 +0100]: > > On Fri, Feb 17, 2012, at 07:23 AM, Martin Pitt wrote: > > > linux-headers-* is already covered by apt-get autoremove, which is > > > good. Perhaps we can mark older kernels as auto-removable as well, so > > > that without any other tools you at least have one command to clean > > > them up all? > > > > Are you sure about this? I did a test and I don't think that autoremove > > removes the linux-headers-*: > > I'm 100% sure that this worked in the past, but apparently that > changed at some point. Indeed autoremove does not seem to do this any > more now. > > Martin I think it only every removed the common architecture headers package automatically, so when you remove the -16-generic package, the -16 package will autoremove. -apw -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
Tim Edwards [2012-02-17 11:49 +0100]: > On Fri, Feb 17, 2012, at 07:23 AM, Martin Pitt wrote: > > linux-headers-* is already covered by apt-get autoremove, which is > > good. Perhaps we can mark older kernels as auto-removable as well, so > > that without any other tools you at least have one command to clean > > them up all? > > Are you sure about this? I did a test and I don't think that autoremove > removes the linux-headers-*: I'm 100% sure that this worked in the past, but apparently that changed at some point. Indeed autoremove does not seem to do this any more now. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On Fri, Feb 17, 2012 at 08:29:08AM +0100, Vincent Ladeuil wrote: > > Martin Pitt writes: > > > > > I think it'd be best if update-manager would auto-remove all kernel > > packages except the most recent two or three during dist-upgrade. This > > needs to be specified carefully of course, as people might explicitly > > run a kernel from the previous distro release. So perhaps some > > clevernes like if you install linux-image-3.2.0-N-generic, delete all > > kernels up to linux-image-3.2.0-(N-2)-generic. > > My own use case here is that I had to work around a bug in newer kernels > by running a very old one for *months*, I don't have the precise number > anymore but I think I had at least 5 or 6 kernels newer than the only > one I could use. Having 5 or so kernels would also be handy for troubleshooting drm bugs; once and a while we have to have the user boot earlier kernels to bracket when a regression started. It's not a huge issue though; we can always just have them download older kernels. But if they're already on disk it makes troubleshooting a bit more convenient. > Is there a way to know the last time a kernel was booted and use that as > a criteria to keep it ? > > This will allow removing kernels unused for months limiting the risks > that we remove a vital one. Time of last boot, and/or total number of times booted would be interesting metrics. For fallback purposes I'd love to hang onto a old known-good kernel that I'd booted a hundred times, rather than the one from last week which may well have the same bug I'm trying to get around. But maybe this is overthinking things. ;-) Bryce -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
> Martin Pitt writes: > I think it'd be best if update-manager would auto-remove all kernel > packages except the most recent two or three during dist-upgrade. This > needs to be specified carefully of course, as people might explicitly > run a kernel from the previous distro release. So perhaps some > clevernes like if you install linux-image-3.2.0-N-generic, delete all > kernels up to linux-image-3.2.0-(N-2)-generic. My own use case here is that I had to work around a bug in newer kernels by running a very old one for *months*, I don't have the precise number anymore but I think I had at least 5 or 6 kernels newer than the only one I could use. Is there a way to know the last time a kernel was booted and use that as a criteria to keep it ? This will allow removing kernels unused for months limiting the risks that we remove a vital one. Vincent -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
Server guys (me included) will only ask that whatever's the default in grub be kept. That, and maybe 2 latest kernel excluding the default. Server guys are also (usually) much more aware with what's going on, so for them they would appreciate a tool that will: * List all kernels (and their baggages) found in /boot * Protect the current default in grub * Show which 2 other kernels are recommended/protected * Provide a way to protect other kernels explicitly * Delete the useless kernels (and their baggage) automatically. Rgds, On Feb 17, 2012 1:25 PM, "Martin Pitt" wrote: > Dustin Kirkland [2012-02-16 10:11 -0600]: > > I don't want to go into all the ways and reasons that the one-liner > > above is sub-optimal or even evil, but I would like to call attention > > to the generic problem and suggest that as a distribution, we provide > > a supported and recommended utility to handle this. > > I agree. Especially since we switched to a two-weeks kernel update > rhythm where almost every update in the most recent stable and LTS > releases breaks ABI, kernels pile up like mad. > > > 1) Surely we're not the only Ubuntu users whose /boot or root > > partition has filled up with age-old kernels, are we? > > Certainly not. I ran into several "home support" cases where Ubuntu > started acting strangely because the root partition filled up, and we > removed about 15 old kernels. > > > 2) Is computer-janitor here to stay, or to be abandoned in favor of > > something else? > > 3) Can we expect computer-janitor to work on command-line only > > environments (Ubuntu servers) too? If so, can we get SRUs out so that > > it works on older distributions? > > TBH, I don't think c-j or any other manual tool is the right answer > here. While it's nice to have it, it doesn't feel right that Ubuntu > "automatically" introduces the problem, but not automatically clean > up after itself. > > > 4) Can we, as a distro, provide and recommend a utility to clean out > > specifically old kernels (perhaps aside from cleaning up userspace > > cruft a la computer-janitor)? > > I think it'd be best if update-manager would auto-remove all kernel > packages except the most recent two or three during dist-upgrade. This > needs to be specified carefully of course, as people might explicitly > run a kernel from the previous distro release. So perhaps some > clevernes like if you install linux-image-3.2.0-N-generic, delete all > kernels up to linux-image-3.2.0-(N-2)-generic. > > linux-headers-* is already covered by apt-get autoremove, which is > good. Perhaps we can mark older kernels as auto-removable as well, so > that without any other tools you at least have one command to clean > them up all? > > For servers it'd be even better if apt-get dist-upgrade would do the > cleanup itself, of course. But we have fewer places to hook into the > logic than in update-manager, so this might be tricky. > > Martin > > -- > Martin Pitt| http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) > > -- > ubuntu-server mailing list > ubuntu-ser...@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-server > More info: https://wiki.ubuntu.com/ServerTeam > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On Fri, Feb 17, 2012, at 07:23 AM, Martin Pitt wrote:
> linux-headers-* is already covered by apt-get autoremove, which is
> good. Perhaps we can mark older kernels as auto-removable as well, so
> that without any other tools you at least have one command to clean
> them up all?
Are you sure about this? I did a test and I don't think that autoremove
removes the linux-headers-*:
$ dpkg -l | awk '/^ii/{print $2}' | grep ^linux
linux-firmware
linux-generic
linux-headers-3.0.0-14
linux-headers-3.0.0-14-generic
linux-headers-3.0.0-15
linux-headers-3.0.0-15-generic
linux-headers-3.0.0-16
linux-headers-3.0.0-16-generic
linux-headers-generic
linux-image-3.0.0-15-generic
linux-image-3.0.0-16-generic
linux-image-generic
linux-libc-dev
linux-sound-base
$ sudo apt-get autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 10 not upgraded.
I'd like to suggest instead the following modifications to the script
that was posted before:
#!/bin/bash
OLDKERNEL=$(ls -tr /boot/vmlinuz-* | head -n -2 | cut -d- -f2- | awk
'{print "linux-image-" $0}')
OLDHEADERS=$(ls -tr /boot/vmlinuz-* | head -n -2 | cut -d- -f2- | sed
's/-generic//g' | awk '{print "linux-headers-" $0}')
if [ -n "$OLDKERNEL" -o -n "$OLDHEADERS" ]; then
sudo apt-get -q remove --purge $OLDKERNEL $OLDHEADERS
fi
(note that this version is not fully automatic as apt will prompt the
user before removing packages)
Tim
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On 17.02.2012 07:23, Martin Pitt wrote: > Dustin Kirkland [2012-02-16 10:11 -0600]: >> I don't want to go into all the ways and reasons that the one-liner >> above is sub-optimal or even evil, but I would like to call attention >> to the generic problem and suggest that as a distribution, we provide >> a supported and recommended utility to handle this. > > I agree. Especially since we switched to a two-weeks kernel update > rhythm where almost every update in the most recent stable and LTS > releases breaks ABI, kernels pile up like mad. > >> 1) Surely we're not the only Ubuntu users whose /boot or root >> partition has filled up with age-old kernels, are we? > > Certainly not. I ran into several "home support" cases where Ubuntu > started acting strangely because the root partition filled up, and we > removed about 15 old kernels. > >> 2) Is computer-janitor here to stay, or to be abandoned in favor of >> something else? >> 3) Can we expect computer-janitor to work on command-line only >> environments (Ubuntu servers) too? If so, can we get SRUs out so that >> it works on older distributions? > > TBH, I don't think c-j or any other manual tool is the right answer > here. While it's nice to have it, it doesn't feel right that Ubuntu > "automatically" introduces the problem, but not automatically clean > up after itself. > >> 4) Can we, as a distro, provide and recommend a utility to clean out >> specifically old kernels (perhaps aside from cleaning up userspace >> cruft a la computer-janitor)? > > I think it'd be best if update-manager would auto-remove all kernel > packages except the most recent two or three during dist-upgrade. This > needs to be specified carefully of course, as people might explicitly > run a kernel from the previous distro release. So perhaps some > clevernes like if you install linux-image-3.2.0-N-generic, delete all > kernels up to linux-image-3.2.0-(N-2)-generic. > While agreeing that it would be quite helpful and seems appropriate to have the cleanup automatic, there is a slight potential pitfall (or two). There are various flavours of kernels and people may or may not deliberately have those installed in parallel. Also various releases had sometimes a changing set of depending packages. For a while this should be only linux-backports-modules (there had been linux-ubuntu-modules and linux-restricted-modules). Though this is not so much of a problem. >From a pattern matching point of view the generic-pae kernels are a bit of a pain as they tend to ruin the "use the last part of a split by "-" for the flavor". But anyway, I think the main issue is the various flavours, so a cleanup that is automatic should retain the last three of each, even though this may tend to leave more kernels around. -Stefan > linux-headers-* is already covered by apt-get autoremove, which is > good. Perhaps we can mark older kernels as auto-removable as well, so > that without any other tools you at least have one command to clean > them up all? > > For servers it'd be even better if apt-get dist-upgrade would do the > cleanup itself, of course. But we have fewer places to hook into the > logic than in update-manager, so this might be tricky. > > Martin > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
Dustin Kirkland [2012-02-16 10:11 -0600]: > I don't want to go into all the ways and reasons that the one-liner > above is sub-optimal or even evil, but I would like to call attention > to the generic problem and suggest that as a distribution, we provide > a supported and recommended utility to handle this. I agree. Especially since we switched to a two-weeks kernel update rhythm where almost every update in the most recent stable and LTS releases breaks ABI, kernels pile up like mad. > 1) Surely we're not the only Ubuntu users whose /boot or root > partition has filled up with age-old kernels, are we? Certainly not. I ran into several "home support" cases where Ubuntu started acting strangely because the root partition filled up, and we removed about 15 old kernels. > 2) Is computer-janitor here to stay, or to be abandoned in favor of > something else? > 3) Can we expect computer-janitor to work on command-line only > environments (Ubuntu servers) too? If so, can we get SRUs out so that > it works on older distributions? TBH, I don't think c-j or any other manual tool is the right answer here. While it's nice to have it, it doesn't feel right that Ubuntu "automatically" introduces the problem, but not automatically clean up after itself. > 4) Can we, as a distro, provide and recommend a utility to clean out > specifically old kernels (perhaps aside from cleaning up userspace > cruft a la computer-janitor)? I think it'd be best if update-manager would auto-remove all kernel packages except the most recent two or three during dist-upgrade. This needs to be specified carefully of course, as people might explicitly run a kernel from the previous distro release. So perhaps some clevernes like if you install linux-image-3.2.0-N-generic, delete all kernels up to linux-image-3.2.0-(N-2)-generic. linux-headers-* is already covered by apt-get autoremove, which is good. Perhaps we can mark older kernels as auto-removable as well, so that without any other tools you at least have one command to clean them up all? For servers it'd be even better if apt-get dist-upgrade would do the cleanup itself, of course. But we have fewer places to hook into the logic than in update-manager, so this might be tricky. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On 16 February 2012 20:21, Barry Warsaw wrote: > On Feb 16, 2012, at 10:11 AM, Dustin Kirkland wrote: > >>I asked about this in IRC yesterday, and Colin Watson pointed me to >>the computer-janitor utility, which is intended to handle this. >>Seconds later, Barry Warsaw told me that computer-janitor should die >>:-) > > c-j needs attention, but I'm not particularly motivated to give it what it > needs. There's basic housekeeping, such as that the code for c-j is sprinkled > between the update-manager and the computer-janitor packages, and even more > important problems such LP: #458872. What's demotivating though is that in > all the discussions we've had about the tool, most people think it's just not > user-friendly enough given today's emphasis on software-center. You should also note that Ubuntu Tweak has its own Janitor tool included. This tool is quite popular among desktop users. Regards, -- # Przemysław Kulczycki ## Jabber/XMPP/Gtalk/Tlen ID: azrael[na]jabster.pl -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Feb 16, 2012, at 03:34 PM, Dustin Kirkland wrote: >Yeah, something like this, perhaps with a uname -r check, to also >exclude the current kernel you're running, which apparently *is* known >to work. > >Regarding computer-janitor and the dbus discussion -- I certainly like >the idea of computer-janitor in general, but I think I agree with >Barry that it feels much more like a desktop than a server solution. > >I guess what I would like to see is to take perhaps Kees' script as a >starting point, improve upon that logic slightly, and ship it within >Ubuntu as a consistent, supported, recommended mechanism for vacuuming >out unneeded kernels. Something like 'remove-old-kernels', perhaps >shipping in computer-janitor, or ideally more pervasive. In order to >be useful, though, we'd need to make that script available to >installed systems via SRU. > >Barry, would you be willing to accept a shell script along these >lines, into computer-janitor, if I cleaned it up and proposed a merge >and shepherded it through the SRU process? Or, is there a better home >we can agree upon? Dustin, try to see if you can make it work within c-j's plugin framework. I don't think it would be too difficult. You can see some examples in the computer-janitor package, but the base classes actually live in the update-manager package (yes, this is one of those odd bookkeeping bugs I was talking about). Cheers, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPPYSbAAoJEBJutWOnSwa/uPAP/1kOXIWsTWmo+e2ZjOn189i7 uSXC5JVeqS8NGrJ3mhF8U/WPmgDNUzN7G3tMD2FmtDOVesI1WsMyRp2XrFzonu9o xsPJYsdzxai0+ZZ7Imv6h6EM1yoyd3AV4dC0LbFTsauEx1InYpa0bNawi8GFIIRm QdJTlIX5E139Faaw5GsG+zoab850I8myTElNc+azL1btCP5LiNsQ5Fx5FXJ/2Y87 IXh3RJ8MByQHnLlefSOjiXI3FRCorpy3DoUzclU2MBxFInaZxmMSssaacN4DP09n OHfsr2TDujph/X0u3M8ngSyDTXaCe+AtMWv63blyGZ6kloAi0u9v4uH+atx0OZuH XUBvUJgkS8l1EDkRfo/jlos00UfSEpeL5xGI6JJRMXj8uZVZw/MSVjronMkIVqR+ Vo5RF274g4S9XoWkZU0RGLNhNZygcJxGxJWfCQm2WPmtUZp1hsOyfY37b4QXZ3hX F8UodzQhtePw7e2tvmpQzaadCjaKnT6pybOCu2Nlq3q8/BvEh2rF0PS0DMhA5xnb LxuKjlaqi1HC5uOSIZHR+g3BYdpH9pTrMafXFdiQilUur5kHV5wGfKNwYI0+WC+D xGbIdcyFx3JbQK1xmtlrm7Y+5GY1oPCmC8f9s1utL7PoT78yFh9QMJL+Z9ohxdFn jCROl1px2Q5u1mUNFv9b =KN6q -END PGP SIGNATURE- -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On Thu, 2012-02-16 at 15:40 -0500, Barry Warsaw wrote: > The real question as to the future of c-j is whether it's even the right > approach to cleaning up your system. If so, then maybe a bit of engineering > to clean it up, better separate the backend from the dbus, ui, and cli > interfaces, and package it in a better way would be worth it. Ideally, something like this should be hooked up to apt, with an appropriate config option somewhere among the unattended upgrades or autoremove settings. Do we keep a successful boot flag for each kernel somewhere? It would be nice if the tool kept the currently running kernel, and the 3-5 previous kernels that have successfully booted. Marc. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Feb 16, 2012 at 2:31 PM, Kees Cook wrote:
> On Thu, Feb 16, 2012 at 02:21:18PM -0500, Barry Warsaw wrote:
>> On Feb 16, 2012, at 10:11 AM, Dustin Kirkland wrote:
>> >I asked about this in IRC yesterday, and Colin Watson pointed me to
>> >the computer-janitor utility, which is intended to handle this.
>> >Seconds later, Barry Warsaw told me that computer-janitor should die
>> >:-)
>>
>> c-j needs attention, but I'm not particularly motivated to give it what it
>> needs. There's basic housekeeping, such as that the code for c-j is
>> sprinkled
>> between the update-manager and the computer-janitor packages, and even more
>> important problems such LP: #458872. What's demotivating though is that in
>> all the discussions we've had about the tool, most people think it's just not
>> user-friendly enough given today's emphasis on software-center.
>
> FWIW, this is the highly advanced system I use for my auto-updated VMs. It
> keeps the latest 2 kernels:
>
> OLD=$(ls -tr /boot/vmlinuz-* | head -n -2 | cut -d- -f2- | \
> awk '{print "linux-image-" $0}')
> if [ -n "$OLD" ]; then
> apt-get -qy remove --purge $OLD
> fi
>
> Be warned, of course, that if you don't reboot often, you can end up
> removing the kernel you're running. :P
Yeah, something like this, perhaps with a uname -r check, to also
exclude the current kernel you're running, which apparently *is* known
to work.
Regarding computer-janitor and the dbus discussion -- I certainly like
the idea of computer-janitor in general, but I think I agree with
Barry that it feels much more like a desktop than a server solution.
I guess what I would like to see is to take perhaps Kees' script as a
starting point, improve upon that logic slightly, and ship it within
Ubuntu as a consistent, supported, recommended mechanism for vacuuming
out unneeded kernels. Something like 'remove-old-kernels', perhaps
shipping in computer-janitor, or ideally more pervasive. In order to
be useful, though, we'd need to make that script available to
installed systems via SRU.
Barry, would you be willing to accept a shell script along these
lines, into computer-janitor, if I cleaned it up and proposed a merge
and shepherded it through the SRU process? Or, is there a better home
we can agree upon?
- --
:-Dustin
Dustin Kirkland
Ubuntu Core Developer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBCgAGBQJPPXZdAAoJEJXmQ3PxUpRpLaUP/0WaUkIv2keM+ajQ4WTaCIi5
2pLc3Y5Jeds2/TLqMBKxdlx6M/Hh1wuUaIxYBB3d/nELYKCXbeCxiADfaBraRiet
PbPxooNKti3sbVc/vrgpu8oC54E8vb5Jc8d4zPr0qDcnKNMzHGPbxA78z8MlR+TQ
vqAPcmZcvKF9jUESvrdkYd9pefaLsFludHSwLjt2Dw7+SPsyOrXRBLw8FConBzoV
CHZXiI+FyKaMANwsHVX/2O+RrcpsCgwahQpCEjBFghumR09xTI4ONRpfgqzBDSuN
SSdVTvVCC56ZJ15ufJGCaRVWY7ESTq8deuODnD5/4xIKyVetJtZigPenGLB6N81l
eRtM9brTQAgdLgJ/BDr6TxIibwmgEzJp/EEKDC3tHvd2I7ZJZJ5WqYoyFMdtJRnh
Rwsdt9iEbqIn2pv677rGMpQjldgrAIwBPu+EqgCIbCMTse0/s5oATxhP/953fBB5
S14J+PTSOQh4FwHuzjcyMMdtltQyvjAXRZwm989MvblGcABck0nNMH1VJqIDR7ke
ujI+5kYeQGDszeddFhy8qtyqAyPj8hpyzgnDzh+5kQdtftMv8Qvci8tuxAvqNjI2
473WDq2RcqKXFI/hMT63Z44dkxzsht8NXwI1ksR8643fT/owsSZiKzwdxUCgWyyD
7ETOc6yNLB/Gs7o2t7z9
=lFFF
-END PGP SIGNATURE-
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On Feb 16, 2012, at 03:16 PM, Scott Kitterman wrote: >On Thursday, February 16, 2012 12:07:58 PM Steve Langasek wrote: >> On Thu, Feb 16, 2012 at 12:04:03PM -0800, Steve Langasek wrote: >> > Bear in mind that dbus is not running on servers by default. So that >> > would be a fine solution for the desktop, but there's a larger >> > architectural decision to confront there if we think that should be the >> > solution on servers as well. >> >> Evan Broder has set me straight here that we *are* installing dbus by >> default, and I see that it's part of the 'standard' task in precise. So >> nevermind. :) > >Right, but that doesn't make it a good thing. > >DBus is a desktop technology and I don't think there's a compelling use case >for adding this additional complexity to servers. > >Myself, I'd prefer it go away. I'm not clear why it was added. I don't have a particularly strong opinion about whether dbus should or should not be installed on servers, but given that c-j was originally intended (and maybe still is ) as a desktop application, I think it makes sense that it's implemented as a dbus client/server. It certainly improved some usability problems in the past. Having said that, the dbus service is a fairly thin wrapper around the backend library, although that latter isn't really well suited to be used as a library atm. I think it could be with a bit of work though. The real question as to the future of c-j is whether it's even the right approach to cleaning up your system. If so, then maybe a bit of engineering to clean it up, better separate the backend from the dbus, ui, and cli interfaces, and package it in a better way would be worth it. Cheers, -Barry -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On Thu, Feb 16, 2012 at 02:21:18PM -0500, Barry Warsaw wrote:
> On Feb 16, 2012, at 10:11 AM, Dustin Kirkland wrote:
> >I asked about this in IRC yesterday, and Colin Watson pointed me to
> >the computer-janitor utility, which is intended to handle this.
> >Seconds later, Barry Warsaw told me that computer-janitor should die
> >:-)
>
> c-j needs attention, but I'm not particularly motivated to give it what it
> needs. There's basic housekeeping, such as that the code for c-j is sprinkled
> between the update-manager and the computer-janitor packages, and even more
> important problems such LP: #458872. What's demotivating though is that in
> all the discussions we've had about the tool, most people think it's just not
> user-friendly enough given today's emphasis on software-center.
FWIW, this is the highly advanced system I use for my auto-updated VMs. It
keeps the latest 2 kernels:
OLD=$(ls -tr /boot/vmlinuz-* | head -n -2 | cut -d- -f2- | \
awk '{print "linux-image-" $0}')
if [ -n "$OLD" ]; then
apt-get -qy remove --purge $OLD
fi
Be warned, of course, that if you don't reboot often, you can end up
removing the kernel you're running. :P
-Kees
--
Kees Cook
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On Thu, Feb 16, 2012 at 14:16, Scott Kitterman wrote: > On Thursday, February 16, 2012 12:07:58 PM Steve Langasek wrote: > > On Thu, Feb 16, 2012 at 12:04:03PM -0800, Steve Langasek wrote: > > > Bear in mind that dbus is not running on servers by default. So that > > > would be a fine solution for the desktop, but there's a larger > > > architectural decision to confront there if we think that should be the > > > solution on servers as well. > > > > Evan Broder has set me straight here that we *are* installing dbus by > > default, and I see that it's part of the 'standard' task in precise. So > > nevermind. :) > > Right, but that doesn't make it a good thing. > > DBus is a desktop technology and I don't think there's a compelling use > case > for adding this additional complexity to servers. > > Myself, I'd prefer it go away. I'm not clear why it was added. > > Scott K > > Perhaps it was pulled in because of upstart's support for dbus? ( http://upstart.ubuntu.com/wiki/DBusInterface) -- Mario Limonciello supe...@ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On Thursday, February 16, 2012 12:07:58 PM Steve Langasek wrote: > On Thu, Feb 16, 2012 at 12:04:03PM -0800, Steve Langasek wrote: > > Bear in mind that dbus is not running on servers by default. So that > > would be a fine solution for the desktop, but there's a larger > > architectural decision to confront there if we think that should be the > > solution on servers as well. > > Evan Broder has set me straight here that we *are* installing dbus by > default, and I see that it's part of the 'standard' task in precise. So > nevermind. :) Right, but that doesn't make it a good thing. DBus is a desktop technology and I don't think there's a compelling use case for adding this additional complexity to servers. Myself, I'd prefer it go away. I'm not clear why it was added. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On Thu, Feb 16, 2012 at 12:04:03PM -0800, Steve Langasek wrote: > Bear in mind that dbus is not running on servers by default. So that would > be a fine solution for the desktop, but there's a larger architectural > decision to confront there if we think that should be the solution on > servers as well. Evan Broder has set me straight here that we *are* installing dbus by default, and I see that it's part of the 'standard' task in precise. So nevermind. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On Thu, Feb 16, 2012 at 02:21:18PM -0500, Barry Warsaw wrote: > In c-j 2.0, I worked to separate the backend functionality into a dbus > service, with gtk and command-line front-ends. I looked at the > debian/changelog to refresh my memory, and that implies the work was done > during the Lucid cycle, but I think we ended up not landing it until after > that LTS release, since my Lucid VM still has c-j 1.13.3. Bear in mind that dbus is not running on servers by default. So that would be a fine solution for the desktop, but there's a larger architectural decision to confront there if we think that should be the solution on servers as well. I personally think we should bite the bullet and run dbus on servers as well, but the server folks may disagree. ;) In any event, there are other places where lack of dbus is already causing suffering on the server, such as with upstart bash-completion support. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On Feb 16, 2012, at 10:11 AM, Dustin Kirkland wrote: >I asked about this in IRC yesterday, and Colin Watson pointed me to >the computer-janitor utility, which is intended to handle this. >Seconds later, Barry Warsaw told me that computer-janitor should die >:-) c-j needs attention, but I'm not particularly motivated to give it what it needs. There's basic housekeeping, such as that the code for c-j is sprinkled between the update-manager and the computer-janitor packages, and even more important problems such LP: #458872. What's demotivating though is that in all the discussions we've had about the tool, most people think it's just not user-friendly enough given today's emphasis on software-center. In c-j 2.0, I worked to separate the backend functionality into a dbus service, with gtk and command-line front-ends. I looked at the debian/changelog to refresh my memory, and that implies the work was done during the Lucid cycle, but I think we ended up not landing it until after that LTS release, since my Lucid VM still has c-j 1.13.3. In theory though, this would allow the c-j functionality to be used by any dbus-aware application, so we could fairly easily ditch the current ui (which itself needs love), and improve the cleaning algorithms underneath. >I tried computer-janitor on my desktop, and it seemed to work >okay. But then I tried it on my servers and it failed: > # sudo computer-janitor find > ERROR:dbus.proxies:Introspect error on :1.3:/: >dbus.exceptions.DBusException: >org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 >matched rules; type="method_call", sender=":1.8" (uid=0 pid=26155 >comm="/usr/bin/python /usr/sbin/computer-janitor find ") >interface="org.freedesktop.DBus.Introspectable" member="Introspect" >error name="(unset)" requested_reply="0" destination=":1.3" (uid=0 >pid=19905 comm="/usr/bin/python /usr/share/computerjanitor/janitor") This is probably LP: #715707. You don't say what version of Ubuntu your servers are running, but I'm guessing its Lucid < Dustin < Precise. When I run the cli on Precise, I do see all the old kernels targetted for removal, and I don't get this error. > 1) Surely we're not the only Ubuntu users whose /boot or root >partition has filled up with age-old kernels, are we? Clearly not. > 2) Is computer-janitor here to stay, or to be abandoned in favor of >something else? See above. My own preference would be: * Fix the housekeeping bugs by moving the c-j code out of the u-m tree * Fixing the dbus backend by addressing the relevant known bugs * Keeping the c-j cli for non-ui uses * Throw away the current c-j ui and pull that functionality into u-m or s-c > 3) Can we expect computer-janitor to work on command-line only >environments (Ubuntu servers) too? If so, can we get SRUs out so that >it works on older distributions? It can if the dbus service is running. As for SRUs, would you want to see the dbus-based version backported to Lucid (if that's even possible)? > 4) Can we, as a distro, provide and recommend a utility to clean out >specifically old kernels (perhaps aside from cleaning up userspace >cruft a la computer-janitor)? I think we mostly need to decide whether there's anything to salvage in c-j, which I think mostly means the dbus service. If so, then maybe this is something we can explicitly target for 12.10. Cheers, -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Distro-provided mechanism to clean up old kernels
I understand that I'm not the first to ask this question. In fact, I
see at least 10 similar questions at AskUbuntu.com, and many more
duplicates:
* http://askubuntu.com/search?q=remove+old+kernels
This week, I received a message from one of our commercial ISP/Cloud
Hosting Providers, saying:
>>> Unlike other Linux distributions, Ubuntu does not automatically remove
>>> older, unused kernel packages after an update. Over time, this will fill
>>> the boot partition and result in future updates failing.
The email continued, recommending that we clean up old Ubuntu kernels
using this command:
# dpkg --get-selections|grep 'linux-image*'|awk '{print $1}'|egrep
-v "linux-image-$(uname -r)|linux-image-generic" |while read n;do
apt-get -y remove $n;done
Truly, I connected to several of my Ubuntu servers, some of which have
been running for over 4 years, and I manually purged 3GB+ of old
kernels on some machines!
I don't want to go into all the ways and reasons that the one-liner
above is sub-optimal or even evil, but I would like to call attention
to the generic problem and suggest that as a distribution, we provide
a supported and recommended utility to handle this.
I asked about this in IRC yesterday, and Colin Watson pointed me to
the computer-janitor utility, which is intended to handle this.
Seconds later, Barry Warsaw told me that computer-janitor should die
:-) I tried computer-janitor on my desktop, and it seemed to work
okay. But then I tried it on my servers and it failed:
# sudo computer-janitor find
ERROR:dbus.proxies:Introspect error on :1.3:/:
dbus.exceptions.DBusException:
org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1
matched rules; type="method_call", sender=":1.8" (uid=0 pid=26155
comm="/usr/bin/python /usr/sbin/computer-janitor find ")
interface="org.freedesktop.DBus.Introspectable" member="Introspect"
error name="(unset)" requested_reply="0" destination=":1.3" (uid=0
pid=19905 comm="/usr/bin/python /usr/share/computerjanitor/janitor")
So I guess my questions are:
1) Surely we're not the only Ubuntu users whose /boot or root
partition has filled up with age-old kernels, are we?
2) Is computer-janitor here to stay, or to be abandoned in favor of
something else?
3) Can we expect computer-janitor to work on command-line only
environments (Ubuntu servers) too? If so, can we get SRUs out so that
it works on older distributions?
4) Can we, as a distro, provide and recommend a utility to clean out
specifically old kernels (perhaps aside from cleaning up userspace
cruft a la computer-janitor)?
--
:-Dustin
Dustin Kirkland
Ubuntu Core Developer
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
