Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to upgrade an old ubuntu server from 8.10 (Intrepid) to 9.04 (Jaunty). But it fails.

root@server1:/# do-release-upgrade
Checking for a new ubuntu release
Failed Upgrade tool signature
Failed Upgrade tool
Done downloading
extracting 'jaunty.tar.gz'
Failed to extract
Extracting the upgrade failed. There may be a problem with the network or with the server.

Does anyone have an idea why I get this error and how to fix it?

UPDATE: I think i might have tracked the problem down.

My /etc/update-manager/meta-release looks like this:



If i go to it has this info for Jaunty:

Dist: jaunty
Name: Jaunty Jackalope
Version: 9.04
Date: Thu, 23 Apr 2009 12:00:00 UTC
Supported: 0
Description: This is the 9.04 release

Those links starting with are broken since jaunty is EOL.

I guess i could fix this by copying this file, replacing "archive" with "old-releases", host the modified file somewhere and change the url in the meta-release file. Is this a good solution or will it make me run into worse problems?

share|improve this question
Maybe i should add that the downloading part here is just a split of a second. I doubt that anything is downloaded for real. – Martin Jun 8 '11 at 12:36
up vote 5 down vote accepted

8.10 and 9.04 are both unsupported, you'll want to keep going all the way up to 10.04.

Canonical maintains documentation on how to upgrade from a release after its repositories go dark here.

Add the following to /etc/apt/sources.list:

deb intrepid main restricted universe multiverse
deb intrepid-updates main restricted universe multiverse
deb intrepid-security main restricted universe multiverse

Update with the new repositories, and upgrade packages against the intrepid repository:

apt-get update && apt-get dist-upgrade

Then you can use the release upgrade tool:


Rinse and repeat, replacing intrepid with jaunty in the sources.list to be able to move up to 9.10. To move to 10.04 you shouldn't need to do manual modifications, as it looks like the karmic sources are still in the original location despite being past the end of support.

share|improve this answer
I've done exactly this but i still get the same error :( – Martin Jun 8 '11 at 0:55
That may be caused by a proxy, especially an apt-cacher proxy - do you use one of those? – Shane Madden Jun 8 '11 at 1:36
Not that i know. I'm a total noob at linux. Is there a way to see if i use it? – Martin Jun 8 '11 at 9:16
Run apt-config dump | grep Acquire::http, this will show you the relevant config. If it is in there, find the config (either in /etc/apt/apt.conf or a file inside /etc/apt/apt.conf.d/) and remove it, then try the upgrade again. – Shane Madden Jun 8 '11 at 14:42
That doesn't give any output. Did you see my update to the question? – Martin Jun 8 '11 at 15:54


I think the problem can be solved in a much simpler fashion without having to use another machine. Here is what I did:

Copied the old (incorrect) file from to a local file (say) /etc/meta-release.rvg I modified /etc/meta-release.rvg so that "archive" was replaced by "old-releases"

Modified /etc/update-manager/meta-release so that it pointed to my local file rather than the incorrect URI on the ubuntu site - here is what it looked like after my change:


URI = file:///etc/meta-release.rvg




I then ran do-release-upgrade and everything worked like a charm


Rajendra Gokhale

share|improve this answer
Thanks. This worked for me. – MountainX Dec 26 '11 at 4:58
Thank you! Great answer! – QuantumMechanic Mar 27 '12 at 1:14
This is the right way to get around this junk, thanks so much! – Bartek Apr 3 '12 at 23:50

After coming across this problem again, I found an even easier answer: put this in the servers /etc/hosts file:

the server isn't name based so you can point at old-releases and it works.

Note: Remember to remove the line from HOSTS when you're upgraded


share|improve this answer

I just came across this problem myself, and being remote from the machine I wanted to upgrade instead of flat install it (plus I had lots of data I didn't want to have to move first!)

The issue as you said is that the files no longer exist in their know locations:

I created a quick php proxy file to get round this (I don't want to release my mirror so I will release the proxy file and you can do it yourself).

You need another webserver setup to receive requests from (enter that as your domain name)

In the htdocs folder place index.php with these contents: (I apologise for the poor formatting - I couldn't get it to look right in the wysiwyg!)



$newDomain = '';

$is_file = false;

if(strpos($_SERVER['REQUEST_URI'],'.')==0) { $tmp = $_SERVER['REQUEST_URI'].".html"; } else { $tmp = $_SERVER['REQUEST_URI']; $is_file = true; }
if(!is_file($dir.$_SERVER['REQUEST_URI'])) { $file = file_get_contents($newDomain.$_SERVER['REQUEST_URI']);

  $dir = 'cache';         $folders =

explode('/',$_SERVER['REQUEST_URI']); ##Make main cache folder if(!is_dir($dir))mkdir($dir,0777); ///Make cache folders for($i=0;$i



$ch = curl_init($newDomain.$_SERVER['REQUEST_URI']); //curl_setopt($ch, CURLOPT_HEADER, 1); ob_start(); $c = curl_exec($ch); $ob = ob_get_clean(); $code = curl_getinfo($ch, CURLINFO_HTTP_CODE); $type = curl_getinfo($ch, CURLINFO_CONTENT_TYPE);

if($is_file) { header('Content-Type: ',$type); header("HTTP/1.1 200 Ok"); readfile('cache'.$tmp,$file); } else { header('Content-Type: ',$type); header("HTTP/1.1 200 Ok"); die($ob); }

Now create .htaccess and put this in it:

allow from all

RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ /index.php [QSA,L]

create folder htdocs/cache and chmod it 777

go onto the machine you are trying to upgrade and edit /etc/hosts (nano /etc/hosts) and enter a line:


replacing the XXX's with the ip address of your new proxy.

you might have to run '/etc/init.d/nscd restart' and '/etc/init.d/networking restart' (on the machine to be upgraded) to make sure your DNS cache is cleared and your new proxy is used as the IP for

run do-release-upgrade again.

It's hacky but it got the job done for me using another dedicated box I had.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.