Upgrade failed - unauthenticated package (module-init-tools)

Bug #1550741 reported by Kev Bowring on 2016-02-27
90
This bug affects 15 people
Affects Status Importance Assigned to Milestone
apt (Ubuntu)
High
Unassigned
kmod (Ubuntu)
Critical
Andy Whitcroft

Bug Description

Upgrading an updated (+ hwe) 14.04 to 16.04 fails on module-init-tools being unauthentiated

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: ubuntu-release-upgrader-core 1:0.220.8
ProcVersionSignature: Ubuntu 4.2.0-30.36~14.04.1-generic 4.2.8-ckt3
Uname: Linux 4.2.0-30-generic i686
ApportVersion: 2.14.1-0ubuntu3.19
Architecture: i386
CrashDB: ubuntu
CurrentDesktop: XFCE
Date: Sat Feb 27 15:46:12 2016
InstallationDate: Installed on 2016-02-27 (0 days ago)
InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Release i386 (20140416.2)
PackageArchitecture: all
SourcePackage: ubuntu-release-upgrader
Symptom: ubuntu-release-upgrader
UpgradeStatus: Upgraded to trusty on 2016-02-27 (0 days ago)
VarLogDistupgradeTermlog:

Kev Bowring (flocculant) wrote :
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/1550741

tags: added: iso-testing
Launchpad Janitor (janitor) wrote :

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

Changed in ubuntu-release-upgrader (Ubuntu):
status: New → Confirmed
summary: - Upgrade failed - unathenticated package
+ Upgrade failed - unathenticated package (module-init-tools)
summary: - Upgrade failed - unathenticated package (module-init-tools)
+ Upgrade failed - unauthenticated package (module-init-tools)

Circumvention, copied from Bug #1550922:

Set up a config file in /etc/update-manager/release-upgrades.d/*.cfg.

According to http://askubuntu.com/questions/425355/error-authenticating-some-packages-while-upgrade one needs to create a file /etc/update-manager/release-upgrades.d/unauth.cfg with the contents:

[Distro]
AllowUnauthenticated=yes

Tested and works.

In order to check for the above condition, one need a precursor script (as root) before the update proper, which goes along these lines:

#! /bin/sh
if [[ -n $(dpkg --get-selections | grep module-init-tools | cut -f1) ]]
then
    cat <<- EOF >/etc/update-manager/release-upgrades.d/unauth.cfg
[Distro]
AllowUnauthenticated=yes
EOF
fi

Thiago Martins (martinx) wrote :

Workaround of post #4 works.
Upgrading going on now... Hope for the best! :-)

Brian Murray (brian-murray) wrote :

Adding some extra debugging (logging.warning() calls) produces the following in /var/log/dist-upgrade/main.log:

2016-03-01 11:59:20,561 WARNING origin is: <Origin component:'main' archive:'xenial' origin:'Ubuntu' label:'Ubuntu' site:'192.168.10.7' isTrusted:True>
2016-03-01 11:59:20,561 WARNING origin is: <Origin component:'main' archive:'xenial' origin:'Ubuntu' label:'Ubuntu' site:'192.168.10.7' isTrusted:True>
2016-03-01 11:59:20,562 WARNING origin is: <Origin component:'' archive:'now' origin:'' label:'' site:'' isTrusted:False>
2016-03-01 11:59:20,562 WARNING not trusted: module-init-tools
2016-03-01 11:59:20,562 WARNING origin is: <Origin component:'main' archive:'xenial' origin:'Ubuntu' label:'Ubuntu' site:'192.168.10.7' isTrusted:True>
2016-03-01 11:59:20,562 WARNING origin is: <Origin component:'main' archive:'xenial' origin:'Ubuntu' label:'Ubuntu' site:'192.168.10.7' isTrusted:True>

I don't know what archive:'now' is though.

Launchpad Janitor (janitor) wrote :

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

Changed in module-init-tools (Ubuntu):
status: New → Confirmed
Dave Morley (davmor2) wrote :

Setting to critical as this is blocking Upgrades which is one of the key install methods for 16.04

Changed in ubuntu-release-upgrader (Ubuntu):
importance: Undecided → Critical
Changed in module-init-tools (Ubuntu):
importance: Undecided → Critical
Michael Vogt (mvo) wrote :

I looked at this a bit more, here are some findings:
- the "module-init-tools" package is returned from cache.get_changes() *but* it not marked for install/remove/upgrade/reinstall/downgrade - funny enough its also not marked "keep" so its in some heisenstate
- module-init-tools is not installable because it has a hard depenency on libkmod2=21-1ubuntu1 but the libmod2 version in xenial is 22-1ubuntu1.
- when apts depcache.cc sees a package like module-init-tools that has a hard dependency that can't be satisfied it will reset the candidate version. I (strongly) suspect it also need to set it back into "keep" state.

So to fix this we need:
- make module-init-tools installable again
- fix apt to not go into heisenstate when it encounters a situation like this

Michael Vogt (mvo) wrote :
tags: added: patch
Launchpad Janitor (janitor) wrote :

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

Changed in apt (Ubuntu):
status: New → Confirmed
David Kalnischkies (donkult) wrote :

(as I was asked to have a look – only reviewing based on comments and code in this bug through)

I guess setting the state explicit here is okay, I wonder why the package hasn't any state through – isn't that kinda normal for a package not touched at all? I also think it is wrong that .get_changes() returns packages in "non-interesting" states as those are clearly not changes.

Basic sanity checking might be in order here to catch such issues in the future as e.g. a package from archive "now" (which is the designation for a package in the dpkg/status file) can realistically only be removed.

APT has the test-bug-735967-lib32-to-i386-unavailable testcase which produces such a situation, the heisenstate doesn't seem to interest apt through and can't be easily observed. Maybe the tests should be extended to be able to call python – the ability could be handy as a CI test in general.

Andy Whitcroft (apw) wrote :

I believe the fundamental issue here is that as of kmod 22-1 we are expecting to be able to drop the module-init-tools transitional, but because that has a versioned dependancy on kmod we end up in an unresolvable situation. As this package is transitional it seems most appropriate to just force it off on upgrades. We should be able to add Provides/Conflicts/Replaces on kmod to achieve this.

affects: module-init-tools (Ubuntu) → kmod (Ubuntu)
Changed in kmod (Ubuntu):
assignee: nobody → Andy Whitcroft (apw)
milestone: none → ubuntu-16.03
Andy Whitcroft (apw) on 2016-03-09
tags: added: block-proposed
Steve Langasek (vorlon) wrote :

The module-init-tools binary package was sitting NBS in xenial; this has been resolved now by the removal of the package from the archive. So it's possible that no further changes are required to kmod, Andy.

Scott Moser (smoser) wrote :

I've just tested this now in a lxc container and we're at least not hitting the module-init-tools complain.
The system is currently running apt-get upgrade (it would previously fail prior to that)

Brian Murray (brian-murray) wrote :

I've also tested an upgrade of a Trusty desktop to Xenial and while the upgrade is in progress, it has gotten past the failure to calculate the upgrade. Subsequently, I'm marking the kmod task as Invalid. It'd still be good to get mvo's apt fix added in some form and make ubuntu-release-upgrader more informative as to the failure.

Changed in kmod (Ubuntu):
status: Confirmed → Invalid
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package kmod - 22-1ubuntu3

---------------
kmod (22-1ubuntu3) xenial; urgency=low

  * reinstate module-init-tools transitional package. (LP: #1550741)
   - as we have versioned dependancies from the kernel to this in 14.04
     removing this package throws the apt in trusty for a loop preventing
     upgrades.
   - note that this reverts the P/C/R combo from the previous upload.

kmod (22-1ubuntu2) xenial; urgency=low

  * Provides/Conflicts/Replaces: module-init-tools to fix upgrades from
    15.10 which has a strict versioned Depends: on kmod. (LP: #1550741)

 -- Andy Whitcroft <email address hidden> Wed, 09 Mar 2016 10:31:51 +0000

Changed in kmod (Ubuntu):
status: Invalid → Fix Released
Changed in ubuntu-release-upgrader (Ubuntu):
importance: Critical → Medium
Adam Conrad (adconrad) on 2016-03-11
Changed in ubuntu-release-upgrader (Ubuntu):
status: Confirmed → Invalid
Martin Pitt (pitti) on 2016-03-14
tags: removed: block-proposed
Michael Vogt (mvo) on 2016-03-16
Changed in apt (Ubuntu):
status: Confirmed → Fix Committed
importance: Undecided → High
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apt - 1.2.7

---------------
apt (1.2.7) unstable; urgency=medium

  "Caesar is dead"

  [ Frans Spiesschaert ]
  * Dutch program translation update (Closes: 817060)
  * Dutch manpages translation update (Closes: 817062)

  [ Julian Andres Klode ]
  * Use native architecture instead of amd64 for build-dep-purge test
  * Do not consider SHA1 usable
  * Test that SHA1-only .diff/Index files are not used
  * test: Use SHA512 digests for GPG, reject SHA1-based signatures
  * methods/gpgv: Reject weak digest algorithms
  * apt-pkg/acquire-worker.cc: Introduce 104 Warning message
  * methods/gpgv: Warn about SHA1 (and RIPEMD-160)

  [ David Kalnischkies ]
  * require $(HASH)-Download field in .diff/Index files
  * flush line-clearing on progress stop before post-invoke (Closes: 793672)
  * enforce verify of filesize in 'apt-get source'

  [ Manuel "Venturi" Porras Peralta ]
  * Spanish apt-mark translation fix (Closes: 817999)

  [ Zhou Mo ]
  * zh_CN.po: fix translation bug. (Closes: #818177)

  [ Michael Vogt ]
  * Fix bug where the problemresolve can put a pkg into a heisenstate
    (LP: #1550741)

 -- Julian Andres Klode <email address hidden> Tue, 15 Mar 2016 19:20:18 +0100

Changed in apt (Ubuntu):
status: Fix Committed → Fix Released
no longer affects: ubuntu-release-upgrader (Ubuntu)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers