F30 change, bootloaderspec by default

<a href="" title=""></a>

I want this change to succeed but I'm experiencing a regression, and
while trying to troubleshoot it I'm finding it difficult to understand
the myriad differences:

- I can't find the code. I assume all of it is in grub as blscfg.mod
and grub2-mkconfig and its associated scripts in /etc/grub.d but I'm
not seeing code or code reference in the change or here
<a href="" title=""></a>

- I can't find any documentation. In particular documentation that
explains how it differs from upstream logic and what files the user
should be interacting with to do typical tasks (typical for those who
tend to interact with the bootloader which should be a minority of
user); I know those differences are really substantial, not least of
which is how to change boot parameters. This is important because
there's a lot of grub2 documentation in Fedora and outside Fedora, all
of which conflicts with this feature. And Fedora's experts in QA and
those who interface with user as volunteer support agents, will need
to thoroughly understand the change, otherwise I'm concerned the
common advice will become "reinstall" or even just disable this

-How does the blscfg module find /boot/loader/entries? Is this path
hard wired somehow? I've got three different installations, all three
have identical grub environment variables shown by "set" command, and
yet one of the installations doesn't find /boot/loader/entries so the
only menu entry is to enter firmware.

- Is upstream expected to eventually accept this change? Have they
given feedback on the change? Are there any other distributions
planning on adopting it, maybe downstreams of ostree?


Re: F30 change, bootloaderspec by default

By Javier Martinez... at 02/06/2019 - 03:08

Hello Chris,

On Wed, Feb 6, 2019 at 5:28 AM Chris Murphy < ... at colorremedies dot com> wrote:
Is this on F29 or Rawhide? Also, it's on an EFI or BIOS install?

That's correct, most of changes are in /etc/grub.d/10_linux and
blscfg.mod as you said:

<a href="" title=""></a>
<a href="" title=""></a>

It depends on how you do it. Changing GRUB_CMDLINE_LINUX in
/etc/default/grub and running grub2-mkconfig should have the same
effect that with a non-bls setup. Using the grubby options (through
the BLS wrapper) is also supported for users using grubby.

Could you please elaborate a little bit? If you see a big mismatch
between some documentation and how the BLS support behaves, please
point out so we can try to make it more transparent for users.

It tries to look for them in ($root)/loader/entries/ and
($root)/boot/loader/entries/ for EFI and ($boot)/loader/entries/ and
($boot)/boot/loader/entries/ for BIOS. The blsdir variable in grubenv
can also be if you want a custom BLS directory path.

Is there any difference between the systems that work and the one who
doesn't? Could you please fill a bug for it, that will make the issue
easier to track.

On Rawhide the blscfg command now supports to load BLS entries to
troubleshoot these cases. For example you should be able to do:

blscfg (hd0,gpt2)/loader/entries/

to load all the BLS snippets from a directory or:

blscfg (hd0,gpt2)/loader/entries/loader/entries/036f3661be4047b6b678d491f76df6f4-5.0.0-0.rc4.git3.1.fc30.x86_64.conf

to load a single BLS snippet.

Not yet, it's hard to engage with upstream GRUB and even to upstream
simple patches take time.

Besides Fedora and RHEL, Endless OS is using our GRUB blscfg patches.
We have also been talking with the ostree folks to use the module so
they can drop the ostree admin instutil grub2-generate command that
genrates a GRUB config from the generated BLS snippets.

I'll be on PTO since today and without good connectivity, so I may not
be able to answer more emails until next week. Please ping Peter Jones
if you need help with this.

Best regards,