Re: [PATCH v2] i386-pc: build verifiers API as module

[Daniel Kiper]

On Tue, Mar 23, 2021 at 12:16:21PM +0800, Michael Chang via Grub-devel wrote:
> 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

IIRC I was looking at this patch a few weeks ago but decided to not take
it because the changes are too intrusive for freeze stage. Though I can
reconsider it once again if you think it is worth of it...

> 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 ...

This makes sense for me and I am OK with hardening the upgrade path.
However, I think it is post release work...

Daniel