Hello Nicolas, On Mon, Feb 11, 2019 at 1:41 PM Nicolas Mailhot <nicolas.mail...@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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org
