Description of problem: Both anaconda during FC4t1 installation and /sbin/grub-install later install grub in the MBR (/dev/hda), even though /dev/hda3 was explicitly selected.
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.