From: Mike Gilbert <floppym@gentoo.org>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH] btrfs: disable zstd support for i386-pc
Date: Tue, 23 Jun 2020 13:50:34 -0400 [thread overview]
Message-ID: <CAJ0EP42uPaY3A8ORppUbN-31Q3XciV5UHHWGxqTymSf54t49OQ@mail.gmail.com> (raw)
In-Reply-To: <20200623063204.GA16299@mercury>
On Tue, Jun 23, 2020 at 2:32 AM Michael Chang <mchang@suse.com> wrote:
>
> On Mon, Jun 22, 2020 at 10:16:49PM -0400, Mike Gilbert wrote:
> > On Sun, Jun 21, 2020 at 2:56 PM Eli Schwartz <eschwartz@archlinux.org> wrote:
> > > But anyway this isn't true. There are valid reasons to reinstall grub on
> > > old systems, in which case you are most likely not benefiting from zstd
> > > support one way or another, but in this case, rerunning grub-install
> > > destroys the working bootloader code and fails to replace.
> >
> > This sounds like a bug/defect in grub-install. Ideally, it would look
> > at the size of the embedding area, and abort early if it is too small.
> > This should happen before files are copied to /boot/grub, but
> > currently it is done afterward.
>
> Even though the system can stay bootable, it cannot receive any grub
> updates afterward, thus breaking the principle of backward compatibilty
> that new build couldn't run at all on an existing system running old
> grub.
There was some discussion earlier in the thread that proposed the
documentation be updated to indicate that using a small embedding area
is not well-supported.
I don't think 100% backward compatibility is a reasonable target,
especially for configurations that have never been well-supported in
the first place.
next prev parent reply other threads:[~2020-06-23 17:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-05 9:19 [PATCH] btrfs: disable zstd support for i386-pc Michael Chang
2019-11-05 10:52 ` Paul Menzel
2019-11-07 4:22 ` Michael Chang
2019-11-06 12:40 ` David Sterba
2019-11-06 18:53 ` Nick Terrell
2019-11-07 6:34 ` Michael Chang
2019-11-06 19:15 ` Vladimir 'phcoder' Serbinenko
2019-11-07 4:55 ` Michael Chang
2019-11-07 5:08 ` Vladimir 'phcoder' Serbinenko
2019-11-07 6:59 ` Michael Chang
2020-06-11 22:58 ` Eli Schwartz
2020-06-21 18:26 ` Mike Gilbert
2020-06-21 18:56 ` Eli Schwartz
2020-06-23 1:59 ` Mike Gilbert
2020-06-23 2:16 ` Mike Gilbert
2020-06-23 6:32 ` Michael Chang
2020-06-23 17:50 ` Mike Gilbert [this message]
2019-11-07 11:52 ` Daniel Kiper
2019-11-13 11:00 ` Daniel Kiper
2019-11-14 9:53 ` Michael Chang
2019-11-15 11:42 ` Daniel Kiper
2019-11-19 8:34 ` Michael Chang
2020-03-03 16:59 ` Daniel Kiper
2020-03-04 7:58 ` Michael Chang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJ0EP42uPaY3A8ORppUbN-31Q3XciV5UHHWGxqTymSf54t49OQ@mail.gmail.com \
--to=floppym@gentoo.org \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.