Life’s an ocean with too much commotion

This howto will show you how to boot your upgraded Ubuntu properly on a Toshiba Tecra S3 laptop. Note that this workaround will not work when installing Ubuntu for the first time on your laptop. If so, you will have to change some BIOS settings so that the SATA controller will be recognized as a generic IDE controller. If not, follow this procedure:

When booting a Toshiba Tecra S3 for the first time, it will fail trying to find the SATA harddisk.

A kernel and initrd image has been provided to boot your linux distribution. The initrd image provides a pseudo filesystem (loaded in RAM) which will execute some bash scripts. These bash scripts will do a lot of checks and configuring and load various modules to detect as much hardware as possible needed for booting your linux distribution. The modules that are loaded are specified in the ‘conf’ directory (modules, initramfs.conf) and the ‘/etc/modprobe.d’ directory.

What goes wrong in this case, is that the ‘ata_piix.ko’ module gets loaded before the ‘ahci’ module. In fact, the ‘ata_piix.ko’ module may not be loaded at all. It is a low-level SCSI driver that only needs to be loaded for Intel PIIX/ICH ATA controllers. So what needs to be done is make sure that the ‘ata_piix.ko’ module is unloaded before the ‘ahci.ko’ module gets loaded. This can be done in the bash scripts that are executed in the initrd image.

Follow this procedure to do so:

1. Boot your Ubuntu distribution with the recovery mode kernel
2. Wait until the initrd scripts time out. This can take up to 5 minutes. After timeout you will be thrown in a shell, forked by the initram process.
3. In this shell, execute the following commands:

# modprobe -r ahci
# modprobe -r ata_piix
# modprobe ahci
# mkdir /mnt
# mount /dev/sda1 /mnt -t ext3
# chroot /mnt
# mkdir /tmp/unpacked
# cd /tmp
# cp /boot/initrd.img-2.6.22-14-386 initrd.img-2.6.22-14-386.gz
# gunzip initrd.img-2.6.22-14-386.gz
# cd /tmp/unpacked
# cpio -id </tmp/initrd.img-2.6.22-14-386
# vi /tmp/unpacked/scripts/functions

4. In this file you will find a function load_modules(). Insert a line on top of this function:

modprobe -r ata_piix 2>/dev/null 1>&2
modprobe -r ahci 2>/dev/null 1>&2

5. Save the file and execute the following commands:

# vi /tmp/unpacked/conf/modules

6. Add the following entry on top of the file

ahci

7. Save the file and execute the following commands:

# cd /tmp/unpacked
# find . | cpio -o -H newc | gzip -9 > /boot/initrd.img-2.6.22-14-386.new
# vi /boot/grub/menu.lst

8. In this file you have to rename the initrd image filename to the new one:

initrd /boot/initrd.img-2.6.22-14-386.new

9. Execute the following commands to exit chroot environment, and reboot

# exit
# reboot

Note: This works for Ubuntu Feisty too.

Some months ago I’ve bought a Nikon d70 (second hand).

Since two weeks my camera is having some green pixels on every picture I take, especially on pictures where it’s dark or with a great exposure value.

I’ve created a script that will parse a picture and interpolate saturation, hue and luminosity values from the second left and second right pixel. So if you have a hot pixel at x,y, it will use the interpolated HSL value of pixels at positions x-2,y and x+2, y. When the given coordinates of the hot pixels are out of range, it will assume the picture is in landscape position and flip the x and y coordinates. With an extra option, it will interpolate all pixels from position x,y to x,bottom of picture. This was necessary because at every picture I took, there was a weak green line visible to the bottom of the picture.

To parse the image files, I use the rMagick library.

Click here to download the hotpixelcleaner gem.

Note: This script has been created to fulfill my needs, but comments are welcome of course.

Here’s a short howto:

$ sudo apt-get install librmagick-ruby1.8
Unpacking librmagick-ruby1.8 (from .../librmagick-ruby1.8_1.13.0-1_i386.deb) ...
Setting up librmagick-ruby1.8 (1.13.0-1) ...
$ sudo gem install hotpixelcleaner-0.0.1.gem
Successfully installed hotpixelcleaner, version 0.0.1
$ hotpixelcleaner --help
Usage: /usr/bin/hotpixelcleaner -f <imagefile>

Options are ...

--co (-c)
Coordinates of pixel to transform 'x,y'
--help (-H)
Print help information
--image (-f)
Use this image file
--out (-o)
Filename to write results to
--to-bottom (-b)
Process image from the given coordinate to the bottom of the picture
--usage (-h)
Print usage information

$ hotpixelcleaner -c 5,5 -f foo.jpg -o bar.jpg -b
Image has been saved to bar.jpg

At June 20, I.T. Works will organise a seminar in Hotel Sofitel Brussels Airport (Diegem). This seminar will focus on Virtualisation and how it will ease business processes and reduce TCO’s (Total cost of ownership). During this day, my colleague Kris Buytaert and me will present the open source product Xen. I will mainly focus on dynamic build environments with Xen.

More information about this seminar can be found at the website of I.T. Works.

Today I’ve played a bit with the Cisco Discovery Protocol.
This protocol is primarily used to obtain information about neighbouring devices:

• IP addresses
• Hostnames
• IOS versions
• Type cisco devices
• on which interface they are connected
• …

This means that you can test your network’s connectivity on layer 2 level.

The beauty is that this information is accessible through SNMP, in two different tables:

• cdpInterface
• cdpCache

I am mostly interested in the cdpCache table (which contains all the data as specified above), the cdpInterface is primarily used to configure CDP on the corresponding Cisco device.
The complete OID list is available on google.

I’ve made a perl wrapper script that recursively search for new devices.
This is how it works:

First you need a seed. In a network where everything’s connected to eachother (that means every Cisco device has at least one neighbour) you must have a starting point.
Choosing this seed is very important, because it will produce a network topology from the seed’s perspective. This seed can be specified as a hostname or IP address.

I use the perl library SNMP::Info(::CDP) for querying this information.
It will recursively search for the neighbours of the neighbours of the neighbours.. until every neighbour has been detected.
All discovered neighbours can be put into a queue. All discovered neighbours that have been queried for neighbours are pushed in an array so that they can be skipped if they are put in the queue again, eg. when there’s a loop in your network.
Yes this sounds extremely like a graphing algorithm
This could all be stored into hash tables or some other data storage type.
I’ve simply printed out a cisco device and it’s neighbours when all neighbours of that cisco device have been detected and put into the queue.

The past month I have been playing with Puppet. It’s a configuration management tool that facilitates managing configuration resources on multiple machines. Especially when handling lots of machines which serve different purposes, it’s not that easy to keep your configuration data up to date.

Suppose you have a /etc/passwd file that should be the same on a certain amount of machines. First you have to make sure this file is present on these machines, then you have to monitor the consistency of this file on these machines and finally you have to make sure that, when having a new version of this file, it gets updated the same way and on all machines.
Also, there can be a necessity to restart some services when updating certain files, or executing some custom commands to make sure the new file is used. This, and unlimited more examples are the main features of a descent configuration management tool.

Puppet, (mainly) developed by Luke Kanies, has main advantages towards other configuration management tools (such as CFEngine, Bcfg2, …). Also, it’s easy to extend the features of puppet, while its developed in Ruby and works with modular types of configuration data.

I’ve been helping the Puppet community with searching for a way to get Puppet high available on a network of machines.
More about this can be read here.

Redhat is currently developing some tools which facilitate the configuration creation section of Puppet. When deploying a certain amount of services and configuration files, they can be easily converted to a puppet configuration file. This project is called Cft.