[Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs

[Reindl Harald]

Am 21.02.2014 23:04, schrieb Adam Williamson:
> The problem is that there are - and this is probably *literal*, not a
> rhetorical flourish - millions of Special Little Use Cases like yours
> (the one below, snipped for brevity) out there. *You* want it to be easy
> to skip /home. *She* wants it to be easy to resize a Slackware install.
> *That guy* wants to use btrfs. *My cat* likes RAID. It is becoming very,
> very clear that we just cannot undertake to support them all and
> guarantee that they are all going to work in a release. It's just _too
> much work_. Everyone agrees that it would be nice if we could, but then
> everyone agrees that it'd be nice if I had a solid gold toilet. Some
> nice things just don't happen. We do not have the resources to be in the
> business of writing the world's biggest disk configuration tool and
> guaranteeing that it'll never go wrong, which isn't *quite* what we're
> currently trying to do, but it's not far from it

that may all be true but the fact that i was *not* able to assign
4 simpüle vdisks to /boot, / and /data in Anaconda the last time
i sued it and gave up after i managed to get /boot and / is not
a compliment - RHEL7-Beta1, very recently

i gave up and added the third virtual disk after the setup
fine in case of single disks, a show-stopper if you intend RAID partitions

_________________________________________________________

that is also not a compliment

md0 = /boot (RAID1)
md1 = / (RAID10)
md2 = /data (RAID10)

the plan was to have them *exactly* in that order and not
the large RAID10 on /dev/sdX1

that was Fedora 16 or 17

Personalities : [raid1] [raid10]
md1 : active raid10 sdd2[2] sdb2[0] sdc2[5] sda2[4]
      40956928 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md2 : active raid10 sdd1[2] sdb1[0] sdc1[5] sda1[4]
      1904636928 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 0/15 pages [0KB], 65536KB chunk

md0 : active raid1 sda3[4] sdb3[0] sdd3[2] sdc3[5]
      511988 blocks super 1.0 [4/4] [UUUU]
_________________________________________________________

the same 2011 with Fedora 14, the expected order

Personalities : [raid1] [raid10]
md2 : active raid10 sda3[4] sdd3[0] sdc3[5] sdb3[3]
      3875222528 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 4/29 pages [16KB], 65536KB chunk

md1 : active raid10 sda2[4] sdd2[0] sdb2[3] sdc2[5]
      30716928 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 1/1 pages [4KB], 65536KB chunk

md0 : active raid1 sda1[4] sdb1[3] sdd1[0] sdc1[5]
      511988 blocks super 1.0 [4/4] [UUUU]
_________________________________________________________

what is *that hard* for Anacodna *not* to shuffle around and
add the partitions on each drive exactly in that order i enter
them? in that case /boot, / and /data at the end is clear and
does not need any additional line of code

Anaconda was +always* the weakest part of Fedora/RHEL if it comes
to partitioning but currently it is unbelievable and thanks god
that i do not face it regulary by clone VM's and even physical
machines with complex setups

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140221/72057ec6/attachment.sig>