I have unattended-upgrades set up, but some packages are not being auto-updated.

root@survey:/home/martin# apt update

root@survey:/home/martin# unattended-upgrade -v --dry-run
Initial blacklisted packages:
Initial whitelisted packages:
Starting unattended upgrades script
Allowed origins are: o=Ubuntu,a=xenial, o=Ubuntu,a=xenial-updates, o=Ubuntu,a=xenial-security, o=UbuntuESM,a=xenial
No packages found that can be upgraded unattended and no pending auto-removals

root@survey:/home/martin# /usr/lib/update-notifier/apt-check -p

The configuration of origins in /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {

The pending packages come, to my best knowledge, from the official ubuntu repository (Launchpad link), so I don't see a reason why it would not be picked up by unattended-upgrade.

The output of the command does say that

No packages found that can be upgraded unattended and no pending auto-removals.

Is there a case where a package is picked up by the tool, comes from an allowed source, but for some reason is not allowed to be upgraded unattended? What further steps can I do to find out why some packages are not eligible?

  • one of your installed packages may be blocking the upgrade, does this help : askubuntu.com/a/602/307184 ? – tatsu Jul 16 '19 at 8:22
  • If you install the packages manually, does the UI present you with a human decision to be taken? If yes, leave a comment @Fabby 0:-) – Fabby Jul 18 '19 at 22:35
  • The proper way to obtain a list of upgradable packages is apt list --upgradable, which also shows more information. Also, a dry run of apt upgrade would show if something unusual would happen during the upgrade. – fkraiem Jul 20 '19 at 2:07
  • By the way, since by default apt upgrade installs packages from all origins, if you want your unattended-upgrades to behave likewise, you should allow all origins as well. – fkraiem Jul 20 '19 at 2:17

I believe you are missing 20auto-upgrades and should first implement it properly to see if that fixes your issue before moving on. You can see that this is an important step in the Automatic Upgrades documentation.

$ cat /etc/apt/apt.conf.d/20auto-upgrades 
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

If you have that file and it is still not working, you can try figuring out what's keeping the packages back. I prefer Origins-Pattern to Allowed-Origins, which is different from the documentation, but has worked well for me:

$ vim /etc/apt/apt.conf.d/50unattended-upgrades
# You need to customize configuration

Here is an example of the critical 'Pattern' component in 50unattended-upgrades:

Unattended-Upgrade::Origins-Pattern {
        // Codename based matching:
        // This will follow the migration of a release through different
        // archives (e.g. from testing to stable and later oldstable).

        // Archive or Suite based matching:
        // Note that this will silently match a different release after
        // migration to the specified archive (e.g. testing becomes the
        // new stable).
//      "o=Ubuntu,a=stable";
//      "o=Ubuntu,a=stable-updates";
//      "o=Ubuntu,a=proposed-updates";

This is an example that doesn't restrict based on the repository:

Unattended-Upgrade::Origins-Pattern {

You will only want either Origin-Patterns or Allowed-Origins and not both. This is more clear and documented in Debian's Unattended Upgrades documentation.

Try enabling just this, which is only the Security updates. Test that it works and add your other patterns, one by one, until you add each and verify that each updated doesn't break your dry run testing.

I'd also recommend specifying Ubuntu and writing completely different configuration files for Debian systems, if you have a mix.

Be sure you aren't holding any packages that could prevent updates:

$ sudo apt-mark showhold

Be sure that you can install the updates normally, or that apt is configured to prioritize each release type correctly:

$ cat /etc/apt/preferences.d/custom
Package: *
Pin: release a=bionic
# Only explicit installs
#Pin-Priority: 1001
# Explicit and dependencies
Pin-Priority: 900

Package: *
Pin: release a=testing
Pin-Priority: 399

Package: *
Pin: release a=unstable
Pin-Priority: -10

Some updates will require a machine reboot and you will have to decide if you do that manually, or allow apt to restart the machine at a given time when required by updates.

| improve this answer | |
  • Thank you for the writeup! Does "o=*"; pattern include really everything? For example, I do not want to use the -proposed ubuntu repository. – Martin Melka Jul 23 '19 at 7:37
  • Yeah, that would be a shortcut to update anything available, but all of this is also governed by Pin-Priority, as shown in the end with /etc/apt/preferences.d/custom. Changing Pin-Priority would affect normal apt installations too. It's not required, but offered additional help to prevent installing packages from specific sources. – earthmeLon Jul 23 '19 at 15:35

A similar question was asked before:

The accept answer states:

Most of the answer is in your unattended-upgrades logfile, located at /var/log/unattended-upgrades/unattended-upgrades.log

Here's an example:

2018-01-08 06:17:51,770 INFO Starting unattended upgrades script
2018-01-08 06:17:51,771 INFO Allowed origins are: ['o=Ubuntu,a=xenial-security']
2018-01-08 06:18:07,765 INFO No packages found that can be upgraded unattended and no pending auto-removals

Take a look at that middle line 'Allowed origins'. That means Software Repositories. The only source there is -security. Not -upgrades, not -backports, no PPAs, no third-party repos.

In other words, this example unattended-upgrades is only providing security upgrades. Nothing else.

You can add, remove, or edit Allowed Origins (repositories) through the Software and Updates Control Panel, or by editing the unattended-upgrades config file, located at /etc/apt/apt.conf.d/50unattended-upgrades.

The rest of the answer is that Xenial (16.04) is two years old. Fewer new security updates for old software.

Additional reading:

| improve this answer | |
  • The important part on how to check the origin of a package to be installed is running apt upgrade --dry-run. In its output there will be something like Inst libpcre2-dev [...] (10.33-1+ubuntu16.04.1+deb.sury.org+1 ***** The main PPA for supported PHP versions with many PECL extensions *****:16.04/xenial [amd64]) []. I copypasted the text between asterisks and googled for it. That led me to the name of the origin. Then this article shows how to determine what to actually write into the u-u config: linux-audit.com/… – Martin Melka Jul 22 '19 at 16:06
  • @MartinMelka Thanks. I've updated answer with your link plus two additional ones that help out. – WinEunuuchs2Unix Jul 22 '19 at 16:31

Worth checking if you have marked to hold packages which might be preventing packages from upgrading.

sudo apt-mark showhold
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.