Bug 205295 - Anaconda installs bootloader in the wrong place
Summary: Anaconda installs bootloader in the wrong place
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda
Version: 4.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: David Lehman
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: RHEL4u7_relnotes RHEL4u8_relnotes
TreeView+ depends on / blocked
 
Reported: 2006-09-05 20:55 UTC by Aleksandar Milivojevic
Modified: 2009-11-24 03:50 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-02-13 19:59:18 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Aleksandar Milivojevic 2006-09-05 20:55:46 UTC
Description of problem:
Well, this is a bug, or might not.  If it was fix for Grub on mirrored drives,
the old bootloader should be zeroed out of MBR too, and some warnning on what is
going on logged somewhere or displayed (or user prompted, or option in ks.cfg
somewhere, or whatever).  Anyhow, read ahead:

I've just noticed that in some cases Anaconda will install bootloader onto
partition, instead of MBR.  Even if I have "bootloader --location=mbr" in ks.cfg
file (which should be default anyhow).

I've tested it several times, with brand new drives and with drives that already
contained some data.  If installation was onto two drives using software
mirroring, it installs bootloader onto first partition of first drive.  If
installation was on single drive (no mirroring) it installs bootloader into MBR
as expected.

The problem is, if there was old boot loader present in MBR, that's what BIOS
will use, and the system will be unbootable.

If I look at /root/anaconda-ks.cfg file after installation, the "bootloader
--location=mbr" is mysteriously changed to "bootloader --location=partition".

I guess possible workaround would be to instruct Anaconda to zeroize MBR before
partitioning drives.  However, boot loader would still end up on first
partition.  But at least system will boot.  Other workarounds would be to
install boot loader into MBR from rescue mode, or to install onto single drive
and create mirrors later.

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

How reproducible:
Always

Steps to Reproduce:
1. Install system with software mirroring
  
Actual results:
Installs boot loader onto first partition of first drive

Expected results:
Should install bootloader into mbr as instructed

Additional info:

Comment 2 Red Hat Bugzilla 2007-06-12 03:16:25 UTC
requested by Jams Antill

Comment 3 Denise Dumas 2008-02-11 23:17:56 UTC
The version of grub we ship in RHEL4 does not
support RAID1 (mirroring). So if the root partition is on RAID1 we
install the bootloader to the first drive instead of the MBR. 

There is a simple workaround -- if you use RAID1, make sure you
clear any preexisting bootloader from the MBR. It's not ideal, but given the
current higher-priority workload and where we are in RHEL4's lifecycle, we're
not going to pursue a fix for RHEL4. 

So I'd like to close this with a release note. 

Comment 4 Don Domingo 2008-02-11 23:33:22 UTC
will add to RHEL4.6 release notes. thanks!

Comment 5 Denise Dumas 2008-02-13 19:59:18 UTC
Closing - this is too big a change for RHEL4, and we're release noting the
workaround as in comment 3

Comment 6 Don Domingo 2008-03-18 00:31:29 UTC
adding to RHEL4.7 release notes (under Installation-Related Notes):

<quote>
The Red Hat Enterprise Linux 4 version of GRUB does not support software
mirroring (RAID1). As such, if you install Red Hat Enterprise Linux 4 on a RAID1
partition, the bootloader will be installed in the first hard drive instead of
the master boot record (MBR). This will render the system unbootable.

If you wish to install Red Hat Enterprise Linux 4 on a RAID1 partition, you
should clear any preexisting bootloader from the MBR first.
</quote>

Denis, please advise if any further revisions are required. I will be posting
this as a kbase as well upon verification to help visibility. thanks!


Comment 7 Don Domingo 2008-06-02 23:17:42 UTC
Hi,

the RHEL4.7 release notes deadline is on June 17, 2008 (Tuesday). they will
undergo a final proofread before being dropped to translation, at which point no
further additions or revisions will be entertained.

a mockup of the RHEL4.7 release notes can be viewed here:
http://intranet.corp.redhat.com/ic/intranet/RHEL4u7relnotesmockup.html

please use the aforementioned link to verify if your bugzilla is already in the
release notes (if it needs to be). each item in the release notes contains a
link to its original bug; as such, you can search through the release notes by
bug number.

Cheers,
Don

Comment 9 jas 2009-07-31 13:10:04 UTC
Hi.

Having just dealt with this problem and not having read the release notes, I wanted to add my 2 cents worth...

First, the documentation as included in the release notes isn't very clear at all.  It says: 

<quote>
The Red Hat Enterprise Linux 4 version of GRUB does not support software
mirroring (RAID1). As such, if you install Red Hat Enterprise Linux 4 on a RAID1
partition, the bootloader will be installed in the first hard drive instead of
the master boot record (MBR). This will render the system unbootable.

If you wish to install Red Hat Enterprise Linux 4 on a RAID1 partition, you
should clear any preexisting bootloader from the MBR first.
</quote>

This statement is confusing to a person who might be installing for the first time and has nothing written INTO the MBR!  While the bug report started out as such, the wording that made it into the release notes implies that you already have something in the MBR which is not always going to be the case!  The first paragraph shouldn't end in "This will render the system unbootable".  Having the boot loader installed to the first partition on the first hard disk will not render the system unbootable.  I recommend adding something to the effect of "if the MBR contains a pre-existing  boot loader from a previous installation".

That being said, the documentation also doesn't point out that by writing grub to just /dev/sda1 that one of these three scenerios could occur: (I've seen all 3 of these situations)

1) The boot loader is written to /dev/sda1 during kickstart and never makes it to /dev/sdb1.  Is it supposed to?  If yes, "great", but if "no", what happens when /dev/sda1 fails and /dev/sdb1 takes over? No boot sector.
2) The boot loader is written to /dev/sda1 and eventually ends up on /dev/sdb1.  This has happened for me, but not all the time, and I can't seem to figure out when it happens versus when it doesn't happen. 
3) The boot loader is written to /dev/sda1 and is then later CLEARED.  I've done a LOT of testing on this scenerio which is definately repeatable.  After the system is fully kickstarted, and /dev/sda1 contains the boot loader while /dev/sdb1 does not, if I issue a "reboot -f", I see just before the boot: "md: md0 is still in use", then the system boots perfect fine, but during boot it somehow syncs /dev/sdb1 to /dev/sda1 (dirty cache?) which clears the boot loader data on /dev/sda1 and thus renders the system unbootable ON THE NEXT BOOT.    This, of course, is pretty serious because now, the system is completely unbootable on the NEXT boot which might not happen until much later...

I chose a different approach.  I let Anaconda install to the partition, but then in my kickstart script, I scripted the installation of grub to BOTH MBRs:

grub --batch <<EOF
root (hd0,0)
setup (hd0)
root (hd1,0)
setup (hd1)
EOF

Now, nothing the RAID does is going to have any effect on my installation.  Of course if you need to rebuild the disk, you need to re-install the boot sector manually, but using the Red Hat strategy of writing to the partition wouldn't change this.

We aren't using the RHEL 5 yet, but even if "bootloader" allowed writing to the MBR for RAID-1 (which it seems that 5.4 may?), where would it write to? -- the MBR on the first disk?  It's not clear that the kickstart "bootloader" directive allows you to explicitly state which disks the boot loader should get installed to.  I don't even know how it would figure this out.

Any feedback?

Jason.

Comment 10 Paul Wouters 2009-11-24 03:50:02 UTC
It's the same in RHEL5 (I tried centos 5.4)

After boot I can run "grub-install /dev/md0" (md0 is my /boot on raid1) and then I can unplug either drive and it will still boot (this is on sata drives, not pata drives)

But I haven't found a way to make Anacondo do it right. I tried doing it in %post in the kickstart file but then it complains about there not being proper drives


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