/boot on RAID with fedora16

[Sam Varshavchik]

Reindl Harald writes:

>
>
> Am 15.02.2012 03:52, schrieb Chris Adams:
> > Once upon a time, Sam Varshavchik <mrsam at courier-mta.com> said:
> >> Alex writes:
> >>> I understand /boot on RAID1 on fedora16 isn't supported.
> >>
> >> That's news to me.
> >
> > It is apparently the "official" stance; see the F16 common bugs page.
>
> and why in the world was a release made with such a "common bugs page"
> instead fix such MAJOR BUGS?

Short-term thinking, and a lack of long-term planning, that's why. Large  
enterprise installs of RHEL mostly employ servers with hardware RAID, mostly  
via vendor-provided binary blobs. Large enterprise installs of RHEL are done  
by wiping the server and imaging it afresh. Old-school IT, with roots in the  
UNIX world, are not familiar with the concept of an actual upgrade. They  
always did that, with UNIX, by wiping the server and loading the new  
release, afresh, so that's what they do with Linux too. The fact that a good  
portion of existing seats whose partitions start at sector 63 will find  
themselves bricked, with this upgrade, is of very little concern, since, as  
I said, most upgrades are done as fresh installs.

As such, mdraid, and the upgrade path, is of little value to RHEL, and I  
think it's just not deemed important enough.

The short-term thinking here is that what's happening now is that this is  
pissing off the people who, maybe a decade from now, maybe more, maybe less,  
will find themselves in positions to make technology decisions. And if  
Fedora's mindshare in the next generation of technology decision-makers  
drops, I believe that there's going to be a fall-out from that. They won't  
be looking at RHEL, but rather at whatever they abandoned Fedora for, and  
that they're comfortable with.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20120215/89417850/attachment.sig>