I attempted to perform a release update today from maverick to natty. Both update-manager -c and do-release-update indicated that no newer releases were available.
After some investigation, I discovered the following was the culprit:
david@marshall:~$ export DEBUG_UPDATE_MANAGER=1
david@marshall:~$ do-release-upgrade
Checking for a new ubuntu release
MetaRelease.__init__() useDevel=False useProposed=False
/etc/update-manager/meta-release: http://changelogs.ubuntu.com/meta-release
/etc/update-manager/meta-release: http://changelogs.ubuntu.com/meta-release-lts
/etc/update-manager/meta-release: -development
/etc/update-manager/meta-release: -proposed
metarelease-uri: http://changelogs.ubuntu.com/meta-release
MetaRelease.download()
result of meta-release download: 'HTTP Error 304: Not Modified'
reading file '/home/david/.cache/update-manager-core/meta-release'
have self.metarelease_information
MetaRelease.parse()
current dist name: 'maverick'
current dist not found in meta-release file
No new release found
david@marshall:~$ ls -l ~/.cache/update-manager-core/meta-release
-rw-r--r-- 1 david david 780 2011-06-30 18:14 /home/david/.cache/update-manager-core/meta-release
david@marshall:~$ cat ~/.cache/update-manager-core/meta-release
<html>
<!--
<?xml version="1.0" encoding="UTF-8"?>
<WISPAccessGatewayParam
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://192.168.10.1/xml/WISPAccessGatewayParam.xsd">
<Redirect>
<AccessProcedure>1.0</AccessProcedure>
<AccessLocation></AccessLocation>
<LocationName></LocationName>
<LoginURL>http://192.168.10.1/login?target=xml</LoginURL>
<MessageType>100</MessageType>
<ResponseCode>0</ResponseCode>
</Redirect>
</WISPAccessGatewayParam>
-->
<head>
<title>...</title>
<meta http-equiv="refresh" content="0; url=http://192.168.10.1/login?dst=http%3A%2F%2Fchangelogs.ubuntu.com%2Fmeta-release">
<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="expires" content="-1">
</head>
<body>
</body>
</html>
---------------
As you can likely tell, I was behind a captive portal on 2011-06-30. Update manager [automatically] attempted to retrieve the meta-release file at that time, and--even though it likely had a valid file before--grabbed the captive portal page, because it was newer. Now when update-manager-core calls self.download(), the following is added:
req.add_header("If-Modified-Since", time.asctime(time.gmtime(lastmodified)))
The meta-release file on the changelog.ubuntu.com server hasn't been changed since I used the captive portal (and likely only changes when a new release cycle begins), so the server returns HTTP 304 (not modified), and the client relies on the cached copy on disk (which is bogus). Neither MetaReleaseCore::download() nor MetaReleaseCore::parse() really care that the file on disk is obviously not the right format, with ::parse() simply returning false to nothing (unchecked return value in ::download()).
Given the small size of meta-release (6.7k), it hardly seems worth the effort of adding complexity necessary to avoid potentially re-downloading this data occasionally, but I suppose it's your prerogative. One workaround while still achieving this goal might be to check the server date is newer *OR* filesize does not match with a HEAD request prior to GET (and without If-Modified-Since), though this still leaves the window open for the corner case of a captive portal page exactly the same size as the meta-release file.
Additionally, if ::parse() returns false, it may be worthwhile to delete the .cache version of the meta-release file (and try to download it one more time?) (and tell the user something more useful than "no update available"?).
ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: update-manager-core 1:0.142.23
ProcVersionSignature: Ubuntu 2.6.35-30.54-generic 2.6.35.13
Uname: Linux 2.6.35-30-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Thu Jul 7 16:40:27 2011
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
ProcEnviron:
LC_TIME=en_DK.utf8
PATH=(custom, user)
LANG=en_US.utf8
SHELL=/bin/bash
SourcePackage: update-manager
Thanks for reporting this bug and for the detailed report, and sorry for having taken some time to get a response. The bug seems confirmed according to the data you provide.