On Wed, 26 Jul 2023, 23:03 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? > Yes bricking did happen before. It was triggered by excessive runtime updates of bootloader settings. It did surface bugs of reclaiming variable storage which got fixed and released by most manufacturers. Due to recent revocations EFI storage is now routinely excercises meaning it is now reliable to use. EFI storage is used by kernel pstore too. Unlike read-only ESP EFI storage can be ephemeral r/w through the lifecycle of VM across reboots without a shutdown. Which is better than ESP. > 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 >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
