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?

4

3 Answers

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.

2

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:

2

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

sudo apt-mark showhold 

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password

Post as a guest

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