Resetting the BIOS on an EeePC 701
This evening, my other half’s Eee 701 broke.
Whenever she turned it on, the green power LED and blue wireless LED came on, stayed on, and nothing else happened. The screen backlight didn’t come on, no power was supplied to the USB ports and the fan did not start to spin.
I tried the usual fixes – taking the battery out, poking a paperclip in the reset button in the back. This didn’t work.
Next I reset the BIOS. To do this, you need to:
- Remove the battery and disconnect from the mains
- Remove the memory cover from the back with a small screwdriver
- Locate the BIOS contacts. Turn it so the memory chip is at the bottom, and look at the top half (the bit that isn’t covered by the memory chip). The contacts are in the bottom-left corner of this, and they are small copper triangles. I’ve circled them in red in this picture.

- You need to short-circuit the two small triangular copper contacts with a screwdriver for a second or two.
- Replace the memory cover and battery, and turn the Eee on again.
- For me, this worked and it booted normally. Your mileage may vary!
Google calendar
I decided that I need to sort out the way I do my personal calendaring.
Currently I only use my phone’s built-in calendar. I nearly always have my phone with me, but it’s a bit of a pain to enter stuff on when I’m sat at a computer anyway, and carrying all that information solely on my phone presents a huge risk of loss, theft or breakage.
I need some kind of centralised store of information that is able to sync with all the devices and programs I want to use, namely:
- Some sort of cross-platform calendar client – mainly for use on Linux but also nice to be able to use similar software if I’m on Windows or OS X.
- Sony-Ericsson P1i (Symbian) built-in calendar
- iPhone, for when I get one
- Web interface, for those times when I’m borrowing a computer and can’t install a client.
Google Calendar seems to be a good choice. It’s flexible and can sync with lots of things.
Linux
So I installed Lightning on all my Fedora and Ubuntu machines. It’s a calendar extension for Thunderbird, which I already use. To install it yourself:
On Fedora:
yum install thunderbird-lightning
On Ubuntu:
apt-get thunderbird-lightning
It’s easy to set up, too. Suppose your Google account is joebloggs@gmail.com, then you would…
- Add a new calendar to Lightning by right-clicking in the Calendar area
- Choose On the Network
- Select CalDAV
- Enter your location as
https://www.google.com/calendar/dav/joebloggs@gmail.com/events - Give the calendar a name
OS X and Windows
It’s a little more work to install Lightning on OS X. You have to download the add-on from Mozilla, and install it in Thunderbird. Same story for Windows.
It’s quite straightforward and there are instructions on the website.
When you’re done, follow the same instructions as for Linux to subscribe to your Google calendar in Lightning.
Sony Ericsson UIQ
Setting up Google Calendar on my Sony Ericsson P1i was a bit of a pain, too. The P1i can’t interact with Google natively, I had to set up an account with Goosync to enable this. Goosync talks to Google, and your phone talks to Goosync using SyncML.
But once you have a Goosync account, you can synchronise a lot of handsets with Google calendar.
So first, you will need to set up an account with Goosync. It’s free and very easy. Goosync will ask you to tie your Goosync account to your Google account.
There’s also an option to have the settings for your phone sent automatically to your handset. However this didn’t work for me so I had to enter the settings manually.
Assuming the sync task on your phone has been set up properly, do a test run to make sure it all works.
- If possible, connect to a wireless network first. If not, 3G will have to do.
- Go to the Main Menu
- Go to Tools
- Go to Remote Sync
- Find the profile that syncs with Goosync
- Find the sync task called Calendar. Make sure it is ticked, and then tap Sync to start off the first synchronisation.
If that worked, you can now run the sync task whenever you like from within the calendar itself.
- Open your phone calendar
- Tap More
- Tap Calendar manager
- Tap Synchronise
That’s all there is to it! Unfortunately there’s no way of making your calendar synchronise automatically at set intervals, but that’s probably a good thing, because you can’t get stung for 3G charges!
iPhone and iPod touch
Coming soon…
Singing the blues
Urban exploration
A friend visited me this weekend. His latest hobby is urban exploration so we decided to give it a go in Bristol. We considered a few sites but eventually we happened upon a factory by chance which shall remain nameless.
Entry was through a small hole in the side. The ground floor doors and windows had been bricked up with breezeblocks, but apparently a past visitor to the factory had somehow removed a block from the wall, leaving a 65 x 22cm hole to squeeze through.

Once inside, it was clear that the owners of the building had taken measures to prevent unauthorised entry.

Most of the ground floor was a no-go area, since the windows had been bricked up and we had no torches, making it impossible to see. The windows on the other floors had not been blocked so sunlight was able to come in.
It was rather creepy. There were pigeons making noises occasionally, making us freeze in our tracks in case the guards were on patrol. Perhaps worse, drips of water fell here and there, and made a rhythmic sound like footsteps. They were especially loud where they fell on sheets of metal, barrels, etc.
The smell was surprisingly agreeable, presumably because it was well ventilated due to the open windows. It smelt slightly of damp but nothing else.
We found some vats which were once used to store chocolate. 12,000 litres of chocolate sounds good to me!

There were several factory buildings and in the alleys between each, glass rooves have been added to create spacious halls. This one was used to house some water tanks.

In the main building there were several floors; all similar. The machines have almost all been removed now, leaving empty space with rows of iron columns.

The building was in generally good condition, but there were some places where wooden floors were unsafe, or walls had holes.

Another of the covered alleyways.

This office looks down upon one of the alleys. It had a huge box of investment reports still inside, but we didn’t have time to sit around and read financial documents.

We saw this sign attached to a door, and wondered what the Collision Films notice was about. Later on we found out via the Internet that McFly filmed the video for Lies in this building. We saw burn marks at odd places on the walls of the building, but from watching this video, I’m not surprised.

A view down into one of the alleyways

Looks like some water has got into this floor, either through a leaky roof or through a broken window.


Goodness knows why there was a door 3 floors up, and goodness knows why the door and its frame have been removed. I didn’t try leaning out, though.

On this floor you can see where machines once stood on the raised areas of the floor.


We found this room in the eaves of the building. It had a service lift and some other interesting features, but the floorboards were broken in places (hence the walking boards between the lift and the doorway, where I stood).

This is the other main shaft in the room, although it’s not entirely clear what it was for. Perhaps some kind of goods lift, or a conduit for some pipes.


Of course, a trip onto the roof was in order, too.

Ten points to anyone who can tell me what this machine is. Twenty points to anyone who dares put their hand in it.

Go on, grab it, I dare you…

There were some deserted offices – many with coffee cups scattered around.

A view down onto one of the covered alleyways. You can see the chocolate vats, the dial of which we saw earlier.

Some high pressure pipes emerge from the floor of this room. I don’t know what they would have carried.

As we concluded our tour, we had a glimpse of daylight from the tiny hole through which we entered and left.

An evil wizard
I painted this scene in art class in year 8 at school.

It’s a pretty poor painting, but I was very proud of it at the time and evidently still proud enough to put it on my website!
I came across it in a box of papers the other day and scanned it in. Unfortunately you can’t see the whole image here – it’s the height of an A4 page, but almost as wide as it is tall, and it wouldn’t all fit in the scanner.
Water
For the summer period, Stu set us Tuesday Challenge Summer Homework. After much um-ing and ah-ing, I settled upon the theme of Water. I’ve interpreted the theme quite loosely – all of these photos have water in them in some way, but not necessarily the focal point.
Llys-y-Fran dam, Pembrokeshire

Tenby harbour, Pembrokeshire

Raindrops on the top of my tent in Pembrokeshire

Sailing across the Baltic sea

Rain lashing down in Copenhagen, Denmark

Sailing through Stockholm archipelago, Sweden

A small boat in Stockholm archipelago, Sweden

Sailing up the narrow Oslofjord, Norway

Oslo docks, Norway

Sunset over the North Sea (note the oil rig)

Fedora, kmod-nvidia and akmod-nvidia
If you have Fedora and an nVidia graphics card, chances are you’ll want to use kmod-nvidia as your graphics driver. It is closed-source, but produced by nVidia themselves and has several advantages over the default open-source drivers that are typically bundled with most distributions – for example, 3D hardware acceleration.
If you have already installed kmod-nvidia – read on, and find out why you should upgrade to akmod-nvidia.
So what’s wrong with kmod-nvidia?
The way it works is simple. For each kernel version, there is a corresponding nVidia kernel module. Keeping the two in sync is a pain, so the packagers at RPMFusion have made a metapackage, simply called kmod-nvidia which tracks the right version of the module for your kernel, e.g. kmod-nvidia-2.6.29.5-191. It’s simple – you install just the metapackage and yum automatically installs the right version of the kernel module.
The problem arises when a new kernel is released, but the packagers of kmod-nvidia haven’t yet released the corresponding kernel module. Sometimes they do it in a few hours but often it takes longer – maybe a day or two. For all the time that the corresponding kernel module doesn’t exist, you cannot update your kernel (and if you are using PackageKit to update your system, you cannot easily update anything!)
What’s different about akmod-nvidia?
akmod-nvidia is different. Rather than downloading someone else’s kernel module when it’s available, akmod-nvidia compiles its own version of the module for whatever kernel you have.
So if you update your kernel, next time you boot into the new kernel, akmod will see that no module exists yet on your system for your kernel, and it will compile it automatically. This takes only one or two seconds – I haven’t noticed the delay on my system.
The advantage is that you don’t have to wait for anyone else to do anything when you update your kernel. It’s also extremely useful if you are running some sort of custom kernel, such as PlanetCCRMA‘s realtime audio kernel.
So how do I install akmod-nvidia?
If you haven’t already got the RPMFusion repository set up on your computer, you will need to do this. (The following code snippet is for Fedora. For CentOS, see the RPMFusion Configuration page.
rpm -Uvh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm
If you already have kmod-nvidia, uninstall it.
yum remove kmod-nvidia
Then you can install akmod-nvidia. It will probably need to pull in a handful of dependencies.
yum install akmod-nvidia
Now if you reboot, akmod will automatically compile your kernel module. You’ll never have to wait for packagers again!
Setting up NRPE remote Linux monitoring with Nagios
This a short and simple guide, explaining how to set up remote monitoring of Linux hosts using NRPE in Nagios. The procedure is simple, but having searched for information on this earlier today I didn’t find a straightforward all-inclusive guide, so I’ve written my own.
These instructions were written with Nagios 3.0.6, and they assume that you already have a working Nagios monitoring server. They assume that the monitoring server was installed from RPM, not from source (some paths will vary).
Configuring the remote server
First, we install the NRPE on the remote server to be monitored. This comes as standard in the Fedora repositories, but on CentOS you’ll need to add the EPEL repository first.
yum install nrpe
We’ll need to make one or two changes to get it working. First open up /etc/nagios/nrpe.cfg and find the allowed_hosts directive. Replace it with the IP address of your Nagios monitoring server.
allowed_hosts=123.123.123.123
Edit your /etc/sysconfig/iptables and add a line to allow port 5666/TCP from the monitoring server’s IP address.
-A INPUT -m tcp -p tcp -s 123.123.123.123--dport 5666 -j ACCEPT
Finally, restart iptables and start NRPE to get it working. We also tell NRPE to start on boot.
service iptables restart service nrpe start chkconfig nrpe on
Configuring the Nagios server
Edit your commands.cfg (usually in /etc/nagios/objects/ if you installed from RPM) and add the following command definition:
define command{
command_name check_nrpe
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}
If this is your first remote Linux host to monitor, create a new host definition file in the same directory as commands.cfg, e.g. linux.cfg. Make a host definition for your new server:
define host{
use linux-server
host_name myserver
alias My Server
address 234.234.234.234
}
Add the following to it as a test to show it works:
define service{
use generic-service
host_name myserver
service_description PING
check_command check_ping!100.0,20%!500.0,60%
}
define service{
use generic-service
host_name yourserver
service_description Load
check_command check_nrpe!check_load
}
Restart Nagios and ensure that both tests work OK. If so, we can move on to some custom test.
Custom checks
The default NRPE client comes with a handful of built-in tests. You can see these near the bottom of nrpe.cfg on your remote machine. But they’re not very exciting, and you’ll probably want to use some of the other checks. If you want to see a list of the available checks in your yum repo, try this:
yum list available nagios-plugins-*
Install any that take your fancy. You’ll need to set up a definition for them in your nrpe.cfg. Use the examples in the file, and try running the Nagios plugin yourself to see if it gives you any clues about the arguments it wants.
Please note, in the default config of NRPE, you cannot use placeholders like $ARG1$, for security reasons. Either hardcode the values in, like
command[check_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/hda1
or enable dont_blame_nrpe=1 further up in the file. There is a security risk associated with doing this. Your funeral!
Restart NRPE again, and let’s move on to setting up your Nagios server. There is no need to create a new command definition, since we are using NRPE again. So open up linux.cfg and let’s add a service definition for the check_hda1 that exists in nrpe.cfg.
define service{
use generic-service
host_name myserver
service_description Disk status
check_command check_nrpe!check_hda1
}
Restart Nagios again and your new checks should appear. Go ahead and install any useful plugins from your yum repository, or have a look at Monitoring Exchange, a great source of free Nagios plugins.
I wrote my own plugins for monitoring your account balance with AQL and checking for the latest installed kernel. One day I will probably get round to uploading them to Monitoring Exchange.
Checking for the latest kernel with Nagios
I’ve just written a module for Nagios that will determine if the currently running kernel is the latest kernel available on the system. It will not tell you if there is a newer kernel in a yum repository or similar.
The main gotcha is that you need an RPM-based system for my script to work, e.g. RHEL, CentOS, Fedora and many others. It is most certainly not bulletproof, but it works on my systems.
All feedback welcome.
N.B. I’ve now published this module on Monitoring Exchange. Please download the plugin from there, as I will keep that copy up to date if there are changes in the future (and the copy on this page is likely to go out of date).
check_kernel
#!/usr/bin/perl -w
# Usage: check_kernel
use strict;
use lib "/usr/local/nagios/libexec";
use utils qw(%ERRORS);
my $running_kernel=`uname -r`;
my $installed_kernel=`rpm -q kernel | tail -n 1`;
my $rpm = `which rpm`;
chomp $running_kernel;
chomp $installed_kernel;
if ($rpm =~ m/no rpm in/i) {
print "UNKNOWN - You must be running an RPM-based systemn";
exit $ERRORS{'UNKNOWN'};
}
if (!defined $running_kernel || !defined $installed_kernel) {
print "UNKNOWN - Test failedn";
exit $ERRORS{'UNKNOWN'};
}
# Strip off the "kernel-" prefix so the strings will match
$installed_kernel =~ s/kernel-//gi;
# Do the test
if ($running_kernel eq $installed_kernel) {
print "OK - running latest installed kernel ($running_kernel)n";
exit $ERRORS{'OK'};
} else {
print "WARNING - reboot to run latest installed kernel ($installed_kernel)n";
exit $ERRORS{'WARNING'};
}

