|
On 07/08/2014 06:17 PM, Matthew Garrett
wrote:
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.* 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. 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 |
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
