Bug 133644 - Installer overwrote boot sector with GRUB on wrong HDD
Summary: Installer overwrote boot sector with GRUB on wrong HDD
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 3
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-09-25 15:57 UTC by C.H.
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-11-04 14:15:59 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description C.H. 2004-09-25 15:57:38 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914
Firefox/0.10

Description of problem:
Graphical FC3T2 installation was performed on a MSI-6702
Athlon 64 system having:
hda PRI MASTER WD1600 160 GBy having NTFS and other partitions on it.
hdb PRI SLAVE ST3200822A 200 GBy
hdc SEC MASTER WD 307
hdd SEC SLAVE MX 91741

The system was booted from USB DVD, and graphical install initiated.
Manual partitioning was selected, and the existing 1GB hdb1 was
selected (as prompted) for formatting as LINUX SWAP.
The existing ~ 184 GBY partition hdb2 was selected, edited, and
defined to be formatted EXT3, and mounted as "/".

The options to install GRUB were selected / shown (as far as my
interpreting them) to install GRUB on the boot sector of
the PRIMARY SLAVE, hdb, which was the drive selected for the FC3T2
install (swap and root).  No installation, mounting, or other
actions were performed relative to the other three physical 
drives -- hda, hdc, hdd, and the expectation was that these would not
be touched.

The result was that the install concluded, the PC rebooted
(actually it hung up late during the shutdown sequence -- 
that isa bug too).

BIOS was edited to select PRI/SLAVE to be the boot drive, however
no bootable sector had been written onto that drive.

Next I rebooted and selected PRI MASTER (hda, *NOT* the install
drive for FC3T2) to be the booted drive, and voila, GRUB / FC3T2
begins to boot.

I'm not sure if this is the old 'installing FC2 stomps Windows
boot sector' bug or what, but clearly there's a bug or at least
the documentation and screen presentation of WHICH boot sector
is going to be modified needs to be MUCH clearer.  I triple
checked it said "hdb" as the target drive for all operations, so
I'm pretty sure it just went ahead and modified the wrong boot
sector.  

Now hda *IS* PRI/MASTER, and *WAS* (at install time)
the first 'boot selected' HD type device in the BIOS 'boot device order'
chain (first dev was USB CDROM) so I can see why it would have THOUGHT
that hda was the right drive for the boot sector, but nonetheless
I'd intended to switch the BIOS setting for boot drive, and didn't
tell it to install the boot to hdb knowing that.

Unfortunately as there's no log that I'm aware of of the install
choices / dialogs, I can't provide any more exact details, 
and after spending many many hours / days working to get the system
installed this far, I'm not immediately keen on repeating it to check.
I assume test sandboxes are plentiful in QA there, and the
old "fc3t2 stomps XP multi-boot-sector" bug has been regression
tested so maybe this is new or I could just be nuts.


Version-Release number of selected component (if applicable):


How reproducible:
Didn't try

Steps to Reproduce:
1.run installer FC3T2 to the SECONDARY SLAVE, manually partition,
avoid hda
2.See if FC3T2 writes its boot sector on hda even so.
3.
    

Actual Results:  Boot sector was written on the wrong (hda) drive, not
the selected
one.


Additional info:

Comment 1 Jeremy Katz 2004-09-27 17:09:11 UTC
Are you sure you said to install the boot loader to the partition? 
Doing so would have required going to the advanced boot loader options
screen and changing from the MBR to the partition.  The main boot
loader screen just lists the boot entries.

Comment 2 Jeremy Katz 2004-11-04 14:15:59 UTC
Closing due to inactivity.  Please reopen if you have further information to add
to this report.


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