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-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
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-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
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-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
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-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
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-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
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-server@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-server > More info: https://wiki.ubuntu.com/ServerTeam > -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
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-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Distro-provided mechanism to clean up old kernels
Quoting Kees Cook (k...@ubuntu.com):
> 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
Clean. I wrote this little perlscript which i hook from APT:
https://8n1.org/raw/8337/e0ec
At my workplace we manage >150 servers for customers, this saved us a
lot of space in backups and on the physical serves. For what it's worth,
i don't think Ubuntu should introduce dbus services just to clean up
kernels.
Ubuntu Server installs are bloated enough as it is.
But that's just my 25 cents.
-Sander.
--
| If you think nobody cares, try missing a couple of payments.
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2
--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
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-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Distro-provided mechanism to clean up old kernels
On Thu, Feb 16, 2012 at 03:36:31PM -0600, Dustin Kirkland wrote: > On Thu, Feb 16, 2012 at 3:08 PM, Craig White wrote: > > this was interesting but I found that I had to NOT use 'head -n -2' but > > rather 'head -n 2' > > You can do 'head -2' or 'head -n2', but not 'head -n -2'. I assumed > it was a typo ;-) Hurm? -n -2 is perfectly valid. It shows "all but the N first lines": -n, --lines=[-]N print the first N lines instead of the first 10; with the leading `-', print all but the last N lines of each file $ seq 1 5 | xargs -n1 | head -2 1 2 $ seq 1 5 | xargs -n1 | head -n 2 1 2 $ seq 1 5 | xargs -n1 | head -n -2 1 2 3 -Kees -- Kees Cook -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
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-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Distro-provided mechanism to clean up old kernels
On Thu, Feb 16, 2012 at 3:08 PM, Craig White wrote: > this was interesting but I found that I had to NOT use 'head -n -2' but > rather 'head -n 2' You can do 'head -2' or 'head -n2', but not 'head -n -2'. I assumed it was a typo ;-) -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
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-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
Re: Distro-provided mechanism to clean up old kernels
this was interesting but I found that I had to NOT use 'head -n -2' but rather
'head -n 2'
Craig
On Feb 16, 2012, at 1: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
>
> -Kees
>
> --
> Kees Cook
>
> --
> ubuntu-server mailing list
> ubuntu-server@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
> More info: https://wiki.ubuntu.com/ServerTeam
--
Craig White ~ craig.wh...@ttiltd.com
1.800.869.6908 ~~ www.ttiassessments.com
Need help communicating between generations at work to achieve your desired
success? Let us help!
--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
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-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
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-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
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-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
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-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Distro-provided mechanism to clean up old kernels
On 2012-02-16 18:11, Dustin Kirkland wrote:
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!
[...]
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?
Nope. I have the same problem. I'm managing a couple of LTSP servers
(with 10.04 LTS on them) and I saved around 400MB on the compressed
image file after I purged all the kernels and reinstalled the last one
(and deleted a lot of generated nbi.img files which remained after
purging the kernels).
There are also old linux-headers-* packages which can take up a lot of
space.
--
Imre Gergely
http://havaz.net
gpg --keyserver subkeys.pgp.net --recv-keys 0x34525305
--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
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-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
