Tag Archives: LVM

Back in play, No. 2.

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:

chroot /mnt/sysimage

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 2.6.27.5-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:

grub-install /dev/sda

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.

Back in play.

The Red Hat corporate help desk kindly sent me a new laptop for temporary use until I get the replacement for my XPS M1330 from Dell. The loaner was a 32-bit machine, and my old drive was 64-bit, so rather than bother with a hard disk transplant, which would mean reinstalling the system, I decided to move my data from my old laptop hard disk (which survived just fine) to the new system, and figured I might as well document it for newer folks who might not know how to do it cleanly.

Keep reading “below the fold” to find out what I did and why.

Continue reading Back in play.