On Tue, 28 May 2019 10:26:10 -0600 Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > 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. I agree with this. > 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 It has worked fine for me until this update. Of course, I used a custom install. > 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. Does this larger boot volume have to be at the start of the drive. Could I re-purpose a swap partition into a boot volume? So, couldn't there be a utility, which when the user points it at an alternate installation, it creates a link in the boot volume with priority. The way grub(1) used to do with the configfile entry. > 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. For a single large boot directory for all OSs on the system, couldn't there be a directory for each OS, allowing for both update and a boot selection screen (a menu of available OSs). > > > 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. I'm not familiar with the term ESP. From context, some kind of partition? Is the boot volume you refer to where the Fedora menu entries are stored /boot? Or a separate partition? > > > 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. Perhaps that could be the basis for a new utility; point it at /dev/sdx and it creates the *conf files in a directory in the boot directory. So, what is the benefit of doing it this way? You've described what has been lost, but what has been gained? What's the rationale for doing it this way? Is the trade-off worth it? My first impression is that this is a step backward. But I hardly understand what is going on here. _______________________________________________ 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
