I saw I, Robot this past weekend, and I liked it a lot more than I thought I would. The previews give the impression that the movie is a "Frankenstein's monter" style story — the very sort of thing Asimov was rebelling against when he developed the Three Laws of Robotics. In reality, the story actually fits reasonably well into the framework of the three laws, however. While it doesn't have the same plot as any of the stories in the book I, Robot, I think it was a reasonably faithful "Asimov-style" robot story.

Spoilers

The movie had some elements of the Zeroth Law, from Robots and Empire. The whole "ghost in the machine" idea was also a theme that Asimov explored a few times, like in Bicentennial Man and "Light Verse" (a short story which appears in the books Robot Dreams and The Complete Robot). The movie actually reminded me a lot of Isaac Asimov's Caliban (which despite the title, is by Roger MacBride Allen, not Isaac Asimov). Overall, I was pretty happy with the movie.

One of the cats of the Coliseum. 

Charmed Labs has a pretty neat product called the Xport which makes it possible to turn a Game Boy Advance into a robot controller. They have several demos which use Lego for the mechanical parts of the robot. It's too bad that their software is for Windows only. :-(

To get my camera working, I just had to change the entry for in /etc/fstab. I found a tool called lsscsi which is useful for finding out which SCSI device is which. When I run it on my machine it says:

[0:0:1:0]    disk    ATA      ST3120026AS      1.02  /dev/sda
[2:0:0:0]    disk    Fujifilm FinePix 1400Zoom 0100  /dev/sdb

The "Fujifilm FinePix" is my camera, so I added the following entry to my /etc/fstab:

/dev/sdb1 /mnt/camera vfat noauto,user 0 0

This wan't too bad, though not exactly something suitable for Joe Sixpack.

Amazingly, my scanner just worked. Yippee!

I tried setting up my printer by running system-config-printer. This all appeared to work, except for the fact that my test page disappeared into the ether.

I did some poking around, and eventually found that lsusb revealed virtually nothing other than an "NEC Corp. HighSpeed Hub". No printer.

More poking around in Red Hat's bug database revealed this bug. I remember there used to be two modules responsible for USB when I had 2.4 kernel, but checking my /etc/modprobe.conf only turned up one: alias usb-controller ehci-hcd. I replace this line with:

alias usb-controller uhci-hcd
alias usb-controller1 ehci-hcd

and then ran /sbin/modprobe usb-controller. Finally, I deleted the phantom printer I'd set up before, and set up a new one. It works. Yay! If only it wasn't so painful. Why didn't the Fedora install translate my old 2.4 modules.conf into a 2.6 compatible modprobe.conf?

Last weekend I decided to upgrade to Fedora Core from Red Hat 9 on my home machine. I'd been using apt-rpm (and Dag Wieers's excellent apt-rpm repository) to install new packages and keep things up-to-date. I'd read that it's possible to upgrade from Red Hat 9 to Fedora by simply doing package upgrades, so I decided to try pointing apt at a Fedora Core 2 repository, and running apt-get distupgrade. Bad Idea.

My first problem was that my new kernel (FC2 uses 2.6.5, while my machine was previously using 2.4.20) would panic on boot, claiming that it couldn't find my root partition. Yikes!

My old kernel was still installed, but the upgrade had managed to remove enough modules that it was essentially unusable. No X. Not even network support was available anymore.

I rode my bike to work and brought along a few CD-RWs. There I was able to burn some Fedora Core 2 installation CDs. "This'll work", I foolishly thought to myself.

When I returned home and tried to run the installer, it reset my computer right after I hit "enter" at the first prompt. Actually, it produced three lines of output, blanked the screen, and then reset. Those three lines flashed by too fast for me to read though. I ended up filing a bug about this. It was promptly closed as a duplicate of this bug. Apparently there's a bug in the 2.6 kernel that only shows up on my motherboard (an ASUS P4P800) and Fedora Core 2. (it's an uninitialized memory bug, so this kind of seemingly random manifestation isn't that uncommon) Luckily, comment 122 of that bug included an ISO image of a fix. I tried it, and it worked! I was able to run the installer.

While running into the install I ran into two oddities. One was that Fedora seemed to think that my hard drive was device /dev/sda while Red Hat 9 referred to it as /dev/hdb. I have a serial ATA drive, so the hd* name makes more sense to me, since sd* is normally used for SCSI devices. I did some Google searches, and they indicated that this was normal, however. Apparently the 2.6 kernel works best with SATA by treating SATA devices as SCSI over IDE devices. Weird. During the install I actually popped over to one of the other virtual consoles (where there's a shell) and tweaked my /etc/fstab to use these device names. (I actually didn't do this on my first attempt, and the installer bombed out when it couldn't find my swap partition)

The other oddity, which seems minor in comparison, was that the installer couldn't find a boot loader installed. I decided to install a "new bootloader", GRUB, despite the fact that I knew GRUB was already installed.

After the install, I tried to boot up. The non-smp kernel still had the uninitialized memory bug, but the smp kernel seemed to work. Part way through the boot, it panicked with the same message I got when I tried the package install:

Loading ext3.ko module
Creating block devices
VFS: Cannot open root device "LABEL=/" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0)

Crap. That's the same error I ran into when I did the package install. I filed another bug with Red Hat, since I'd had such luck with my first bug report. The bug is still "new" as I write this, however. The bug outlines some of the things I tried to do to fix the problem, which amounted to including a mysterious "vdso=0" kernel option (several searches on Google turned up people claiming that this would fix this problem) or changing the root option to "/dev/sda3" rather than "LABEL=/" (even more searches indicated that this was the solution).

After a couple of days of waiting and repeated searching on Google, I finally came across a page where someone asked about a similar error message, and someone else said "oh, that's the mkinitrd problem". The "mkinitrd problem"? Huh? A few more searches turned up this page which mentioned the following command line:

./mkinitrd --preload=scsi_mod --preload=sd_mod --with=ft3xx /boot/initrd.img-2.4.22-sata 2.4.22

Apparently mkinitrd creates an "initialization RAM disk image", aka "initrd file", which should contain the set of modules that your kernel needs to get itself to the point where it can load the rest of the modules from your hard drive. So maybe my problem was that my initrd was missing some modules.

I was actually able to get a working shell on my machine by using the "rescue" mode of the Fedora Install CDs, and there I was able to mount my hard drive. That meant that all of the modules must be in memory at that point, so lsmod should tell me a superset of what I need.

I had scsi_mod and sd_mod, which were mentioned in the command line above, so I guessed that I should leave that oart of the command line the same. I didn't have any ft3xx module though. Hmmm... I did have a module named ata_piix, however. That seemed promising. I then ran the following command:

./mkinitrd --preload=scsi_mod --preload=sd_mod --with=ata_piix /boot/initrd.img-2.6.5smp-sata 2.6.5-1.358smp

I then added an entry to my /etc/grub.conf to use this initrd, and also changed the root option to /dev/sda3 for good measure.

Finally, I was able to boot into Fedora. Of course, a number of things were still broken. Actually, many of these things are still broken, but I've fixed a couple:

• my display was using the nv driver, rather than the nvidia driver. The former doesn't support OpenGL or DPMS, as far as I can tell. Switching to the nvidia driver was easy, but whenever I went into X my monitor would turn off. Eventually I found that adding the following to the Device section of my xorg.conf fixed this problem:

  Option "IgnoreDisplayDevices" "CRT, TV"
  

  My monitor is plugged into DVI, but apparently the driver thought that it should use the analog VGA connector. Now DPMS and OpenGL seem to work.
• My mouse wheel stopped working. Apparently pointing devices are now supported in the kernel in some way. Instead of /dev/mouse there's now a /dev/input/mice. I first tried adding psmouse.proto=imps to the kernel line in /etc/grub.conf. That didn't seem to do help. I then tried unplugging the (non-wheel) mouse I had plugged into the PS/2 mouse port, and moved my (USB) wheel trackball over to that port (with an adaptor, of course). I then rebooted, and this works. Hmph.

  I actually had the second mouse plugged in because Miranda doesn't like my trackball. Having both mice plugged in worked fine in RH9.

Things I still need to fix include:

• CUPS doesn't seem to remember that I have a printer.
• I haven't tested out my scanner. I bet it's busted.
• I haven't tried mounting my camera. It used to be /dev/sda1. Seeing as how that's what Fedora calls my /boot partition, it must at least have a different name.
• I'd still like to get that second mouse working.