On Sun, Jan 1, 2017 at 6:31 PM, Mayavimmer <mayavimmer@xxxxxxxxx> wrote:
> On 02/01/2017 02:10, Chris Murphy wrote:
>> On Sun, Jan 1, 2017 at 1:45 PM, JD <jd1008@xxxxxxxxx> wrote:
>>>
>>> Without having done it myself, I suspect that for the 2nd installation, grub
>>> will
>>> make write into /boot/grub2/grub.cfg file an entry that is similar to the
>>> entry it makes
>>> when it detects a windows bootable partition.
>>
>> On BIOS firmware computers, yes. And it's the 2nd installation GRUB
>> that "owns" the drive. It is this grub.cfg whose generic entries
>> should be replaced using configfile to point to the 1st installations
>> grub.cfg. This is much more maintainable and compatible.
>>
>> On UEFI firmware, there is only one fedora bootloader and grub.cfg, so
>> the 2nd installation will overwrite the 1st. I would modify the
>> installation so that each has its own grub.cfg found at /boot/grub2
>> just like it's a BIOS setup (and is supported by upstream GRUB as they
>> do it this way by default, I'm baffled why Fedora does this
>> differently). And then create a minimalist grub.cfg on the efi system
>> partition that points to the two installation specific grub.cfgs by
>> using configfile command.
>
> Eminently reasonable.
>
> And while we are waiting for that, I would ask: why the UEFI overwrite
> pain? Can we add these 3 lines of pseudocode?
>
> if thisBox.alreadyHas( anotherFedora ) and isUEFI:
> showDialog("Sorry, cannot currently add a second Fedora")
> exit(0)
Because that code by itself would prevent replacing an existing Fedora
(of any release version). So now you need a dialog that tells the user
they need to first remove the existing Fedora to install a new Fedora.
And while that is arguably a less trouble UX, it thwarts the dual
Fedora user case where the user has the ability to hack up the
bootloader but doesn't want to screw around with the gory details of
OS installation.
This use case isn't that difficult to support if there were other
changes made to simplify installation and bootloading in general,
while also standardizing bootloading. macOS and Windows manage to do
this today and their installers are completely brain dead stupid. So
it doesn't take a complicated installer to do the things people *need*
to do. It takes a complicated installer to do the things people want
to do but could be met some other way but they don't want to do it
that way because it's not their way and get all pissy if the installer
isn't justifying their way with direct support. I still advocate
ripping out all of the custom partitioning UI... and I'm not a fan of
making the installer ass tons more complicated by inserting blivet-gui
into it. Just run that tool from outside the installer if desired,
cluttering up the installer just makes it more unwieldy...
When billion dollar companies have rock solid installers that only
support the 80% use case with essentially zero bugs and user
complaints about lack of function; compared to installers that try to
disproportionately appease the other 20% use cases with constant
regressions, it makes me think of project failure.
--
Chris Murphy
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
