do-release-upgrade timesout with "Failed to connect..." from behind a proxy from 18.04 to 20.04

Asked by Dave

I'm trying to upgrade an Ubuntu 18.04LTS VM that is behind a proxy. Running do-release-upgrade seems to timeout and reports "Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings".

The various http_proxy env var settings are correct - curl can retrieve the changelogs.ubuntu.com page correctly. apt's proxy settings are also correct - all apt functions work.

With my basic knowledge of python I've run a python interactive session and have done an "init_proxy()" from UpdateManager.Core.utils, which returns the correct proxy address. I've also looked inside the MetaRelease.py module and have done
req = Request("https://changelogs.ubuntu.com/meta-release-lts")
uri = urlopen(req, timeout=20)
for line in uri.readlines():
    print(line)

...and this printed out the contents of the file at the changelogs URL. However if I import MetaReleaseCore and do
init_proxy()
m = MetaReleaseCOre(False,False)
m.downloaded.wait()

...then I get the same error as if I run the do-release-upgrade command directly.

I can't see that it's a problem with my proxy config.

(FYI, earlier today, on the same machine, I did a do-release-upgrade to get from 16.04 to 18.04, followed by an apt update/upgrade/dist-upgrade, all with no problem).

Description: Ubuntu 18.04.1 LTS
Release: 18.04
ubuntu-release-upgrader-core:
  Installed: 1:18.04.17

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Solved by:
Dave
Solved:
Last query:
Last reply:
Revision history for this message
actionparsnip (andrew-woodhead666) said :
#1

if you run:

sudo apt update

Does it run OK?

Revision history for this message
Dave (dfluff) said :
#2

It does. I can do an apt update and upgrade with no problems, having correctly set the apt proxy config.

Revision history for this message
actionparsnip (andrew-woodhead666) said :
#3
Revision history for this message
Dave (dfluff) said :
#4

@actionparsnip: that reddit post describes my problem, but doesn't offer a solution. There is one post in the replies where the OP suggests that he had to configure proxys for apt in both /etc/apt/apt.conf AND in /etc/apt/apt.conf.d/95proxies in order to make it work for him, which seems a little odd, but I gave it a go anyway. It made no difference - do-release-upgrade still behaves as before.

Revision history for this message
Dave (dfluff) said :
#5

Well, on another VM that should be nearly identical to the first, and which is behind the same proxies, do-release-upgrade from 18.04 to 20.04 worked fine, so I guess there's something subtle I'm missing with the first VM. I shall keep digging.

Revision history for this message
Dave (dfluff) said :
#6

Sadly I never worked out what was causing this. I edited do-release-upgrade to add m.DEBUG=True which at least gave mt the following error:

Checking for a new Ubuntu release
result of meta-release download: '<urlopen error [Errno 99] Cannot assign requested address>'
Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings
NO self.metarelease_information
No new release found.

I tried some of the suggested solutions for the [Errno 99] message, i.e. using sysctl to change tcp_tw_reuse, or tcp_max_orphans and tcp_orphan_retries but that made no difference.

Next I did a wget of the meta-release and meta-release-lts files, put them in the root of the VMs own webserver and edited /etc/update-manager/meta-release to point to that URL instead. This at least caused do-release-upgrade to see that there was an update available, but then I got errors stating that the upgrade could not be authenticated. I tried a couple of the suggestions for fixing this issue with no luck.

At this point I gave up, manually edited my /etc/apt/sources.list (see https://stackoverflow.com/a/62463184/4121877 ) and did my own apt update/apt upgrade, which completed successfully, meaning that the machine has now been upgraded to 20.04 without using do-release-upgrade.

Revision history for this message
Dave (dfluff) said :
#7

I'm going to set this to "problem solved", because technically I have achieved my goal of upgrading Ubuntu, but I never worked out why do-release-upgrade was unable to function even though curl and apt worked correctly, and even though a (supposedly) identical VM also worked correctly.