On Mon, May 25, 2020 at 4:00 AM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > On Sun, May 24, 2020 at 7:48 PM James Cassell > <fedoraproject@xxxxxxxxxxxxx> wrote: > > On Sun, May 24, 2020, at 9:39 PM, Chris Murphy wrote: > > > On Sun, May 24, 2020 at 6:42 PM Paul Dufresne via devel > > > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > Le 20-05-24 à 19 h 34, Naheem Zaffar a écrit : [snip] > > > But an additional difficulty to fully implementing the spec is so far > > > upstream GRUB don't want to follow it. So that means Fedora has to > > > carry patches for GRUB to support it. And it's just yet another of > > > 100+ patches Fedora carries for GRUB, and makes it difficult for the > > > Fedora and RH boot teams. The resources so far implement some of the > > > parts of BLS that help make things better on Fedora, but it's not a > > > complete implementation. Drop-in snippets to add new kernels is crash > > > safe, worst case the previous kernel is booted and you just reinstall > > > the kernel; but writing out a new grub.cfg or modifying it, wasn't > > > ever crash safe. Also, modifying the snippets is easier, they're just > > > a few lines and fairly self-describing compared to what users often > > > did, which was wade neck deep into editing grub.cfg. Or the Rube > > > Goldberg machine that is editing /etc/default/grub, running a script > > > (grub-mkconfig), which then runs 20 other scripts to create a > > > configuration file that is actually a script. Yes, what was implemented in GRUB and also the other bootloaders used in Fedora (Petiboot and zipl) was support to parse BLS snippets. The goal was to have a consistent bootloader configuration scheme and file format across all the different architectures and bootloaders supported by Fedora. This allowed to simplify and improve the bootloader configuration tooling for the reasons Chris already mentioned. We could get rid of the old grubby tool that was used before to parse and modify the bootloader specific configuration files, which was quite fragile since users also changed these files breaking the assumptions made by grubby. Using BLS snippets for all Fedora variants also aligned better with OSTree based ones, that were already using BLS snippets for the boot entries. > > > > Even so, isn't the canonical way of persistently updating kernel args, still, to edit /etc/default/grub and run the script? (If not, are there docs for the new way?) > > It does still work, but by indirection. You set it in > /etc/default/grub but grub2-mkconfig puts it into grub.cfg first and > then it goes into grubenv. The grubenv variables are loaded by GRUB at > boot time, and the BLS snippets reference those variables. > This still works from F33 onwards. But instead of grub2-mkconfig updating a variable in grubenv, the options field of the BLS snippets are updated with the kernel cmdline set in /etc/default/grub. This is done for backward compatibility because as mentioned in this thread, is the canonical form to update the kernel cmdline and documented everywhere. > I've resorted to using 'grub2-editenv' to directly modify grubenv. But > as grubenv is fragile, using it will be abandoned. > There's a grubby script that is provided for backward compatibility, that just modifies the BLS snippets. So this can also be used to update the kernel cmdline. I agree that we need better tools for users to manage the BLS snippets and also improve the documentation. 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
