Changing what action for security updates unusable

Bug #1554099 reported by Kev Bowring on 2016-03-07
44
This bug affects 9 people
Affects Status Importance Assigned to Milestone
software-properties (Ubuntu)
High
Unassigned
Xenial
High
Unassigned
unattended-upgrades (Ubuntu)
Undecided
Michael Vogt
Xenial
Undecided
Michael Vogt

Bug Description

Open software-properties.

Important security updates is not enabled on install.

Secondly - it is not possible to change the action to take with security updates even if it is enabled (note: I enabled security updates, reloaded cache and restarted software-properties before trying to change the action)

eg - the Display Immediately/Download automatically/Download and install automatically

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: software-properties-gtk 0.96.18
ProcVersionSignature: Ubuntu 4.4.0-10.25-generic 4.4.3
Uname: Linux 4.4.0-10-generic x86_64
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
CurrentDesktop: XFCE
Date: Mon Mar 7 15:35:24 2016
InstallationDate: Installed on 2016-03-07 (0 days ago)
InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160307)
PackageArchitecture: all
SourcePackage: software-properties
UpgradeStatus: No upgrade log present (probably fresh install)

Kev Bowring (flocculant) wrote :
Kev Bowring (flocculant) on 2016-03-07
description: updated
Launchpad Janitor (janitor) wrote :

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

Changed in software-properties (Ubuntu):
status: New → Confirmed
Jason Gerard DeRose (jderose) wrote :

Same is happening with latest Ubuntu (Unity) Xenial daily ISO (sha1sum 8e06dd499bfe357ebbad44c827d8428d70baacf4).

I attached a screenshot of the same problem under Unity.

This bug has been around for a few weeks or so, although I'm not exactly sure when it was introduced.

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1554099

tags: added: iso-testing
Brian Murray (brian-murray) wrote :

This is likely a result of the following change in unatteded-upgrades:

unattended-upgrades (0.90) unstable; urgency=medium

  [ Alexandre Detiste ]
  * tweak a bit the French translations

  [ Michael Vogt ]
  * debian/templates: set unattended-upgrades/enable_auto_updates to
    "true" (Closes: #707055)

Brian Murray (brian-murray) wrote :

I've observed this on a fresh install of xenial, but not on an upgraded system.

Changed in software-properties (Ubuntu):
importance: Undecided → High
Brian Murray (brian-murray) wrote :

I'm pretty sure this is the source of the problem, software-properties looks at Apt configuration options, which are the following in a fresh install of Xenial.

bdmurray@clean-xenial-amd64:~$ grep -r "APT::Periodic" /etc/apt/*
/etc/apt/apt.conf.d/10periodic:APT::Periodic::Update-Package-Lists "1";
/etc/apt/apt.conf.d/10periodic:APT::Periodic::Download-Upgradeable-Packages "0";
/etc/apt/apt.conf.d/10periodic:APT::Periodic::AutocleanInterval "0";
/etc/apt/apt.conf.d/20auto-upgrades:APT::Periodic::Update-Package-Lists "1";
/etc/apt/apt.conf.d/20auto-upgrades:APT::Periodic::Unattended-Upgrade "1";

So we have autodownload set to 0, and unattended set to 1. Looking at the code in SoftwareProperties.py we see:

147 if apt_pkg.config.find_i(softwareproperties.CONF_MAP["autoupdate"]) > 0:
148 # Autodownload
149 if apt_pkg.config.find_i(softwareproperties.CONF_MAP["unattended"]) == 1\
150 and apt_pkg.config.find_i(softwareproperties.CONF_MAP["autodownload"]) == 1 :
151 return softwareproperties.UPDATE_INST_SEC
152 elif apt_pkg.config.find_i(softwareproperties.CONF_MAP["autodownload"]) == 1 and \
153 apt_pkg.config.find_i(softwareproperties.CONF_MAP["unattended"]) == 0:
154 return softwareproperties.UPDATE_DOWNLOAD
155 elif apt_pkg.config.find_i(softwareproperties.CONF_MAP["unattended"]) == 0 and \
156 apt_pkg.config.find_i(softwareproperties.CONF_MAP["autodownload"]) == 0:
157 return softwareproperties.UPDATE_NOTIFY
158 else:
159 return None

So somebody's created a situation we hadn't planned on.

Brian Murray (brian-murray) wrote :

Changing /etc/apt/apt.conf.d/10periodic so that Download-Upgadeable-Packages is "1", populates the drop down box with choices so maybe that was just neglected in 20auto-upgrades.

tags: added: regression-release
Brian Murray (brian-murray) wrote :

Michael - is APT::Periodic::Download-Upgradeable-Packages supposed to be 1 or is there an possibility missing in SoftwareProperties.py?

Changed in unattended-upgrades (Ubuntu Xenial):
assignee: nobody → Michael Vogt (mvo)
unflavored (unflavored) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in unattended-upgrades (Ubuntu):
status: New → Confirmed
Doug McMahon (mc3man) wrote :

It seems unattended-upgrades sets default to *install* in 20auto-upgrades, (1), but in 10periodic the default for download (APT::Periodic::Download-Upgradeable-Packages) is set to just Display immediately (0)

This creates an impossible situation, Unattended-Upgrade can't install when Download is off

Once the 10 file is edited to make the 20 file viable any changes in Software & Updates regarding these options is mirrored between the 2 files so they are 'on the same page' so to speak from that point on.

The whole deal can be re-created at any point by removing unattended-upgrades package, then re-installing software-properties-gtk & unattended-upgrades

Brian Murray (brian-murray) wrote :

This bug number was neglected in the changelog entry which fixed it.

software-properties (0.96.19) xenial; urgency=medium

  * data/gtkbuilder/main.ui:
    - let the new label wrap when needed
  * softwareproperties/SoftwareProperties.py:
    - security upload autoinstallation doesn't require autodownload to
      be on, but check that unattended-upgrade is installed instead

Changed in unattended-upgrades (Ubuntu Xenial):
status: Confirmed → Invalid
Changed in software-properties (Ubuntu Xenial):
status: Confirmed → Fix Released
Jason Gerard DeRose (jderose) wrote :

I'm still seeing this bug on a fresh install from today's daily ISO (20160321, sha1sum 4773a2328eb4470761e1c37174d5d3cad5b6219d).

But I'm no longer seeing it on my upgraded existing install from a few months back.

unflavored (unflavored) wrote :

Fixed for me in daily ISO 20160323, sha1sum 0715033d3ee1f2e769bb3ee547a9982f81b1f432

Jason Gerard DeRose (jderose) wrote :

Yup, I can also confirm that it seems fixed in the 20160323 daily ISO (tested yesterday). Will test today's shortly.

Jason Gerard DeRose (jderose) wrote :

Yup, I can also confirm that it seems fixed in the 20160323 daily ISO.

Michael MacEachern (maceach-b) wrote :

This is not fixed for me. I installed from 16.04.1 back in November, and it's now doing this for me, so can this please be re-opened? Some recommended removing 20auto-upgrades, but it didn't work either.

Michael MacEachern (maceach-b) wrote :

This is a bug yet once again in the latest version of 16.04.1, that was installed fresh back in November.

sudo rm /etc/apt/apt.conf.d/20auto-upgrades

does NOT work. I have to edit 10periodic and set everything to 0, but once you set security updates to download and install automatically, it once again goes dim on next launch of Software and Updates.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers