On Mon, Mar 22, 2021 at 04:20:00PM +0100, Daniel Kiper wrote: > On Thu, Mar 18, 2021 at 07:30:26PM +0800, Michael Chang via Grub-devel wrote:
[snip] > NAK for this patch and others "fixing" small MBR gaps. I am not going to > deal with this kind of issues any longer because a few folks in the > world cannot/do not want/... reinstall their systems. Sorry guys. > > Additionally, the commit 5fd18f77e (mbr: Warn if MBR gap is small and > user uses advanced modules) and 505d92f5e (mbr: Document new limitations > on MBR gap support) are pretty clear we do not support advanced configs > with small MBR gaps any longer. If I remember correctly, the short mbr gap warning is only visible to the user who really runs into the problem at the moment that is too late for them to take any prevention measure. In other words, this is not useful as a reminder to the user that they have to start to change their setup for good. I raised the concern but it seemed nobody cared [1] .. [1] https://lists.gnu.org/archive/html/grub-devel/2020-11/msg00077.html The "too late" literally means the system is unbootable afterwards, becase incompleted installs would end up with inconsistent state between image and module, resulting in symbol looking up failure. Therefore it is also something we have to look after although it is also rather complicated [2] ... [2] https://www.mail-archive.com/grub-devel@gnu.org/msg30663.html Afterall, keeping existing running system to survive update (NOT new install) is really an important thing as many can't afford that to happen. If we can make it any better to reduce the cost please consider to do it. It doesn't conflict with the purpose to stop the short mbr gap support, given we all know the broken system can be avoided in the first place ... > PS FYI, I am not sure anybody cares but I think patch is not fully correct > because lockdown part of kernel calls into verifiers module on i386-pc. It is covered by this [3] hunk ... As long as the mandatory "efi" verifiers lockdown is not used by platform other than efi, we could defer it's initialization to module loading in pc platform which is auto-loaded by dependent verifier modules as to what is used to be ... [3] --- a/grub-core/kern/main.c +++ b/grub-core/kern/main.c @@ -29,7 +29,9 @@ #include <grub/command.h> #include <grub/reader.h> #include <grub/parser.h> +#ifndef GRUB_MACHINE_PCBIOS #include <grub/verify.h> +#endif #ifdef GRUB_MACHINE_PCBIOS #include <grub/machine/memory.h> @@ -275,8 +277,10 @@ grub_main (void) grub_printf ("Welcome to GRUB!\n\n"); grub_setcolorstate (GRUB_TERM_COLOR_STANDARD); +#ifndef GRUB_MACHINE_PCBIOS /* Init verifiers API. */ grub_verifiers_init (); +#endif grub_load_config (); Thanks, Michael > > _______________________________________________ > 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
