On Mar 23, 2014, at 12:19 PM, Liam Proven <lproven(a)gmail.com> wrote:
The thing is, edge cases like this are really informative. It's really
hard to trace an obscure intermittent bug and it's really hard to file
a useful bug report when the bug is "it doesn't work for me" and you
can't really add more data than that.
OK but what you've done is said what I've never heard anyone say, which is having
never successfully installed Fedora to baremetal in 10 years. And on top of it, you
haven't stated the nature of the failure, either the error messages you've gotten,
or the logs the installer always produces from the moment it's launched.
But if you have a whole bunch of users saying "this doesn't
work for
me" or "I find this really hard" or "this program can't give me
the
options I want", then that to me seems like a big obvious signal that
something is badly wrong and needs examination and possibly
re-consideration.
Define "whole bunch", how this is ascertained, and how the assertion applies to
Fedora.
It's not much use for tracing a particular bug - chances are that
for
everyone who's failed to install an instance of F20, the reason is
different. There's no one bug to file.
I don't even know what you mean by "failed to install" because there are
several ways that can manifest but in any case the installer always writes log files from
the moment it's launched, figuring out the problem isn't difficult especially when
it's reproducible.
In this case, for instance, I'd point the accusing finger at the
installer developers' assumptions that:
[a] on a system with 2 disks, either of those disks can be usefully
analysed by the install program in isolation. That's an invalid
assumption and the result is a program that can't handle many common
instances.
I can't tell whether you're referring to Fedora's installer or not. But it
doesn't work this way.
[b] that one will want to install the bootloader on the MBR of the
drive with the root filesystem. That's an invalid assumption, too.
Why, and what alternative is valid?
[c] that one will want to install a bootloader into an MBR and
nowhere
else. That's an invalid assumption.
A default bootloader had to be chosen, and GRUB2 is what was chosen. The boot.img portion
can only go in the MBR, and the core.img is too big to fit in a VBR so it's usually
put in the MBR gap (or BIOS Boot on GPT disks). There really isn't a work around for
this given the design of GRUB2. If you want to install a bootloader to a VBR then a
different bootloader selection is needed, such as extlinux. Fedora supports this as a
hidden option, right now it's too much effort to give it equally visible support.
I'm not aware of any other distribution that even supports two bootloaders. All kernel
updates support either GRUB or extlinux (and others).
[d] that on a system with multiple Linux installs, you can group
sets
of partitions by install - in other words, these ones belong to
install #1, these to install #2, these to install #3. That's invalid
for me - I share /home and swap between all my installs. Only the root
FS is unique to each. That breaks F20's installer.
Define "breaks" please produce log files for these install attempts. I have done
what you suggest and it doesn't break for me, it installs and uses a pre-existing
/home and swap just fine.
These are not bugs. These are design errors, where someone has assumed
that their personal preconceptions are universal truths.
Flawed logic. The design decisions aren't going to mesh with everyone's
requirements. Multibooting on BIOS computers is fundamentally flawed besides not being
standardized at all, and therefore there is no one correct way to arrive at a multiboot
system, and no one correct way to interpret a multiboot system and always support
installing to multiboot systems.
Chris Murphy