Trick or Treat!

Tonight I gave out candy while working on my laptop, which isn’t tooo bad since at least I left the lab for Halloween! Trick-or-treat in Pittsburgh ran from 5:30-7:30, according to KDKA. At 5:30 it was still quite light since daylight savings time still hasn’t ended. Since I had the laptop open, I tracked my trick-or-treaters:

2 @ ~5:20

1 @ 5:58

1 @ 6:06

1 @ 6:13

3 @ 6:38

1 @ 6:43

2 @ 6:59

1 @ 7:05

1 @ 7:06

7 @ 7:19 ** out of candy **

Less than half of them actually said “Trick-or-treat.” A similar fraction failed to say thank you. A smaller fraction actually blatantly grabbed multiple pieces of candy. I let this slide since their hands are a lot smaller than mine.

I decorated for the occasion by putting a bike helmet in the middle of a sheet, picking the sheet up around the helmet, and then tying some rope around the base of the helmet to basically make a sagging head of a ghost. It worked pretty well, so I made another one using our ice cream maker (essentially a plastic ball).

Advertisements

Primary interface not eth0

I’ve been having some issues with my virtual machines running Debian Etch coming up with their primary interface as eth2 or eth3, even though there is only one “physical” (it’s virtual, actually) NIC in the system. Well, another kind soul has had the exact same problem: Primary interface not eth0. Debian caches the MAC address used so that interface numbers are somewhat persistent. The fix? Look at the contents of /etc/udev/rules.d/z25_persistent-net.rules. If you’re too lazy for that, just delete the file. Don’t forget to reboot.

Debian’s bootcd is cool

Debian’s bootcd allows you to make a bootable ISO image from a running Debian system, literally. It will be an identical copy (wrt packages installed) of the running system. There are options to make configuration changes as necessary (IP addresses, for example). Debian Administration has a short article about it. I’m creating my first ISO now, we’ll see how it goes.

My first ISO didn’t boot. The kernel panicked because it couldn’t mount the root filesystem. The last three lines of output:

Begin: Mounting root filesystem... ...
/init: /init: 151: Syntax error: 0xauto
Kernel panic - not syncing: Attempted to kill init!

This is caused by the default Debian kernel including the CD-ROM drivers as modules, thereby requiring their presence in an initial ram disk (initrd). The default initrd is not properly structured to allow for booting from the CD. The bootcd maintainers thought of this. I did an `aptitude install bootcd-mkinitramfs discover` and then tried again. The resulting ISO booted nicely, though it would have been nice if the documentation for bootcd was more explicit that the bootcd-mkinitramfs package was necessary.

I still have three more issues to resolve:

1. My NIC came up as eth1 instead of eth0; see my next post.
2. The ISO included a compressed root filesystem. My ISO was only 200MB so I’m hoping the whole system will fit without compression. I set COMPRESS=”no” in /etc/bootcd/bootcdwrite.conf.
3. My files in /var/www were gone; they are now in /var.ro/www. Apache doesn’t like that. I moved www to /home/www and made sure it wouldn’t be included in NOT_TO_RAM. I could have tried to monkey around with symlinks but I want the performance of serving out of RAM.

SAS vs SATA Part 2: Adaptec 3405 SAS Controller + Tyan n3600R Mobo

Recently I mentioned that I needed some SCSI action in order to get VMware ESX server to play nice, and detailed my learning experiences with SAS and SATA. I now have in my possession an Adaptec 3405 SAS Controller, with the objective being to install it in a system based on a Tyan n3600 Motherboard. This in itself became another saga.

The Tyan board has two PCI-Express slots, a x8, and a x16. For whatever reason, only the x16 slot aligns with a mechanical slot on the back of the case. I deem this alignment to be important because the controller will have a fairly substantial cable hanging off of it inside the case, and PCI-Express x4 is not a very substantial (mechanically) connector.

The first thing I tried was installing the card in the x16 slot which provided nice mechanical stability. Upon rebooting the machine, the monitor never came out of sleep mode (i.e., its power LED stayed orange and never turned green), even though I was able to press NumLock and get the keyboard’s LED to blink for a while (not indefinitely; the system eventually froze). Bummer, no luck.

The next thing I did was remove the metal bracket from the back of the card and insert it in the x8 slot. This time, the card worked as expected. I tried installing ESX server but ran into a problem inserting the aacraid_esx30 module where the error message was to the tune of invalid module parameters. Google provided very little of any use, except for one message from a guy who suspected an interrupt problem and that the error message was spurious. I packed it in and gave up on the x8 slot. This was two days ago.

Today, I decided to call Adaptec Tech Support. I was put in touch with a very helpful woman who was patient while I connected, disconnected, rebooted, and generally messed with my system. Her conclusion, and it was a good one, was that I should update the BIOS of my motherboard and of my controller card.

Step 1: Update the BIOS of the motherboard. I updated from v1.01 to v3.00 on the Tyan S2912 BIOS update site. After doing this, my system booted as expected with the card in the x16 slot. This solves my first problem: get the system to boot with the Adaptec card, but it says nothing about whether ESX Server will like the card.

I decided to give the ESX Server install a try before updating the firmware on the controller card. The installer hung while “Loading aacraid_esx30 driver…”. Booo. The diagnostic 7-segment display on the motherboard seems to be stuck, oscillating between two values. It happens so quickly that even my digital camera can’t get a good capture, but it looks like the values are 46 and 86 (hex). I guess I will be applying the Adaptec BIOS updates.

The BIOS on my adaptec card as I received it is version 12415. The Adaptec SAS-3405 BIOS Update site showed two newer versions: 12814 and 15323. The tech support woman suggested that I update iteratively, instead of directly to the latest version. Further, each update is sufficiently large that it requires two floppy disks, plus the DOS boot disk, for a total of 5 floppies involved in the updating.

Upon booting the ESX Server installer in text mode, the message “Loading aacraid_esx30 driver…” appears for about 5 minutes before asking me to test the install CD. I selected “Skip”, and then the same “Loading aacraid_esx30 driver…” message returned for many more minutes. Eventually, this too timed out and the installer continued. I also have an IDE disk in the machine and this is the only drive listed when installation reaches the Partitioning step. This is insufficient since it leaves me with nowhere to store guest VM images.

I came across a forum post entitled “aacraid_esx30 / Adaptec RAID 2120S” where somebody else had the same problem. No resolution is posted, however. Adaptec lists ESX Server 3 as supporting the SAS-3405 with no additional driver needed.

To be continued…

root=/dev/ram0

My goal is to create a linux installation that can run totally diskless and stateless (i.e., if anything goes wrong during runtime, a reboot fully restores the original system image). This kind of thing is useful with clusters of large numbers of identical (or nearly so) machines. No NFS root file system, no hard drive, nothing. It seems there are two ways to boot it: network and read-only CD-ROM.

I’m playing around with this using virtual machines, so I’m not sure which will offer better performance. I have had success booting the Debian Etch installer by following an article entitled Setting up a server for PXE network booting. I used the dnsmasq setup because I already have a Debian VM which runs dnsmasq to serve as a DHCP server and NAT box for my diskless VMs.

This proves that my server is configured correctly, and that my guest VMs will boot from it. However, I want an operation guest image, not the Debian installer.

I then found an older article on Diskless Linux which had a useful Makefile for working with the compressed root filesystem image. It suggested copying files into the new root filesystem image manually, a process that doesn’t much interest me, especially since I’ve used debootstrap successfully many times in the past. I’ve also used systems based on BusyBox in the past, so I expect to come to some sort of resolution.

Damn Small Linux Diskless Boot worked when I mounted the ISO, copied its contents to my tftpboot folder, and added a sensible entry to my pxelinux.cfg/default file:

LABEL dsl_lowram
KERNEL dsl/linux24
APPEND ramdisk_size=100000 init=/etc/init lang=us apm=power-off vga=normal initrd=dsl/minirt24.gz noscsi noideraid nosound nousb nofirewire noicons minimal nomce noapic noapm quiet BOOT_IMAGE=knoppix

I want to get rid of all the X support and install a web server.

To be continued…

Subversion and post-commit script errors

SVN does not handle errors with the post-commit script very gracefully. I’m using CommitMessage 2.0. For example:

$ svn commit -m "test2"
Sending paper/intro.tex
Transmitting file data .svn: Commit failed (details follow):
svn: MERGE request failed on '/svn/paper'
svn: MERGE of '/svn/paper': 200 OK (https://svnserver)

The problem was that the particular user who performed the commit did not have an entry in the [userMap] section of commitmessage.conf.

Prior to identifying the problem, this particular client was version 1.2.x and the server was 1.4.1. In that case the error message was:

$ svn commit -m "minor edit"
Sending paper/intro.tex
Transmitting file data .svn: Commit failed (details follow):
svn: MERGE request failed on '/svn/paper'
svn: The MERGE request returned invalid XML in the response: XML parse error at
line 23: Opening and ending tag mismatch: None line 0 and S:post-commit-err
. (/svn/paper)

I’m not sure if this old client would have worked with the current server had commitmessage.conf been correctly configured.

UPDATE 2009.03.23: I just ran into all these problems yet again upgrading from Debian Etch to Debian Lenny (i.e., from SVN 1.4 to SVN 1.5). I haven’t fixed the commit script yet but one way to prevent so many client-side apparent failures is to add “exit 0” to the end of /var/lib/svn/REPO/hooks/post-commit. A non-zero exit code from post-commit triggers all sorts of pain. I prefer that the commit emails fail silently so people can go about their work.