"Unattended-Upgrade::Remove-Unused-Dependencies" does not work
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | unattended-upgrades (Ubuntu) |
Medium
|
Michael Vogt | ||
| | Precise |
Medium
|
Brian Murray | ||
| | Trusty |
High
|
Unassigned | ||
Bug Description
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-
----
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-
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/
// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
Unattended-
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,
adjusting candidate version: '<Version: package:
adjusting candidate version: '<Version: package:
adjusting candidate version: '<Version: package:
adjusting candidate version: '<Version: package:
adjusting candidate version: '<Version: package:
adjusting candidate version: '<Version: package:'libdrm2' version:
Checking: bc (["<Origin component:'main' archive:
Checking: grub-common (["<Origin component:'main' archive:
Checking: grub-pc (["<Origin component:'main' archive:
Checking: grub-pc-bin (["<Origin component:'main' archive:
Checking: grub2-common (["<Origin component:'main' archive:
Checking: iproute (["<Origin component:'main' archive:
Checking: landscape-common (["<Origin component:'main' archive:
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-
| tags: | added: precise |
| Launchpad Janitor (janitor) wrote : | #2 |
Status changed to 'Confirmed' because the bug affects multiple users.
| Changed in unattended-upgrades (Ubuntu): | |
| status: | New → Confirmed |
This thing seems to be broken in 2 ways (on 12.04 at least):
A) Its checking internally for the wrong variable ( now_auto_
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.
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.]
| tags: | added: patch |
| tags: | added: trusty |
| Changed in unattended-upgrades (Ubuntu): | |
| importance: | Undecided → Medium |
| assignee: | nobody → Michael Vogt (mvo) |
| status: | Confirmed → Triaged |
Actually I just saw that it is semi fixed in 14.04 in the way that
now_auto_
now reads
now_auto_removable - pkgs_auto_removable
which is also wrong, as
now_auto_removable = set([pkg.name for pkg in cache
and
pkgs_auto_removable = set([pkg.name for pkg in cache
are apparently the same, therefore substracting them from each other is always empty.
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_
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) wrote : | #8 |
Lars Heide, your patch works great for me, I think it should be applied upstream. But some people may find "differential" behavior (now_auto_
| the2nd (the2nd) wrote : | #9 |
same problem here. ubuntu 12.04.
is there any fix for this available?
| Chris Case (morgul) wrote : | #10 |
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.
Note that situation #1089195 is another possible outcome of this bug.
| Apreche (apreche) wrote : | #12 |
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) wrote : | #13 |
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) wrote : | #14 |
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) wrote : | #15 |
@Nathaniel: does http://
| Jamie (jamiejellicoe) wrote : | #16 |
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-
| Jamie (jamiejellicoe) wrote : | #17 |
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)
Each day this bug breaks more Ubuntu servers that do unattended-
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) wrote : | #19 |
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) wrote : | #20 |
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/
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-
| Alexander Skiba (ghostlyrics) wrote : | #21 |
In regard to #20:
I've submitted a pull request that *changes the default behavior* of `Remove-
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.
APT::Periodic:
# APT::Periodic:
# - 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.
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(
The output of "is_auto_removable" only changes after that AFAIK.
| Guy Baconniere (lordbaco) wrote : | #26 |
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) wrote : | #27 |
GhostLyrics' upstream patch has been merged (https:/
Right now my servers are running apt-get -y autoremove on a cron job, but I'd love to ditch that.
| Michael Vogt (mvo) wrote : | #28 |
This is fixed, I plan to do a backport for 14.04 and 12.04 via the trusty-backports, precise-backports mechanism.
| Changed in unattended-upgrades (Ubuntu): | |
| status: | Triaged → Fix Released |
| Alexander List (alexlist) wrote : | #29 |
Did you even consider providing the fix via SRU?
| Alexander List (alexlist) wrote : | #30 |
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) wrote : | #31 |
Would like to second that this get backported to Trusty and other supported versions.
| Samuel Reed (strml) wrote : | #32 |
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) wrote : | #33 |
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) wrote : | #34 |
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:
| Seth Arnold (seth-arnold) wrote : | #35 |
mvo, is this suitable for an SRU? Thanks
| Steve Brorens (sbrorens) wrote : | #36 |
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) wrote : | #37 |
Short version: backports won't work.
Slightly longer version: It's not in trusty-backports, it's not in vivid-(
(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.
| Changed in unattended-upgrades (Ubuntu Trusty): | |
| status: | New → Triaged |
| importance: | Undecided → High |
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) wrote : | #39 |
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) wrote : | #40 |
| Michael Vogt (mvo) wrote : | #41 |
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).
Hello Nils, or anyone else affected,
Accepted unattended-upgrades into trusty-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
| Changed in unattended-upgrades (Ubuntu Trusty): | |
| status: | Triaged → Fix Committed |
| tags: | added: verification-needed |
| Steve Brorens (sbrorens) wrote : Re: [Bug 1267059] Re: "Unattended-Upgrade::Remove-Unused-Dependencies" does not work | #43 |
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:/
(https:/
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:/
>
> Title:
> "Unattended-
>
> To manage notifications about this bug go to:
>
> https:/
>
| Steve Brorens (sbrorens) wrote : | #44 |
It's just removed a kernel corrctly, so I've tagged as "confirmed"
| Changed in unattended-upgrades (Ubuntu Trusty): | |
| status: | Fix Committed → Confirmed |
| Steve Brorens (sbrorens) wrote : | #45 |
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) wrote : | #46 |
@Steve Brorens: It's actually the little "Tags" section under the bug description and right before the comments that needs edited. Remove 'verification-
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.
| tags: |
added: verification-done removed: verification-needed |
| Christopher Heuer (cheuer) wrote : | #47 |
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.
| Changed in unattended-upgrades (Ubuntu Trusty): | |
| status: | Confirmed → Fix Committed |
| Launchpad Janitor (janitor) wrote : | #48 |
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
| Changed in unattended-upgrades (Ubuntu Trusty): | |
| status: | Fix Committed → Fix Released |
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) wrote : | #50 |
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).
Hi,
I see from https:/
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:/
>
> Title:
> "Unattended-
>
> To manage notifications about this bug go to:
>
> https:/
>
| Changed in unattended-upgrades (Ubuntu Precise): | |
| status: | New → Triaged |
| importance: | Undecided → Medium |
| Changed in unattended-upgrades (Ubuntu Precise): | |
| status: | Triaged → In Progress |
| assignee: | nobody → 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:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
| Changed in unattended-upgrades (Ubuntu Precise): | |
| status: | In Progress → Fix Committed |
| tags: | removed: verification-done |
| tags: | added: verification-needed |
| Felix Barbeira (fbarbeira) wrote : | #53 |
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-
linux-
0 upgraded, 0 newly installed, 12 to remove and 9 not upgraded.
Remv linux-image-
Remv linux-image-
Remv linux-image-
Remv linux-image-
Remv linux-image-
Remv linux-image-
Remv linux-image-
Remv linux-image-
Remv linux-image-
Remv linux-image-
Remv linux-image-
Remv linux-image-
root@~#
This is the log of "unattended-
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,
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-
2015-12-18 18:58:46,711 INFO Packages auto-removed
| tags: |
added: verification-done removed: verification-needed |
| Peter Grandi (pg-8) wrote : | #54 |
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) wrote : | #55 |
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
| Changed in unattended-upgrades (Ubuntu Precise): | |
| status: | Fix Committed → Fix Released |
| Guy Baconniere (lordbaco) wrote : | #56 |
# 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]
| grep -oE '[0-9.]+-[0-9]+' | sort -u)" | xargs -r apt-get --dry-run purge
| SeanBoran (sean-boran) wrote : | #57 |
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-
Unattended-
Unattended-
Unattended-
Unattended-
# install patches automatically, update weekly,
# wipe unused packages after 3 weeks. No report.
APT::Periodic:
APT::Periodic:
APT::Periodic:
APT::Periodic:
APT::Periodic:
APT::Periodic:
Reading https:/
| Alexander Skiba (ghostlyrics) wrote : | #58 |
@sean-boran, comment #57:
The fix is available in the trusty-updates repository. See this changelog: http://
| Jarno Suni (jarnos) wrote : | #59 |
Peter Grandi, doesn't unattended-
| costinel (costinel) wrote : | #60 |
this bugs says "Precise Fix Released Medium Brian Murray Edit"
apt-listchanges -a /var/cache/
" 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:
Initial blacklisted packages:
Starting unattended upgrades script
Allowed origins are: ['o=Ubuntu,
adjusting candidate version: '<Version: package:'apt' version:
adjusting candidate version: '<Version: package:
adjusting candidate version: '<Version: package:'apt-utils' version:
adjusting candidate version: '<Version: package:'e2fslibs' version:
adjusting candidate version: '<Version: package:'e2fsprogs' version:
adjusting candidate version: '<Version: package:
adjusting candidate version: '<Version: package:
adjusting candidate version: '<Version: package:
adjusting candidate version: '<Version: package:'libss2' version:
adjusting candidate version: '<Version: package:'ntpdate' version:
adjusting candidate version: '<Version: package:
Checking: dosfstools (["<Origin component:'main' archive:
Checking: gdisk (["<Origin component:
Checking: libnvpair1 (["<Origin component:'main' archive:'precise' origin:
Checking: libudev0 (["<Origin component:'main' archive:
Checking: libuutil1 (["<Origin component:'main' archive:'precise' origin:
Checking: libzfs2 (["<Origin component:'main' archive:'precise' origin:
Checking: libzpool2 (["<Origin component:'main' archive:'precise' origin:
| costinel (costinel) wrote : | #61 |
worse, before running unattended-
| Alexander Skiba (ghostlyrics) wrote : | #62 |
@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@
Initial blacklisted packages:
Starting unattended upgrades script
Allowed origins are: ['o=Ubuntu,
adjusting candidate version: '<Version: package:'ntpdate' version:
Checking: ca-certificates (["<Origin component:'main' archive:
Checking: cpio (["<Origin component:'main' archive:
Checking: libc-bin (["<Origin component:'main' archive:
Checking: libc-dev-bin (["<Origin component:'main' archive:
Checking: libc6 (["<Origin component:'main' archive:
Checking: libc6-dev (["<Origin component:'main' archive:
Checking: libgcrypt11 (["<Origin component:'main' archive:
Checking: libgnutls26 (["<Origin component:'main' archive:
Checking: libssl1.0.0 (["<Origin component:'main' archive:
Checking: linux-headers-
| costinel (costinel) wrote : | #63 |
> have you made sure you manually set that option to 'true'? It's 'false' by default.
yes,
root@mailhost:~# grep Dependencies /etc/apt/
Unattended-
root@mailhost:~# ls -lht /etc/apt/
-rw-r--r-- 1 root root 2.1K May 8 2013 /etc/apt/
| costinel (costinel) wrote : | #64 |
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-
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://
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-
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/
cat /var/tmp/
http://
root@wifi:~# ls /boot
abi-3.13.
abi-3.13.
abi-3.13.
abi-3.13.
abi-3.13.
abi-3.13.
abi-3.13.
abi-3.13.
config-
config-
config-
config-
config-
config-
config-
config-
grub vmlinuz-
initrd.
initrd.
initrd.
initrd.
initrd.
root@wifi:~# grep LTS /etc/motd
Welcome to Ubuntu 12.04.5 LTS (GNU/Linux 3.13.0-77-generic x86_64)
| costinel (costinel) wrote : | #65 |
> 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) wrote : | #66 |
costinel, the --dry-run removes the packages, see Bug #1544942.
| costinel (costinel) wrote : | #67 |
> 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) wrote : | #68 |
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-
| Mikko Pesari (mpesari) wrote : | #69 |
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) wrote : | #70 |
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) wrote : | #71 |
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-
that is shown in the output actually removes the packages since it does not have --no-act, --dry-run or --simulate.
| Jarno Suni (jarnos) wrote : | #72 |
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) wrote : | #73 |
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) wrote : | #74 |
However, if I do not run unattended-upgrades with --dry-run before running without it, automatic removing of unneeded packages works.


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 Upgrade: :Remove- Unused- Dependencies "true";
// (equivalent to apt-get autoremove)
Unattended-
But it's actually only equivalent to apt-get autoremove if there was nothing to be autoremoved beforehand. That should be clarified.