On Tue, May 28, 2019 at 8:32 PM stan <upaitag@xxxxxxxx> wrote: > > 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. It is confusing because there's an upstream bootloaderspec that originated along with gummiboot bootloader which became systemd-boot (or sd-boot). The variants are sd-boot, rpm-ostree, and Fedora's GRUB blscfg.mod and kernel install plugins. Each of these is doing something a little different. sd-boot expects kernel+initramfs+bls *conf files to all be on the EFI system partition. It is a UEFI bootloader only. And it expects to mount the EFI system partition to either /boot or /efi > My understanding, after some reading, is that there has to be a > separate /boot/efi partition, and that was where the BLS information > resided. Out of the box on Fedora 30, whether UEFI or BIOS, the bootloaderspec *conf files (the menu entry drop in scripts) are found in /boot/loader/entries which is a directory on the boot volume mounted at /boot You can optionally not create a /boot mountpoint using custom partitioning, and in that case /boot/loader/entries is a directory on the root volume mounted at / Fedora's GRUB, which includes the blscfg.mod (a GRUB module that parses bootloaderspec *conf files) will find them in either location, regardless of firmware type. So, unlike the upstream bootloaderspec, BLS *conf files are not on the EFI system partition. Pretty much the EFI system partition on Fedora isn't going to be a changing thing anymore. It'll occasionally get some EFI OSLoader (the actual bootloader binaries) updates, and I think fwupd stages firmware updates there for some things (?) that's about it. > 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. Depends on your point of view. The grub.cfg speaks GRUB language, and the BLS *conf files are a much simpler restricted set of commands. So most of the GRUB environment setup is still done by grub.cfg, but it's also non-changing. What changes everytime there's a kernel update is the menu entry. That's now in a *conf file, one per kernel. It does very much have the potential to seem like a Choose Your Own Adventure book, because each thing keeps pointing to something else. GRUB pre-boot environment binary -> grub.cfg -> grubenv & blscfg.mod -> /boot/loader/entries/*conf -> /boot/ So the grub.cfg reads grubenv to know things like default kernel, whether last boot succeeded and if so to hide the GRUB menu and if not to show the GRUB menu, and boot parameters. Then grub.cfg executes the blscfg module which in turn reads and parses the BLS snippets. > > 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? No symlinks on FAT. As complicated as it seems, the way forward for two or more Fedora's is a separate boot volume that's shared among them. And remove the automount of the EFI system partition on the older distro versions. GRUB + blscfg.mod will see /boot/loader/entries contains a bunch of *conf files, one per each distro specific kernel installed. OK I just realized a problem. There is only one grubenv and it will define the root file system as a variable that all of the *conf files will pick up and set as a boot parameter. Option 1: It is possible to change 'options $kernelopts ' by removing $kernelopts and explicitly list the boot parameters you want including a different root. Option 2: It is possible to have two, maybe three, different variables for kernel options in the grubenv, each with a different root; and then just edit the older *conf files to use the proper variable, .e.g. $kernelopts30 or $kernelopts31 Option 3: It is possible to have more than one 'options' key in each *conf file and they are combined So an fc30 conf file: ... options $kernelopts options root=/dev/mapper/fedora-root30 And fc31 conf file ... options $kernelopts options root=/dev/mapper/fedora-root31 That would cause both fc30 and fc31 to boot with the same kernel options in common except for the root which is explicitly set in the *conf file. I haven't tested how the *conf files are created however; I don't know if they are copied, which would preserve the custom defined root, appropriate for that distro version. So this needs testing and a write up if it works. > 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? The installer has a rather explicit bootloader related error message if a /boot/efi mount point is not defined on a computer with UEFI firmware presented. A common test@ axiom is: don't tell us it didn't work or that it failed. Tell us exactly in detail what did happen. i.e. a screenshot or cell photo of the point of failure, and likely also logs. -- 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
