grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5 2/2] Document new limitations on MBR gap support


From: Colin Watson
Subject: Re: [PATCH v5 2/2] Document new limitations on MBR gap support
Date: Thu, 18 Mar 2021 09:49:04 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

On Fri, Dec 04, 2020 at 02:57:00PM +0100, Daniel Kiper wrote:
> On Fri, Nov 13, 2020 at 09:28:16PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> > From 4bd2f59773bec11ad7be1ced5b49edbf44d711f2 Mon Sep 17 00:00:00 2001
> > From: Vladimir Serbinenko <phcoder@gmail.com>
> > Date: Tue, 10 Nov 2020 20:23:56 +0100
> > Subject: [PATCH 2/2] Document new limitations on MBR gap support
> >
> > Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
> 
> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
> 
> This is last chance to complain! I am going to take this patch next week...

I only just saw this, sorry.

I agree with warning people, of course, and I agree that at some point
in the future it may simply no longer be possible to make other
configurations fit.  This has been at least a bit difficult for as long
as I've been working on GRUB, and I'm more than aware of the technical
problems.  I also of course agree that partitioning tools should leave a
generous region for the boot loader; as far as I'm aware all systems I
work on have done this for quite some time.

But we have to remember that the "fix" for an upgraded system already in
this situation is, realistically, to reinstall the system from scratch
(unless you're an expert capable of moving things around by hand, in
which case chances are you would have known better than to get into this
situation in the first place).  This is a very bad situation to leave
users in.  We should make strenuous attempts to avoid taking other
configurations over the critical threshold when they were previously
under it, even if that makes our code uglier.

We should be careful that we do not use this documentation change as an
excuse to reject bug reports about upgrade regressions out of hand.  It
may of course be that they turn out to be unfixable, but the difficulty
of repairing a system in this state means that we should have a very
high bar for giving up.

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]