Linux, musical road-dogging, and daily life by Paul W. Frields
 
Back in play, No. 2.

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.

3 Comments

  1. Yanko

    So, we have the capability to produce a livecd that would run on almost everything, talking to all kinds of hardware, but simply moving an already installed , not space constrained hard disk(s) results in this unfortunate situation. Surely I am not the only one who finds this ridiculous.
    Please stop all the silly mkinitrd hardcodig already…..

  2. @Yanko: It was a bit of a hassle, honestly. On the other hand, the use cases for a Live image and a hard disk in a desktop computer are pretty different. I’m not even sure if I fixed the situation the “correct” way — although my solution certainly seemed to work. Could you make some suggestions on how the developers can improve this situation?

  3. Yanko

    @Paul, I’ve moved my share of installations across systems and your procedure is as good as any,. It was never pretty for sure.

    Ideally the initrd and its config would be clearly separated, with both being someplace in the systems nonvolatile storage. If not both then at least the config. But hey, the system BIOS being the most retarded and retrograde piece of software in the last 20 years -> little chance of happening.

    So what I can see be done currently is to turn the initrd into something like: try fast hardcoded config, is root there? no -> go the slow (lets call it livecd) way around. Separating the logic and the configuration on the way there.

    ..and yes I am sitting in my armchair. Sorry about that.

Comments are closed.