Jeremy Katz wrote:
On Tue, 2008-12-02 at 11:26 +0100, Hans de Goede wrote:
Jeremy Katz wrote:
On Mon, 2008-12-01 at 18:58 +0100, Hans de Goede wrote:
You are right studying the code further this does indeed happen. And installing
to the first sector of the raid set partitions should be fine, assuming that
the disk has a dos like mbr which just bootstraps to the bootsector of the
active partition, but what if the disk does not have a valid mbr?
This has come up from time to time. One answer is that if we don't
detect something that looks like an MBR and we're doing this (or any
install /boot partition type installs), we should overwrite with a
"real" MBR. The problem is that this could trample over some other boot
loaders which has been something we haven't been willing to do in the
past. Maybe we should pop up a warning and default to doing so, but
give a way out if the user knows that they have a valid reason. Even
though I hate those sorts of things :/
I vote for just defaulting to installing on the MBR even in the raid1 case, if
the user wants the redundancy one gets from installing into the mdraid
partition, they can still easily select that. The user needs to have either a
special BIOS, or needs to modify the BIOS settings and / or remove the disk
when it died, which all require a very experienced user. I don't think it is to
much to ask this special group of users to change the selection from install to
mbr to install to partition during install if they want the additional
redundancy this gives.
That is a major change from what the behavior has been essentially
forever. And it's the sort of change that leads to downtime and admin
cursing. I really don't think that just installing to one MBR by
default if you're doing a RAID'd /boot is the intent or the desire... if
we're going to default to doing the MBR, then we need to do similar bits
to ensure that there's a boot record installed on both MBRs.
Ok then how about still defaulting to the old behavior, but atleast allow
installing to the MBR in the raid1 case (which we currently do not allow)? Note
I don't have much of an opinion on this either way, I'm just trying to fix: 217176
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
