On 12.07.2014 21:03, Gene Czarcinski wrote:
On 07/08/2014 06:17 PM, Matthew Garrett wrote:
* Spec doesn't address how a spec compliant installer should behave
when installing along side an existing installation: Should
bootability of the previous OS must be preserved? That seems a
critical point of contention with most distros erring on the side of
"oh, whatever" <hand waive> "user obviously doesn't care about the
other OS that much, they're installing ours." I think as a default
behavior it's pernicious.
Sure, that's outside the spec. If there's a boot fragment for the other
OS then it'll remain installable. If the OS wants to support booting
non-compliant OSes then it should ensure that fragments are generated.
What*is* missing is guidance on naming of chainload/efi fragments -
using the machine ID there is obviously inappropriate. I'll add
something on that.
I have been at this for a lot of years and one thing I have learned (the
hard way as usual) is "*do not destroy a working system*". That is, when
you want to do something like upgrade from Fedora 19 to Fedora 20, first
have you OS installed in a separate partition (or, in my case, separate
BTRFS subvol) and then install the new system into a different partition
or btrfs subvol.
These days grub2 does not play well installing to the boot partition ...
it has to go into an MBR. That is OK, it installs into the MBR of the
boot drive such as sda and I use either 30_os_prober/os-prober generated
menuentry items or some 40_custum "hand-crafted" menuentry items which
"chainload the configuration files".
While moving forward, we need to be careful and not break the capability
to boot old installs after installing the latest and greatest.
This is *not* an argument to keep os-prober. On the contrary, I want to
get rid of it as it is currently implemented and used. But, I want to
have some way to boot old installs as well as the 2000 pound gorilla OS
(Windows). I believe Chris's point able OS X is spot on ... just ignore
it, the user can boot it up using the native firmware.
In general I agree with Chris Murphy's point of view and his suggestions
... especially about not using vfat as the common location for
configuration info. I will add my comments as they occur to me.
Gene
VFAT == Very Fragile All Time :)
extlinux fan club
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
