I've just installed Fedora Core 4 on my PC, which also has a small Windows partition (don't ask) on /dev/hda as well as my trusty Red Hat9 installation on the second drive (/dev/hdb). Unfortunately, after the install, I can no longer boot into Red Hat.

I had previously installed FC3 on /hda and had been able to boot fine into Windows or Red Hat -- or FC3 until I clobbered it by messing around with it too much. I decided just to overwrite it completely with FC4, since it was broken and I hadn't ever done anything worth keeping on it. During the install, I instructed Anaconda to leave the hdb drive (with Red Hat) unchanged, and told it to include a boot loader option to boot into the /boot partition on that drive.

Anyway, it doesn't work. If I select "Red Hat" from the grub menu, I get an error message to the effect that I'm trying to boot something that's not bootable (sorry, I don't have the exact message since I'm writing this from memory at work).

<edited later: Here is a screen dump of grub's output when I select RH9:
Booting 'Red Hat 9'

rootnoverify (hd1,0)
chainloader +1

Error 13: Invalid or unsupported executable format.

end edit>
How should I configure grub in order to boot Red Hat? I'm pretty sure everything on the Red Hat side is okay, since it shouldn't have been changed and it was working fine before.

thanks in advance,
Bruce

If you put FC boot-loader in MBR then you should have told Anaconda to use /boot of FC and NOT the one from Red Hat.

If you want to preserve Red Hat's boot-loader in MBR then just tell Anaconda to install FC boot-loader in its root partition so that you can amend Red Hat's /boot/grub/menu.lst to include FC as the additional booting choice.

You can still fix it by running FC installation CD in rescue mode to do the above.

Let us know which boot loader you have placed in the MBR and list its /boot/grub/menu.lst here. We also need your partition scheme which you can provide by listing here the content of

fdisk -l

Yes, I assume anaconda put the bootloader on /dev/hda since it didn't even know that there was a Linux installation on /dev/hdb. My hope was just to have grub run from the FC4 partition, but to have the option of booting RH9 from the second drive when I wanted to. I believe that's what I was doing when I had FC3 installed; I didn't think the old RH9 bootloader was ever being used.

Here is what my current FC4 grub.conf looks like:
I suspect that Red Hat 9 entry needs to be changed. Should I have the rootnoverify entry there? I don't think anaconda recognized that this was a Linux boot partition, so it's treating it like an unknown OS. Along the same lines, should I be using the chainloader? Doesn't that invoke the RH9 bootloader? I was thinking I'd just be able to point grub to the RH9 boot and root partitions and let it boot from there.

I've also realized that I probably have to update my fstab file. Here's what it looks like:
No reference to /dev/hdb .... do I need to add entries to mount the FC9 partitions before grub can access them and boot from them?

I don't really understand the boot process well at all, so please feel free to explain, or just to direct me to a good reference, if that's easier.

thanks,
Bruce

OK your FC4 menu.lst would work and you can achieve what you what if you do the following

(1) Boot into FC4, log in as root, click terminal
(2) make a temporary directory in /mnt and mount RH9's /boot, which I assume to be /dev/hdb1, on it
mkdir /mnt/hdb1
mount /dev/hdb1 /mnt/hdb1
(3) Change root into RH9 so that you can work inside RH9
chroot /mnt/hdb1
(4) Restore RH9's Grub inside its root partition
grub-install /dev/hdb1
(5) Exit and reboot and RH9 should be available from FC4

Chainloading is one of the two methods all boot loaders (NTloader (from XT & Win2k), Lilo and Grub) can use to boot a system.

In chainloading one boot-loader is asked to boot another boot-loader and leave the activated 2nd boot-loader to boot its own system

This is a general method used by both Grub and Lilo to boot a foreign system like Windows because it hasn't got a kernel. You will notice FC4 is booted by one kernel statement and one initrd statement.

There is nothing to stop a Linux to use chainloading to boot a fellow Linux and the trick is to ensure this fellow Linux has a boot loader inside its root partition. What I have showed you above is how to replicate Grub inside its root partition.

That is nothing to it. I use chainloading mainly to boot 50+ systems in my box because the command to boot them are genric. Only the root partition reference is changed.

Feel free to try it on any DOS, Windows, Linux, BSD and Solaris.

Thanks, saikee -- that sounds like a fairly straightforward way to do it.

I am still wondering, however - is it also possible to auto-mount my RH9 root and boot partitions in fstab, and then to put "root", "kernel", and "initrd" entries in the grub.conf stanza for RH9 (in place of the rootnoverify and chainloader lines), pointing to the appropriate locations in the /dev/hdb partitions that I mounted in fstab? Perhaps another way to ask this is to ask whether the fstab file is read before the grub.conf file.

(This how I had thought my previous configuration was working, but since I forgot to make backup copies of my FC3 grub and fstab files, I guess I'll never know ... unless you tell me that it's impossible to do it that way.)

thanks,
Bruce

P.S. Thanks for the clear explanation - I always appreciate it when people take the time to write out the explicit commands, rather than assuming that the questioner will know what they are.

belliott4488,

No! the instruction has to be in /boot/grub/menu.lst. Forget about Grub.conf as it is just a dynamic link as I never use it myself.

The fstab is a later part of the booting process. Grub must know what partition to boot first. Without it Grub will have no idea where /etc/fstab is because a jerk like me can have 43 partitions in one disk and 30 of them all have their own /etc/fstab!

fstab list out the partition Grub must mount. It will have the root and swap partition information repeated from /boot/grub/menu.lst The two sets of information must match so you have been barking on the wrong tree if you think fstab is the only one needs to be right.

I know that I tend to write too much but I think it helps to simplify the problem and making identification of the root cause easier. Some people like you get the maximum out of it.

Well, one small point: on my system, at least, it's menu.lst that is the symbolic link to grub.conf. But it doesn't matter, does it? If I "edit" menu.lst, then I'm really just editing grub.conf. There's only one file.

Okay, I should have realized that fstab must be read later in the boot process, since it's clearly associated with one specific OS installation and must therefore come after the selection of which OS to boot. But still, I just thought that I could tell grub where to find the kernel for RH9, maybe by explicitly telling it to look at (hd1,0) (the RH9 boot partition) for the root partition and then telling it where to find the kernel and intird relative to the that. Is there no way to do that? I would have expected a stanza that looked much like the one for FC4, but referencing (hd1,0) instead of (hd0,1), i.e. the hdb drive rather than the hda drive.

If that's not possible, then I probably was chainloading the RH bootloader all along and never knew it. I'll try your suggestion above and let you know how it works out.

thanks,
Bruce

saikee -

I was about to follow your instructions (quoted below), but I decided I should backup my grub files on RH9 first in case I needed them. That got me wondering, though: why are you suggesting that I invoke grub-install under RH9? grub must have been installed there already, since I've always been able to boot into RH9. Is there a reason why you think my RH9 grub installation has been corrupted?

thanks,
Bruce

Of course you can do that - and despite what saikee says, makes things much easier IMHO.

I never chainload Linux bootloaders - I have just the one, with all my systems referenced (directly) from the one menu.lst/grub.conf.
What you have described works fine, and faster as you save on the load of the latter loader code.
As an aside, you don't need all the partitions mounted for this to work. Use of a "root" directive instructs grub to mount that partition. The boot will proceed fine.

As for menu.lst vs grub.conf;
last time I looked at the code, the "true" filename was the former. Several distros I know of patch grub to actually use grub.conf (in the source) instead. In all installs I do, I make sure they are linked - that way people don't get confused.

Edit: This post refers to the previous post, not that last one that just arrived.

thanks, syg00 - you emboldened me just to go ahead and try it, so I edited my grub.conf (yes, that's the 'real' file in my FC4 install, and menu.lst is symbolically linked to it) as follows (this is just the RH9 stanza, of course):

I still don't really understand what the "ro root=LABEL=/" does, but it seems to work. (I just copied this from my old RH9 grub.conf, changing (hd0,0) to (hd1,0), since the drive where RH now resides is now the second drive.) In fact, I'm posting this from RH9 right now.

Thanks for all the help - I'll be back as I run into trouble getting FC4 all configured the way I like and prepare to put RH9 into retirement.

- Bruce

OK I give a little run down of the two method one can boot a Linux

Every system must boot itself directly by calling the kernel and initrd (if used).

To boot another system two methods are possible

(A) Directly by calling another system's kernel and initrd. That is what sys00 does.

(B) Indirectly by chainloading. This effective using Linux A's boot loader to boot Linux'B' boot loader. Therefater Linux B is booted by its own boot loader.

Method (b) is the only method if Linux is asked to boot a foreign system that has no kernel. DOS and Windows are prime examples. Unknow to many Linux users Method B can be also used on fellow Linux.

I advocate Method B because it does not need to know the kernel and initrd names. It can be an easier method for those who are having difficulties with Method A.

Perhaps the most useful part of Method B is because it is generic and so there is nothing to remember except the partition number of any system to be booted. By arranging its bootloader inside its root partition the system is forever chainloadable. Its bootloader, as created during installation and in working order, is untouched and preserved.

If one looks at the way each Linux boots itself the parameters selected to go with the kernel are different to other Linux. Trying to mess around with them is plainly silly because one loses the optimisation. Why not boot up its original boot loader and let it take care of itself.

Therefore in chainloading you still get the direct method of booting, with the arrangement created by the installer and not by the user!

This save a lot of confustion raised by belliott4488 like

I still don't really understand what the "ro root=LABEL=/" does
telling it where to find the kernel and intird relative to the that. Is there no way to do that?

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

ro is read only and is essential for booting a kernel so that it will not be damage by accidental write by some stupid moves.

The "root=LABEL=/" is the bit of Red Hat series I don't like but it is getting popular. Instead of addressing root=/dev/hdax as all other Linux the LABEL in fact is ID writen by Red Hat Linux on the partition /dev/hdax. You will find the same information in fstab. Any incidental error in the partition ID will render the Linux unbootable. I often have to intervene by changing it back to /dev/hdax to make it bootable again.

You see trying to intervene with a boot loaderwhen it is unnecessary to do so is a bad idea, especially you can avoid it completely with chainloading.

Thanks, saikee - It's clearer to me now why you prefer this method. I'll definitely keep all this in mind, especially if I find myself installing any more Linux distros.

- Bruce

GRUB and LILO always conflict with Windows. And GNU GRUB is not so robust, causing many problems during boot.

So try GRUB for DOS please. It is a cross-platform boot loader based on GNU GRUB. The GRUB.EXE can be started from DOS/Win9x; and GRLDR can be started from BOOT.INI of Windows NT/2K/XP/2003; and even more, the GRUB.EXE can be started from LINUX via the KEXEC tool.

By using GRUB.EXE or GRLDR, you don't have to touch your MBR. It is the safest way coexisting with DOS/Windows.

You needn't install GRUB for DOS. Just run GRUB.EXE from DOS, or append a line of "C:\GRLDR=START GRUB" into your BOOT.INI(restart and select the "START GRUB" menu item), that will do.

Download GRUB for DOS here: http://freshmeat.net/projects/grub4dos/

There is a fat12grldr.img file with the GRUB for DOS release. You can create a GRUB bootable floppy with this fat12grldr.img file.

Or, you can just copy GRUB.EXE to your DOS floppy and run GRUB.EXE to enter the GRUB environment.