Well, one migration just wasn’t enough for me this weekend apparently. My friend (and ace author/Asterisk guru extraordinaire) Jared gave me a new mobo that I could transplant into my desktop system, which had been running an old AthlonXP 1800+ on an Asus mobo. The new one is a Gigabyte mobo with an Athlon64 3000+! (Overgenerosity is one of Jared’s many faults.) 😉
I transplanted another 2 GB of RAM onto the new mobo for a total of 3 GB, and then performed all the physical parts of the procedure (tearing my hands up minimally in the process). Everything was fine upon booting up to the point when I got a very interesting error, saying that the UUID for the new root volume wasn’t found.
Normally GRUB references the new root volume with a “UUID=” parameter, meaning that it should be virtually impossible to attach any additional storage device and have it override your normal root volume. That was a great change from back when I was doing forensic work and we had to take special precautions. You wouldn’t want to connect a working copy of evidence in the field and then inadvertently write to it because it has the same label as your normal root volume. (Nowadays there are hardware write blockers, but back when I started doing that kind of work over a decade ago they didn’t exist.)
So anyway, back to my point, which is that the system wasn’t finding my UUID. I booted off a F10 install disc in rescue mode and could easily see that the UUID for the root volume was fine, and agreed with GRUB, which told me that for some reason the system wasn’t recognizing the LVM setup in my system. The rescue disc had no problem recognizing and mounting my volumes under /mnt/sysimage as usual. I’m not sure why that kernel module wouldn’t be loading properly during the boot process, or why else my LVM setup wouldn’t be recognized — but it could easily have something to do with the brand new IDE controller my drive was using on the new mobo.
To fix it, first I chrooted to the mounted system:
Then I rebuilt the initial RAMdisk. I’m lazy and hate having to remember the mkinitrd command line for this, so I cheated and just ran the new-kernel-pkg command as shown in the kernel’s %postinstall scriptlets. I’m sure this was overdoing it, but part of that process is re-running mkinitrd, so I figured what the heck.
rpm -q --scripts kernel
That gave me the command I needed under %postinstall:
new-kernel-pkg --package kernel --mkinitrd \
--depmod --install 188.8.131.52-117.fc10.i686
After a few minutes the command finished, and just in case that process changed the inodes (and possibly the location) for the kernel and the initial RAMdisk, I decided to rerun the GRUB installer too:
Then I used the exit command to get out of the chroot environment, and exit again to reboot. Voila, the machine now started up fine and I was ready to rock and roll. Of course it’s not lost on me that I have a 64-bit capable CPU now, so I really want to blow away the system and use 64-bit Fedora, but I’ll get to that when I get to it.
The really funny thing about all this was that right after I finished all that and started writing this blog post, FedEx showed up at my door with my new replacement Dell XPS M1330 laptop! 😀
UPDATE: Whoops, copied the wrong scriptlet above, which would not have fixed the problem but actually made it worse.