TC7 bootloader installation

[Dennis Jacobfeuerborn]

On 11/04/2012 04:39 AM, Adam Williamson wrote:
> On Sun, 2012-11-04 at 03:29 +0100, Dennis Jacobfeuerborn wrote:
>> On 11/04/2012 02:50 AM, Adam Williamson wrote:
>>> On Sun, 2012-11-04 at 02:36 +0100, Dennis Jacobfeuerborn wrote:
>>>
>>>> Also what does this mean for UEFI installations with Fedora? When I install
>>>> F18 will it detect that the UEFI bits already exists on the harddisk and
>>>> overwrite only the binary bits and only add the new install to the grub menu?
>>>
>>> What the current code does is, if you have an existing Fedora entry in
>>> the UEFI boot manager, simply erase it and write a new entry. I haven't
>>> checked recently what it does with the EFI system partition, but it does
>>> not re-use the previous copy of grub(2)-efi.
>>
>> But what happens to the files in \EFI\redhat specifically grub.conf? Will
>> this just be updated or overwritten (thus killing the entry for the
>> previous release)?
> 
> Like I said, I haven't tested recently enough to be 100% sure. My guess
> is that they either just get blown away and rewritten - they're actually
> owned by the grub2-efi package - or that anaconda creates a second EFI
> system partition and you wind up with two. I think it did that at one
> point, but I don't know if it still does. In general, multiple UEFI
> installs is just not a case that we've covered very well yet. With the
> current state of Fedora's support, you're just better off sticking to
> one Fedora install at a time and giving the installer a nice clean slate
> to work with when you reinstall. One Fedora install per disk is as far
> as you can push it without having to start fixing stuff up manually, I'd
> guess.
> 
>>>> While I get that BIOS stuff needs to be supported for a while I think
>>>> supporting UEFI multiboot would simplify things because you can separate
>>>> the installations completely rather than having to deal with updating
>>>> existing boot structures that could potentially break stuff.
>>>
>>> They're really separate topics and don't need to be considered in
>>> relation to each other.
>>
>> What I was aiming at was that currently in order to install a new Fedora
>> release next to the old one the data in \EFI\redhat needs to be modified
>> carefully to add the new stuff but also keep the old config intact.
>> With proper UEFI multiboot support each release could create a directory
>> \EFI\fedora${releasever} and install the bootloader there with a fresh
>> grub.conf only for that release. Since there is no shared data between the
>> two Fedora version no breakage can happen with the update of grub.efi or
>> grub.conf.
>> The user can then directly boot into both release from the UEFI boot menu
>> rather then first having to select "Fedora" from the UEFI menu and then
>> again select between the releases from the grub menu.
> 
> I understand how it could work in theory, yes. I'm on record as saying
> that UEFI's bootloader design is a deal saner than BIOS's, and should
> enable much better multiboot co-operation between OSes in an ideal
> world. It's just not something we currently support very well in
> practice.
> 
> BTW, a directory named after the release version wouldn't be a very good
> idea, because it'd get very confusing if you did upgrades, and it
> precludes multiple installs of the same release. It'd probably be best
> to use some kind of unique identifier.

So for fun and profit I just went ahead and copied the redhat directory to
fedora15, modified the grub.conf to remove all other entries and set the
timeout to 0 and installed a bootloader entry with efibootmgr. Now i can
boot straight into the old system from the UEFI menu without an additional
menu layer. As far as I can tell the only thing missing now would be the
ability to tell tools which grub.conf to modify in case of e.g. a kernel
update. Other than that a new installation could now completely overwrite
the redhat directory and the Fedora bootloader entry and it wouldn't affect
the old installation at all which makes installations/upgrades safer and
the involved code simpler because it doesn't have to deal with modifying
shared data anymore.

Regards,
  Dennis