Over the years I’ve replaced the hardware on quite a number of broken servers. Sometimes swapping the disks just works and in other occasions it fails and the disks are not detected. This is caused by missing SATA drivers in the initrd. This is easily fixed by booting from a rescue CD and creating a new initrd with the right drivers.

When you boot from a rescue CD you can check the SATA driver that is loaded by doing the following:

root@server1 [~]# lsmod|grep sata
sata_nv 22217 2
libata 105757 1 sata_nv

In this case sata_nv is used. To check if this is available in the initrd on the original disks you have to unpack the initrd that is used for booting. First chroot into the systemimage from the rescue image.

chroot /mnt/sysimage
mkdir /root/temp-initrd
cp /boot/initrd-xxx.img /root/temp-initrd
cd /root/temp-initrd
gunzip < initrd.img | cpio -i --make-directories

In the lib directory that is just unpacked you can see the modules that are included:

root@server1 [~/temp-initrd/lib]# ls
./ ../ dm-mod.ko ext3.ko jbd.ko scsi_mod.ko sd_mod.ko

This means the sata_nv driver is not included. This is causing the boot problems. To fix this we need to rebuild the initrd for the correct kernel with the right drivers:.

mkinitrd --with=sata_nv --with=raid1 /boot/initrd-2.6.x-y.z.1.el5.img 2.6.x-y.z.1.el5

Make sure to specify the right kernel, because if you boot from a rescue CD you are probably running a different kernel then is actually installed on the system you are replacing the disks for.

Last week I was looking at testing SplashID Enterprise. While a first installation with the MySQL database running on a Mac Mini was working fine, the installation with the Splash Enterprise Admin client failed when the database was running on a default Linux (CentOS) installation. I tried contacting SplashData support, but they could not help me, so I tried to debug myself. I enabled the query log so I could see the queries executed by the Admin client. These queries showed that SplashID ran queries reffering to specific tables in upper case (eg. MYSQL.USER). I manually tried some of these queries and these queries failed with “unknown table” error.

Now I found the problem, I thought it was easy to fix it. I just had to make MySQL case-insensitive. This sounds easier than it actually was 🙂 Lots of articles talked about the character set and the collation, but these only affect the data in the tables, not the actual table name itself. Some googling let met to the lower_case_table_names setting in MySQL. It appears that Windows, Unix and MacOSX all have different default settings, and therefor behave differently.

Setting the following line in the my.cnf in the [mysqld] section solved my case problem with SplashID. MySQL now changes all table names to lower case.

lower_case_table_names=1

Update: I have not tested SplashID Enterprise yet, so I don’t know if it is any good 🙂