"Unattended-Upgrade::Remove-Unused-Dependencies" does not work

[Nils Toedtmann]

I have a system that runs unattended-upgrades just fine. Now i want to automate removal of old kernels and kernel header packages that are accumulating otherwise. So i set 'Unattended-Upgrade::Remove-Unused-Dependencies "true";'. But it doesn't work.

----
Details: Lots of stuff pending autoremoval:

$ apt-get --assume-no autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED
  linux-headers-3.2.0-38 linux-headers-3.2.0-38-generic linux-headers-3.2.0-39 linux-headers-3.2.0-39-generic linux-headers-3.2.0-40 linux-headers-3.2.0-40-generic linux-headers-3.2.0-41 linux-headers-3.2.0-41-generic linux-headers-3.2.0-43 linux-headers-3.2.0-43-generic linux-headers-3.2.0-44 linux-headers-3.2.0-44-generic linux-headers-3.2.0-45 linux-headers-3.2.0-45-generic linux-headers-3.2.0-48 linux-headers-3.2.0-48-generic linux-headers-3.2.0-51 linux-headers-3.2.0-51-generic linux-headers-3.2.0-52 linux-headers-3.2.0-52-generic linux-headers-3.2.0-53 linux-headers-3.2.0-53-generic linux-headers-3.2.0-54 linux-headers-3.2.0-54-generic linux-headers-3.2.0-55 linux-headers-3.2.0-55-generic linux-headers-3.2.0-56 linux-headers-3.2.0-56-generic linux-image-3.2.0-39-generic linux-image-3.2.0-40-generic linux-image-3.2.0-41-generic linux-image-3.2.0-43-generic linux-image-3.2.0-44-generic linux-image-3.2.0-45-generic linux-image-3.2.0-48-generic linux-image-3.2.0-51-generic linux-image-3.2.0-52-generic linux-image-3.2.0-53-generic linux-image-3.2.0-54-generic linux-image-3.2.0-55-generic linux-image-3.2.0-56-generic
0 upgraded, 0 newly installed, 41 to remove and 13 not upgraded.
After this operation, 2,893 MB disk space will be freed.
Do you want to continue [Y/n]? N
Abort.

Note that the majority of these packages have been installed by unattended-upgrades from precise-security.

According to the comments within/etc/apt/apt.conf.d/50unattended-upgrades, this should automate autoremoval:

  // Do automatic removal of new unused dependencies after the upgrade
  // (equivalent to apt-get autoremove)
  Unattended-Upgrade::Remove-Unused-Dependencies "true";

but nothing happens (note the line "Packages that are auto removed: '' ":

$ unattended-upgrades --debug --dry-run
Initial blacklisted packages:
Starting unattended upgrades script
Allowed origins are: ['o=Ubuntu,a=precise-security']
adjusting candidate version: '<Version: package:'accountsservice' version:'0.6.15-2ubuntu9.6.1'>'
adjusting candidate version: '<Version: package:'libaccountsservice0' version:'0.6.15-2ubuntu9.6.1'>'
adjusting candidate version: '<Version: package:'libdrm-intel1' version:'2.4.43-0ubuntu0.0.3'>'
adjusting candidate version: '<Version: package:'libdrm-nouveau1a' version:'2.4.43-0ubuntu0.0.3'>'
adjusting candidate version: '<Version: package:'libdrm-radeon1' version:'2.4.43-0ubuntu0.0.3'>'
adjusting candidate version: '<Version: package:'libdrm2' version:'2.4.43-0ubuntu0.0.3'>'
Checking: bc (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'gb.archive.ubuntu.com' isTrusted:True>"])
Checking: grub-common (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'gb.archive.ubuntu.com' isTrusted:True>"])
Checking: grub-pc (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'gb.archive.ubuntu.com' isTrusted:True>"])
Checking: grub-pc-bin (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'gb.archive.ubuntu.com' isTrusted:True>"])
Checking: grub2-common (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'gb.archive.ubuntu.com' isTrusted:True>"])
Checking: iproute (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'gb.archive.ubuntu.com' isTrusted:True>"])
Checking: landscape-common (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'gb.archive.ubuntu.com' isTrusted:True>"])
pkgs that look like they should be upgraded:
Fetched 0 B in 0s (0 B/s)
blacklist: []
Packages that are auto removed: ''
InstCount=0 DelCount=0 BrokenCout=0
No packages found that can be upgraded unattended

----
I am using unattended-upgrades-0.76ubuntu1 on Ubuntu 12.04.3 LTS

[Nils Toedtmann (m-launchpad-net-mail-nils-toedtmann-net)]

I had a quick glance at /usr/bin/unattended-upgrade, and it looks like that Unattended-Upgrade::Remove-Unused-Dependencies only autoremoves dependancies that have become auto-removeable during *this* very run of unattended-upgrade! Anything that had already been auto-removeable before invokation of /usr/bin/unattended-upgrade will not get autoremoved by unattended-upgrade.

(See lists "pkgs_auto_removable" set in line 706, "now_auto_removable" set in line 817, and only their difference being autoremoved in line 819)

Is that correct?

If this is the intended functionality of Unattended-Upgrade::Remove-Unused-Dependencies, then this is not a bug with unattended-upgrade, but with its documentation. /etc/apt/apt.conf.d/50unattended-upgrades says

    // Do automatic removal of new unused dependencies after the upgrade
    // (equivalent to apt-get autoremove)
    Unattended-Upgrade::Remove-Unused-Dependencies "true";

But it's actually only equivalent to apt-get autoremove if there was nothing to be autoremoved beforehand. That should be clarified.

[Launchpad Janitor (janitor)]

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

[Lars Heide (l-heide-deactivatedaccount)]

This thing seems to be broken in 2 ways (on 12.04 at least):

A) Its checking internally for the wrong variable ( now_auto_removable-pkgs_auto_removable instead of now_auto_removable-pkgs) :
Do this and it will actually tell you the packages that are to be removed.

B) It does not actually remove the packages because there is no call to cache.commit()

I have included a patch. I don't know if there is some intended behaviour this is breaking though.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "correct variable and issue commit" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Lars Heide (l-heide-deactivatedaccount)]

Actually I just saw that it is semi fixed in 14.04 in the way that

now_auto_removable-pkgs_auto_removable

now reads

now_auto_removable - pkgs_auto_removable

which is also wrong, as

now_auto_removable = set([pkg.name for pkg in cache
                                  if pkg.is_auto_removable])
and

pkgs_auto_removable = set([pkg.name for pkg in cache
                               if pkg.is_auto_removable])

are apparently the same, therefore substracting them from each other is always empty.

[Lars Heide (l-heide-deactivatedaccount)]

I checked and apparently now_auto_removable and pkgs_auto_removable are always the same, as "is_auto_removable" only returns different results _after_ the packages have actually been upgraded. Just marking them does apparently not change the output of is_auto_removable(). I tried to use the ProblemResolver but I didn't get the output of is_auto_removable() to change.

One possible solution is to actually upgrade the packages and then check for autoremovability, then you can make it works as intended. My original patch implemented only an autoremove (same as "apt-get autoremove").

[urusha (urusha)]

Lars Heide, your patch works great for me, I think it should be applied upstream. But some people may find "differential" behavior (now_auto_removable-pkgs_auto_removable) safer. Then the right solution may be: implementing logic described in #7 (in addition to patch from #4) with adding new config option like "Remove-Unused-Dependencies-NewOnly".

[the2nd (the2nd)]

same problem here. ubuntu 12.04.

is there any fix for this available?

[Chris Case (morgul)]

This is a pretty big issue, as installing Ubuntu server with the defaults will always create a boot partition, and enabling automatic updates (which is desirable from a security standpoint) means that every few weeks kernel updates start failing because the old kernels haven't been removed.

I would very much like to see what seems like a simple problem fixed. This effects every single ubuntu VM at my work (of which we have about 80), and is incredibly annoying to have to deal with.

[Nils Toedtmann (m-launchpad-net-mail-nils-toedtmann-net)]

Note that situation #1089195 is another possible outcome of this bug.

[Apreche (apreche)]

I can confirm what Nils Toedtmann says. I discovered this bug precisely because I encountered situation #1089195. This is a serious issue for any production servers as you want them to get automatic security updates, but running out of inodes will simply bring them down. I don't know why this hasn't been fixed in over a year. It's an extremely serious problem.

[JohnWashington (ubuntu-johnwash)]

Apreche: you say it's a serious issue, and I agree with you. Allegedly, if I look at the stats at the top of the page, this affects me and 34 other users. Though I'm betting that's just the tip of the iceberg.

Informal discussions reveal that bugs need to have thousands indicating it affects them before they're likely to get attention. So either don't hold your breath or find a way to get more visibility. :(

Or find a developer you can get interested?

[Nathaniel W. Turner (nturner)]

This bug is serious (it causes filesystems to fill up on pretty much every production server that doesn't have a huge root fs).
It has a reasonable looking patch that fixes the problem.
I don't think there is anything to discuss other than: How do we get the fix into Ubuntu?

[JohnWashington (ubuntu-johnwash)]

@Nathaniel: does http://packaging.ubuntu.com/html/fixing-a-bug.html help?

[Jamie (jamiejellicoe)]

This is ridiculous, why has this not been fixed yet?

I manage around 100 VM's and this problem is causing me serious headaches. I simply haven't got time to go round manually autoremoving old kernals and it would be foolish not to leave unattended security updates on.

Just because there are only ~34 people who have bothered to write on this thread does not mean that others with 13.04 or greater are not affected, I think most will be eventually.

It is correct to say that the documentation is wrong; Unattended-Upgrade::Remove-Unused-Dependencies "true"; is not currently equivalent to apt-get autoremove but that is the expected behaviour (I imagine most people who install ubuntu don't want to have to consider how to remove old kernals so this should be the default behaviour)

[Jamie (jamiejellicoe)]

P.s. How is this bug not classed as a security risk? When /boot is full no more security updates can be installed (when the owner of the machine is lead to believe they are still being installed)

[Nils Toedtmann (m-launchpad-net-mail-nils-toedtmann-net)]

Each day this bug breaks more Ubuntu servers that do unattended-upgrades, in particular cloud servers with <<100GB rootfs. I alone have a few dozens affected machines.

And it's not totally trivial for Admin Average to diagnose the inode shortage, realize it's flooded with linux-headers packages, and to convince apt-get (potentially stuck in 'broken dependancies') to clean up.

I think this is more impartant than "medium", at least for Precise/LTS.

[Alexander Skiba (ghostlyrics)]

I've patched the packages for Precise, Trusty and Debian Wheezy. Although it's been done in a very ugly and quite sloppy way I can provide the patches.

[Ingolf Becker (ingolf.becker)]

For some reason the unattended upgrades script is very picky about which packages are to be removed. It tries to auto-remove only those packages that have been made redundant by the current set of updates. However, installing a new kernel does not make any previous kernel version redundant automatically - a separate script (/etc/kernel/postinst.d/apt-auto-removal) is run after kernel upgrades that marks all but the two most recent kernels as 'auto-removable'.

I am not sure that the current behaviour can be described as expected or intended - the original author clearly does not trust that what apt thinks is unused (and therefore removable) is unused in reality. He is trying to work around the possibility of having `apt-get auto-remove` break running systems.

Really, there should be two changes: Change the documentation for `Remove-Unused-Dependencies`, and adding a switch that will always remove kernels that have been marked as `auto-removable`. For those people that are happy to have `apt-get auto-remove` automatically, there is the `APT::Periodic::AutocleanInterval` variable in /etc/apt/apt.conf.d/10periodic. (Which should really be documented too...)

[Alexander Skiba (ghostlyrics)]

In regard to #20:

I've submitted a pull request that *changes the default behavior* of `Remove-Unused-Dependencies` to remove *all* orphaned packages, here: https://github.com/mvo5/unattended-upgrades/pull/6/files (1 week as of this comment)

I've not received any feedback on this yet, though - neither if it is okay like this nor if I should've used another parameter for auto-cleaning all orphaned packages.

[Lars Heide (l-heide-deactivatedaccount)]

APT::Periodic::AutocleanInterval is kinda documented in /etc/cron.daily/apt

# APT::Periodic::AutocleanInterval "0";
# - Do "apt-get autoclean" every n-days (0=disable)

From what I read from the code, it does just that. According to the man page "autoclean clears out the local repository of retrieved package files".

In what way is that equivalent to "autoremove"?

Besides: The original authors intent "to auto-remove only those packages that have been made redundant by the current set of updates" fails. Please see comment #7:

The author checks for auto-removable packages, then marks the new packages as "to install" and then checks again for autoremovable packages and then tries to remove the difference of those two sets. But the two sets are always the same, the resulting set is therefore empty. Without actually installing the new packages, the solver does not return a different set of auto-removable packages.

[Lars Heide (l-heide-deactivatedaccount)]

As there has been confusion about this apparently:

Marking the packages for upgrade

line 1194: "mark_upgrade()"

is not the same as upgrading them. The upgrade only happens after the changes are commited:

line 392: "res = cache.commit(install_progress=iprogress)"

The output of "is_auto_removable" only changes after that AFAIK.

[B. (b-deactivatedaccount-deactivatedaccount)]

I agree with @Jamiejellicoe this ticket should be rated as "Security issue" (250) but we are close that (236)...

Having /boot full can lead to kernel, inird image or grub.conf corruption and
on top of that it's blocking new security updates to be applied.

When /boot is full you cannot even purge old kernel before /boot has a minimum
disk space. So my workaround is to echo -n > /boot/initrd.img- some old kernel's inird images
so I have enough free space to cleanup old kernel, header, etc.

[Travis Odom (travis-a-odom)]

GhostLyrics' upstream patch has been merged (https://github.com/mvo5/unattended-upgrades/pull/6). Anyone know how/when this might flow into Ubuntu and/or get backported?

Right now my servers are running apt-get -y autoremove on a cron job, but I'd love to ditch that.

[Michael Vogt (mvo)]

This is fixed, I plan to do a backport for 14.04 and 12.04 via the trusty-backports, precise-backports mechanism.

[Alexander List (alexlist)]

Did you even consider providing the fix via SRU?

[Alexander List (alexlist)]

So, there is a fix released, but it is still not in backports for trusty... how does that help affected users?

Please backport the fix to all currently supported versions of Ubuntu, and propose it for SRU. Thanks!

[Nick Peelman (peelman)]

Would like to second that this get backported to Trusty and other supported versions.

[Samuel Reed (strml)]

This is causing us issues left and right. Has the backport come through yet? We are still seeing servers fill up disks because of this bug.

[Mikko Pesari (mpesari)]

For what it's worth; I've worked around this by installing the version from wily on some trusty machines. So far so good. The machines upgrade daily and old kernels and their headers are removed.

[Jon Ribbens (jribbens-r)]

Is there any news on this being added as a security update to trusty? I'm beginning to wonder what "LTS" means if a bug that results in every installation of Ubuntu sooner or later ceasing to receive security updates does not get pushed out as part of the security updates.

(As someone else mentioned, "APT::Periodic::AutocleanInterval" does not fix this, that is something completely different.)

[Seth Arnold (seth-arnold)]

mvo, is this suitable for an SRU? Thanks

[Steve Brorens (sbrorens)]

Just chipping in to say that it's very frustrating to see this marked with a status of "Fix released".

Perhaps I'm misunderstanding what that implies, but:

 - all my servers running 14.04 LTS don't have the fix yet - and apparently won't get it unless I take action
 - if I'm reading the above comments right, I have to add trusty-backports to get it (and it may not even *be* in there yet)

Very unsatisfactory and unclear.

I'm advising that for all our servers with this issue that we add the simple "...running apt-get -y auto remove on a cron job..." fix suggested above by Travis. That may be a hack, but seem to me to be safer that enabling backports on production servers.

[Alexander Skiba (ghostlyrics)]

Short version: backports won't work.

Slightly longer version: It's not in trusty-backports, it's not in vivid-(updates|backports), it is however in wily.
(Yes, I am aware that it's not an LTS and therefore not ideal, I have the same situation at work.) Information retrieved on 2015-11-30.

[Nils Toedtmann (m-launchpad-net-mail-nils-toedtmann-net)]

Nice to see that a LTS-killing bug is taken seriously (after 2 years).

What about Precise? It is affected and has still 1.5y to live.

(Though one might argue that any affected Precise machine must be either dead or manually patched by now)

[Steve Brorens (sbrorens)]

It does indeed also apply to Precise (12.04 LTS ), I have clients with a number of these having regular problems with this issue.

[Michael Vogt (mvo)]

I pushed a fix to trusty-proposed, please double check the git diff was a bit unclean. As much testing as possible is appreicated (work for me).

[Brian Murray (brian-murray)]

Hello Nils, or anyone else affected,

Accepted unattended-upgrades into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/unattended-upgrades/0.82.1ubuntu2.4 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!

[Steve Brorens (sbrorens)]

Thanks, I've installed to one of our cloud servers as a test, and will see
if I can get authorisation to the same to some client test and dev servers
next week.

 - steve

BTW: I've popped a comment in bug 1516388
<https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1516388>
 (https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1516388)
because I have a few older servers with the same issue.

On Fri, Dec 4, 2015 at 5:33 AM, Michael Vogt <email address hidden>
wrote:

> I pushed a fix to trusty-proposed, please double check the git diff was
> a bit unclean. As much testing as possible is appreicated (work for me).
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1267059
>
> Title:
> "Unattended-Upgrade::Remove-Unused-Dependencies" does not work
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1267059/+subscriptions
>

[Steve Brorens (sbrorens)]

It's just removed a kernel corrctly, so I've tagged as "confirmed"

[Steve Brorens (sbrorens)]

I'm sure that it's possible to "tag" this as also applying to Precise (12.04) - but it's not clear to me how to do that. Could someone do so, or point me to instructions? Thx

[Shane Synan (digitalcircuit)]

@Steve Brorens: It's actually the little "Tags" section under the bug description and right before the comments that needs edited. Remove 'verification-needed' and add 'verification-done', and that should be it!

If you can, you may want to change "Confirmed" back to "Fix Committed" - that's for confirming the bug exists, not for confirming that a proposed package fixed it. "Fix Committed" means the fix is developed, but hasn't yet passed testing.

Unfortunately, I'm not sure about how to mark this as also affecting Precise.

[Christopher Heuer (cheuer)]

unattended-upgrades updated openssl this morning on two machines that I set to use trusty-proposed, and old kernels were removed properly. Changing status back and edited tag per comment #46.

[Launchpad Janitor (janitor)]

This bug was fixed in the package unattended-upgrades - 0.82.1ubuntu2.4

---------------
unattended-upgrades (0.82.1ubuntu2.4) trusty-proposed; urgency=medium

  * cherry pick fix for unused-dependencies removal (LP: #1267059)

 -- Michael Vogt <email address hidden> Thu, 03 Dec 2015 17:02:17 +0100

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for unattended-upgrades 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 regressions.

[Steve Brorens (sbrorens)]

Could someone with the permissions to do so *please* "Nominate this for series" - tagging it as also applying to 12.04? - as per my comment #45.

I would, but appear not to have sufficient permission. (Oddly the "Nominate this for series" option only shows while I'm logged out).

[Steve Brorens (sbrorens)]

Hi,

I see from https://launchpad.net/~ubuntu-release-nominators that you are
one of those who can do this "Nomination" of 1267059 9as per my recent
comment). If it's not done shortly I will raise a new bug, but that seems a
bit silly...

Thanks,

 - steve

On Fri, Dec 11, 2015 at 9:56 AM, Brian Murray <email address hidden> wrote:

> The verification of the Stable Release Update for unattended-upgrades
> 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 regressions.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1267059
>
> Title:
> "Unattended-Upgrade::Remove-Unused-Dependencies" does not work
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1267059/+subscriptions
>

[Brian Murray (brian-murray)]

Hello Nils, or anyone else affected,

Accepted unattended-upgrades into precise-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/unattended-upgrades/0.76ubuntu1.2 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!

[Felix Barbeira (fbarbeira)]

I tested the version 0.76ubuntu1.2 on a couple of precise VMs and it works fine on both of them:

root@:~# apt-get autoremove -s
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  linux-image-3.2.0-64-generic linux-image-3.2.0-74-generic linux-image-3.2.0-75-generic linux-image-3.2.0-77-generic linux-image-3.2.0-79-generic linux-image-3.2.0-80-generic linux-image-3.2.0-87-generic linux-image-3.2.0-88-generic
  linux-image-3.2.0-90-generic linux-image-3.2.0-91-generic linux-image-3.2.0-92-generic linux-image-3.2.0-94-generic
0 upgraded, 0 newly installed, 12 to remove and 9 not upgraded.
Remv linux-image-3.2.0-64-generic [3.2.0-64.97]
Remv linux-image-3.2.0-74-generic [3.2.0-74.109]
Remv linux-image-3.2.0-75-generic [3.2.0-75.110]
Remv linux-image-3.2.0-77-generic [3.2.0-77.114]
Remv linux-image-3.2.0-79-generic [3.2.0-79.115]
Remv linux-image-3.2.0-80-generic [3.2.0-80.116]
Remv linux-image-3.2.0-87-generic [3.2.0-87.125]
Remv linux-image-3.2.0-88-generic [3.2.0-88.126]
Remv linux-image-3.2.0-90-generic [3.2.0-90.128]
Remv linux-image-3.2.0-91-generic [3.2.0-91.129]
Remv linux-image-3.2.0-92-generic [3.2.0-92.131]
Remv linux-image-3.2.0-94-generic [3.2.0-94.134]
root@~#

This is the log of "unattended-upgrades":

2015-12-18 18:55:24,401 INFO Initial blacklisted packages:
2015-12-18 18:55:24,402 INFO Starting unattended upgrades script
2015-12-18 18:55:24,402 INFO Allowed origins are: ['o=Ubuntu,a=precise-security']
2015-12-18 18:55:27,509 INFO Packages that are upgraded:
2015-12-18 18:55:29,601 INFO Packages that are auto removed: 'linux-image-3.2.0-77-generic linux-image-3.2.0-79-generic linux-image-3.2.0-88-generic linux-image-3.2.0-91-generic linux-image-3.2.0-75-generic linux-image-3.2.0-94-generic linux-image-3.2.0-90-generic linux-image-3.2.0-74-generic linux-image-3.2.0-80-generic linux-image-3.2.0-64-generic linux-image-3.2.0-92-generic linux-image-3.2.0-87-generic'
2015-12-18 18:58:46,711 INFO Packages auto-removed

[Peter Grandi (pg-8)]

Note that this long story started from kernel upgrades, and so far nobody has made an important point...

When you install a new kernel package, you may want to remove all previous versions indeed, *except* the one that is currently running.

Because if you remove the package for the currently running kernel, if you add a new device or do anything that requires loading a module, that will fail. This is because kernel modules by default require an exactly matching kernel version, unlike shared objects or other stuff that gets upgraded. A few other useful things will fail if a running kernel is not matched by an installed package.

This would require extra logic to special-case the kernel packages for this.

[Launchpad Janitor (janitor)]

This bug was fixed in the package unattended-upgrades - 0.76ubuntu1.2

---------------
unattended-upgrades (0.76ubuntu1.2) precise-proposed; urgency=medium

  * cherry pick fix for unused-dependencies removal. (LP: #1267059)

 -- Brian Murray <email address hidden> Fri, 11 Dec 2015 10:06:00 -0800

[B. (b-deactivatedaccount-deactivatedaccount)]

# This will simulate the removal of useless packages linked to old kernels
dpkg --get-selections 'linux-*.*.*-*' | grep $'\t''install' | cut -f1 \
| grep -vF "$(uname -r | cut -d- -f1,2)" \
| grep -vF "$(dpkg --get-selections 'linux-*image*' \
| grep -E '^[^0-9]+'$'\t''install$' | cut -f1 | xargs -r apt-cache depends \
| grep -oE '[0-9.]+-[0-9]+' | sort -u)" | xargs -r apt-get --dry-run purge

[SeanBoran (sean-boran)]

Hi,
I regularly have systems with /boot full due, I believe, to this issue and had an example this morning.

Manually running "apt-get autoremove" deleted kernels+headers for the last 10 kernels or so. How can that be automated?

Above one refers to version .76ubuntu1.2, and I have 0.82.1ubuntu2.3 which sound newer.
have I missed something or are the fixes not yet mainstream in 14.04?
(Just noticed 0.82.1ubuntu2.4 is available too)

Or are the apt settings wrong perhaps:

Unattended-Upgrade::Mail "root@localhost";
Unattended-Upgrade::MailOnlyOnError "true";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::MinimalSteps "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
# install patches automatically, update weekly,
# wipe unused packages after 3 weeks. No report.
APT::Periodic::Enable "1";
APT::Periodic::Update-Package-Lists "7";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "21";
APT::Periodic::Unattended-Upgrade "7";
APT::Periodic::Verbose "0";

Reading https://wiki.debian.org/UnattendedUpgrades https://help.ubuntu.com/lts/serverguide/automatic-updates.html did not help much, are there better sources?

[Alexander Skiba (ghostlyrics)]

@sean-boran, comment #57:

The fix is available in the trusty-updates repository. See this changelog: http://changelogs.ubuntu.com/changelogs/pool/main/u/unattended-upgrades/unattended-upgrades_0.82.1ubuntu2.4/changelog

[Jarno Suni (jarnos)]

Peter Grandi, doesn't unattended-updgrades' automatic removal of new unused dependencies take into account file "/etc/apt/apt.conf.d/01autoremove-kernels"? `apt-get autoremove` does. BTW. I think /etc/kernel/postinst.d/apt-auto-removal should be run during boot to ensure that "/etc/apt/apt.conf.d/01autoremove-kernels" protects the running kernel.

[costinel (costinel)]

this bugs says "Precise Fix Released Medium   Brian Murray Edit"

apt-listchanges -a /var/cache/apt/archives/unattended-upgrades_0.76ubuntu1.2_all.deb says

" unattended-upgrades (0.76ubuntu1.2) precise-proposed; urgency=medium

  * cherry pick fix for unused-dependencies removal. (LP: #1267059)

 -- Brian Murray <email address hidden> Fri, 11 Dec 2015 10:06:00 -0800"

first run

root@mailhost:/boot# unattended-upgrades -d --dry-run
Initial blacklisted packages:
Starting unattended upgrades script
Allowed origins are: ['o=Ubuntu,a=precise-security']
adjusting candidate version: '<Version: package:'apt' version:'0.8.16~exp12ubuntu10.21'>'
adjusting candidate version: '<Version: package:'apt-transport-https' version:'0.8.16~exp12ubuntu10.21'>'
adjusting candidate version: '<Version: package:'apt-utils' version:'0.8.16~exp12ubuntu10.21'>'
adjusting candidate version: '<Version: package:'e2fslibs' version:'1.42-1ubuntu2.2'>'
adjusting candidate version: '<Version: package:'e2fsprogs' version:'1.42-1ubuntu2.2'>'
adjusting candidate version: '<Version: package:'libapt-inst1.4' version:'0.8.16~exp12ubuntu10.21'>'
adjusting candidate version: '<Version: package:'libapt-pkg4.12' version:'0.8.16~exp12ubuntu10.21'>'
adjusting candidate version: '<Version: package:'libcomerr2' version:'1.42-1ubuntu2.2'>'
adjusting candidate version: '<Version: package:'libss2' version:'1.42-1ubuntu2.2'>'
adjusting candidate version: '<Version: package:'ntpdate' version:'1:4.2.6.p3+dfsg-1ubuntu3.6'>'
adjusting candidate version: '<Version: package:'update-manager-core' version:'1:0.156.14.5'>'
Checking: dosfstools (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'ro.archive.ubuntu.com' isTrusted:True>"])
Checking: gdisk (["<Origin component:'universe' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'ro.archive.ubuntu.com' isTrusted:True>"])
Checking: libnvpair1 (["<Origin component:'main' archive:'precise' origin:'LP-PPA-zfs-native-daily' label:'ZFS Daily Releases for Ubuntu' site:'ppa.launchpad.net' isTrusted:True>", "<Origin component:'main' archive:'precise' origin:'LP-PPA-zfs-native-stable' label:'ZFS Stable Releases for Ubuntu' site:'ppa.launchpad.net' isTrusted:True>"])
Checking: libudev0 (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'ro.archive.ubuntu.com' isTrusted:True>"])
Checking: libuutil1 (["<Origin component:'main' archive:'precise' origin:'LP-PPA-zfs-native-daily' label:'ZFS Daily Releases for Ubuntu' site:'ppa.launchpad.net' isTrusted:True>", "<Origin component:'main' archive:'precise' origin:'LP-PPA-zfs-native-stable' label:'ZFS Stable Releases for Ubuntu' site:'ppa.launchpad.net' isTrusted:True>"])
Checking: libzfs2 (["<Origin component:'main' archive:'precise' origin:'LP-PPA-zfs-native-daily' label:'ZFS Daily Releases for Ubuntu' site:'ppa.launchpad.net' isTrusted:True>", "<Origin component:'main' archive:'precise' origin:'LP-PPA-zfs-native-stable' label:'ZFS Stable Releases for Ubuntu' site:'ppa.launchpad.net' isTrusted:True>"])
Checking: libzpool2 (["<Origin component:'main' archive:'precise' origin:'LP-PPA-zfs-native-daily' label:'ZFS Daily Releases for...

[costinel (costinel)]

worse, before running unattended-upgrades, apt-get autoremove showed lots of kernels good for removal. after upgrading and running the new unattended-upgrades, apt-get autoremove no longer lists these kernels at fit for autoremove.

[Alexander Skiba (ghostlyrics)]

@costinel: have you made sure you manually set that option to 'true'? It's 'false' by default. For the record, this is what it looks like with a completely fresh vagrant VM for Ubuntu Precise.

vagrant@vagrant-ubuntu-precise-64:~$ sudo unattended-upgrade --debug
Initial blacklisted packages:
Starting unattended upgrades script
Allowed origins are: ['o=Ubuntu,a=precise-security']
adjusting candidate version: '<Version: package:'ntpdate' version:'1:4.2.6.p3+dfsg-1ubuntu3.6'>'
Checking: ca-certificates (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'archive.ubuntu.com' isTrusted:True>", "<Origin component:'main' archive:'precise-security' origin:'Ubuntu' label:'Ubuntu' site:'security.ubuntu.com' isTrusted:True>"])
Checking: cpio (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'archive.ubuntu.com' isTrusted:True>", "<Origin component:'main' archive:'precise-security' origin:'Ubuntu' label:'Ubuntu' site:'security.ubuntu.com' isTrusted:True>"])
Checking: libc-bin (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'archive.ubuntu.com' isTrusted:True>", "<Origin component:'main' archive:'precise-security' origin:'Ubuntu' label:'Ubuntu' site:'security.ubuntu.com' isTrusted:True>"])
Checking: libc-dev-bin (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'archive.ubuntu.com' isTrusted:True>", "<Origin component:'main' archive:'precise-security' origin:'Ubuntu' label:'Ubuntu' site:'security.ubuntu.com' isTrusted:True>"])
Checking: libc6 (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'archive.ubuntu.com' isTrusted:True>", "<Origin component:'main' archive:'precise-security' origin:'Ubuntu' label:'Ubuntu' site:'security.ubuntu.com' isTrusted:True>"])
Checking: libc6-dev (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'archive.ubuntu.com' isTrusted:True>", "<Origin component:'main' archive:'precise-security' origin:'Ubuntu' label:'Ubuntu' site:'security.ubuntu.com' isTrusted:True>"])
Checking: libgcrypt11 (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'archive.ubuntu.com' isTrusted:True>", "<Origin component:'main' archive:'precise-security' origin:'Ubuntu' label:'Ubuntu' site:'security.ubuntu.com' isTrusted:True>"])
Checking: libgnutls26 (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'archive.ubuntu.com' isTrusted:True>", "<Origin component:'main' archive:'precise-security' origin:'Ubuntu' label:'Ubuntu' site:'security.ubuntu.com' isTrusted:True>"])
Checking: libssl1.0.0 (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'archive.ubuntu.com' isTrusted:True>", "<Origin component:'main' archive:'precise-security' origin:'Ubuntu' label:'Ubuntu' site:'security.ubuntu.com' isTrusted:True>"])
Checking: linux-headers-generic (["<Origin component:'main' archive:'precise-updates' origin:'Ubuntu' label:'Ubuntu' site:'archive.ubuntu.com' isTrusted:True>", "<Origin component:'main' archive:'precise-s...

[costinel (costinel)]

> have you made sure you manually set that option to 'true'? It's 'false' by default.

yes,

root@mailhost:~# grep Dependencies /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Remove-Unused-Dependencies "true";

root@mailhost:~# ls -lht /etc/apt/apt.conf.d/50unattended-upgrades
-rw-r--r-- 1 root root 2.1K May 8 2013 /etc/apt/apt.conf.d/50unattended-upgrades

[costinel (costinel)]

here is another box

oot@wifi:~# eatmydata apt-get install unattended-upgrades
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  bsd-mailx
The following packages will be upgraded:
  unattended-upgrades
1 upgraded, 0 newly installed, 0 to remove and 14 not upgraded.
Need to get 24.8 kB of archives.
After this operation, 4,096 B of additional disk space will be used.
Get:1 http://ro.archive.ubuntu.com/ubuntu/ precise-updates/main unattended-upgrades all 0.76ubuntu1.2 [24.8 kB]
Fetched 24.8 kB in 0s (124 kB/s)
Reading changelogs... Done
apt-listchanges: Mailing root: apt-listchanges: changelogs for wifi
Preconfiguring packages ...
(Reading database ... 293592 files and directories currently installed.)
Preparing to replace unattended-upgrades 0.76ubuntu1.1 (using .../unattended-upgrades_0.76ubuntu1.2_all.deb) ...
Unpacking replacement unattended-upgrades ...
Processing triggers for man-db ...
Processing triggers for ureadahead ...
Setting up unattended-upgrades (0.76ubuntu1.2) ...
root@wifi:~# strace -etrace=file -f unattended-upgrades -d --dry-run > /var/tmp/firstrun.log 2>&1

cat /var/tmp/firstrun.log |pastebinit -b http://paste.ubuntu.com
http://paste.ubuntu.com/15273973/

root@wifi:~# ls /boot
abi-3.13.0-65-generic initrd.img-3.13.0-76-generic
abi-3.13.0-68-generic initrd.img-3.13.0-77-generic
abi-3.13.0-71-generic initrd.img-3.13.0-79-generic
abi-3.13.0-73-generic lost+found
abi-3.13.0-74-generic memtest86+.bin
abi-3.13.0-76-generic memtest86+_multiboot.bin
abi-3.13.0-77-generic System.map-3.13.0-65-generic
abi-3.13.0-79-generic System.map-3.13.0-68-generic
config-3.13.0-65-generic System.map-3.13.0-71-generic
config-3.13.0-68-generic System.map-3.13.0-73-generic
config-3.13.0-71-generic System.map-3.13.0-74-generic
config-3.13.0-73-generic System.map-3.13.0-76-generic
config-3.13.0-74-generic System.map-3.13.0-77-generic
config-3.13.0-76-generic System.map-3.13.0-79-generic
config-3.13.0-77-generic vmlinuz-3.13.0-65-generic
config-3.13.0-79-generic vmlinuz-3.13.0-68-generic
grub vmlinuz-3.13.0-71-generic
initrd.img-3.13.0-65-generic vmlinuz-3.13.0-73-generic
initrd.img-3.13.0-68-generic vmlinuz-3.13.0-74-generic
initrd.img-3.13.0-71-generic vmlinuz-3.13.0-76-generic
initrd.img-3.13.0-73-generic vmlinuz-3.13.0-77-generic
initrd.img-3.13.0-74-generic vmlinuz-3.13.0-79-generic

root@wifi:~# grep LTS /etc/motd
Welcome to Ubuntu 12.04.5 LTS (GNU/Linux 3.13.0-77-generic x86_64)

[costinel (costinel)]

> have you made sure you manually set that option to 'true'?

also, if you pay attention to my pasted logs, THE FIRST TIME the updated version is run with -d --dry-run, it DOES mention wanting to remove kernels.
however the second time I run it, without --dry-run, it NO LONGER mentions removing packages!

[Jarno Suni (jarnos)]

costinel, the --dry-run removes the packages, see Bug #1544942.

[costinel (costinel)]

> the --dry-run removes the packages

no, it doesn't. #1544942 affects only one person, and in comment #64 you can see that files on /boot are not removed

[costinel (costinel)]

and #1544942 does not say dry-run removes packages, but says the output is different between with and without dry-run (which is something I also observed but only the first run after the upgrade to latest precise version of unattended-upgrades)

[Mikko Pesari (mpesari)]

I tested on Precise. When running with --dry-run, unattended-upgrade marks the autoremovable packages as manually installed. This prevents them from being removed when running without --dry-run afterwards. Check "apt-mark showmanual".

[Mikko Pesari (mpesari)]

Happens on Trusty and Xenial too. There are a few bug reports about it marking kernels as manually installed. They may be related. Here's a test case anyway:

Normal run:

# apt-get install lolcat
# apt-mark showmanual lolcat
lolcat
# apt-mark auto lolcat
lolcat set to automatically installed.
# unattended-upgrade
# dpkg -l lolcat
dpkg-query: no packages found matching lolcat

With --dry-run:

# apt-get install lolcat
# apt-mark showmanual lolcat
lolcat
# apt-mark auto lolcat
lolcat set to automatically installed.
# unattended-upgrade --dry-run
# dpkg -l lolcat
ii lolcat ...
# apt-mark showmanual lolcat
lolcat

[Jarno Suni (jarnos)]

As for bug #1544942,

It is reported on Wily, which has newer version of unattended upgrades, so it may behave differently.

I think command
/usr/bin/dpkg --status-fd 9 --force-depends --force-remove-essential --remove linux-headers-4.2.0-16-generic:amd64 linux-headers-4.2.0-16:all linux-image-extra-4.2.0-16-generic:amd64 linux-image-4.2.0-16-generic:amd64
that is shown in the output actually removes the packages since it does not have --no-act, --dry-run or --simulate.

[Jarno Suni (jarnos)]

costinel, In bug #1544942 I run with --dry-run two times and do not compare outputs between with --dry-run and without it.

[Jarno Suni (jarnos)]

Mikko Pesari, oh the packages are not actually removed in Wily, either. I was fooled by the output of the unattended-upgrades command.

costinel, you were right about --dry-run not removing the packages. I corrected my bug report (bug #1544942).

[Jarno Suni (jarnos)]

However, if I do not run unattended-upgrades with --dry-run before running without it, automatic removing of unneeded packages works.

[Richard Anderson (richmbx)]

Is this still an issue?

I have Xenial installs where this occurs occasionally. I don't have much information other than /boot partition fills where we will get alerts. After logging in and running apt-get autoremove the space is cleared.

apt-mark showauto 'linux-image-.*'
Show 3 kernels, which I believe is normal. (currently linux-image-4.4.0-176-generic,linux-image-4.4.0-177-generic, linux-image-generic)

apt-mark showmanual 'linux-image-.*'
Does not show any results.

/etc/apt/apt.conf.d/50unattended-upgrades has the following uncommented:
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "${distro_id}ESM:${distro_codename}";
};
Unattended-Upgrade::Remove-Unused-Dependencies "true";

unattended-upgrades 1.1ubuntu1.18.04.7~16.04.6

[Richard Anderson (richmbx)]

This may or may not be an issue, but here are my observations. The order of operations seems to be the cause of my issue with the additional factor that the /boot partition size is unusually small compared to recent Ubuntu installations.

Order of operations as follows:

1. unattended-install script is run
2. removes packages found in /etc/kernel/postinst.d/apt-auto-removal
3. Installs new kernel
4. creates new /etc/kernel/postinst.d/apt-auto-removal

At this point it does not remove any old packages after the new kernel is installed. However, when unattended-install is run a second time it will remove those packages. This seems like an awkward approach. Ideally, the old kernel packages would get removed the first run of unattended-install. I considered safety concerns in removing older kernels after an update but then it still gets removed on a second run. It is also there is a setting here that I overlooked.

I applied a work around in kernel/postinst.d/zzz_autoremove to simply run apt-get autoremove -y a few seconds after unattended-install is completed. This approach is not ideal but functional for this potentially unique issue.

[Richard Anderson (richmbx)]

* It is also there is a setting here that I overlooked.

should have been:

It is possible also there is a setting here that I overlooked.