On 02/01/2017 02:55, Chris Murphy wrote:
> 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).
Ok, right. Then we could get the best of both worlds, in keeping with
the Hippocratic Oath to at least do no harm, by dropping the exit() in
this two line pseudocode:
if thisBox.alreadyHas( anotherFedora ) and isUEFI:
showDialog("WARNING: you already have a Fedora installation\n"
"If you continue it will be OVERWRITTEN!")
...or "will be rendered inaccessible", until your suggestions not
implemented or some progress is made. Right now people who have not read
this thread risk losing their data.
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.
Ok, I would not mind going outside the installer to get multiple Fedoras
on my machine. Perhaps we should set up a temporary very informal guide
on how to do that.
Is there a wiki like service associated with this list where we could
gather the wisdom accumulated so far? Tests done, machines used,
configurations, workarounds, repeatable scenarios, faqs, howtos, hearsay?
>
> 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.
It's easier for them because they control their equivalent upstream
grubs and everything else. Besides the money.
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...
I am ok with that for the kind of work I do, but I understand the
average Joe would not like it. You could argue Joe should run Mint instead.
>
> 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.
>
Agreed.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
