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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test