[jkoshi]

Hi all,

I have a problem with the grub bootloader, as follows: I have a laptop
with an 80G disk, with Windows XP on the first half of the disk (NTFS),
and Fedora core 4 (LVM) on the rest. Dual boot is managed by grub, which
was installed with the Fedora install.

I wanted to clone this disk, so I don't lose hours of setup and install
effort on both OS's, and more hours of my work, in case of a disk crash.
So, I did the following:

1) Cloned the entire 80G disk to a 120G USB disk.
2) Restored from that clone onto a new 80G disk of the same geometry,
and replaced the existing disk with the newly cloned one.
3) On start-up, got a grub hang at "GRUB", so I did the following:

a) Boot from Fedora core 4 rescue CD
b) chroot /mnt/sysimage
c) grub-install /dev/hda

4) Now the grub hang went away, and gave me the OS selection menu, and
Windows booted fine, but selecting the Linux installation gave me
"Error 17: Cannot mount selected partition". So I did the following:

a) Boot from Fedora core 4 rescue CD
b) chroot /mnt/sysimage
c) grub-install /dev/hda
d) Enter grub -> grub<CR>
e) grub> find /grub/stage1 -> gave me (hd0,3)
f) grub> root (hd0,3)
g) grub> kernel /vmlinuz-2.6.17-1.2142_FC4 ro root=/dev/hda4
h) grub> initrd /initrd-2.6.17-1.2142_FC4.img. -> gave me:
"Error 16: Inconsistent filesystem structure".

5) Then I exited grub, repeated steps (a) and (b) above, and rebuilt the
initrd: "mkinitrd -v -f initrd-2.6.17-1.2142_FC4.img 2.6.17-1.2142_FC4",
6) Repeated from step 4(a), and got the same error at step (h).

Is this a known problem in grub, or am I doing something wrong in these
steps? Thanks in advance for a fix to this very frustrating problem.

regards,
John

[saikee]

I don't think it is a problem with Grub.

The error indicated it was "Inconsistent filesystem structure".

My guess is your LVM doesn't like the step

2) Restored from that clone onto a new 80G disk of the same geometry,
and replaced the existing disk with the newly cloned one.

which could be the reason causing the trouble to the filing structure of the LVM.

I would have just used the cloned disk right away. When I got both systems working to my satisfaction I then boot up Gparted and expand my two systems to take up the extra hard disk space provided by the 120Gb disk. I don't use the LVM myself but it may need LVM own utility for expansion.

When properly cloned, say using the dd command, your 120Gb hard disk should have the same geometry as the 80Gb and there should have been no need to fiddle its geometry. At least that is my experience of cloning the 2.5" laptop hard disks.

My suggestion is go back to clone it again as it is easier and quicker that way.

[jkoshi]

Hi Saikee,

Thanks for your feedback.

I can boot the system with a Linux rescue CD, with the
restored disk in place, and see ALL my directories and
files when mounted. If any of the LVM file or data
structures were corrupted, this would not be possible.

Grub is complaining about the initrd image, with the
message "Error 16: Inconsistent filesystem structure".
But again, it complains even with a rebuilt initrd.

John

[vtel57]

Don't know if this will help you at all, but here it is:

http://www.gnu.org/software/grub/manual/grub.html

I tend to agree with Saikee here. GRUB is not seeing what it expects to see when looking at your file system.

[saikee]

Well how about putting the matter to the test

You have Grub in Fedora. Pressing the "c" key drops you into a Grub prompt. In a Grub prompt you can boot FC4 line by line manually and Grub issues a warning only on the line it cannot cope. So how about typing these lines at Grub prompt and report which line Grub refuses to work with?

root (hd0,3)
kernel /vmlinuz-2.6.17-1.2142_FC4 ro root=/dev/hda4
initrd /initrd-2.6.17-1.2142_FC4.img
boot

I think you have to remember at run time and before the kernel is booted Grub has no intelligence to read a LVM. It is the kernel and initrd that actually know how a LVM works and able to go inside to get files.

All Grub does is go to the hard disk address as indicated by "root (hd0,3)" and "root=/dev/hda4" to load the vmlinuz and initrd into the memory. At the moment it can't execute the menu.lst because it can't cope with the filing structure.

There is another possible explanation and that is Grub can only find the root partition if you specify the address in the hard disk by a "label" instead of a device name, as a standard Fedora using LVM should have root=Lablel=/123 for example. Altering root=/dev/hda4 will work only if you haven't got a LVM. Grub is known to be unable to read a LVM. If you don't believe it you can type "geometry (hd0)" at the Grub prompt to see Grub reports the LVM partition, with type No 8e, having an unknown filing system.

Also your specification of "root=" parameter in the menu.lst may not match that in the /etc/fstab and that is another cause for Grub to fail.

Lastly your root=/dev/hda4 may be incorrect. It appears your hda4 is the /boot partition. The "root=" parameter should normally point to the "/" partition.

[jkoshi]

Saikee,

Thanks for the follow-up. I did the following, on the laptop, with the original hard
disk in place:

1) Enter "c" at the grub OS selection menu
2) grub> root (hd0,3) -> gave me "Filesystem type unknown, partition type 0xf"

Of course, I could not proceed further.

Then I booted the system normally into FC4, and noted the console output:
==========================================================
root (hd0,2)
FIlesystem type is extfs, partition type 0x83
kernel /vmlinuz-2.6.17-1.2142_FC4 ro root=/dev/VolGroup00/LogVol00 rhgb quiet acpi=noirq
[Linux-bzImage, setup=0x1e00, size=0x1b659c]
initrd /initrd-2.6.17-1.2142_FC4.img
[Linux-initrd @ 0x37e51000 0x19ed3a bytes]
==========================================================

So it looks like the "root (hd0,3)" could be the problem, as you noted. I'm not yet
clear as to why the "grub> find /grub/stage1" gave me "(hd0,3)". But I'll try with
the cloned disk, with "root (hd0,2)" to see if it'll work. I'll post the result of this
after I get some time, later, to switch in the cloned disk, etc, and to test this.

By the way, I had already tried "root=/dev/VolGroup00/LogVol00", but since the
"root (hd0,3)" was probably wrong to begin with, this may not have been relevant.

John

[saikee]

The partition Type 0xf or f is the extended partition created within Win95.

You must have made a mistake in recording the result from the Grub command "find /grub/stage1".

The new information indicates the /boot partition is in (hd0,2)