On Tue, 28 May 2019 13:46:11 -0700 Samuel Sieb <samuel@xxxxxxxx> wrote: I'm still exploring BLS and UEFI, so the questions below might be naive. > On 5/28/19 1:23 PM, stan wrote: > > On Tue, 28 May 2019 10:26:10 -0600 > > Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > >> 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? > > The /boot partition can be anywhere. I generally don't even create a > separate partition, it's just included in /. But if you're wanting > to share it, it would need to be separate. I just got into the habit when that was the recommended configuration, and haven't changed. My understanding, after some reading, is that there has to be a separate /boot/efi partition, and that was where the BLS information resided. Except for people using systemd-boot, as described here, https://bugzilla.redhat.com/show_bug.cgi?id=1714007 and here, https://wiki.archlinux.org/index.php/Systemd-boot > > 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. > > You can still do that. Even with BLS I would expect you could add an > entry in the static part of the grub.cfg to point to the other > installation. But aren't all these BLS scriptlets in the same partition for Fedora? I thought that under BLS the grub.cfg was just a dummy place holder, and all the heavy lifting was done by the scriptlets. > >> 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). > > Probably, but you would somehow have to convince each OS install to > update its own part. Wouldn't that just be a symbolic link from the /boot(/efi) partiition to wherever the BLS scriptlets reside? > >> 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's the EFI boot partition where the firmware knows to find the boot > loaders. It's not /boot, it's normally mounted at /boot/efi. And I don't have one. I think this is why my attempt to install as UEFI failed, because I used a custom configuration and didn't create a /boot/efi partition. But isn't the /boot/efi partition where the BLS scriptlets reside? _______________________________________________ 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
