Did you already have an active partition on the box?  What does fdisk
-l show?

Yes, there were active partitions in all those machines. (In both the
P4 machines there were Windows 2000 active partitions, while on the
Athlon an FC2.)

Fdisk -l, I did not take that. Neither did I copy the entire
/boot/grub directory structure nor did I compare that directory
structure before and after fixing the problem manually. Sorry. (The
first and second time I thought I was doing something stupid and
wrong, but then when it repeated itself on the third computer I knew
the installer was doing something wrong.)

I will try to simulate and see if I can reproduce the problem.

Thank you.

(My bad I had to discover these problems in the final RCs :(; I should
have done the testing during earlier test stages. But then I was busy
at the Uni.)

If there's already an active partition set, then we leave it active. 
Otherwise, we break the use of third-party boot managers.

Installing to the partition instead of the MBR is really only useful
for cases where you have a third-party boot manager.  In all other
cases, you probably want to install to the MBR.

I am afraid I do not understand you completely.

Are you saying that if you ask the installer to install the grub
bootloader at the first sector of a partition (rather that at MBR)
then it may not install grub there? (or only install it partially)

This is my setup:
1. Windows on /dev/hda1
2. FC2's /boot on /dev/hda2 (and there are other partitions for FC2
for /, /usr, /tmp, /var etc..)
3. FC2's grub on MBR
4. Grub is the very first boot loader to be loaded by the BIOS (to
load both FC2's kernel, to chain load Windows boot loader and to load
any other boot loaders)
5. FC3 (RC5) is in /dev/hda12 (there is only one parition ie, /;
everything else such as /boot, /usr, /tmp, /var etc. are just directories)
6. FC3 installer was instructed to install grub on /dev/hda12 (so that
it could be chain loaded from FC2's grub (pls refer to point 3)
7. FC2's grub, when instructed to load FC3's grub, loaded the first
stage, but while loading second stage completely hangs.

Are you saying this is an unsupported arragement?

Thank you.
Hari.

PS: I appreciate your help. And I am unable to reproduce this problem
on my laptop, but I shall try and reproduce this problem on other
machines today.

(I have used the vanilla FC3 x86_64 DVD installation media.)

I have reproduced this bug on my AMD64. In this computer FC2's grub on
MBR (/dev/hda) is the primary boot loader for the entire system.

I selected "Advanced boot loader" option during installation, and
chose to install the boot loader on the first sector of one and only
partition (root) of the FC3 (/dev/hda17).

Then I added the following section in my primary grub:
title FC3
    rootnoverify hd(0,16)
    chainloader +1

When I select that it just hangs. (Though ctrl+alt+del works fine.)

I have not tried to fix anything up this time around, although I know
I can fix this by using the Rescue mode and using /sbin/grub-install.
Upon request I can provide files/directories etc..

(It is as if Anaconda installer 'forgot' to install the boot loader.)

Thank you
Hari

I think I understand the problem: I observe that the FC3 - Anaconda -
Disk Druid created partitions are not visible when I use "fdisk -l
/dev/hda". But OTOH they are there and accounted for when I use
"parted /dev/hda print". (I tried this upon completion of the
installation and just before rebooting.)

What are the odds Anaconda (grub installation procedure) was upset
about that?

(Even after a reboot it is still the case, ie, parted shows the Disk
Druid created partitions while fdisk does not.)

Thank you.
Hari.

And Oh BTW, kernel accounts for those 'hidden' (partially :) partitions:

hda: max request size: 1024KiB
hda: Host Protected Area detected.
        current capacity is 234435439 sectors (120030 MB)
        native  capacity is 234441648 sectors (120034 MB)
hda: 234435439 sectors (120030 MB) w/8192KiB Cache, CHS=16383/255/63,
UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12
hda13 hda14 hda15 hda16 hda17 hda18 >

And so does /proc/partitions file.

Yes; hda17 and hda18 are the two FC3 installation created partitions.
And both are the one and only partitions for two FC3 installations
obviously. Yes; I have installed FC3 multiple times on this computer :).

Interestingly when I installed the second FC3 (on /dev/hda18), the
previously installed FC's partition (/dev/hda17) was visible in the
Disk Druid screen. IOW, Anaconda does the right thing while "reading"
the partitions, but not while "writing". Maybe it uses two kinds of
procedures/tools: one for partition "reading", which obviously does
the right thing, but not the partition "writing", which might be at
fault. Just a guess.

Summary: fdisk does not display Anaconda - Disk Druid created
partitions (/dev/hda17 and hda18) in my case (before and after the
reboot); OTOH, parted, kernel and /proc/partitions are just fine with
those partitions. And that just might be the root cause of my problem.

Thank you.
Hari.

fdisk won't display any partitions over /dev/hdaX16.

As for your original question, we install GRUB, but changing the
active partition is usually the exact opposite of what the user
expects.  If they expected GRUB to be activated by default, then you
install to the MBR.