oli's website

I recently wanted to decommission an old Linux server to further consolidate services and cut back on the total number of machines running. The system was a Celeron 2.4 Ghz PC with 512MB of RAM and a 120GB PATA drive (which had about 15GB free). It had been running CentOS 5 and had run flawlessly while sitting in a wardrobe for years. It had two main tasks: to act as a file server for the household, and to initiate and receive backups from a remote server for a family business.

I first used VMWare Converter years ago when I moved to the Apple platform as I wanted to keep my old Windows XP system image and sell off the hardware. That was about 18 months ago and at that stage Linux support was considered 'experimental'. Performing conversions from Windows machines at that stage could be done live, and that method had worked successfully for me at the time. I eventually salvaged all the data from that Windows XP installation and wiped the image as it was no longer required.

VMWare Converter has since become far more mature and I was happy to find out that it supported RHEL 4 and 5 (and in turn CentOS). It can convert systems to either ESXi or VMWare Server (I'm using this) disk images.

Considering VMWare is giving ESXi away I assumed that VMWare Converter was also free. Wrong! After a bit of Googling I discovered that after signing up for a trial key to other VMWare products download access to VMWare Converter is also available. I burnt the downloaded ISO to a CD then booted from the CD on the old server. I was able to map a network drive over SMB to the destination server then start the conversion progress. This process takes a long time, especially if you only remember when you're 25% of the way through that the machine is sitting on a 10 mbit switch. Luckily I wasn't in a rush.

After the conversion was complete I was left with a directory full of VMDK files as well as the standard configuration files.

I was not really expecting the system to boot without a hitch at first, and it took a bit of troubleshooting to get it all up and running. Thanks to this document on the Red Hat Knowledgebase and this useful post on the Fedora development mailing list I was able to get the system to boot after building a new initrd image.

The couple of hours I spent troubleshooting and reconfiguring the new virtual machine was time worth spent. I was confident from the beginning that I'd be able to get the system converted, and was prepared to spend some time troubleshooting any issues that might come up. Converting the machine saved me a lot of time, since decommissioning the whole server would have involved moving/sorting out all the data that was on there. Having been used as a file server by 4 people over a few years meant that the main shared directory was a complete mess.

Anyone running systems on old hardware which they want to get rid of to save power/clear physical space, etc. should take a good look at how VMWare Converter can help.

If you get this error when trying to mdadm --add a drive back into a mdadm array, then it's probably because the drive you are trying to add has been partitioned incorrectly. To confirm that this is the cause run fdisk -l on all the drives already in the array.

You will notice that all the drives in the array will have the same results for the second line of output:

64 heads, 32 sectors/track, 476940 cylinders

Note those details for the drives already in the array.

Now run the fdisk -l command again on the drive you are trying to add. The results will most likely be different. To resolve this, run fdisk on the drive you are trying to add to the array. Remove all partitions that you might have created before.

In expert mode (press x) you have the following options:


Expert command (m for help): m
Command action
b move beginning of data in a partition
c change number of cylinders
d print the raw data in the partition table
e list extended partitions
f fix partition order
g create an IRIX (SGI) partition table
h change number of heads
i change the disk identifier
m print this menu
p print the partition table
q quit without saving changes
r return to main menu
s change number of sectors/track
v verify the partition table
w write table to disk and exit


You'll need to use options c, h, and s to match up the settings with the existing drives. Once you've done this recreate a partition on the new drive and write the partition table to the disk and exit. Now you should be able to add the drive back into the array.

I wanted to create a second Aperture Vault on a hfsplus volume, but hosted on my network. I could do this using Disk Utility, but due to some complications in the way my Linux Samba server is setup I needed to create the disk images on my Linux server directly.

In this case I am creating a 160GB volume named 'APV.dmg' to match the size of the external firewire drive I use with Aperture.

The following command will create the empty disk image:

dd if=/dev/zero of=APV.dmg bs=1M count=163840

Then to format it as a hfsplus volume:

mkfs.hfsplus -v 'Aperture Vault' APV.dmg

I test copied some files over my LAN (gigE) to this volume when it was mounted on my Mac, and the speeds are equivalent to an external firewire drive. That is, they are limited by the 5400rpm 2.5" SATA drive in my laptop rather than any other component.

I recently created some .dmg files using Disk Utility on my Mac system. I placed these files on my Linux server which hosts them to the network via Samba. The advantage of mounting the .dmg files is that I can use a native Mac file system, which means I can store Aperture vaults on there as well as have these locations indexed/journalised by Spotlight.

I wanted to ensure that I would be able to read the data on these disk images if I was Mac-Less, but most guides indicated I should use the following command:

mount -t hfs -o loop /directory/location_of_dmg.dmg /mnt/mountpoint

This gave errors about bad filesystem type...

It seems later versions of Mac OSX use a filesystem recognised by Linux as "hfsplus", so the following command is required:

mount -t hfsplus -o loop /directory/location_of_dmg.dmg /mnt/mountpoint

This way in case of some disaster which leaves me with no Mac system, I can still retrieve/recover data from the Mac disk images!

If you try and empty your trash can in OSX while a file is in use, you'll be presented with a message that looks like this:

This is not particularly useful, because if you're trying to delete a file you have worked on in multiple applications you won't know what is actually using the file. You can use terminal to force delete the trash, or resort to rebooting to get around this problem - but there's a better way. Open up terminal and enter the following command:

lsof | grep filename

Replace filename with part of or all of the filename that produced the error. You'll get some output like this:

In this case two applications have the problematic file open. PathFinder and Preview. If I close these applications and try and empty the Trash again it will allow the file to be deleted.