FC5 upgrade, grub dual boot nightmare...
 

My system was configured with a grub bootloader, Windows XP and RH8 that I set up, quite literally, years ago. The setup involved grub+RH8 on Hard Disk 0 and a fully bootable Windows XP disk on Hard Disk 1 (I did this to fall-back to booting from HD1 from the BIOAS in the config if anything went wonky, good strategy... at least I have my XP OS up).

I finally managed to download the FC5 ISOs and perform an upgrade. I copied the appropriate directory from the Install CD1 into the /boot/isolinux directory and and upgraded grub appropriately. No problems, I booted the isolinux image and my upgrade was under-way.

I selected the option to automatically update the boot-loader, thinking that indeed a new kernel image would need to be selected. The install completed successfully, but when the system reboots I simply get the grub 0.97 prompt. At this point, I haven't the faintest idea what to do next... unfortunately, I did not snag a copy of the grub.conf file. Any thoughts on how to proceeed... I'm relatively sure this is really about configuring grub.

From the grub prompt follow this guide.

OK. Way more information, but no luck just yet.

geometry (hd0) indicates drive 0x80, with three partitions 0, 1, 2 of filesystem type ext2fs (type 0x83). I am presuming these are indeed the linux partitions. The third partition is filesystem type unknown, type 0x82. geometry (hd1) indiciates drive 0x81 with one partition, type unknown, partitioning type 0x7. My assumption is that this is indeed my "Hard Drive 1" with windows on it.

When grub boots, it is set to (hd0,0). Using "find /boot/grub/menu.lst" yields "Error 15: File not found", and typing 'kernel /boot/vmlinuz' then tab completion, also yields a file not found. The same occurs when it use 'root (hd0,1)'. And (hd0,2) is not mountable.

Back to (hd0,0), using 'kernel /' tab completion yeilds a result of "/boot.b'. Repeating on (hd0,1) yeilds what appears to be the filesystem tree 'root, usr, dev, boot, etc' except using 'kernet /boot' tab completion yeilds nothing; e.g., just completes to '/boot/'. With my root at (hd0,1), I file completion "finds" all the files, but I cannot cat them (e.g., 'cat /etc/grub.conf' yields file not found (rats).

Now, I am stuck again... help?

Got a kick out of it bumping into my own thread.

But honestly I have never managed to find a PC system that cannot be booted by a Grub prompt.

In a Grub prompt the XP in (hd1) can be fired up by
The two map statements are doing the Bios swap of the disk order, except it does this on-the-fly and revert back the orginal disk order when XP is closed down.

The orginal FC5, if installed properly, should boot by
Once inside FC5 Grub can be installed back into the MBR by
There is no need to upgrade Grub if the kernel is changed. I believe Grub has been upgraded to 0.97 but the user does not know how to restore the original configuration back into the MBR. GRub is a boot loader. Inside FC5 there is a configuration file to boot the systems picked up by the installer.

The commands in Grub prompts are those needed inside the configuration file menu.lst except (1) You need a "title" to start with to tell yourself the name of the system and (2) the "boot" statement is not needed.

All the above are described indeed in the booting tips mentioned by pljvaldez.

pljvaldez,

Thank you for advocating the thread.
-------------------------
Edited insertion

My above commands should be OK for booting both systems. I believe the original "setup" command should have been
That instructs Grub to fetch the configuration from the root partition of (hd0,0) and install itself into the disk (hd0). Grub counts from 0 so (hd0) means the whole disk or MBR as the partition reference is omitted.

OK, and, by the way... what the heck happened to my grub installation, anyway?!?!

Nothing I think.

Grub can be installed on its own without attached to an operating system. Think you just did that if you get a Grub prompt out. Your FC5 menu.lst should be intact.

You don't need a boot loader (either Grub or Lilo) installed in order to boot a Linux up, as long as you have a Grub prompt. You can use Grub to find out the kernel and initrd files and boot the Linux manually.

Learn to use it. It is really the most lethal weapon in booting.

I haven't tried any of these yet, but when I tried to perform "cat /etc/grub.conf" or even "configfile /boot/grub/menu.lst" as you suggested, grub barfed-back with an Error 15: File not found (even though it found it with file completion). Also, I'm sensitive about blasting the MBR from the XP drive, so I've been avoiding the setup command until I completely figure out what's wrong. Why won't grub find or cat or configfile the files? Sorry, more help needed...

Since you're struggling with the grub prompt, I would boot a liveCD (like Knoppix) and then use step B5 from the link I posted before. Just change /dev/hda4 to whatever drive is your / Fedora partition.

(sigh) OK. Good news and bad news. The configfile was loaded by 'configfile /grub/menu.lst', and the menu was updated with the new FC5 kernel image. HOWEVER, the boot barfed with a 'fschk.ext3: Unable to resolve 'LABEL=/boot'. I have been poking around the forums and google for an answer with the next step. Once again, the /boot directory is empty for some odd reason.

I have a sense it's booting from the wrong spot; e.g., shouldn't that be '/' (if so, how is that changed)? Odd, though... I tried using 'kernel /vmlinuz-etc, etc' from the grub prompt and it booted with the same error.

In such a case paste your /boot/grub/menu.lst and /etc/fstab here. Also the output of the Bash command "fdisk -l".

Fedora likes LVM and often uses a label to identify a hard disk partition. Normal Linux sticks with the raw device name (like /dev/hda1). I often have to change to the raw device convention to get a Fedora to boot normally.

Cut and paste is a little tough... it's more like "transcribe". Here we go. The Fedora Core (2.6.15.-1.2054_FC5) boots as follows in grub as indicated by 'cat /grub/grub.conf':
"root (hd0,0)
kernet /vmlinuz-2.6.15.-1.2054_FC5 ro root=LABEL=/
initrd /initrd.-2.6.15.-1.2054_FC5.img"
(I noticed also that the grub.conf file has a "NOTICE" in it indicating that I have a /boot partition and all kernel and initrd paths are relative to /boot/; also, there is a commented out line indicating "#boot=/dev/hdb1" - probably an example; see my os mapping above)

The first couple lines of my /etc/fstab are:
"LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
....
/dev/hhdb3 swap swap defaults 0 0"
(the other lines are /dev/pts, /proc. /dev/shm, /mnt/...)

fdisk -l yields....
"Device Boot Start End Blocks Id System
/dev/hda1 * 1 4864 (...) 7 HPFS/NTFS

...
/dev/hdb1 * 1 13 104391 83 Linux
/dev/hdb2 14 1761 14040810 83 Linux
/dev/hdb3 1762 1826 (....) 82 Linux/swap"

Also, not sure if this is where we were going with this, but I tried
"grub> root (hd0,0)
grub> kernel /boot/vmlinuz-2.4.21 root=/vmlinuz-2.6.15.-1.2054_FC5 ro root=/dev/hdb2
grub> boot"
with the same result/error (also with /dev/hdb1 -> that caused a kernel panic, obviously not bootable). D'oh.

OK I think there may be a communication problem here.

You system appears to boot but your kernel is unloadable. That is to say Grub works perfectly and load the kernel as it supposed to do.

Grub is a boot loader it operates with limited resource and no access to a kernel. Its duty ceases after putting the kernel into the memory.

Upgrading a distro can easily cause a panic. This because in a new installation all the system files are made compatible before the release whereas in an upgrade, with only selected files replaced, some files could mismatch inside the installed filing system.

The easiest way to get out of this situation is to copy all the personal data out and then do a clean install with FC5.

However before a clean re-install I suggest you boot FC5 once more with the following lines in a Grub prompt
In the above (hd1,0) is Grub's convention for hdb1 as Grub counts from 0 and calls the first disk hda as (hd0). The root=/dev/hdb1/ is a Linux convention for passing a parameter while loading the kernel.

Also you need to amend the root reference in the /etc/fstab to reflect it is /dev/hdb1 as it possibly using the label "/".

The Red Hat family likes to call the root partition by a label (e.g. /123) as against the common convention of the raw device name (e.g. /dev/hdb1/) and reverting to the normal convention can overcome the booting difficulties in all of my cases.

root (hd1,0) does not work because grub indicates it cannot mount this partition (kinda what I expected). Interesting that your instructions in the last post match the commented out notice in the menu.lst file. If hd0 contains the ext3fs partitions, how come you would expect root (hd1,0) to work? If (hd0,0) the boot partition? Similarly, using /dev/hda2. The panic is preceeded by a "VFS: Cannot open root device 'hdsa' or unknown-block(3,2)" Once again, the parameters in the menu.lst shown below DO boot the kernel... it's that fsck.ext3 unable to resolve label that's the problem (e.g., any other root=/dev/...) kernel panics with the aforementioned error.

Also, in your suggestion "you need to amend the root reference in the /etc/fstab to reflect it is /dev/hdb1 as it possibly using the label "/".", I'm not sure what line needs to change. And, should it be "/dev/hdb1" based on the inability to mount root (hd1,0)?

Thanks for the help, by the way...

Your hdb has 3 partitions with hdb3 being the swap. Traditionally Red Hat family like to use a /boot partition, which should be you hdb1 (or hd1,0 size about 100Mb) and then put everything as a LVM which would match your hdb2 (or (hd1,1), size 14Gb)

Grub does not mount (hd1,0). Grub should just report that partition has been found type 0x82 file type ext2 etc.

Your (hd0) is hda and that has only XP inside its the first partition hda1, which is known to Grub as (hd0,0). Grub, or its stage1, resides in the MBR of hda. When MBR is read by the Bios Grub being inside the memory will load its real intelligence (stage2) from the boot sector of hdb1.

Red Hat family (and just about every distro I know) stores Grub files, kernels and boot loader accessories in the /boot directory. Thus once the /boot directory is identified the "kernel" and "initrd" commands can find the correct files to load. The process is very simple.

In the /etc/fstab the files the kernel must loaded are defined there. The first one should the root of the filing system "/".

If your Fedora uses "root=Label=/" in the kernal statement then it will most probably has
.
as the first line in /etc/fstab.

Therefore if you alter the parameter to "root=/dev/hdb1" then you should match it in /etc/fstab with the statement
in /etc/fstab

Since you don't know where is your /boot or your /boot/grub/menu.lst why not let Grub tell you. In a Grub prompt type
Grub will then report back which partition has it. Also do a
to let Grub tell you the partition details as exactly Grub find them. If your hda has XP then its partition 0 should be type 0x7 and Grub will deny knowing it as Grub cannot read a NTFS partition to "find" files inside (Grub therefore say filing system unknown).