e On Tue, May 28, 2019 at 9:09 AM Richard Ryniker <ryniker@xxxxxxxxxxxx> wrote: > > Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote on Mon, 27 May 2019 22:27:16 -0600: > > >Dual Fedora's isn't officially supported. The installer almost always > >steps on the previous Fedora's bootloader making it unbootable, in > >favor of a new bootloader for the new Fedora installation. > > This deserves some attention. I expect to be able to install Fedora in > some disk space, and still be able to boot an older Fedora previously > installed in other disk space. For the default installation, that hasn't been the case in a long time. One of the reasons this doesn't work out of the box is anaconda doesn't activate LVs for prior Fedora versions, and therefore grub2-mkconfig doesn't discover them. https://bugzilla.redhat.com/show_bug.cgi?id=825236 The bootloaderspec feature in Fedora 30 makes this use case easier to support, but it's still not going to just work out of the box because each Fedora installation has separate boot volumes, which means the latest installed and active bootloader sees only the latest Fedora version's bootloader configuration files. If Fedora versions share a boot volume, then the latest version bootloader sees both installations and can present them in the GRUB menu, but that's not part of the default/automatic installation behavior. One possible gotcha is the boot volume needs to be big enough. For a few releases it's been 1GiB which probably is big enough for two Fedora's to share, because we don't use kdump by default whereas I guess it's configured on RHEL and that was the impetus behind the boot volume size change. Another gotcha is on UEFI, the older Fedora during software updates will (rarely) need to update the bootloader which will step on the binary files in /boot/efi/EFI/fedora, which isn't the end of the world but it's probably better if the old Fedora /etc/fstab is modified to remove the automount of /boot/efi so that the EFI System partition isn't ever updated except by the new Fedora. > I would like the Fedora Installer to be aggressive when it builds its new > boot configuration file, and copy as much as it can from old boot > configuration data. Certainly it cannot understand everything, but I > would prefer a menu item with some comment that Fedora does not know if > this will work but has included it because it was found in the existing > system, than to find my old configuration was simply discarded by a new > Fedora installation. On BIOS, it's preserved but ignored. On UEFI the contents of the EFI system partition in EFI/fedora are blown away and replaced. It's been that way since we've had UEFI support as far as I can recall. The nice thing is that on Fedora 30 with BLS support, the grub.cfg on the ESP no longer contains the Fedora menu entries, those are now on the boot volume. So they will be preserved, but again they're ignored out of the box because we don't automatically share boot volumes. > It may be the best solution is some dual strategy that has the Fedora > Installer do what is "easy" (other simple Fedora systems, maybe Windows) > and leaves harder cases (unknown systems, unusual configurations, storage > volumes that are not accessible during installation) for some utility > that can be executed after installation by a user who can quide it to > make desired changes to the boot configuration. > > "Do no harm." applies here, because recovery of boot configuration data > lost during Fedora installation requires knowledge and experience beyond > what many users have. Something that has been lost is a way to create the bootloader configuration files if they're deleted. With Fedora 29 and older you can just run grub2-mkconfig and that pile of scripts will discover all the information needed to regenerate menu entries. That's no longer the case, as grub2-mkconfig doesn't create menu entries for Fedora anymore, it'll just recreate a static grub.cfg with the command to look in /boot/loader/entries for *conf files. But if those *conf files are missing, you get no entries in the GRUB menu. How do we recreate them? *shrug* Right now that script is in the kernel RPMs, so you'd need to reinstall a kernel to get a new *conf file in place. -- Chris Murphy _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
