Ubuntu

FR: Limit and clean-up kernel images and headers automatically

Reported by Sam_ on 2012-01-30
130
This bug affects 25 people
Affects Status Importance Assigned to Milestone
apt (Ubuntu)
Wishlist
Unassigned
Precise
High
Steve Langasek
Quantal
High
Brian Murray
aptitude (Ubuntu)
Undecided
Unassigned
Precise
Undecided
Unassigned
Quantal
Undecided
Unassigned

Bug Description

Question #186146 is one among multiple where user unintentionally collects multiple kernel images in particular with LTS. There is no hint from relevant package management application GUIs which advise to clean up those images. With future LTS support of five years the issue presumable will extend.
Expected.
After installation of a newer kernel image ask the user if previous kernel images should be removed.
Checkbox: yes - no
If yes, offer a list of installed kernel images, don't list the one booted. Advise to keep at least the last functional one.
Also remove -headers.

Perhaps an additional consideration for the blueprint.
https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-lts-upgrades

There is a new Quantal blueprint regarding the subject.
https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-clean-old-kernels

Sam_ (and-sam) on 2012-01-30
description: updated
Torsten Spindler (tspindler) wrote :

The 'computer-janitor' seems to be designed to take care of old kernels for the user. For me on Precise it offers to remove old kernels.

Changed in apt (Ubuntu):
status: New → Incomplete
Sam_ (and-sam) wrote :

Aside that I wouldn't recommend computer-janitor, Oneiric uds removed it from standard app list, the request wasn't about offereing just another app which may clean-up older kernel images, Synaptic can do the same if a user interacts accordingly.
The removal request should come from the app which is supposed to run the upgrade in order to take users attention.
Although, if the weakness is user interaction, then I'd extend the request to remove kernel images automatically without user interaction, just keep the last two.

Changed in apt (Ubuntu):
status: Incomplete → New
Torsten Spindler (tspindler) wrote :

I do believe linux-image packages are excluded from autoremove on purpose, as specified in debian/apt.conf.autoremove.

Are you requesting a feature for apt where it controls the number of kernels (linux-image*) installed in parallel?

Sam_ (and-sam) wrote :

Yes Torsten, apt should interact with the user in order to keep the number of kernel images rational.
I've looked at manpages and couldn't find specific notes about linux-images and autoremove.
It autoremoves linux-headers although not very clever, at the moment it would remove linux-headers-3.2.0-16 but not -15.

I've confirmed the problem, especially with LTS. I've set the importance to wishlist as there are manual ways to work around this limitation in apt.

summary: - Limit and clean-up kernel images and headers automatically in LTS
+ FR: Limit and clean-up kernel images and headers automatically in LTS
Changed in apt (Ubuntu):
status: New → Confirmed
importance: Undecided → Wishlist
Sam_ (and-sam) on 2012-09-15
description: updated
tags: added: precise quantal

APT has good reason to not autoremove kernels, why you want to break that?

You want *some* process to reap old kernels, ok, but that does not
mean that the core package manager should be that process. The
selection of which kernels to clean up is domain-specific. Determine
such a list external to apt and use apt-get remove (not autoremove) to
dispose.

At the very least, if you insist on using markauto + autoremove, do
not make this the default. Your external process should invoke apt
with a custom configuration where APT::NeverAutoRemove does not
contain the entries blocking the desired autoremoval. Use APT_CONFIG
envvar and/or apt-get -c.

I think this is being worked on for quantal, see https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-clean-old-kernels

In the meantime here's a script that calls apt-get to remove all but the current kernel and the 1 most recent before that.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apt - 0.9.7.6ubuntu1

---------------
apt (0.9.7.6ubuntu1) raring; urgency=low

  [ Michael Vogt ]
  * merged from debian-sid

  [ Program translation updates ]
  * Catalan (Jordi Mallach)
  * Drop a confusing non-breaking space. Closes: #691024
  * Thai (Theppitak Karoonboonyanan). Closes: #691613

  [ David Kalnischkies ]
  * apt-pkg/packagemanager.cc:
    - do not do lock-step configuration for a M-A:same package if it isn't
      unpacked yet in SmartConfigure and do not unpack a M-A:same package
      again in SmartUnPack if we have already configured it (LP: #1062503)

  [ Steve Langasek ]
  * debian/apt.conf.autoremove: don't include linux-image*,
    linux-restricted-modules*, and linux-ubuntu-modules* packages in the
    list to never be autoremoved.
  * debian/apt.auto-removal.sh, debian/rules, debian/apt.dirs: install new
    script to /etc/kernel/postinst.d/ which ensures we only automatically
    keep the currently-running kernel, the being-installed kernel, and the
    newest kernel, so we don't fill /boot up with an unlimited number of
    kernels. LP: #923876.

apt (0.9.7.6) unstable; urgency=low

  [ Program translation updates ]
  * Ukrainian (A. Bondarenko)

  [ David Kalnischkies ]
  * apt-pkg/pkgcachegen.cc:
    - ensure that dependencies for packages:none are always generated
    - add 2 missing remap registrations causing a segfault in case
      we use the not remapped iterators after a move of the mmap again
    - write the native architecture as unique string into the cache header
      as it is used for arch:all packages as a map to arch:native.
      Otherwise arch comparisons later will see differences (Closes: #689323)
  * apt-pkg/pkgcache.cc:
    - ignore negative dependencies applying in the same group for M-A:same
      packages on the real package name as self-conflicts (Closes: #688863)
  * cmdline/apt-cache.cc:
    - print versioned dependency relations in (r)depends if the option
      APT::Cache::ShowVersion is true (default: false) as discussed in
      #218995 to help debian-cd fixing #687949. Thanks to Sam Lidder
      for initial patch and Steve McIntyre for nagging and testing!
  * apt-pkg/edsp.cc:
    - include reinstall requests and already installed (= protected) packages
      in the install-request for external resolvers (Closes: #689331)
  * apt-pkg/policy.cc:
    - match pins with(out) an architecture as we do on the commandline
      (partly fixing #687255, b= support has to wait for jessie)
  * apt-pkg/contrib/netrc.cc:
    - remove the 64 char limit for login/password in internal usage
    - remove 256 char line limit by using getline() (POSIX.1-2008)

  [ Colin Watson ]
  * apt-pkg/pkgcachegen.cc:
    - Fix crash if the cache is remapped while writing a Provides version
      (LP: #1066445).
 -- Michael Vogt <email address hidden> Tue, 06 Nov 2012 15:12:36 +0100

Changed in apt (Ubuntu):
status: Confirmed → Fix Released
Steve Langasek (vorlon) on 2013-02-06
Changed in apt (Ubuntu Precise):
importance: Undecided → Medium
Changed in apt (Ubuntu Quantal):
importance: Undecided → High
Changed in apt (Ubuntu Precise):
importance: Medium → High
assignee: nobody → Adam Conrad (adconrad)
Changed in apt (Ubuntu Quantal):
assignee: nobody → Adam Conrad (adconrad)
Adam Conrad (adconrad) on 2013-02-11
Changed in apt (Ubuntu Precise):
status: New → In Progress
Changed in apt (Ubuntu Quantal):
status: New → In Progress

Hello Sam_, or anyone else affected,

Accepted apt into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/apt/0.8.16~exp12ubuntu10.8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in apt (Ubuntu Precise):
status: In Progress → Fix Committed
tags: added: verification-needed
Changed in apt (Ubuntu Quantal):
status: In Progress → Fix Committed
Colin Watson (cjwatson) wrote :

Hello Sam_, or anyone else affected,

Accepted apt into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/apt/0.9.7.5ubuntu5.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

  * debian/apt.conf.autoremove: don't include linux-image*,
    linux-restricted-modules*, and linux-ubuntu-modules* packages in the
    list to never be autoremoved.

Aptitude in Precise and later (and earlier) carries a patch that potentially nullifies this change. Previously the patch was redundant (see bug #1053776), now it will prevent this "fix" from being effective for users of aptitude.

The file 05aptitude configures an aptitude option that has similar effect to apt's never autoremove setting.

Daniel Hartwig (wigs) wrote :

See also bug #1033838 for justification that 05aptitude should be completely removed.

Johan Kiviniemi (ion) wrote :

When updating to apt 0.9.7.5ubuntu5.3, no /etc/apt/apt.conf.d/01autoremove-kernels was generated and apt-get autoremove would uninstall all kernel versions but the latest from my system.

Running /etc/kernel/postinst.d/apt-auto-removal 3.5.0-24-generic manually generated the file.

Johan Kiviniemi (ion) on 2013-02-20
tags: added: verification-failed
removed: verification-needed
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in aptitude (Ubuntu Precise):
status: New → Confirmed
Changed in aptitude (Ubuntu Quantal):
status: New → Confirmed
Changed in aptitude (Ubuntu):
status: New → Confirmed
Tony Pursell (ajpursell) wrote :

I too can confirm that updating apt to the new version in precise-proposed does not result in the removal of unwanted kernels.

Steve Langasek (vorlon) wrote :

Reuploaded to precise with a change to manually call the kernel postinst hook script on upgrade.

Changed in apt (Ubuntu Precise):
status: Fix Committed → In Progress
assignee: Adam Conrad (adconrad) → Steve Langasek (vorlon)

Hello Sam_, or anyone else affected,

Accepted apt into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/apt/0.8.16~exp12ubuntu10.9 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in apt (Ubuntu Precise):
status: In Progress → Fix Committed
tags: removed: verification-failed
tags: added: verification-needed

If I don't want old kernels to be removed automatically when installing this package what should I do? Is there a dialog now asking which kernels to remove or not?

Michael Wisheu (wisheu) wrote :

Fabri, with this change kernel packages aren't automatically removed.
The difference is that with the new apt package older kernel packages are now listed as autoremovable.

This means that when everything plays well that apt notifies you on install, remove, upgrade, ... which older kernel packages are autoremovable. In order to remove them you have to manually run 'apt-get autoremove'.

Fabri Velas (fabrivelas) wrote :

Thanks Michael, it works. Kernel packages are listed by autoremove, while they were not before installing this package.

tags: added: verification-done
removed: verification-needed
Brian Murray (brian-murray) wrote :

Fabri with which release does this work for you?

Fabri Velas (fabrivelas) wrote :

Sorry, it works for precise
Linux 3.5.0-26-generic #40~precise1-Ubuntu SMP Thu Feb 28 13:48:15 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Michael Wisheu (wisheu) wrote :

If there is more need for verification please let me know and I'll try to find time to verify it for the missing releases.

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

This bug was fixed in the package apt - 0.8.16~exp12ubuntu10.9

---------------
apt (0.8.16~exp12ubuntu10.9) precise-proposed; urgency=low

  [ David Kalnischkies ]
  * apt-pkg/depcache.cc:
    - prefer to install packages which have an already installed M-A:same
      sibling while choosing providers (LP: #1130419)

  [ Steve Langasek ]
  * Invoke /etc/kernel/postinst.d/apt-auto-removal directly on upgrade for
    bug #923876, so that an 'apt-get autoremove' run before any new kernel
    packages have been installed gives the expected behavior.

apt (0.8.16~exp12ubuntu10.8) precise; urgency=low

  * Backport kernel auto-removal/retention policy from raring (LP: #923876)
    - debian/apt.auto-removal.sh, debian/rules, debian/apt.dirs: Add new
      script to /etc/kernel/postinst.d/ that ensures we always retain the
      currently-running, being-installed, and newest-installed kernels.
    - debian/apt.conf.autoremove: don't include linux-restricted-modules*,
      linux-image*, and linux-ubuntu-modules* in the never-removed list.
 -- Steve Langasek <email address hidden> Sat, 02 Mar 2013 20:22:43 +0000

Changed in apt (Ubuntu Precise):
status: Fix Committed → Fix Released
Fabri Velas (fabrivelas) wrote :

I don't know what I have done, but today I noticed that the old linux kernels listed in the 'auto removable' section in synaptic have gone (they are still installed, though). The only thing listed now is two linux-headers-3.5.0-22* files. I still have the headers for 23, 24, 25 and 26 and the corresponding linux images.

Michael Wisheu (wisheu) wrote :

Can someone please give an update on the change needed to the aptitude package?
From my point of view it still contains offending lines as pointed out in comment https://bugs.launchpad.net/ubuntu/+source/apt/+bug/923876/comments/11.

Current state of /etc/apt/apt.conf.d/05aptitude:
aptitude::Keep-Unused-Pattern "^linux-image.*$ | ^linux-restricted-modules.*$ | ^linux-ubuntu-modules.*$";
aptitude::Get-Root-Command "sudo:/usr/bin/sudo";

But /etc/apt/apt.conf.d/05aptitude should contain only:
aptitude::Get-Root-Command "sudo:/usr/bin/sudo";

John Karahalis (openjck) wrote :

On Quantal, this does not appear to solve the problem described in bug #1131512. My boot partition still becomes full after some kernel upgrades. If not handled before the next reboot, this can make the system un-bootable.

Steve Langasek (vorlon) wrote :

> On Quantal, this does not appear to solve the problem described in bug #1131512.

If you use update-manager to install updates, there is a remaining issue with aptdaemon causing all updates to be marked as manually installed, preventing apt's autoremoval from doing the right thing. (This may be fixed now in raring, I'm not sure and don't have the bug number in front of me; see the bug list for the aptdaemon package to confirm.)

> If not handled before the next reboot, this can make the
> system un-bootable.

This should never happen, and would be an entirely separate bug. The kernel *update* may fail, but the old, successfully installed kernel would still be available and should be the default in the bootloader configuration.

On 11 May 2013 10:58, Steve Langasek <email address hidden> wrote:
>> On Quantal, this does not appear to solve the problem described in bug
> #1131512.
>
> If you use update-manager to install updates, there is a remaining issue
> with aptdaemon causing all updates to be marked as manually installed,
> preventing apt's autoremoval from doing the right thing. (This may be
> fixed now in raring, I'm not sure and don't have the bug number in front
> of me; see the bug list for the aptdaemon package to confirm.)

Bug #1078544. Fixed in Quantal with
aptdaemon=0.45+bzr861-0ubuntu9.1.2. Any kernels installed while that
bug was active need to be manually removed or marked auto-installed.

A similar problem with kernel images marked as manually installed was
reported recently when using unattended-upgrades, but has not been
confirmed. Bug #1175637.

Redoubts (redoubts) on 2013-06-16
tags: added: raring
Daniel Hartwig (wigs) wrote :

Untested and dont care.

John Karahalis (openjck) wrote :

Still have this issue on a fresh install of Raring. And as others say, this is especially problematic for those of us with an encrypted setup, as the /boot partition fills up very quickly, causing software upgrades to fail. This problem can only be solved by manually removing old kernels, and I suspect the average user will not think to do this.

Tim Fisher (k2trf) wrote :

Can confirm @John's statement - exists for me in Raring as well.

Updating to reflect occurance in Raring as well.

On 21 June 2013 02:09, John Karahalis <email address hidden> wrote:
> Still have this issue on a fresh install of Raring.

Note that kernel images installed before this change was made in apt
0.9.7.6ubuntu1 will still have to be removed manually. If you find
that subsequent kernel images are not cleaned up, then please file a
new report using ‘ubuntu-bug’. Such report should contain details of
how the system is updated, such as whether you use any of apt-get,
unattended-upgrades, update-manager, aptitude, etc..

On 21 June 2013 05:00, Tim Fisher <email address hidden> wrote:
> Can confirm @John's statement - exists for me in Raring as well.

Likewise.

Always file regression reports as new issues that can be investigated
individually.

Daniel Hartwig (wigs) wrote :

apt 0.9.7.5ubuntu5.4

Changed in apt (Ubuntu Quantal):
status: Fix Committed → Fix Released

Unsubscribing sponsors. Someone please check the aptitude update out and we can apply it if it works.

Iain Lane (laney) wrote :

(re-subscribe sponsors in that case)

Brian Murray (brian-murray) wrote :

This fix did not make it into Quantal.

apt (0.9.7.5ubuntu5.4) quantal-security; urgency=low

  * SECURITY UPDATE: InRelease verification bypass
    - CVE-2013-1051
  * This package does _not_ contain the changes from 0.9.7.5ubuntu5.3 in
    quantal-proposed.

Changed in apt (Ubuntu Quantal):
status: Fix Released → In Progress
assignee: Adam Conrad (adconrad) → Brian Murray (brian-murray)

Hello Sam_, or anyone else affected,

Accepted apt into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/apt/0.9.7.5ubuntu5.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in apt (Ubuntu Quantal):
status: In Progress → Fix Committed
tags: removed: verification-done
tags: added: verification-needed

I tested this in a quantal virtual machine that was running kernel 3.5.0-39, by first installing apt from quantal-proposed, then disabling proposed and using 'apt-get dist-upgrade' to install kernel version 3.5.0-40. I then rebooted and enabled proposed again, from which I then used 'apt-get dist-upgrade' to update to kernel version 3.5.0-41. Then I rebooted again and ran 'sudo apt-get autoremove --purge' and did not see kernel version 3.5.0-39 in the list of packages to be removed.

Steve Langasek (vorlon) wrote :

Brian, please show the output of 'apt-mark showauto | grep linux-image-3.5.0-40-generic' from this system.

Steve Langasek (vorlon) wrote :

Note that because 3.5.0-39 was installed using the *old* version of apt, it's actually expected that this version of the kernel won't be marked for autoremoval. 3.5.0-40 is the first version that will be a candidate for autoremoval, and it won't actually be autoremoved in this case because you rebooted to 3.5.0-40 before installing 3.5.0-41... making 3.5.0-40 the "last good" kernel that's being kept.

Brian Murray (brian-murray) wrote :

I followed the same procedure but did not reboot between installing 3.5.0-40 and 3.5.0-41 and then 3.5.0-40 was listed when running 'apt-get autoremove'.

tags: added: verification-done-quantal
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package aptitude - 0.6.8.2-1ubuntu2

---------------
aptitude (0.6.8.2-1ubuntu2) saucy; urgency=low

  * Remove debian/05aptitude:
    - sudo setting is redundant with user-setup (LP: #1033838)
    - Keep-Unused-Pattern setting is redundant with apts NeverAutoRemove,
      which conflicts with an apt update to permit autoremoval of old kernel
      images (LP: #923876, #1053776)
    - Thanks to Daniel Hartwig for the patch.
    - Remove 05aptitude from debian/aptitude.install
 -- Brian Murray <email address hidden> Mon, 23 Sep 2013 17:05:47 -0700

Changed in aptitude (Ubuntu):
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apt - 0.9.7.5ubuntu5.5

---------------
apt (0.9.7.5ubuntu5.5) quantal; urgency=low

  * Backport kernel auto-removal/retention policy from raring (LP: #923876)
    - debian/apt.auto-removal.sh, debian/rules, debian/apt.dirs: Add new
      script to /etc/kernel/postinst.d/ that ensures we always retain the
      currently-running, being-installed, and newest-installed kernels.
    - debian/apt.conf.autoremove: don't include linux-restricted-modules*,
      linux-image*, and linux-ubuntu-modules* in the never-removed list.
  * Fix unhandled If-Modified-Since case that causes apt lists corruption.
    LP: #1179781
 -- Dave Chiluk <email address hidden> Wed, 21 Aug 2013 13:14:06 -0500

Changed in apt (Ubuntu Quantal):
status: Fix Committed → Fix Released
shinyblue (shinyblue) wrote :

Why is this bug marked fixed for Precise? And how can this bug be "fixed" for Quantal which is not LTS? The point of the bug title is that LTS is the one that this bug refers to because over 5 years the kernels will really accumulate.

So I don't see how it can be fixed until it's fixed such that those of us on LTS get the old kernels cleaned up simply by running the updates.

Confused.

Steve Langasek (vorlon) wrote :

This is marked fixed because the bug that was preventing kernels from being marked as ok to clean up *in the future* has been resolved. This doesn't change the fact that kernels which were previously marked as not-auto-installed are still marked that way on the system; there's no way to safely undo that. Users who care about this will still need to remove the old kernels on a one-time basis.

And it's fixed in quantal because there's nothing LTS-specific about the problem, the problem is just more severe in an LTS. Fixed the bug description accordingly.

summary: - FR: Limit and clean-up kernel images and headers automatically in LTS
+ FR: Limit and clean-up kernel images and headers automatically
Bruno Medeiros (brunojcm) wrote :

Is it supposed to work on linux-generic-lts-* packages? It's not working for me.

Still not clear for me why this is marked as for "Precise" while it is only fixed for "Quantal"?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints