Chris Murphy wrote:
On Mar 21, 2014, at 6:18 PM, Liam Proven <lproven@xxxxxxxxx> wrote:
Secondly, I can confirm this finding. I was completely unable to install
F20 using the current installer program. My system has 2 drives - a 1TB HD
and a 120GB SSD. The SSD holds Ubuntu and Win7; the 1TB drive holds /home,
swap, a dedicated Windows swap partition, a Windows data drive, and 2 spare
unused root partitions for test distros.
This is /not/ a very complex layout - there is no RAID, no LVM, no GPT,
nothing hairy or difficult.
It is actually a complex layout. Most of the world's installers can't deal
with what you just described.
I will simply note that the old installer could...
[...discussion of unrelated OS behavior...]
And yes, it's fair to bring up what money bags companies with more money and
resources than god. Because this is an area where they've all considered what
you're describing, is an edge case. Not common at all.
Really? On a percentage basic, I assume you're right. But in terms of raw number
of the current Fedora user base, I would guess that 30% of the users have
another OS installed, and almost as many have multiple drives. Getting a 120GB
SSD for <$100 these days is causing many people to rethink. So the number of
people who do or may see this is probably in the thousands. It certainly isn't rare.
The Fedora 20 installer's default/easy/guided/auto path installs to free
space. Yet it has more options and outcomes than the total number of all
possible options in both the Windows and OS X installers combined.
That's definitely true, my personal experience indicates that many of the
outcomes are suboptimal (meaning fail to boot ANYTHING after install, delete of
otherwise lose data on existing partitions, or won't boot anything except Fedora).
Hmm. Now I believe you were just about to cite a bugzilla ID describing the
above behavior?
It's really impractical to list all the failure modes, and probably not helpful
id someone did. Would a description of seemingly valid actions resulting in
failure repeated in N variations help or swamp the system, getting no improvement?
Would a suggestion be valid in a bug report, which said: if the user specifies a
partition (meaning valid storage unit) with a known filesystem installed the
installer should default to "use, don't lose" and present [use] [reformat]
[oops] options before proceeding.
The F20 installer was completely unable to understand it and allow me to
install a complete system. Assigned some 250GiB of space, it said that it
needed 6.5GB and there wasn't enough room.
I've done hundreds of hours of installer testing over the last year. It has
been really frustrating. This is the most complicated/capable installer I've
ever worked with other than maybe the OpenSUSE installer. Out of the gate it
offerred too much compared to the time/resources allotted for QA, debugging,
and code changes needed.
The reality is, you get either stability or you get features. You don't get
both. The mantra for the new installer was about getting as many of old
installer's features into the new one as soon as possible, and stability was
simply expected to have to take a hit in order to do that. And that's exactly
what happened.
It seems that there are a number of users, some of us experienced users, who
feel that the current "new" installer is lacking in both. It's hard to find a
way to tell it to do what you want, and when you do in many cases it doesn't
work properly.
Let's pretend the installer could only do 20% of what the old installer did,
yet it was almost bullet proof - never crashed, didn't have any of the logic
problems you're talking about, and so on. Would Fedora users have understood
that trade off? Maybe a lot of them would have. But then we'd have a lot of
others pining for a right to a GUI that lets them create some of the most
esoteric storage layouts of all time.
The first thing users don't understand is why things in Fedora are rewritten
from scratch instead of improved. Evolution rather than replacement. Fedora
dinosaurs don't improve until they become birds, they are whacked with a meteor
and replaced with mammal 0.9, a not ready for existence in a harsh world,
premature baby. And when that becomes reliable and usable, WHACK! comes the next
meteor.
And guess what? That has to be coded, and ostensibly should be tested. And
quite frankly the QA resources are really limited. Not every possible
combination permitted in Manual Partitioning is tested at all. That's how
much it can do. It's nearly unlimited possibilities because, guess another
thing, I've never once seen it disqualify a drive layout from the start. I've
never seen it look at a crazy layout and go "umm yeah, no please use gparted
and obliterate this drive first." But I've seen that many times with the OS X
installer: flat out refusal, "go format the drive in Disk Utility." Quite a
few times when trying to prepare a drive for dual boot on OS X I've seen the
error message that the disk can't be partitioned, and that I had to
obliterate the whole drive and reinstall OS X from scratch in order to
install Windows side by side. So really, anaconda is extremely tolerant and I
think that's something of a problem too. It probably should be disqualifying
a lot of nut case layouts, and just saying no.
And would it be easier to test improvements on an existing project (yes), or
more responsible not to release software which doesn't work (yes, again)?
In trying to install, it erased one of the spare-root partitions and was
unable to recreate it in the available empty space.
And you have a bug for this? It's *really* difficult to get the installer to
inadvertently delete partitions. It requires two clicks: selection, then
deletion. For guided partitioning, the button is labeled "delete" whereas the
button in manual partitioning is labeled as a minus symbol.
Is there a case where a partition of a certain partition type will be considered
"up for grabs" and used without asking? Real question, not being snarky, I think
I've seen this as well, the boot partition of one install was reused as the boot
for a newer total install, and had it asked I would not have clicked a
[reuse-partition] button.
One thing that some people don't easily grok is that Manual Partitioning
isn't partitioning oriented.
Why not? And why isn't there a mode which is, so the user can set up ther system
as they need it?
> It's mount point oriented. And that's because
mount points can be partitions, subvolumes, logical volumes, or md block
devices. It's not correct to call all of those things partitions. But all of
them ultimately are assigned mount points. This is a top down view, rather
than the typical bottom up view where you always have partitions, and then
maybe you have raid devices or LVs or subvolumes. The idea is to think less
about the details of the layout and more about the outcome you want.
It doesn't seem to know about using nbd, either, or creating array with a
deliberately missing member (nbd to be added later, write mostly). I don't fault
the lack of nbd support, I do the missing way to create RAID with missing members.
Did the install team ever consider just letting people drop into a shell and use
command line tools to do a tiny bit of magic, then rescan the physical devices
again to be sure the configuration is understood? It might save a huge pile of
user frustration and cries for support of flexible configuration options.
This is understandably confusing if you're really familiar with storage stack
creation. But most people aren't. Nevertheless, one of the first steps is
drive selection, which is about the most bottom layer there is. And then the
very next step is the top most layer, which are the mount points. So it's an
unexpected context shift from bottom to top, seemingly without any
conversation about what's happening in the middle. It's a different
approach.
If you remain attached that what you're doing in Manual Partitioning is in
fact partitioning, you'll continue to be frustrated.
Then why not provide manual partitioning, or rename the mode to something
"pretending you have any say in how we do install?" Frustrated is exactly the
issue here.
Now, if you didn't file a bug about your anecdote, I want you to imagine me
staring at you with a look of "really?" Because this much effort complaining
yet no bug report? How exactly do you expect it to get better?
I've been a user since fc3 or 4, and I have learned that complaints about design
issues are treated as suggestions for future enhancement rather than bugs. If
the software functions as designed it's not a bug, it's a design decision. I
have said that on (rare) occasions, although I try to say "the software doesn't
currently do that."
--
Bill Davidsen <davidsen@xxxxxxx>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
