On Thu, 27 Jul 2023 00:49:06 +0300 "Vladimir 'phcoder' Serbinenko" <phco...@gmail.com> wrote:
> Have you considered that some firmwares brick if EFI storage is over 50% > full? Why not having a file on ESP instead? What if the ESP is readonly? What if there is no ESP? I take your point about crappy firmwares. As mentioned these patches come from RedHat's downstream GRUB and I believe they are using them in production. So apparently this hasn't been an issue for their users. Now I suspect its probably almost never getting used, so perhaps its a low probability that the issue you mention is seen. Should there be giant warnings in the usage, documentation, or command execution (with confirmation)? How big of a problem is it really (considering the likelihood that this might be used on one of those machines)? Glenn > > Le jeu. 27 juil. 2023, 00:09, Glenn Washburn <developm...@efficientek.com> > a écrit : > > > This patch series (for me) was motivated by the "gdb: Add more support for > > debugging on EFI platforms" patch series, which allowed printing in early > > EFI init of the GDB command for properly loading symbols. That approach of > > having the functionality be included at compile time was ultimately > > rejected. During the discussion of that series, Robbie suggested[1] using > > patches by Peter and in the Redhat downstream repo which uses an EFI > > variable to store a GRUB env block. Using this, a user could store a > > variable in the env block stored in the EFI variable and then have GRUB > > load that env block in early init as a way to enable the printing of the > > GDB command. > > > > I've taken the original patches by Peter, made more suitable for including > > in GRUB, fixed some bugs, and added a minor feature. The first patch, adds > > env block loading in early EFI init from the GRUB_ENV EFI variable. The > > second patch is included to provide tools for GRUB to set this EFI env > > block itself, as opposed to needing to use the method suggested by > > Robbie[1], which requires GNU/Linux and the user-space grub2-editenv > > utility. Of course, if GRUB is crashing before one can run the > > efi-export-env command, then other ways of creating and setting the EFI > > envblk variable are necessary. The third patch adds a test which checks the > > usability of the commands and the early init loading. And the last patch, > > whichvmotivated this series, prints the GDB command string if the GRUB > > variable named "enable_earlyinit_gdbinfo" is present and is set to "1", > > after > > the env block is loaded from the GRUB_ENV EFI variable. We might want a > > different name for the GRUB variable, I don't really have a preference. > > > > Glenn > > > > [1] https://mail.gnu.org/archive/html/grub-devel/2023-03/msg00072.html > > > > Glenn Washburn (2): > > tests: Add efienv_test for testing efi-export-env and efi-load-env > > efi: Print GDB command for loading symbols if variable exists > > > > Peter Jones (2): > > efi: Load env block from GRUB_ENV EFI variable in early init > > efi: Add efi-export-env and efi-load-env commands > > > > Makefile.util.def | 6 ++ > > docs/grub.texi | 24 +++++ > > grub-core/Makefile.core.def | 7 ++ > > grub-core/commands/efi/env.c | 182 +++++++++++++++++++++++++++++++++++ > > grub-core/kern/efi/efi.c | 3 + > > grub-core/kern/efi/init.c | 37 +++++++ > > grub-core/lib/envblk.c | 43 +++++++++ > > include/grub/efi/efi.h | 5 + > > include/grub/lib/envblk.h | 3 + > > tests/efienv_test.in | 57 +++++++++++ > > 10 files changed, 367 insertions(+) > > create mode 100644 grub-core/commands/efi/env.c > > create mode 100644 tests/efienv_test.in > > > > -- > > 2.34.1 > > > > > > _______________________________________________ > > Grub-devel mailing list > > Grub-devel@gnu.org > > https://lists.gnu.org/mailman/listinfo/grub-devel > > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
