Ticket #1283 (closed defect: fixed)

Opened 12 years ago

Last modified 11 years ago

Lucid cannot upgrade to Precise

Reported by: jdreed Owned by: jdreed
Priority: blocker Milestone: Current Semester
Component: -- Keywords:
Cc: jmorzins@… Fixed in version:
Upstream bug:


Jacob initially encountered this on his workstation. I just encountered it in a clean Lucid VM. The upgrade errors out with "Unauthenticated packages found" and lists all the debathena packages.

Jacob has the same failure, except that he also has ksplice enabled, and ksplice is listed in the "unauthenticated packages" list. I'm not sure if something changed WRT 3rd-party packages, or what.

Change History

comment:1 Changed 12 years ago by jmorzins

For what it's worth I uninstalled ksplice uptrack to remove that error from the list; now all that's left is the debathena error.

comment:2 Changed 12 years ago by jdreed

For maximum awesomeness, Lucid will happily upgrade to maverick (despite it being EOL'd). I'm not sure if this means it's the Precise updater that's broken, or what.

comment:3 Changed 12 years ago by jdreed

adehnert notes he encountered this a few weeks ago. My current hypothesis is that the failure occurred when 12.04.1 came out. The failure does not occur when upgrading from Oneiric to Precise.

comment:4 Changed 12 years ago by jdreed

I dug into release-upgrader. If we set Apt to allow unauthenticated packages, everything is fine. Something is wrong though, because python-apt thinks that the precise repository is not trusted. The pkg.candidate.origin object is this:

<Origin component:'debathena-config' archive:'precise' origin:'Debathena' label:'Debathena' site:'debathena.mit.edu' isTrusted:False>                                                                 

And in fact, there is no Release.gpg file in /var/lib/apt/lists. I have no idea how that happened. An "apt-get update" won't fix it. Nuking /var/lib/apt/lists/debathena* and apt-get update will cause it re-download the Release.gpg file, and then do-release-upgrade works just fine. This baffles me.

comment:5 Changed 12 years ago by jdreed

However, if I try and re-create the original situation, it downloads Release.gpg into lists/partial, and then apt-get update fails with BADSIG (as Jacob encountered). So Lucid's apt is doing something stupid, and I'm not sure why.

comment:6 Changed 12 years ago by jdreed

This problem is present on 10.04.0, using an old ISO image I had. I wrapped gpgv to see what's actually going on, and the Release file it's trying to verify is in fact the InRelease? file, which of course won't verify against Release.gpg. Everything (including strace) suggests it is actually downloading the Release file, not the InRelease? file, so I have no idea what's going on here.

I'll note that Lucid has gpg 1.4.10, and magrathea has 1.4.11, but that should not be relevant (right?)

comment:7 Changed 11 years ago by jdreed

  • Status changed from new to accepted
  • Owner set to jdreed
  • Priority changed from high to blocker

OK, we need to do something about this, since Lucid Desktop is EOL'd at the end of next month. Lucid's APT is clearly broken and/or doesn't like our repository. But the fact that Jacob was also seeing this with Ksplice suggests that something else is going on here. However, given the close association between Ksplice and Debathena, we both may be doing the exact same thing that Lucid doesn't like. Can someone from Ksplice chime in about how that repo is managed/was managed 3 months ago (e.g. reprepro? Something else?)

I think I'm fine with telling people to temporarily disable repo authentication, upgrade, and then turn it back on, but I'd like a better answer.

comment:8 follow-up: ↓ 9 Changed 11 years ago by jdreed

I've wasted far too much time on this, and have stopped caring. The fundamental problem is that _something_ is downloading debathena's InRelease? file instead of its Release file (although naming it as the Release file in /var/lib/apt/lists). I'll note that the upgrade from Lucid to Precise goes across a version where support for InRelease? became a thing. If people encounter this in the wild, I'm going to tell them to add this to /etc/update-manager/release-upgrades.d/debathena.cfg and move on with their lives:


(and then delete it after the upgrade)

comment:9 in reply to: ↑ 8 Changed 11 years ago by kaduk

Replying to jdreed:


(and then delete it after the upgrade)

I'm not super-happy about that, but don't really have a better alternative handy. Would you be willing to suggest a new install instead of upgrading, if appropriate for the user's use-case?

comment:10 Changed 11 years ago by jdreed

Yes, this would be a last resort. But geofft also said he'd poke at it if I gave him a broken VM, which I will do later.

comment:11 Changed 11 years ago by jdreed

A borked VM (NAT, 1G RAM, 20G disk) is available here:
 http://loop.mit.edu/borked.tgz (1.2GB)

Steps to reproduce:

  • install from ubuntu-10.04.4-desktop-amd64.iso
  • apt-get update && apt-get dist-upgrade
  • reboot
  • wget http://debathena.mit.edu/install-debathena.sh
  • sudo sh install-debathena.sh
  • select standard, no extra-software
  • do-release-upgrade
  • shutdown VM
  • tar up VM directory

comment:12 Changed 11 years ago by jdreed

I wonder if less dumb solution is for debathena to temporarily stop using InRelease? files (can we do that?).

comment:13 Changed 11 years ago by jdreed

  • Status changed from accepted to closed
  • Resolution set to fixed

"Fixed" by adding a RewriteRule? that denies any InRelease? file to any user-agent that appears to be the broken version of APT. I don't know what the upstream bug is, and don't really care at this point.

Note: See TracTickets for help on using tickets.