Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 151204 - Grub is installed in the MBR even if told not to
Summary: Grub is installed in the MBR even if told not to
Alias: None
Product: Fedora
Classification: Fedora
Component: grub
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Mike McLean
: 151564 154548 157603 (view as bug list)
Depends On:
Blocks: FC4Blocker
TreeView+ depends on / blocked
Reported: 2005-03-16 00:01 UTC by Miloslav Trmač
Modified: 2007-11-30 22:11 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-05-25 15:03:47 UTC

Attachments (Terms of Use)

Description Miloslav Trmač 2005-03-16 00:01:03 UTC
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.

Comment 1 Gerry Tool 2005-03-16 01:52:28 UTC
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.

Comment 2 Peter Jones 2005-03-16 15:49:37 UTC
Hopefully fixed in rawhide... can you try it out and see?

Comment 3 Dax Kelson 2005-03-17 00:58:23 UTC
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.

Comment 4 Peter Jones 2005-03-23 21:44:47 UTC
*** Bug 151564 has been marked as a duplicate of this bug. ***

Comment 5 Dr J Austin 2005-04-02 10:12:01 UTC
See also Bug 152164

Comment 6 Kazutoshi Morioka 2005-04-12 09:18:39 UTC
FC4T2 shows same problem

Comment 7 Kazutoshi Morioka 2005-04-12 09:52:48 UTC
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. 

Comment 8 Gerry Tool 2005-04-13 17:09:56 UTC
I confirm this is still a problem in FC4T2 graphical install from DVD.

Comment 9 Peter Jones 2005-04-14 15:41:45 UTC
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.

Comment 10 Kazutoshi Morioka 2005-04-20 12:46:24 UTC
I consider that anaconda uses booty's for GRUB installation.
The 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.

Comment 11 Warren Togami 2005-05-02 03:57:47 UTC
*** Bug 154548 has been marked as a duplicate of this bug. ***

Comment 12 Gene Czarcinski 2005-05-02 04:12:23 UTC
I have only had this occur on a x86_64 install.

Comment 13 Miloslav Trmač 2005-05-02 19:46:13 UTC
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.

Comment 14 Gerry Tool 2005-05-10 14:11:52 UTC
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.

Comment 15 Peter Jones 2005-05-11 15:57:03 UTC
Should be fixed now; check tomorrow morning's rawhide.

Comment 16 Gerry Tool 2005-05-11 17:24:31 UTC
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?

Comment 17 Gene Czarcinski 2005-05-12 14:40:33 UTC
verified via ftp minimal install -- fixed in development as of 12 May 2005.

Comment 18 Marius Andreiana 2005-05-13 05:28:58 UTC
*** Bug 157603 has been marked as a duplicate of this bug. ***

Comment 19 Alexandre Oliva 2005-05-22 05:16:42 UTC
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.

Comment 20 Alexandre Oliva 2005-05-22 05:17:32 UTC
*** Bug 127557 has been marked as a duplicate of this bug. ***

Comment 21 Miloslav Trmač 2005-05-24 19:47:06 UTC
Alexandre, that is probably an unrelated issue; IIRC from the fedora-test-list
discussions, grub-on-RAID is always using the MBR.

Comment 22 Alexandre Oliva 2005-05-25 05:02:48 UTC
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 :-(

Comment 23 Jeremy Katz 2005-05-25 15:03:47 UTC
lxo -- yes, your problem is separate from this one.

Note You need to log in before you can comment on or make changes to this bug.