MetaRelease.download() Issue after Captive Portal
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
update-manager (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Eoan |
Fix Released
|
High
|
Unassigned |
Bug Description
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_
david@marshall:~$ do-release-upgrade
Checking for a new ubuntu release
MetaRelease.
/etc/update-
/etc/update-
/etc/update-
/etc/update-
metarelease-uri: http://
MetaRelease.
result of meta-release download: 'HTTP Error 304: Not Modified'
reading file '/home/
have self.metareleas
MetaRelease.parse()
current dist name: 'maverick'
current dist not found in meta-release file
No new release found
david@marshall:~$ ls -l ~/.cache/
-rw-r--r-- 1 david david 780 2011-06-30 18:14 /home/david/
david@marshall:~$ cat ~/.cache/
<html>
<!--
<?xml version="1.0" encoding="UTF-8"?>
<WISPAccessGa
xmlns:xsi="http://
xsi:noNamespa
<Redirect>
<AccessProcedu
<AccessLocatio
<LocationName>
<LoginURL>http://
<MessageType>
<ResponseCode>
</Redirect>
</WISPAccessG
-->
<head>
<title>...</title>
<meta http-equiv=
<meta http-equiv="pragma" content="no-cache">
<meta http-equiv=
</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.
The meta-release file on the changelog.
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
ProcVersionSign
Uname: Linux 2.6.35-30-generic x86_64
NonfreeKernelMo
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
Changed in update-manager (Ubuntu): | |
importance: | Undecided → Medium |
Changed in update-manager (Ubuntu): | |
status: | Confirmed → Triaged |
tags: | added: rls-cc-incoming |
tags: |
added: rls-ee-incoming removed: rls-cc-incoming |
tags: | removed: rls-ee-incoming |
tags: | added: id-5ce6d6855257155f211b5d3f |
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.