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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel