How to upgrade Ubuntu 10.4 / 10.10 Maverick to the latest version of Ubuntu Linux?

Are you seeing errors like Failed to fetch binary … 404 Not Found?

Ubuntu have dropped support for 10.4 & 10.10.  By default now when you run the apt-get / apt-update and sudo do-release-upgrade you’ll start getting 404 errors to say that various repositories  can’t be fetched / found.

For examples you’ll be seeing something like this:

Failed to fetch
404 Not Found

Failed to fetch
404 Not Found


This is because Ubuntu have moved them from their archive site to their site but your Ubuntu Linux installation doesn’t know about that site.  I’m not sure why they do this because it must be causing pain for thousands of users as they come to upgrade.  I know they’ve had plenty of time to upgrade but lots of people don’t upgrade until they have a real business driver to do so.


How to fix your Ubuntu Linus 10.4 / 10.10 Maverick so you can upgrade it.

To fix the 404 issue so that your Ubuntu Maverick installation can find the repositories so that it can do the upgrade you need to update your sources.list file.

To do that issue the sudo vi /etc/apt/sources.list command

Replace the existing lines with the following:

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

save the file and then issue the following commands:

sudo apt-get clean
sudo apt-get update

sudo apt-get install update-manager-core

sudo do-release-upgrade

The do-release-upgrade command will now upgrade you to the next release eg 11.04.  When that finishes do it again to go to 11.10 and again to go to 12.04 etc until your system is up to date or at the level you want it.

This assumes you are happy to upgrade from the command line.

Image Resize and thumbnails not working in WordPress.

I had a strange problem on a WordPress blog site today that I haven’t seen before.  The image resize and thumbnail generation wasn’t working.  Normally when you upload an image to WordPress it creates 3 versions of the image at different sizes but this wasn’t happening and I was just left with the large original file.

When I went to insert the image into a post the resize options were disabled (or greyed out).

Wordpress resize disabled

WordPress resize disabled

At first I thought it might have been caused by a problem with the Theme I was using but the problem continued after switching back to one of the standard themes.  Then I checked the directory permissions incase the WordPress install didn’t have authority to write the resized images back to the file system, but again that was all fine.

It turns out that WordPress uses the Apache PHP5-GD library to do it’s resizing and for some reason on the build of Ubuntu Linux on the server I was using this wasn’t installed by default.  To check this I just put a phpinfo(); into a small dummy php file and ran it from the browser.   What you should see is something like this:

Is Apache gd installed?


If you don’t see this then it’s simple to install with

sudo apt-get install php5-gd

and then restart Apache and you’re done.

Improve your website by getting to know your log files.

What are log files?
When someone visits your website they are making requests on your web server.   The details of these requests are recorded in your web server log files.  Most websites in the World run on Apache web servers and that’s what I’m going to be talking about in this article.  If your website is using another type of web server (for example Microsoft IIS), the principles are the same but the commands and tools you need to use to analyse the files will differ.

Types of log files
By default the Apache (HTTPD) web server creates two log files, ‘acccess_log’ and ‘error_log’.   If you are not sure where these files are on your server then you will need to look at your server config.  You should find two lines like these:

CustomLog  /var/www/
ErrorLog   /var/www/

These tell the Apache web server where to write the log files.

What gets logged?
Unless you have specifically reconfigured your web server it will probably be writing log files in the Common Logfile Format (CLF).    The log file will contain records like the one below: – – [10/May/2009:17:44:17 +0100] “GET /store/product-images/PC1.jpg HTTP/1.1” 200 16989 “” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729)

This may look complicated and might put you off going any further but it really is very simple.  Lets break this down one element at a time. – This is the IP address from where the request on your web server was made.

– You will generally always just see a hyphen in this field.  It should contain the id of the person making the request but for security reasons this is seldom enabled and would be unreliable if present as it would be easily spoofed by hackers.

– You will also generally see a hyphen in this field.  If your website protects some pages or directories by using HTTP authentication you will see the user id of the person making the request in this field, once they have been authenticated.

[10/May/2009:17:44:17 +0100] – The date of the request.

“GET /store/product-images/PC1.jpg HTTP/1.1” – the request made by the web browser or search engine.

200 – the HTTP status code the server gave in response to the request.  This is explained in more detail below.

6989 – the number of bytes sent back to the person who made the request.

“” – the referring site or page.

“Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729)” – the browser/ search engine bot / platform string.

What to look out for in log files.
When I look at log files I typically start by looking for requests, which have resulted in a 404 response.  This means that someone has requested a page (or resource such as a graphic), which doesn’t exist.  If you find this happening then look at the referring site or page.  If the referrer is you own site then you need to get this broken link fixed.  If the request is coming from another site you might need to contact the sites owner and ask them to update the link.  In the real world getting a site owner to update a link can be quite difficult, therefore if the error is happening a lot consider setting up a 301 “Permanently Moved” redirect.

Once you’ve addressed any 404 errors, you should then review any requests, which have resulted in a 500 response.  Status 500 indicates a runtime error on your web server typically when generating a dynamic CGI (PHP, JSP, ASP etc) type web page.  Look at the time this error happened and then look around that time in the error_log file for more information.

In a future article I will look in more detail at other status codes and some of the tools you can use to explorer you log files.

If you have any tips for great ways to use log files or questions please leave a comment below.