On Tue, 28 May 2019 10:26:10 -0600
Chris Murphy <lists(a)colorremedies.com> wrote:
On Tue, May 28, 2019 at 9:09 AM Richard Ryniker
<ryniker(a)alum.mit.edu> wrote:
>
> Chris Murphy <lists(a)colorremedies.com> 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.