On Tue, Jan 12, 2021 at 8:24 PM Brian C. Lane <bcl@xxxxxxxxxx> wrote:
[snip]
> >
> > The `$prefix` variable will be set to the device partition where
> > `/boot/grub2/grub.cfg` is stored, using the partition filesystem's
> > Universally Unique IDentifier (UUID). That way the correct GRUB
> > configuration file will be loaded, making it as secure as the current
> > approach where the configuration file in the ESP is used.
>
> I don't see how adding more files and splitting information between
> them helps simplify things. You still need a system specific grub.cfg in
> the EFI directory so you haven't removed anything.
>
Yes, but this file should be static and never change. As mentioned, it
will just search the correct partition using GRUB's search command,
set a new $prefix variable and finally run `configfile
$prefix/grub.cfg`.
> And now users who are trying to debug things have more places to look
> for problems.
>
> If you want a consistent way to find the grub.cfg on bios and efi, why not
> create a symlink in /boot/grub2/ like we already do for grubenv?
> Actually, we already have symlinks in /etc/grub2.cfg and
> /etc/grub2-efi.cfg
>
Symlinks have been proven to be error prone and a constant source of
issues for users. In fact one of the goals of this change is to get
rid of the grubenv symlink.
Very often we have bugs filed about users removing the symlink, then
creating a new grubenv with `grub2-editenv create` in
/boot/grub2/grubenv and then complaining about the GRUB env variables
not being updated (because /boot/grub2/grubenv is now a real file
instead of a symlink to the one in the ESP).
So the goal is for users to only care about /boot/grub2/grub{.cfg,env}
and never having to touch the files in the ESP. That's what most
distros do (and even we do on images generated with coreos-assembler
and OSBuild), to avoid making EFI a special case and to have
consistency across EFI, x86_64 legacy BIOS and ppc64le.
Best regards,
Javier
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
