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.

• 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.