Unattended upgrade is ignoring some packages

Question

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
python-rfc3339
python-zope.hookable
python-configargparse
python-zope.component

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

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-updates";
        "${distro_id}:${distro_codename}-security";
        "${distro_id}ESM:${distro_codename}";
};

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?

Solution 1

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";
        "origin=Ubuntu,codename=${distro_codename}";
};

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

Unattended-Upgrade::Origins-Pattern {
      "o=*";
}

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.

Solution 2

A similar question was asked before:

• Why unattended-upgrades upgraded so few packages, seemingly?

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:

• How to enable silent automatic updates for any repository?
• Generates system-specific repositories to be added in configuration file for silently updating all packages via unattended upgrades.
• Upgrading External Packages with unattended-upgrade

Solution 3

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

sudo apt-mark showhold

Comments

[Martin Melka]

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/…

[WinEunuuchs2Unix]

@MartinMelka Thanks. I've updated answer with your link plus two additional ones that help out.

[Martin Melka]

Thank you for the writeup! Does "o=*"; pattern include really everything? For example, I do not want to use the -proposed ubuntu repository.

[earthmeLon]

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.