The second was that SELinux denied access to about a dozen services on start-up. It was in auditing mode, not enforcing mode, so the services still worked, but I wanted to be able to start enforcing the policy once I resolved some other issues.

After digging through the Fedora Core SELinux FAQ, messing with restorecon and relabeling, I noticed that it didn’t log any errors when I restarted the services manually, only when they started on boot. I looked more closely at log entries. Here’s a typical one:

Jun 22 09:21:06 <servername> kernel: audit(1119457266.772:14): avc: denied { use } for pid=1941 comm="ntpdate" name=init dev=rootfs ino=8 scontext=system_u:system_r:ntpd_t tcontext=system_u:system_r:kernel_t tclass=fd

The device, rootfs, was the key. When I had installed the new kernel, it was running under the simpler SELinux policy for Fedora Core 3. The “targeted” policy in Fedora Core 4 covers more services. So the initial ramdisk the kernel uses to boot had everything labeled for the old policy.

Solution: Rebuild the initrd. Reboot. Done.

mv /boot/initrd-2.6.11-1.1369_FC4.img \
   /boot/initrd-2.6.11-1.1369_FC4.img.bak;
/sbin/mkinitrd initrd-2.6.11-1.1369_FC4.img \
    2.6.11-1.1369_FC4

On top of that, when Linux started booting, the screen was messed up as if the character set had been run through a meat grinder. You could tell what the letters were, but there was a ton of extra garbage. Then, when init set the character set, the gibberish cleared up and the screen looked normal again.

I had been dealing with other problems that looked like video card or driver issues, but I eventually realized that the problem had nothing to do with the hardware upgrade.

About a week earlier, I had removed a couple of partitions from my hard drive and resized some of the remaining ones. Because I had to recover this drive from a hosed partition table a while back, the /boot partition was created later than some of the data partitions—including the ones I wanted to remove. So when I deleted partitions 6–8, /boot went from being partition 12 to partition 9.

When I updated grub.conf to look for the OS on partition 9—(hd0,8) in GRUB’s start-from-zero mentality—I forgot to update the line that tells it where to find the menu’s background image. It still read, splashimage=(hd0,11)…

I’d never noticed it because I’ve gotten into the habit of turning the computer on, then walking into another room while it boots. The default OS started up fine, so I never saw the blank screen or gibberish until the hardware upgrade had me sitting there, watching it boot.

So if you find that your GRUB menu just isn’t showing up, but your system still boots… check splashimage and make sure it points at a real file!