Most shebang implementations seem to behave contrary to my expectations.

As an example, prior to today, I would have expected the following script to output 'debug: true'

#!/usr/bin/env ruby -d
puts "debug: #{$DEBUG}"

Running it, I get this:

% ./test.rb
/usr/bin/env: ruby -d: No such file or directory

This is because the 'program' executed is '/usr/bin/env' and the first argument passed is 'ruby -d', exactly as if you had run: /usr/bin/env "ruby -d"

My expectation was that the above would behave exactly like this:

% /usr/bin/env ruby -d test.rb
debug: true

It doesn't. The workaround, however, is pretty trivial. It's only a few lines of C to get me a program that works as I want. I call the program 'shebang'. Why is it C and not a script? Because most platforms have a requirement that the program being executed from the shebang line be a binary, not another script.

#!/usr/local/bin/shebang ruby -d
puts "debug: #{$DEBUG}"

Now run the script again, with our new shebang line:

% ./test.rb
debug: true

Simple and works perfectly.

jls(~) % sudo yum install subversion
Loaded plugins: refresh-packagekit
Setting up Install Process
Parsing package install arguments
Package subversion-1.4.6-7.x86_64 already installed and latest version

I had hoped (hope is not a strategy) Fedora would have given me svn 1.5 by now. Nope.

To get svn 1.5, rather than ask fedora or google, I just built it myself. I needed to 'yum install neon-devel' and used './configure --with-neon=/usr --with-ssl --with-zlib=/usr/lib' to configure subversion. Otherwise the build/install went fine.

Huzzah!

When you create a loop device from a disk image with losetup, it doesn't bother reading the partition table from the disk image so you don't get the nice and easy access to, for example, /dev/loop0p1 for partition 1.

FreeBSD seems to get this right, as I recall, but Linux does not.

fdisk outputs these devices, but they don't exist:

% sudo fdisk -l /dev/loop0 | grep '^/'
/dev/loop0p1   *           1        1043     8377866    7  HPFS/NTFS
/dev/loop0p2            1044        2088     8393962+   7  HPFS/NTFS

Linux's mount(8) command gives you the '-o offset=XXX' option. The offset is a byte offset, and lets you decide how far into your disk image you want to start. However, fdisk doesn't output in bytes, it outputs in cylinders or sectors.

Not to worry, it helpfully outputs the conversion between the units and bytes:

% sudo fdisk -l /dev/loop0 | grep Units
Units = cylinders of 16065 * 512 = 8225280 bytes

Knowing this, let's use awk to generate the offsets for us:

% sudo fdisk -l /dev/loop0 
  | awk '/^Units/ { bytes=$(NF-1) } /^\// { print $1 "[" $NF "]: mount -o offset=" $3 * bytes }'
/dev/loop0p1[HPFS/NTFS]: mount -o offset=8225280
/dev/loop0p2[HPFS/NTFS]: mount -o offset=17174384640

Now simply mount them with 'mount -t ntfs -o loop,offset=XXXX mydiskimage /mnt' or whatever you want :)

I upgraded my vmware machine from vmware 1.3 to vmware 2.0 beta. The install process was great by comparison to the last two releases. This install was much nicer than the previous one for simple reasons that I didn't have to hack the perl script to not misbehave, and I didn't have to mess around compiling or finding my own vmware kernel modules. Everything Just Worked during the install.

On the downside, vmware-server-console is deprecated. Vmware Server 2.0 uses Vmware Infrastructure, which appears to be tomcat+xmlrpc and other things. The New Order seems to be that you manage your vms with the webbrowser, which isn't a bad idea. However, we must remember that Good Ideas do not always translate into Good Implementations.

The web interface looks fancy, but the code looks like it's from 1998. The login window consists of layers and layers of nested tables and a pile of javascript all in the name of getting the login window centered in the browser. You can see the page align itself upon rendering even on my 2gHz workstation with Firefox. Horrible.

Once you log in, you're presented with a visually-useful-but-still-runs-like-shit interface. The interface itself appears useful and nice, but again fails to respond quickly presumably due to the piles of poorly written javascript involved.

Since VMware thought this was a fresh install, it didn't know about any of my old virtual machines. Adding them using the web interface causes vmware to crash. Oops. So, I found a vmware infrastructure client executable randomly in the package; "find ./ -name '*.exe'" will find it for you. Copied this to my windows box and installed it. I used this tool to re-add my old vmware machines.

Unfortunately, "raw disks" are disabled in this free version of vmware server. I'm not sure why. My Solaris VM uses raw disks for its zfs pool, so this was a problem. Luckily, this is purely a gui limitation and not a vmware limitation. To repair my Solaris VM, I created a new virtual machine with the same features and told it where it's first disk lived (the first disk was a normal file-backed vmware disk image). After that, I looked at the old vm's .vmx file and copied in the lines detailing the raw drives to the new .vmx file:

scsi0:1.present = "true"
scsi0:1.filename = "zfs-sdb.vmdk"
scsi0:1.deviceType = "rawDisk"
scsi0:2.present = "true"
scsi0:2.filename = "zfs-sdc.vmdk"
scsi0:2.deviceType = "rawDisk"

Everything's backup and running sanely now in vmware. Hurray :)

Now that I have all the hardware/bios problems fixed on this system, I've started installing vitrual machines. However, getting vmware to go was no small task.

• The install script failed to build the vmmon kernel module, so I hacked the script to not do it.
• Ubuntu has packages for vmmon and vmnet, but installs them in /lib/modules/.../vmware-server/ instead of /lib/modules/.../misc/ where the vmware init.d script expects them. Hacked that with a symlink. The init script looks for 'foo.o' and the ubuntu package provides 'foo.ko'.
• I couldn't verify my license key because vmware-vmx would fail to run with an error of "No such file or directory". Turns out this really means "You are running a 32 bit binary and I can't find the libraries it needs". The solution is to apt-get install ia32-libs and possibly others.

There are probably other hacks I had to do, but it's 5am and I don't remember them right now.

So my new fancy computer is here. Turns out I originally bought the wrong formfactor motherboard, because I had a silly moment.

Either way, I've now got the system running, but not without some serious battle scars.

Ubuntu happily installed (very slow to partition/newfs stuff though). However, upon reboot, the bios clearly couldn't see the boot drive. My SATA drives are plugged into the on-board Silicon Image RAID controller with no raid configurations set up.

Guessing, I told the raid controller to create a 1-disk concatonation with the disk I wanted to boot from. Voila, the BIOS sees the one disk now and I can boot from it. Linux finds the other two SATA drives when booting.

Sigh..

Also, when Ubuntu says "Computing the new partitions" it really means "I'm creating a new partition right now. Go get something to eat, I'm going to be here for a while." Large partitions, for some reason, take quite some time to create.

-bash-3.1# yum install django
No Match for argument: django
Nothing to do

-bash-3.1# yum install Django
Downloading Packages:
(1/1): Django-0.95.1-1.fc 100% |=========================| 1.5 MB    00:02

Ahh. Clearly.