[PATCH v2] docs: Update for stopping small mbr gap support
Further to the discussion about disabling btrfs zstd support for
i386-pc[1], this paragraph in manual about mbr gap size doesn't seem to
hold true any longer.
"You must ensure that the first partition starts at least 31 KiB (63
sectors) from the start of the disk"
As in many occasions we inevitablely have to provide core image with the
size that goes beyond 31 KiB. For instance, diskfilter and crypto
modules which are needed by root disk formatted with btrfs, lvm, mdadm
and so on would add quite a lot space to the image.
So this misinformation would have people misguided and thought that it
is still fine to use small MBR gap utill some point of time the update
has grown the size too much that the grub-install can no longer embed
the image to the mbr gap. In this case changing the partition layout is
required but it is never easy to do so.
The patch tries to correct the paragraph with a more practical size that
works for grub and also for modern computer systems in general.
[1] https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00025.html
Signed-off-by: Michael Chang
---
Changes since v2:
* Rework a paragraph in commit message and also some places in manual
to be more clear to read
* Correct some typos
docs/grub.texi | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index 83979af38..4614a2ee1 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -845,12 +845,20 @@ only be used if the @file{/boot} filesystem is on the
same disk that the
BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive
numbers.
-The GRUB development team generally recommends embedding GRUB before the
-first partition, unless you have special requirements. You must ensure that
-the first partition starts at least 31 KiB (63 sectors) from the start of
-the disk; on modern disks, it is often a performance advantage to align
-partitions on larger boundaries anyway, so the first partition might start 1
-MiB from the start of the disk.
+The GRUB development team generally recommends embedding GRUB before the first
+partition, unless you have special requirements. You must ensure that the first
+partition starts at least 1 MiB from the start of the disk; Additionally, on
+modern disks it is often a performance advantage to align partitions on larger
+boundaries and 1 MiB is the least common multiple of many used alignment sizes.
+E.g. SSD, it became crucial to have the partition correctly aligned to avoid
+excessive read-modify-write cycles and thus modern tools set to use 1 MiB as a
+standard practice.
+
+In case of legacy systems that cannot boot if first partition is not on the
+cylinder boundary, the fallback blocklist install method should remain working
+for them if the core image grows too much someday. Here we just can't advertise
+that 31 KiB (63 sectors) is a sensible size any longer as that would pose great
+constraint to include new features as time goes by.
@heading GPT
--
2.16.4
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] docs: Update for stopping small mbr gap support
On Thu, Mar 05, 2020 at 05:00:11PM +0100, C. Masloch wrote:
> Two small suggestions inlined in the quoted part.
>
> Regards,
> ecm
>
>
> On at 2020-03-05 15:38 +0100, Daniel Kiper wrote:
> > On Thu, Mar 05, 2020 at 06:40:01PM +0800, Michael Chang wrote:
> >> Further to the discussion about disabling btrfs zstd support for
> >> i386-pc[1], this paragraph in manual about mbr gap size doesn't seem to
> >> hold true any longer.
> >>
> >> "You must ensure that the first partition starts at least 31 KiB (63
> >> sectors) from the start of the disk"
> >>
> >> As in many occasions we inevitablely have to provide core image size
> >> that goes beyond 31 KiB, this statement becomes a true liability as
> >> people would be misguided and think it is still fine to use small MBR
> >> gap, that has always been a headache in distribution's upgrade path as
> >> growing new feature would render the size requirement bigger but no way
> >> for the user to relocate their partitions.
> >
> > Could you split this paragraph into a few sentences? Now it does not
> > read very well...
> >
> >> The patch tries to correct the paragraph with a more practical size that
> >> works for grub and also for modern computer systems in general.
> >>
> >> [1] https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00025.html
> >>
> >> Signed-off-by: Michael Chang
> >> ---
> >> docs/grub.texi | 20 ++--
> >> 1 file changed, 14 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/docs/grub.texi b/docs/grub.texi
> >> index 83979af38..651468268 100644
> >> --- a/docs/grub.texi
> >> +++ b/docs/grub.texi
> >> @@ -845,12 +845,20 @@ only be used if the @file{/boot} filesystem is on
> >> the same disk that the
> >> BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive
> >> numbers.
> >>
> >> -The GRUB development team generally recommends embedding GRUB before the
> >> -first partition, unless you have special requirements. You must ensure
> >> that
> >> -the first partition starts at least 31 KiB (63 sectors) from the start of
> >> -the disk; on modern disks, it is often a performance advantage to align
> >> -partitions on larger boundaries anyway, so the first partition might
> >> start 1
> >> -MiB from the start of the disk.
> >> +The GRUB development team generally recommends embedding GRUB before the
> >> first
> >> +partition, unless you have special requirements. You must ensure that the
> >> first
> >> +partition starts at least 1 MiB from the start of the disk; on modern
> >> disks, it
> >
> > s/; on modern disks, it/. Additionally, on modern disks it/
> >
> >> +is often a performance advantage to align partitions on larger boundaries
> >> and 1
> >> +MiB is the least common multiple of many used alignment sizes. For SSD, it
> >
> > s/For SSD, it/E.g. SSD, it/
> >
> >> +became crucial to have the partition correctly aligned to avoid excessive
> >> +read-modify-write cycles and thus modern tools set to use 1 MiB as a
> >> stardard
> >> +practice.
>
> s/stardard/standard
OK.
>
> >> +
> >> +In case legacy systems that cannot boot if first partition not on the
> >> cylinder
> >
> > s/In case legacy/In case of legacy/
> > s/partition not/partition is not/
> >
> >> +boundary, the fallback blocklist install method should remain working for
> >> them
> >> +if the core image growing too much someday. Here we just can't advertise
> >> that
>
> s/growing/grows/
OK.
Many thanks for the review. :)
Regards,
Michael
>
> >> +31 KiB (63 sectors) is a sensible size any longer as that would pose great
> >> +constraint to include new features as time goes by.
> >
> > Daniel
>
> ___
> 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
Re: [PATCH] docs: Update for stopping small mbr gap support
On Thu, Mar 05, 2020 at 03:38:20PM +0100, Daniel Kiper wrote:
> On Thu, Mar 05, 2020 at 06:40:01PM +0800, Michael Chang wrote:
> > Further to the discussion about disabling btrfs zstd support for
> > i386-pc[1], this paragraph in manual about mbr gap size doesn't seem to
> > hold true any longer.
> >
> > "You must ensure that the first partition starts at least 31 KiB (63
> > sectors) from the start of the disk"
> >
> > As in many occasions we inevitablely have to provide core image size
> > that goes beyond 31 KiB, this statement becomes a true liability as
> > people would be misguided and think it is still fine to use small MBR
> > gap, that has always been a headache in distribution's upgrade path as
> > growing new feature would render the size requirement bigger but no way
> > for the user to relocate their partitions.
>
> Could you split this paragraph into a few sentences? Now it does not
> read very well...
OK. I'll come up with a better expression next version.
>
> > The patch tries to correct the paragraph with a more practical size that
> > works for grub and also for modern computer systems in general.
> >
> > [1] https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00025.html
> >
> > Signed-off-by: Michael Chang
> > ---
> > docs/grub.texi | 20 ++--
> > 1 file changed, 14 insertions(+), 6 deletions(-)
> >
> > diff --git a/docs/grub.texi b/docs/grub.texi
> > index 83979af38..651468268 100644
> > --- a/docs/grub.texi
> > +++ b/docs/grub.texi
> > @@ -845,12 +845,20 @@ only be used if the @file{/boot} filesystem is on the
> > same disk that the
> > BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive
> > numbers.
> >
> > -The GRUB development team generally recommends embedding GRUB before the
> > -first partition, unless you have special requirements. You must ensure
> > that
> > -the first partition starts at least 31 KiB (63 sectors) from the start of
> > -the disk; on modern disks, it is often a performance advantage to align
> > -partitions on larger boundaries anyway, so the first partition might start
> > 1
> > -MiB from the start of the disk.
> > +The GRUB development team generally recommends embedding GRUB before the
> > first
> > +partition, unless you have special requirements. You must ensure that the
> > first
> > +partition starts at least 1 MiB from the start of the disk; on modern
> > disks, it
>
> s/; on modern disks, it/. Additionally, on modern disks it/
OK.
>
> > +is often a performance advantage to align partitions on larger boundaries
> > and 1
> > +MiB is the least common multiple of many used alignment sizes. For SSD, it
>
> s/For SSD, it/E.g. SSD, it/
OK.
>
> > +became crucial to have the partition correctly aligned to avoid excessive
> > +read-modify-write cycles and thus modern tools set to use 1 MiB as a
> > stardard
> > +practice.
> > +
> > +In case legacy systems that cannot boot if first partition not on the
> > cylinder
>
> s/In case legacy/In case of legacy/
> s/partition not/partition is not/
OK.
>
> > +boundary, the fallback blocklist install method should remain working for
> > them
> > +if the core image growing too much someday. Here we just can't advertise
> > that
> > +31 KiB (63 sectors) is a sensible size any longer as that would pose great
> > +constraint to include new features as time goes by.
Thanks a lot for taking time to review.
Regards,
Michael
>
> Daniel
>
> ___
> 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
[PATCH] Enable the datetime module for the emu platform
Fixes a build failure:
grub-core/commands/date.c:49: undefined reference to `grub_get_weekday_name'
grub-core/commands/ls.c:155: undefined reference to `grub_unixtime2datetime'
Bug: https://bugs.gentoo.org/711512
Signed-off-by: Mike Gilbert
---
grub-core/Makefile.core.def | 1 -
1 file changed, 1 deletion(-)
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 91297e4eb..48b82e763 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1700,7 +1700,6 @@ module = {
i386_xen_pvh = lib/xen/datetime.c;
mips_arc = lib/arc/datetime.c;
- enable = noemu;
};
module = {
--
2.25.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] docs: Update for stopping small mbr gap support
Two small suggestions inlined in the quoted part.
Regards,
ecm
On at 2020-03-05 15:38 +0100, Daniel Kiper wrote:
> On Thu, Mar 05, 2020 at 06:40:01PM +0800, Michael Chang wrote:
>> Further to the discussion about disabling btrfs zstd support for
>> i386-pc[1], this paragraph in manual about mbr gap size doesn't seem to
>> hold true any longer.
>>
>> "You must ensure that the first partition starts at least 31 KiB (63
>> sectors) from the start of the disk"
>>
>> As in many occasions we inevitablely have to provide core image size
>> that goes beyond 31 KiB, this statement becomes a true liability as
>> people would be misguided and think it is still fine to use small MBR
>> gap, that has always been a headache in distribution's upgrade path as
>> growing new feature would render the size requirement bigger but no way
>> for the user to relocate their partitions.
>
> Could you split this paragraph into a few sentences? Now it does not
> read very well...
>
>> The patch tries to correct the paragraph with a more practical size that
>> works for grub and also for modern computer systems in general.
>>
>> [1] https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00025.html
>>
>> Signed-off-by: Michael Chang
>> ---
>> docs/grub.texi | 20 ++--
>> 1 file changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/docs/grub.texi b/docs/grub.texi
>> index 83979af38..651468268 100644
>> --- a/docs/grub.texi
>> +++ b/docs/grub.texi
>> @@ -845,12 +845,20 @@ only be used if the @file{/boot} filesystem is on the
>> same disk that the
>> BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive
>> numbers.
>>
>> -The GRUB development team generally recommends embedding GRUB before the
>> -first partition, unless you have special requirements. You must ensure that
>> -the first partition starts at least 31 KiB (63 sectors) from the start of
>> -the disk; on modern disks, it is often a performance advantage to align
>> -partitions on larger boundaries anyway, so the first partition might start 1
>> -MiB from the start of the disk.
>> +The GRUB development team generally recommends embedding GRUB before the
>> first
>> +partition, unless you have special requirements. You must ensure that the
>> first
>> +partition starts at least 1 MiB from the start of the disk; on modern
>> disks, it
>
> s/; on modern disks, it/. Additionally, on modern disks it/
>
>> +is often a performance advantage to align partitions on larger boundaries
>> and 1
>> +MiB is the least common multiple of many used alignment sizes. For SSD, it
>
> s/For SSD, it/E.g. SSD, it/
>
>> +became crucial to have the partition correctly aligned to avoid excessive
>> +read-modify-write cycles and thus modern tools set to use 1 MiB as a
>> stardard
>> +practice.
s/stardard/standard
>> +
>> +In case legacy systems that cannot boot if first partition not on the
>> cylinder
>
> s/In case legacy/In case of legacy/
> s/partition not/partition is not/
>
>> +boundary, the fallback blocklist install method should remain working for
>> them
>> +if the core image growing too much someday. Here we just can't advertise
>> that
s/growing/grows/
>> +31 KiB (63 sectors) is a sensible size any longer as that would pose great
>> +constraint to include new features as time goes by.
>
> Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] docs: Update for stopping small mbr gap support
On Thu, Mar 05, 2020 at 06:40:01PM +0800, Michael Chang wrote:
> Further to the discussion about disabling btrfs zstd support for
> i386-pc[1], this paragraph in manual about mbr gap size doesn't seem to
> hold true any longer.
>
> "You must ensure that the first partition starts at least 31 KiB (63
> sectors) from the start of the disk"
>
> As in many occasions we inevitablely have to provide core image size
> that goes beyond 31 KiB, this statement becomes a true liability as
> people would be misguided and think it is still fine to use small MBR
> gap, that has always been a headache in distribution's upgrade path as
> growing new feature would render the size requirement bigger but no way
> for the user to relocate their partitions.
Could you split this paragraph into a few sentences? Now it does not
read very well...
> The patch tries to correct the paragraph with a more practical size that
> works for grub and also for modern computer systems in general.
>
> [1] https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00025.html
>
> Signed-off-by: Michael Chang
> ---
> docs/grub.texi | 20 ++--
> 1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 83979af38..651468268 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -845,12 +845,20 @@ only be used if the @file{/boot} filesystem is on the
> same disk that the
> BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive
> numbers.
>
> -The GRUB development team generally recommends embedding GRUB before the
> -first partition, unless you have special requirements. You must ensure that
> -the first partition starts at least 31 KiB (63 sectors) from the start of
> -the disk; on modern disks, it is often a performance advantage to align
> -partitions on larger boundaries anyway, so the first partition might start 1
> -MiB from the start of the disk.
> +The GRUB development team generally recommends embedding GRUB before the
> first
> +partition, unless you have special requirements. You must ensure that the
> first
> +partition starts at least 1 MiB from the start of the disk; on modern disks,
> it
s/; on modern disks, it/. Additionally, on modern disks it/
> +is often a performance advantage to align partitions on larger boundaries
> and 1
> +MiB is the least common multiple of many used alignment sizes. For SSD, it
s/For SSD, it/E.g. SSD, it/
> +became crucial to have the partition correctly aligned to avoid excessive
> +read-modify-write cycles and thus modern tools set to use 1 MiB as a stardard
> +practice.
> +
> +In case legacy systems that cannot boot if first partition not on the
> cylinder
s/In case legacy/In case of legacy/
s/partition not/partition is not/
> +boundary, the fallback blocklist install method should remain working for
> them
> +if the core image growing too much someday. Here we just can't advertise that
> +31 KiB (63 sectors) is a sensible size any longer as that would pose great
> +constraint to include new features as time goes by.
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 08/12] kern: Make grub_error() more verbose
Please evaluate size increase for this. In the past passing file and line
number to grub_dprintf was a huge source of increased Kern and core size
Le mer. 4 mars 2020 à 13:01, Javier Martinez Canillas
a écrit :
> From: Peter Jones
>
> Add file and line to grub_error() output to make troubleshooting easier.
>
> Signed-off-by: Peter Jones
> Signed-off-by: Javier Martinez Canillas
> ---
>
> grub-core/kern/err.c | 13 +++--
> include/grub/err.h | 5 -
> 2 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/grub-core/kern/err.c b/grub-core/kern/err.c
> index 53c734de70e..aebfe0cf839 100644
> --- a/grub-core/kern/err.c
> +++ b/grub-core/kern/err.c
> @@ -33,15 +33,24 @@ static struct grub_error_saved
> grub_error_stack_items[GRUB_ERROR_STACK_SIZE];
> static int grub_error_stack_pos;
> static int grub_error_stack_assert;
>
> +#ifdef grub_error
> +#undef grub_error
> +#endif
> +
> grub_err_t
> -grub_error (grub_err_t n, const char *fmt, ...)
> +grub_error (grub_err_t n, const char *file, const int line, const char
> *fmt, ...)
> {
>va_list ap;
> + int m;
>
>grub_errno = n;
>
> + m = grub_snprintf (grub_errmsg, sizeof (grub_errmsg), "%s:%d:", file,
> line);
> + if (m < 0)
> +m = 0;
> +
>va_start (ap, fmt);
> - grub_vsnprintf (grub_errmsg, sizeof (grub_errmsg), _(fmt), ap);
> + grub_vsnprintf (grub_errmsg + m, sizeof (grub_errmsg) - m, _(fmt), ap);
>va_end (ap);
>
>return n;
> diff --git a/include/grub/err.h b/include/grub/err.h
> index 24ba9f5f592..b68bbec3c72 100644
> --- a/include/grub/err.h
> +++ b/include/grub/err.h
> @@ -85,7 +85,10 @@ struct grub_error_saved
> extern grub_err_t EXPORT_VAR(grub_errno);
> extern char EXPORT_VAR(grub_errmsg)[GRUB_MAX_ERRMSG];
>
> -grub_err_t EXPORT_FUNC(grub_error) (grub_err_t n, const char *fmt, ...);
> +grub_err_t EXPORT_FUNC(grub_error) (grub_err_t n, const char *file, const
> int line, const char *fmt, ...);
> +
> +#define grub_error(n, fmt, ...) grub_error (n, __FILE__, __LINE__, fmt,
> ##__VA_ARGS__)
> +
> void EXPORT_FUNC(grub_fatal) (const char *fmt, ...) __attribute__
> ((noreturn));
> void EXPORT_FUNC(grub_error_push) (void);
> int EXPORT_FUNC(grub_error_pop) (void);
> --
> 2.24.1
>
>
> ___
> 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
Re: [PATCH] build: Add soft-float handling for SuperH (sh4)
On Wed, Mar 04, 2020 at 02:31:34PM +0100, John Paul Adrian Glaubitz wrote: > While GRUB has no platform support for SuperH (sh4) yet, this change > adds the target-specific handling of soft-floats such that the GRUB > utilities can be built on this target. > > Signed-off-by: John Paul Adrian Glaubitz Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 11/12] efi/gop: Add debug output on GOP probing
On Wed, Mar 04, 2020 at 12:58:50PM +0100, Javier Martinez Canillas wrote: > From: Peter Jones > > Add debug information to EFI GOP video driver probing function. > > Signed-off-by: Peter Jones > Signed-off-by: Javier Martinez Canillas Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 10/12] efi/uga: Use video instead of fb as debug condition
On Wed, Mar 04, 2020 at 12:58:49PM +0100, Javier Martinez Canillas wrote: > From: Peter Jones > > All other video drivers use "video" as the debug condition instead of "fb" > so change this in the efi/uga driver to make it consistent with the others. > > Signed-off-by: Peter Jones > Signed-off-by: Javier Martinez Canillas Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 09/12] efi: Print error messages to grub_efi_allocate_pages_real()
On Wed, Mar 04, 2020 at 12:58:48PM +0100, Javier Martinez Canillas wrote: > From: Peter Jones > > No messages were printed in this function, add some to ease debugging. > > Also, the function returns a void * pointer so return NULL instead of > 0 to make the code more readable. > > Signed-off-by: Peter Jones > Signed-off-by: Javier Martinez Canillas Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 08/12] kern: Make grub_error() more verbose
On Wed, Mar 04, 2020 at 12:58:47PM +0100, Javier Martinez Canillas wrote: > From: Peter Jones > > Add file and line to grub_error() output to make troubleshooting easier. > > Signed-off-by: Peter Jones > Signed-off-by: Javier Martinez Canillas Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06 release
On Wed, Mar 04, 2020 at 05:39:10AM +0100, Patrick Steinhardt wrote: > On Tue, Mar 03, 2020 at 06:26:03PM +0100, Daniel Kiper wrote: > > On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote: > > > Hi all, > > > > > > As I told during my FOSDEM 2020 presentation we are preparing for > > > GRUB 2.06 release. Tentative schedule is below: > > > - code freeze: 15th of March, 23:59:59 UTC; everything posted after > > > that date will not be considered as a release material, > > > > Just a kind reminder... Less than two weeks left... > > > > Daniel > > Any chance to get the Arogn2 changes in? As far as I remember we were Let's try... We will see how it goes. If you run over the freeze date then I can give you an exception. However, not so long... > pending some legal issues where you've reached out to GNU, right? Please Yeah, I sent your question to FSF folks a few days ago. Sadly, still no reply... > correct me if I'm wrong here and you're waiting for me on anything > there. What about this UEFI allocator thing? Anyway, I would suggest posting next version for review now. Then we should have code quite quickly hammered out. Legal stuff should not take long if we get a reply which we more or less expect what it will be. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06 release
On Tue, Mar 03, 2020 at 06:33:54PM +0100, John Paul Adrian Glaubitz wrote: > On 3/3/20 6:26 PM, Daniel Kiper wrote: > > On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote: > >> Hi all, > >> > >> As I told during my FOSDEM 2020 presentation we are preparing for > >> GRUB 2.06 release. Tentative schedule is below: > >> - code freeze: 15th of March, 23:59:59 UTC; everything posted after > >> that date will not be considered as a release material, > > > > Just a kind reminder... Less than two weeks left... > > I really appreciate the faster release cycle. Much appreciated! > > Thanks a lot for your efforts, Daniel! You are welcome! Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] docs: Update for stopping small mbr gap support
Further to the discussion about disabling btrfs zstd support for
i386-pc[1], this paragraph in manual about mbr gap size doesn't seem to
hold true any longer.
"You must ensure that the first partition starts at least 31 KiB (63
sectors) from the start of the disk"
As in many occasions we inevitablely have to provide core image size
that goes beyond 31 KiB, this statement becomes a true liability as
people would be misguided and think it is still fine to use small MBR
gap, that has always been a headache in distribution's upgrade path as
growing new feature would render the size requirement bigger but no way
for the user to relocate their partitions.
The patch tries to correct the paragraph with a more practical size that
works for grub and also for modern computer systems in general.
[1] https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00025.html
Signed-off-by: Michael Chang
---
docs/grub.texi | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index 83979af38..651468268 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -845,12 +845,20 @@ only be used if the @file{/boot} filesystem is on the
same disk that the
BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive
numbers.
-The GRUB development team generally recommends embedding GRUB before the
-first partition, unless you have special requirements. You must ensure that
-the first partition starts at least 31 KiB (63 sectors) from the start of
-the disk; on modern disks, it is often a performance advantage to align
-partitions on larger boundaries anyway, so the first partition might start 1
-MiB from the start of the disk.
+The GRUB development team generally recommends embedding GRUB before the first
+partition, unless you have special requirements. You must ensure that the first
+partition starts at least 1 MiB from the start of the disk; on modern disks, it
+is often a performance advantage to align partitions on larger boundaries and 1
+MiB is the least common multiple of many used alignment sizes. For SSD, it
+became crucial to have the partition correctly aligned to avoid excessive
+read-modify-write cycles and thus modern tools set to use 1 MiB as a stardard
+practice.
+
+In case legacy systems that cannot boot if first partition not on the cylinder
+boundary, the fallback blocklist install method should remain working for them
+if the core image growing too much someday. Here we just can't advertise that
+31 KiB (63 sectors) is a sensible size any longer as that would pose great
+constraint to include new features as time goes by.
@heading GPT
--
2.16.4
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
