Cloning and Migrating F9 partitions to new hardware - boot failure

[fashionhat]

Hello, all

I am at wit's end. I am trying to migrate to new hardware, using gparted to copy the Linux partitions from the original PATA hard drive, to the destination SATA harddrive, but I can not keep the same partition scheme, so the new partitions are differently numbered and have changed from primary to logical.

The original (PATA) drive has Fedora 9 installed on an AMD Turion 64; the destination is an AMD Turion 64 (X2).

parition schemes:

original:
/dev/sda1 NTFS
/dev/sda2 /boot
/dev/sda3 swap
/dev/sda4 /


copy:
/dev/sda1 FAT16 (Dell Utilities)
/dev/sda2 NTFS (Vista RECOVERY partition)
/dev/sda3 NTFS (VISTA OS)
/dev/sda4 extended
/dev/sda5 /boot
/dev/sda6 swap
/dev/sda7 /


Thus, the partitions I copied with gparted are the original (2,3,4); their copies are now the new (5,6,7), respectively.

gparted copied the UUIDs, to the new (5,6,7) partitions, as confirmed with the GPartED LiveCD vol_id utility. Thus, as I see it, there should be no need to alter the /etc/fstab, as it still bears the correct UUID references that should work. (I may be wrong, and, perhaps, new UUID's need to be issued?)

In spite of the matching UUIDs, after running grub-install on the new system (in rescue mode), when I try to boot the new system, i get:

Decompressing Linux... done
Booting the kernel.

Aperture beyond 4GB. Ignoring.
..MP-BIOS bug: 8254 timer not connected to IO-APIC
Red Hat nash version 6.0.52 starting
Unable to access resume device (/dev/sda6)
mount: could not find filesystem '/dev/root'
setuproot: moving /dev failed: No such file or directory
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
Mount failed for selinuxfs on /selinux:  No such file or directory
switchroot: mount failed: No such file or directory
_<blinking cursor>
Kernel alive

----
Ctrl+Alt+Del reboots from the above

----------------------------------------------------------

Also, I can boot from Fedora 9 install DVD, selecting "rescue installed system", and the rescue software seems to find everything (except, perhaps, swap)

I can then chroot /mnt/sysimage, and then run gnome with "startx". At this point, everything seems to be OK, EXCEPT my audio device is not detected, and (i think) I have no swap (sorry for not remembering-- I have screwed up my cloned partitions right now, so that I currently can't run Gnome until i reclone the partitions).

----------------------------------------------------------

NOTE: I read in one of the posts here (DangerMouse, in http://forums.fedoraforum.org/showthread.php?t=196349 ) that the days of being able to transplant a harddrive with Fedora OS from one hardware environment into another, and have it boot up with full functionality with the new hardware are over. (The joy of such seamless transplants died with Fedora 6, the post says. Indeed, I always bragged to my friends about Fedora's ability to do exactly that, and the few times it has failed for me recently I assumed the cause was the new methods of referring to storage devices, such as Volume Groups and UUIDs, and nothing more -- and also assumed that the fix simply entailed learning the new procedures, and there weren't any other roadblocks)

Dangermouse also suggests that there /is/ some probability of succeeding with such migrations, although it is _low_ (success only if one is "extremely lucky")

What seems like near-success (reaching the point where Gnome and all applications seem to be running on the clone) seems to indicate that either the likelihood of success is higher than what DangerMouse suggests, or that I am indeed extremely lucky with enough similarity between the two AMD Turion laptops to allow the desired migration.

Thus, I am hoping that the solution is somewhere within reach, although I seem to have exhausted my knowledge and the knowledge I can obtain through online searches.

----------------------------------------------------------

FWIW, I have "played" with fstab, have altered the initrd (using cpio), namely, the "init" script therein (but that just seems an alternative to changing the boot options in grub, such as root=/dev/sda5, etc.). One way in which changing the "init" script in the initrd helped was that it confirmed to me that my initrd was, indeed, being found and loaded on boot, since my changes to it manifested on the screen.

Are there, perhaps, any other boot parameters I can change in grub? Could the problem be related to having changed from primary to logical partitions?

I would greatly appreciate some advice. It seems it would also be of general use to revisit & discuss the likelihood of success of the type of migrations I am attempting, since it is a great convenience/time saver.

thanks

Andrew

[fashionhat]

There are three things that could have done the trick, and I will list them here.

I am too weary and anxious at the moment (after three weeks battling with this!) to try to isolate the one thing that did it; I would like to move on with my work asap. However, I will describe all three.

Here is what i did, since my last post.

(I re-cloned my partitions because, as I wrote earlier, they were messed up)

I booted into F9 rescue mode, chroot-ed to /mnt/sysimage, ran "startx" to go to Gnome...

In Gnome, I:

1) ...changed /etc/modprobe.conf to include "alias scsi_hostadapter sata_sil"

2) ...re-ran mkinitrd with a slew of "--preload=<module>" parameters. These included all the modules already in the init script, PLUS the "sata_sil" module.

3) re-ran grub-install /dev/sda

Voila.

Step 1 may have been redundant to Step 2, or vice versa. I don't know.

There is a tiny tiny remote possibility that simply running "mkinitrd", without the above modifications, would have helped. However, I remember distinctly trying to do that before, more than once, although not in Gnome, and not after "su - root". (Just being overly meticulous here, probably unnecessarily)

Anyhow, the cloned system booted up! WITH SOUND! also, with the onboard WiFi card automatically configured and working! plus everything else (cautiously optimistic). (The WiFi, Video, Sound and other cards are all different in the destination system.)

Thus, would it be correct to conclude that it was a PATA versus SATA module/driver issue?

Thanks to all those who read my post and gave it a thought.

[Nokia]

From what you say, it really seems that it was a driver issue. If there's nothing else you might have modified and forgot about it, that's it.