Bug 127557

Summary: kickstart install asked to write boot loader on raid boot partition overwrites mbr
Product: [Fedora] Fedora Reporter: Alexandre Oliva <oliva>
Component: anacondaAssignee: Peter Jones <pjones>
Status: CLOSED INSUFFICIENT_DATA QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: rawhideCC: bill, triage
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-06 23:59:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 133260, 150221    

Description Alexandre Oliva 2004-07-09 17:39:15 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
I had the following line in my kickstart file:

bootloader --location=partition  --md5pass=wontpastehere:-)

Nevertheless, anaconda installed the boot loader in the mbr.

This *might* have to do with the fact that I had:

raid /boot --useexisting --fstype ext3 --device=md6

but if it couldn't figure out where to install the boot record, it had
better ask me, instead of overwriting the mbr and not installing it
where I told it to.

It left me with a bootable system, but I could no longer boot into the
previously-installed OS, that was supposed to have been preserved and
remained as the default.

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

Comment 1 Jeremy Katz 2004-09-30 21:20:57 UTC
Do you get "MBR not suitable as boot device; installing to partition"
output on tty3 (or in /tmp/anaconda.log) during the install?

Comment 2 Alexandre Oliva 2004-09-30 23:20:21 UTC
Nope, and I'd be surprised if I did, since the problem is actually the
converse: I tell it to preserve the MBR and install the boot info in
the partition, but it goes ahead and overwrites the MBR (and doesn't
set up boot info in the raid device).

Comment 3 Jeremy Katz 2004-10-01 15:39:38 UTC
My test here was ending up with grub being installed in the right
place.  Will keep looking.

Comment 4 Jeremy Katz 2004-10-01 20:58:41 UTC
Can you look at the first 512 bytes of the first disk in the RAID
device and see if it has "GRUB" in it?  Are you sure that what
happened isn't just that the active partition was changed to be your
new boot?

Comment 5 Alexandre Oliva 2004-10-01 23:01:41 UTC
It has GRUB in it, but that's because I put it there myself.

The way I had things set up here, I had one /boot raid1 device for
FC2, and one for FC3test.  The FC2 grub.conf has an entry to
chain-load the FC3test one, and vice-versa.  The FC2 boot device was
the one that booted first.  To my surprise, after I installed
FC3test1, it became the default on all of the boxes that had RAID1
devices for /boot, but remained correct for those that didn't.

Since GRUB is installed in the MBR, just pointing to a different
partition, I don't think the active partition should make any
difference.  And, if it does, why did the active partition change, and
only when /boot was on raid?

Comment 7 Alexandre Oliva 2004-10-02 19:00:54 UTC
Confirmed with a fresh install of yesterday's rel-eng compose tree. 
In VT5, before the reboot, I see:

Unknown partition table signature
Unknown partition table signature

and then a GRUB session log that shows it selected the correct root
device for the first raid 1 member partition and then installed grub
in the MBR:

root (hd0,5)
install /grub/stage1 d (hd0) ...

Could it be that it only happens with pre-existing raid 1 devices? 
Maybe it's trying to read a partition table from the raid device itself?

Comment 8 Jeremy Katz 2004-10-04 13:41:25 UTC
Has this ever actually worked (installing to the partition when /boot
is RAID1)?  I'm rereading the code and I don't think that it ever has...

Comment 9 Alexandre Oliva 2004-10-04 16:17:00 UTC
I don't know.  I started using --location=partition quite recently.

Comment 10 Jeremy Katz 2004-10-04 17:00:53 UTC
Okay.  Will be fixed in booty-0.44-1

Comment 11 Alexandre Oliva 2004-10-22 23:58:13 UTC
It does install the boot loader in the first member of a raid 1
device, indeed.  But it does so even if I specify --location=mbr. 
That's wrong.

Comment 12 Alexandre Oliva 2005-03-16 19:15:04 UTC
Still broken in FC4test1.  Is this now a dupe of bug 151204, fixed post-FC4test1?

Comment 13 Alexandre Oliva 2005-04-18 18:20:33 UTC
The MBR is rewritten in FC4test2 although anaconda was asked to install the boot
loader in the boot partition only.  Tested with both raid and regular /boot
partitions.

Comment 14 Alexandre Oliva 2005-05-22 05:17:25 UTC

*** This bug has been marked as a duplicate of 151204 ***

Comment 15 Alexandre Oliva 2005-11-30 16:51:02 UTC
Still broken if /boot is a RAID device.

Comment 16 Alexandre Oliva 2006-01-13 15:53:52 UTC
Still no way to get anaconda to install the boot loader on raid partitions, not
on MBRs.  In fact, the interactive installer doesn't even offer such an option,
although kickstart doesn't error out if you request such allegedly impossible feat.

Comment 17 Bill Rugolsky, Jr. 2006-02-16 00:49:27 UTC
See https://www.redhat.com/archives/fedora-list/2005-August/msg04002.html

for how I get GRUB to work on RAID1.

Comment 18 Red Hat Bugzilla 2007-02-05 19:34:16 UTC
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

Comment 19 Bug Zapper 2008-04-03 15:37:08 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 20 Alexandre Oliva 2008-04-05 07:11:39 UTC
The installer still thinks it knows better, and claims perfectly reasonable
options to be impossible.  Should we make this a WONTFIX?

Comment 21 Bug Zapper 2008-05-06 23:59:54 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp