Hello Nicolas,
On Mon, Feb 11, 2019 at 1:41 PM Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
Le 2019-02-10 20:05, Chris Murphy a écrit :
> On Wed, Feb 6, 2019 at 1:08 AM Javier Martinez Canillas
> Between this feature for F30, and the F29 feature to hide the grub
> menu which comes with boot success+fail marking by using the grubenv,
> there are substantial changes in bootloading on Fedora that exist no
> where else and near as I can tell there is no documentation at all. I
> can't really call specs we don't fully follow, or feature pages, to be
> documentation.
FYI I had to rescue two EFI rawhide system this week-end borked by grub
changes. As far as I could reconstruct:
1. the new grub needs the env file to be regenerated or kernel scriplets
will fail "environment block too small"
Yes, grub2-editenv is too fragile. The problem is when the grubenv
file is modified without grub2-editenv, that breaks the assumption
grub2-editenv makes that the file will be filled with # characters to
always have a size of 1024 bytes. This was also the case on non-BLS
configuration, but in that case only the saved_entry variable was set
while for BLS also kernelopts is set.
2. there are *two* versions of this file, one in EFI directory space
another in /boot/grub2
3. half our tools think the correct path if the first one, the other the
second is the correct one
4. they all depend on things written by the other half in a "common"
file
5. it only works because the boot/grub2 is a symlink to the EFI version,
syncing all the tools
6. but nothing makes sure it is
7. you you follow net advice blindly, you will break the symlink while
regenerating the env file and fixing the error in 1.
I didn't get how it will break the symlink. IIRC grub2-editenv create
will just follow the symlink and "empty" the grubenv file (where empty
for GRUB means adding the '# GRUB Environment Block' header and
filling with # characters up to 1024 bytes).
8. the result is unbootable, it will miss the kernelopts line in the
file the EFI bootloader reads. No kernelopts line, no root to pivot to
in initramfs
I also wonder how you got in this situation, the
grub2-switch-to-blscfg script should had restored the original
(non-BLS) grub2.cfg file if grub2-editenv set failed. I tried to
reproduce your issue with a borked grubenv but couldn't, I'll try to
dig deeper on this.
Regards,
--
Nicolas Mailhot
Best regards,
Javier