Bug 151204

I confirm that Anaconda did this to me while installing from the DVD.
 It put grub in the MBR even though /dev/hda7 was explicitly selected.

Hopefully fixed in rawhide... can you try it out and see?

I had FC4t1 mess me up this way as well.

When I get some time, I'll try to install rawhide and see if the problem is
still persisting.

*** Bug 151564 has been marked as a duplicate of this bug. ***

See also Bug 152164

FC4T2 shows same problem

Although this bug was closed, FC4T2 installer shows same problem.
GRUB is installed into MBR.
This time, /sbin/grub-install after installation dosen't have this problem.
I confirmed this when text installation, I have not tested graphical installation. 

I confirm this is still a problem in FC4T2 graphical install from DVD.

morioka, can you outline your test procedure here?  Several people have reported
this working correctly, and anaconda uses grub-install to perform the
installation.  So I'm hoping more detail will show us any subtleties which are
causing this problem.

Really?
I consider that anaconda uses booty's bootloaderInfo.py for GRUB installation.
The bootloaderInfo.py uses /sbin/grub --batch to install grub bootloader.
The grub-install is used only copying stage files with --justcopy option.
And I think rawhide's bootloaderInfo dose not sepcify --boot-device.

*** Bug 154548 has been marked as a duplicate of this bug. ***

I have only had this occur on a x86_64 install.

Happened to me again, current rawhide (modulo mirror delay), text install on i386.
Tell me what info you need and I'll try to get it.

This is still happening in a graphical install in FC4T3 (yes, T3).  I did a
fresh install from the DVD, specified that it put the boot loader in the first
sector of the boot partition, /dev/hda6.  Instead, it overwrote the MBR on hda,
and I had to use a rescue disk to get the MBR back under control of my FC3 install.

My system is an x86, Athlon.  Hda is the master on the first channel of the
onboard IDE controller.  FC3 is on hda1 and the new FC4T3 is on hda6.

This really needs to get fixed before FC4 is released.  If there is any testing
you can suggest, I will be happy to try.

Should be fixed now; check tomorrow morning's rawhide.

I would like to be able to test this in an install.  Is there any way to couple
the revised anaconda with the rest of the distro to do an install?

verified via ftp minimal install -- fixed in development as of 12 May 2005.

*** Bug 157603 has been marked as a duplicate of this bug. ***

Still broken if /boot happens to be on raid1: the MBR is rewritten even if the
installer is told to modify only the /boot partition.  For non-raid /boot, it
indeed ceased to overwrite the MBR when told not to.

*** Bug 127557 has been marked as a duplicate of this bug. ***

Alexandre, that is probably an unrelated issue; IIRC from the fedora-test-list
discussions, grub-on-RAID is always using the MBR.

Then anaconda should error out if the wrong option is in the kickstart file,
instead of silently overwriting the MBR.  You're write that there were
discussions about this in fedora-test-list, but I don't think there was agreement.

I don't see why grub-on-RAID would have to be in the MBR.  I have a perfectly
functional set up here, that has worked for years, in which two or more /boot
partitions for different installs, all of them in RAID 1, offer options to
chainload the others, and one of them is set up in the MBR as well.

In general I prefer an experimental install to not overwrite the MBR, since this
might render might stable install unusable as well.

Anyhow, if it's a separate bug, I'll reopen the bug I filed a long ago, that I
just marked as a dupe of this one.  This will have the unfortunate side effect
that the problem will no longer be regarded as an FC4 blocker :-(

lxo -- yes, your problem is separate from this one.