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

Bug #923876 reported by Sam_
162
This bug affects 31 people
Affects Status Importance Assigned to Milestone
apt (Ubuntu)
Fix Released
Wishlist
Unassigned
Precise
Fix Released
High
Steve Langasek
Quantal
Fix Released
High
Brian Murray
aptitude (Ubuntu)
Fix Released
Undecided
Unassigned
Precise
Won't Fix
Undecided
Unassigned
Quantal
Won't Fix
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)
description: updated
Revision history for this message
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
Revision history for this message
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
Revision history for this message
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?

Revision history for this message
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.

Revision history for this message
Torsten Spindler (tspindler) wrote : Re: FR: Limit and clean-up kernel images and headers automatically in LTS

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)
description: updated
tags: added: precise quantal
Revision history for this message
Daniel Hartwig (wigs) wrote : Re: [Bug 923876] Re: FR: Limit and clean-up kernel images and headers automatically in LTS

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.

Revision history for this message
Tim Edwards (tkedwards) wrote : Re: FR: Limit and clean-up kernel images and headers automatically in LTS

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.

Revision history for this message
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)
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)
Changed in apt (Ubuntu Precise):
status: New → In Progress
Changed in apt (Ubuntu Quantal):
status: New → In Progress
Revision history for this message
Colin Watson (cjwatson) wrote : Please test proposed package

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
Revision history for this message
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!

Revision history for this message
Daniel Hartwig (wigs) wrote : Re: FR: Limit and clean-up kernel images and headers automatically in LTS

  * 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.

Revision history for this message
Daniel Hartwig (wigs) wrote :

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

Revision history for this message
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)
tags: added: verification-failed
removed: verification-needed
Revision history for this message
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
Revision history for this message
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.

Revision history for this message
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)
Revision history for this message
Adam Conrad (adconrad) wrote : Please test proposed package

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
Revision history for this message
Fabri Velas (fabrivelas) wrote : Re: FR: Limit and clean-up kernel images and headers automatically in LTS

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?

Revision history for this message
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'.

Revision history for this message
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
Revision history for this message
Brian Murray (brian-murray) wrote :

Fabri with which release does this work for you?

Revision history for this message
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

Revision history for this message
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.

Revision history for this message
Chris Halse Rogers (raof) wrote : Update Released

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.

Revision history for this message
Launchpad Janitor (janitor) wrote : Re: FR: Limit and clean-up kernel images and headers automatically in LTS

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
Revision history for this message
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.

Revision history for this message
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";

Revision history for this message
Anonymous (unquoteveracity-deactivatedaccount) 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.

Revision history for this message
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.

Revision history for this message
Daniel Hartwig (wigs) wrote : Re: [Bug 923876] Re: FR: Limit and clean-up kernel images and headers automatically in LTS

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.

Revision history for this message
Redoubts (redoubts) wrote : Re: FR: Limit and clean-up kernel images and headers automatically in LTS
Redoubts (redoubts)
tags: added: raring
Revision history for this message
Daniel Hartwig (wigs) wrote :

Untested and dont care.

Revision history for this message
Anonymous (unquoteveracity-deactivatedaccount) 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.

Revision history for this message
Tim Fisher (k2trf) wrote :

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

Updating to reflect occurance in Raring as well.

Revision history for this message
Daniel Hartwig (wigs) wrote : Re: [Bug 923876] Re: FR: Limit and clean-up kernel images and headers automatically in LTS

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.

Revision history for this message
Daniel Hartwig (wigs) wrote :

apt 0.9.7.5ubuntu5.4

Changed in apt (Ubuntu Quantal):
status: Fix Committed → Fix Released
Revision history for this message
Iain Lane (laney) wrote : Re: FR: Limit and clean-up kernel images and headers automatically in LTS

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

Revision history for this message
Iain Lane (laney) wrote :

(re-subscribe sponsors in that case)

Revision history for this message
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)
Revision history for this message
Steve Langasek (vorlon) wrote : Please test proposed package

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
Revision history for this message
Brian Murray (brian-murray) wrote : Re: FR: Limit and clean-up kernel images and headers automatically in LTS

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.

Revision history for this message
Steve Langasek (vorlon) wrote :

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

Revision history for this message
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.

Revision history for this message
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
Revision history for this message
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
Revision history for this message
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
Revision history for this message
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.

Revision history for this message
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
Revision history for this message
Bruno Medeiros (brunojcm) wrote :

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

Revision history for this message
Stanislav German-Evtushenko (giner) wrote :

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

Revision history for this message
Rolf Leggewie (r0lf) wrote :

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".

Changed in aptitude (Ubuntu Quantal):
status: Confirmed → Won't Fix
Revision history for this message
Sebastian Schlatow (buzz-dee) wrote :
Download full text (25.5 KiB)

I also have this bug.:

~$ dpkg -l | grep -i linux
ii dmsetup 2:1.02.77-6ubuntu2 i386 Linux Kernel Device Mapper userspace library
ii eject 2.1.5+deb1+cvs20081104-13.1 i386 ejects CDs and operates CD-Changers under Linux
ii fonts-lklug-sinhala 0.6-3 all Unicode Sinhala font by Lanka Linux User Group
ii hplip 3.14.3-0ubuntu3.2 i386 HP Linux Printing and Imaging System (HPLIP)
ii hplip-data 3.14.3-0ubuntu3.2 all HP Linux Printing and Imaging - data files
ii iw 3.4-1 i386 tool for configuring Linux wireless devices
ii kbd 1.15.5-1ubuntu1 i386 Linux console font and keytable utilities
ii keyutils 1.5.6-1 i386 Linux Key Management Utilities
ii kmod 15-0ubuntu6 i386 tools for managing Linux kernel modules
ii libaio1:i386 0.3.109-4 i386 Linux kernel AIO access library - shared library
ii libbluetooth3:i386 4.101-0ubuntu13 i386 Library to use the BlueZ Linux Bluetooth stack
ii libdevmapper-event1.02.1:i386 2:1.02.77-6ubuntu2 i386 Linux Kernel Device Mapper event support library
ii libdevmapper1.02.1:i386 2:1.02.77-6ubuntu2 i386 Linux Kernel Device Mapper userspace library
ii libhyphen0 2.8.6-3ubuntu2 i386 ALTLinux hyphenation library - shared library
ii libkeyutils1:i386 1.5.6-1 i386 Linux Key Management Utilities (library)
ii libpci3:i386 1:3.2.1-1ubuntu5 i386 Linux PCI Utilities (shared library)
ii libsctp1:i386 1.0.15+dfsg-1 i386 user-space access to Linux Kernel SCTP - shared library
ii libselinux1:i386 2.2.2-1ubuntu0.1 i386 SELinux runtime shared libraries
ii libsemanage-common 2.2-1 all Common files for SELinux...

Revision history for this message
Sebastian Schlatow (buzz-dee) wrote :
Revision history for this message
Jarno Suni (jarnos) wrote :

As for apt, does the fix offered to this bug mean that you can upgrade by
sudo apt-get dist-upgrade
and have no fear of /boot getting full?

Anyway, I suppose this method of upgrading will work now for the issue in Trusty and later:
sudo apt-get dist-upgrade --auto-remove --purge

sudo apt-get autoremove
may also remove other packages besides old kernels and related packages, but maybe that is not bad thing.

If I install a kernel manually by `apt-get install`, it will be marked as "manual", and will not be removed by `apt-get autoremove`, unless I run `apt-mark auto` for it first. Isn't is bad to skip removing any manually installed kernels? Would it be better to skip only kernels marked as "hold"?

Revision history for this message
Jarno Suni (jarnos) wrote :

For another thing, original bug reporter Sam_ seems to be after the ability of GUI package managers to handle removing old kernels. Current fix does not seem to fix the issue with e.g. update-manager. There is another bug report about it: Bug #1389620
Also unattended-upgrades are involved: Bug #1054927

Revision history for this message
Pxtl (pxtl) wrote :

I'm still running out of space in /boot in 16.04

Revision history for this message
Sam_ (and-sam) wrote :

I'm still on 14.04 and will upgrade to 16.04 when the offer arrives.
I still purge older kernel manually via terminal since they don't get removed automatically.
@pxtl I'd recommend to open a new bug with a hint to this one.

Revision history for this message
Jarno Suni (jarnos) wrote :

Pxtl, in 16.04 the bug is fixed according to Bug #1357093. Please comment there, if you believe it is not the case. I can not reopen the bug anymore, but you may want to report a new bug against unattended-upgrades and link it here.

Revision history for this message
Steve Langasek (vorlon) wrote :

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release

Changed in aptitude (Ubuntu Precise):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.