partition image restore causes Grub Legacy shell find command to hang

[Felix Miata]

I've never run into this before. I have several different distros installed 
on an 80GB SATA HD. All have Grub Legacy installed to each's / partition. The 
actual boot partition sda3 also has the usual Grub Legacy files in 
/boot/grub/, and it is what the BIOS loads. Booting this way works fine for 
all distros either loading kernels/initrds directly using this Grub, or 
chainloading, or using configfile. I've run tune2fs -U random on ever native 
partition since this problem started.

The problem is I restored an freshly made DFSee image of a partition from one 
system to a new location of same size and CHS on another HD and needed to 
setup Grub on that partition. However, no matter which distro I boot, when I 
start the Grub shell and try to run setup by first executing the find command 
to confirm all instances of any expected files, such as /boot/vmlinux, 
/boot/initrd, or /boot/grub/stage1, the find command hangs. If I try to 
simply set root and then run setup, the root command exits normally, the but 
setup command hands in same manner as the find command.

I've tried using both (hd0) /dev/sda and (hd0) /dev/disk/by-id/ata-blahblah 
in /boot/grub/device.map. I've also tried putting the HD into a different 
system, just in case it had anything to do with system hardware. Standard 
DOS/PC code is in the MBR. I even did 'newmbr 1' with DFSee in case it had 
any corruption. The boot track beyond the first sector is nothing but A7h bytes.

I've also tried dropping directly to the grub shell from the Grub boot menu. 
In this case the result is slightly different. Instead of just sitting there 
displaying "find /boot/grub/stage1", it lists the first three instances 
(0,2), (0,5) & (0,7) then just sits there instead of displaying the remainder 
of four. At this point, ESC does nothing, as does CAD. This seems to indicate 
there is some kind of problem with either (0,7) or (0,8), but I have no idea 
what to try next to find the exact obstacle. Fdisk and DFSee indicate nothing 
amiss in the partitioning.

Deleting the (0,8) aka sda9 partition table entry and rebooting makes the 
problem go away. Recreating it and rebooting brings it back. Recreating, 
rebooting, wiping and reformatting keeps the problem gone. So, something 
about the partition image restore process really upset Grub. I used the DFSee 
menus for both creating and restoring the smart compressed image. Partition 
size was 4800MB. The imz file was about 1/3 of that.

Before the reformat I looked at the mounted directory structure. I noticed 
neither the initrds nor the kernels belonging in /boot were there. It's hard 
to guess what other files got lost.

Any ideas what happened?
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/