[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

partition image restore causes Grub Legacy shell find command to hang

From: Felix Miata
Subject: partition image restore causes Grub Legacy shell find command to hang
Date: Fri, 26 Apr 2013 03:25:19 -0400
User-agent: Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20100101 SeaMonkey/2.17.1

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/ 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  ***

reply via email to

[Prev in Thread] Current Thread [Next in Thread]