GRUB 2.12~rc1 released

GRUB 2.12~rc1 released

[Daniel Kiper]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

Hi all,

The GRUB maintainers are proud to announce the GRUB 2.12~rc1 that has been just released.

We would like to thank all the people who have contributed to the project.

The tarball is available at https://alpha.gnu.org/gnu/grub/grub-2.12~rc1.tar.xz
and its signature at https://alpha.gnu.org/gnu/grub/grub-2.12~rc1.tar.xz.sig

Release is signed with the following fingerprint:
  BE5C 2320 9ACD DACE B20D  B0A2 8C81 89F1 988C 2166

It's also available as a signed grub-2.12-rc1 tag in official git repository.

If you do not have xz support alternatively you may consider file
https://alpha.gnu.org/gnu/grub/grub-2.12~rc1.tar.gz and its signature at
https://alpha.gnu.org/gnu/grub/grub-2.12~rc1.tar.gz.sig

If you want a binary version for Windows (i386-pc, i386-efi and x86_64-efi
flavors) it is available under https://alpha.gnu.org/gnu/grub/grub-2.12~rc1-for-windows.zip
and its signature at https://alpha.gnu.org/gnu/grub/grub-2.12~rc1-for-windows.zip.sig

Translators can use http://alpha.gnu.org/pub/gnu/grub/grub-2.12~rc1.pot for translation.
The pot signature is available at http://alpha.gnu.org/pub/gnu/grub/grub-2.12~rc1.pot.sig

Please test this release candidate. If we do not spot major issues we are going
to release 2.12 in a month or so.

In the meantime we will be looking mostly at the patches fixing tests and
documentation posted on grub-devel up until now. If time allows we will also be
looking at the patches which introduces new interesting features which should be
merged after 2.12 official release.

Daniel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: GRUB 2.12~rc1 released

[Pete Batard]

Hi Daniel,

Thanks for the long awaited 2.12~rc1.

As I have mentioned in the past, and I feel need to mention again on 
account that it continues causes real-life grievances for downstream 
GRUB end users and especially people trying to install Linux, the formal 
GRUB 2.12 release cannot come soon enough, as the lack of timely GRUB 
releases combined with Linux distro maintainers taking it upon 
themselves to cherry pick post 2.06 commits, has recently been creating 
and continues to create major headaches for, among others, Ubuntu and 
Fedora users [1].

Thus, in part because of the above, I have been eager to test 2.12~rc1.

However, I'm afraid I have to report a potential build error, that can 
happen on a fully up to date Debian 11.7 system set up with the default 
packages, whereas compiling 2.06 with the same options on the same 
system works fine.

Basically, after extracting the tarball, if one uses:

./autogen.sh
./configure --disable-nls --enable-boot-time
make

to build GRUB, then the build might ultimately fails with:

----------------------------------------------------------------------
(...)
mv syminfo.lst.new syminfo.lst
cat syminfo.lst | sort | mawk -f ./genmoddep.awk > moddep.lst || (rm -f 
moddep.lst; exit 1)
mawk: ./genmoddep.awk: line 106: function asorti never defined
make[3]: *** [Makefile:51274: moddep.lst] Error 1
make[3]: Leaving directory '/usr/src/grub-2.12~rc1/grub-core'
make[2]: *** [Makefile:28853: all] Error 2
make[2]: Leaving directory '/usr/src/grub-2.12~rc1/grub-core'
make[1]: *** [Makefile:12127: all-recursive] Error 1
make[1]: Leaving directory '/usr/src/grub-2.12~rc1'
make: *** [Makefile:3954: all] Error 2
----------------------------------------------------------------------

My investigation indicates that, this has to do with the default awk 
being provided by Debian 11.7 being 'mawk' rather than 'gawk':

----------------------------------------------------------------------
# awk -W version
mawk 1.3.4 20200120
Copyright 2008-2019,2020, Thomas E. Dickey
Copyright 1991-1996,2014, Michael D. Brennan
----------------------------------------------------------------------

Now, this issue can solved by installing gawk and reconfiguring, as the 
build then completes successfully, with 'awk -W version' reporting:

----------------------------------------------------------------------
# awk -W version
GNU Awk 5.1.0, API: 3.0 (GNU MPFR 4.1.0, GNU MP 6.2.1)
Copyright (C) 1989, 1991-2020 Free Software Foundation.
----------------------------------------------------------------------

In other words, I am not sure how much GRUB 2.12 wants to be friendlier 
towards non gawk users, but, considering that the error I mentioned 
above can happen on a relatively recent Debian system, maybe a test for 
'asorti()' during configure or the use of an 'asorti()' equivalent, that 
will work for now gawk users, warrants being looked into.

Regards,

/Pete

[1] https://github.com/pbatard/rufus/issues/2243

On 2023.07.10 18:35, Daniel Kiper wrote:
> Hi all,
> 
> The GRUB maintainers are proud to announce the GRUB 2.12~rc1 that has been just released.
> 
> We would like to thank all the people who have contributed to the project.
> 
> The tarball is available at https://alpha.gnu.org/gnu/grub/grub-2.12~rc1.tar.xz
> and its signature at https://alpha.gnu.org/gnu/grub/grub-2.12~rc1.tar.xz.sig
> 
> Release is signed with the following fingerprint:
>    BE5C 2320 9ACD DACE B20D  B0A2 8C81 89F1 988C 2166
> 
> It's also available as a signed grub-2.12-rc1 tag in official git repository.
> 
> If you do not have xz support alternatively you may consider file
> https://alpha.gnu.org/gnu/grub/grub-2.12~rc1.tar.gz and its signature at
> https://alpha.gnu.org/gnu/grub/grub-2.12~rc1.tar.gz.sig
> 
> If you want a binary version for Windows (i386-pc, i386-efi and x86_64-efi
> flavors) it is available under https://alpha.gnu.org/gnu/grub/grub-2.12~rc1-for-windows.zip
> and its signature at https://alpha.gnu.org/gnu/grub/grub-2.12~rc1-for-windows.zip.sig
> 
> Translators can use http://alpha.gnu.org/pub/gnu/grub/grub-2.12~rc1.pot for translation.
> The pot signature is available at http://alpha.gnu.org/pub/gnu/grub/grub-2.12~rc1.pot.sig
> 
> Please test this release candidate. If we do not spot major issues we are going
> to release 2.12 in a month or so.
> 
> In the meantime we will be looking mostly at the patches fixing tests and
> documentation posted on grub-devel up until now. If time allows we will also be
> looking at the patches which introduces new interesting features which should be
> merged after 2.12 official release.
> 
> Daniel
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB 2.12~rc1 released

[Julian Andres Klode]

[-- Attachment #1: Type: text/plain, Size: 2829 bytes --]

On Mon, Jul 10, 2023 at 06:35:50PM +0200, Daniel Kiper wrote:
> Hi all,
> 
> The GRUB maintainers are proud to announce the GRUB 2.12~rc1 that has been just released.
> 
> We would like to thank all the people who have contributed to the project.
> 
> The tarball is available at https://alpha.gnu.org/gnu/grub/grub-2.12~rc1.tar.xz
> and its signature at https://alpha.gnu.org/gnu/grub/grub-2.12~rc1.tar.xz.sig
> 
> Release is signed with the following fingerprint:
>   BE5C 2320 9ACD DACE B20D  B0A2 8C81 89F1 988C 2166
> 
> It's also available as a signed grub-2.12-rc1 tag in official git repository.
> 
> If you do not have xz support alternatively you may consider file
> https://alpha.gnu.org/gnu/grub/grub-2.12~rc1.tar.gz and its signature at
> https://alpha.gnu.org/gnu/grub/grub-2.12~rc1.tar.gz.sig
> 
> If you want a binary version for Windows (i386-pc, i386-efi and x86_64-efi
> flavors) it is available under https://alpha.gnu.org/gnu/grub/grub-2.12~rc1-for-windows.zip
> and its signature at https://alpha.gnu.org/gnu/grub/grub-2.12~rc1-for-windows.zip.sig
> 
> Translators can use http://alpha.gnu.org/pub/gnu/grub/grub-2.12~rc1.pot for translation.
> The pot signature is available at http://alpha.gnu.org/pub/gnu/grub/grub-2.12~rc1.pot.sig
> 
> Please test this release candidate. If we do not spot major issues we are going
> to release 2.12 in a month or so.
> 
> In the meantime we will be looking mostly at the patches fixing tests and
> documentation posted on grub-devel up until now. If time allows we will also be
> looking at the patches which introduces new interesting features which should be
> merged after 2.12 official release.


Summary of my experience so far:

- The test changes to error out instead of skipping when not root or
  tools unavailable break distro builds (who wants to build as root?),
  see the other thread.

  I'll probably end up reverting that in the Debian+Ubuntu tree.

- All the tests/iso9660_*.iso.gz files are missing from the tarball,
  hence it is not possible to pass the test suite either way.

- The secure boot fallback on x86 does not work when mokutil
  --disable-validation is used, see my patch.

Apart from that, I was able to rebase the Debian patch set on top of
2.12~rc1, build packages and verify correctness on amd64 qemu.

I patched on our custom peimage relocator/start_image/load_image
implementation to get working secure boot with PE entry points in
the loader (without having to wait for shim support or continuing
with the rhboot patches), currently waiting for review on that
and some minor tweaks needed and then will push to Debian experimental.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: GRUB 2.12~rc1 released

[Olaf Hering]

[-- Attachment #1.1: Type: text/plain, Size: 367 bytes --]

Mon, 10 Jul 2023 18:35:50 +0200 Daniel Kiper <daniel.kiper@oracle.com>:

> Please test this release candidate. If we do not spot major issues we are going
> to release 2.12 in a month or so.

A regression in building the documentation was introduced between 
e67a551a4..857af0e17:

https://lists.gnu.org/archive/html/bug-grub/2023-06/msg00006.html


Olaf

[-- Attachment #1.2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB 2.12~rc1 released

[Vitaly Kuzmichev]

[-- Attachment #1.1: Type: text/plain, Size: 902 bytes --]

Hello Daniel, Hello Glenn,

I'm now finally completing my patch for search command to add support
to search partition devices by PARTUUID, which I submitted in Apr 2021 [1].
I also integrated support to search by partition label submitted by Daniel
Wagenknecht in Sep 2022 [2].
I (hopefully) addressed all the review points raised for both patches.
I split all the changes into a set of 16 patches to ease your review.

My question is whould you like to review them now and include in upcoming
Grub 2.12 release, or should I submit the patchset after release?

There were some other few attempts to add this functionality to Grub from
different people since 2021, I think this is worth to be added in 2.12.

[1] https://lists.gnu.org/archive/html/grub-devel/2021-04/msg00055.html
[2] https://lists.gnu.org/archive/html/grub-devel/2022-09/msg00064.html

With Best Regards,
Vitaly.


[-- Attachment #1.2: Type: text/html, Size: 3961 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB 2.12~rc1 released

[Glenn Washburn]

On Sun, 20 Aug 2023 12:28:57 +0000
Vitaly Kuzmichev <vitaly.kuzmichev@rtsoft.de> wrote:

> Hello Daniel, Hello Glenn,

Hi Vitaly,

> 
> I'm now finally completing my patch for search command to add support
> to search partition devices by PARTUUID, which I submitted in Apr 2021 [1].
> I also integrated support to search by partition label submitted by Daniel
> Wagenknecht in Sep 2022 [2].

Awesome! I've had on my list to do this also, but haven't gotten to it.
So thank you!

> I (hopefully) addressed all the review points raised for both patches.
> I split all the changes into a set of 16 patches to ease your review.

16 patches sounds like a lot. Does it make sense to break it into so
many? I have found that larger patch sets tend to move more slowly, or
not at all on this list. I'd suggest you break it up to at least two
patch series, one for PARTUUID and one for PARTLABEL.

> My question is whould you like to review them now and include in upcoming
> Grub 2.12 release, or should I submit the patchset after release?

I would have liked this functionality to be in the upcoming release,
especially considering that it will likely be a couple years until the
next release. I think there is likely less risk in these changes
because they add compartmentalized new features that should not effect
current features. So if its broken, then GRUB won't lose any features
it didn't already have. On the other hand if its broken in an
exploitable way, that would be worse than not including it. I'd suggest
sending the patches now and I'll take a look at them. I suspect the
chances of Daniel wanting to include them are not great, but in that
case it can be picked backup after the release with the series already
in progress.

> There were some other few attempts to add this functionality to Grub from
> different people since 2021, I think this is worth to be added in 2.12.

I think the point here, if I understand you correctly, is that since
this has been submitted before the feature freeze, that it might be
eligible as part of the exception to the feature freeze. I think it
does add a little weight, but may be not enough and really depends on
the nature of the changes (how risky are they?).

Glenn

> 
> [1] https://lists.gnu.org/archive/html/grub-devel/2021-04/msg00055.html
> [2] https://lists.gnu.org/archive/html/grub-devel/2022-09/msg00064.html
> 
> With Best Regards,
> Vitaly.
> 

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB 2.12~rc1 released

[Vitaly Kuzmichev]

Hi Glenn,

On Mon, 2023-08-21 at 14:52 -0500, Glenn Washburn wrote:
> On Sun, 20 Aug 2023 12:28:57 +0000
> Vitaly Kuzmichev <vitaly.kuzmichev@rtsoft.de> wrote:
> 
> > Hello Daniel, Hello Glenn,
> 
> Hi Vitaly,
> 
> > 
> > I'm now finally completing my patch for search command to add
> > support
> > to search partition devices by PARTUUID, which I submitted in Apr
> > 2021 [1].
> > I also integrated support to search by partition label submitted by
> > Daniel
> > Wagenknecht in Sep 2022 [2].
> 
> Awesome! I've had on my list to do this also, but haven't gotten to
> it.
> So thank you!
> 
> > I (hopefully) addressed all the review points raised for both
> > patches.
> > I split all the changes into a set of 16 patches to ease your
> > review.
> 
> 16 patches sounds like a lot. Does it make sense to break it into so
> many? I have found that larger patch sets tend to move more slowly,
> or
> not at all on this list. I'd suggest you break it up to at least two
> patch series, one for PARTUUID and one for PARTLABEL.
> 

Ok, I can merge some patches together. Most of them are just adding
some helper functions to be used in a later patch. I think it is ok to
fold them into one.

I do not like to split into two patch series because I now have single
patch for all documentation update. If I split it, the changes would
intersect and may cause some conflicts if you change the order of
applying them.

Also I have minor update for 4 filesystem modules to replace some
common code with a helper function introduced in one of the patches.
I will fold them too and use "fs:" prefix for subject, if it is ok for
you.

This should reduce patch series to 7 or so.


> > My question is whould you like to review them now and include in
> > upcoming
> > Grub 2.12 release, or should I submit the patchset after release?
> 
> I would have liked this functionality to be in the upcoming release,
> especially considering that it will likely be a couple years until
> the
> next release. I think there is likely less risk in these changes
> because they add compartmentalized new features that should not
> effect
> current features. So if its broken, then GRUB won't lose any features
> it didn't already have. On the other hand if its broken in an
> exploitable way, that would be worse than not including it. I'd
> suggest
> sending the patches now and I'll take a look at them. I suspect the
> chances of Daniel wanting to include them are not great, but in that
> case it can be picked backup after the release with the series
> already
> in progress.

Ok I will send the patches within a day.

> 
> > There were some other few attempts to add this functionality to
> > Grub from
> > different people since 2021, I think this is worth to be added in
> > 2.12.
> 
> I think the point here, if I understand you correctly, is that since
> this has been submitted before the feature freeze, that it might be
> eligible as part of the exception to the feature freeze. I think it
> does add a little weight, but may be not enough and really depends on
> the nature of the changes (how risky are they?).

I tested the changes in a virtual machine and they work ok.
PARTUUID related code is running on our x86_64 embedded devices for
years already.

I saw in the mailing list a problem with GUID unaligned access on Ia64.
Perhaps this could affect my code too, as I do read of 'struct
grub_guid_t' members from on-stack 'struct grub_gpt_partentry'. (Should
I use grub_get_unaligned16/-32 in this case?)

Apart from this the risk of including these patches is low.

You can drop the changes related to FS modules if you find them too
risky.

Thanks.
Best Regards,
Vitaly.


> 
> Glenn
> 
> > 
> > [1]
> > https://lists.gnu.org/archive/html/grub-devel/2021-04/msg00055.html
> > [2]
> > https://lists.gnu.org/archive/html/grub-devel/2022-09/msg00064.html
> > 
> > With Best Regards,
> > Vitaly.
> > 

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB 2.12~rc1 released

[Daniel Kiper]

Hi Vitaly,

On Tue, Aug 22, 2023 at 11:14:54AM +0000, Vitaly Kuzmichev wrote:
> Hi Glenn,
>
> On Mon, 2023-08-21 at 14:52 -0500, Glenn Washburn wrote:
> > On Sun, 20 Aug 2023 12:28:57 +0000
> > Vitaly Kuzmichev <vitaly.kuzmichev@rtsoft.de> wrote:
> >
> > > Hello Daniel, Hello Glenn,
> >
> > Hi Vitaly,
> >
> > >
> > > I'm now finally completing my patch for search command to add
> > > support
> > > to search partition devices by PARTUUID, which I submitted in Apr
> > > 2021 [1].
> > > I also integrated support to search by partition label submitted by
> > > Daniel
> > > Wagenknecht in Sep 2022 [2].
> >
> > Awesome! I've had on my list to do this also, but haven't gotten to
> > it.
> > So thank you!
> >
> > > I (hopefully) addressed all the review points raised for both
> > > patches.
> > > I split all the changes into a set of 16 patches to ease your
> > > review.
> >
> > 16 patches sounds like a lot. Does it make sense to break it into so
> > many? I have found that larger patch sets tend to move more slowly,
> > or
> > not at all on this list. I'd suggest you break it up to at least two
> > patch series, one for PARTUUID and one for PARTLABEL.
> >
>
> Ok, I can merge some patches together. Most of them are just adding
> some helper functions to be used in a later patch. I think it is ok to
> fold them into one.
>
> I do not like to split into two patch series because I now have single
> patch for all documentation update. If I split it, the changes would
> intersect and may cause some conflicts if you change the order of
> applying them.
>
> Also I have minor update for 4 filesystem modules to replace some
> common code with a helper function introduced in one of the patches.
> I will fold them too and use "fs:" prefix for subject, if it is ok for
> you.
>
> This should reduce patch series to 7 or so.

I would suggest, as Glenn did, to send them as is. Even if you have 16
of them. Then Glenn and I will be able to suggest what should have to be
merged and what should not.

> > > My question is whould you like to review them now and include in
> > > upcoming
> > > Grub 2.12 release, or should I submit the patchset after release?
> >
> > I would have liked this functionality to be in the upcoming release,
> > especially considering that it will likely be a couple years until
> > the
> > next release. I think there is likely less risk in these changes
> > because they add compartmentalized new features that should not
> > effect
> > current features. So if its broken, then GRUB won't lose any features
> > it didn't already have. On the other hand if its broken in an
> > exploitable way, that would be worse than not including it. I'd
> > suggest
> > sending the patches now and I'll take a look at them. I suspect the
> > chances of Daniel wanting to include them are not great, but in that
> > case it can be picked backup after the release with the series
> > already
> > in progress.
>
> Ok I will send the patches within a day.

Great!

> > > There were some other few attempts to add this functionality to
> > > Grub from
> > > different people since 2021, I think this is worth to be added in
> > > 2.12.
> >
> > I think the point here, if I understand you correctly, is that since
> > this has been submitted before the feature freeze, that it might be
> > eligible as part of the exception to the feature freeze. I think it
> > does add a little weight, but may be not enough and really depends on
> > the nature of the changes (how risky are they?).
>
> I tested the changes in a virtual machine and they work ok.
> PARTUUID related code is running on our x86_64 embedded devices for
> years already.

Cool!

> I saw in the mailing list a problem with GUID unaligned access on Ia64.
> Perhaps this could affect my code too, as I do read of 'struct
> grub_guid_t' members from on-stack 'struct grub_gpt_partentry'. (Should
> I use grub_get_unaligned16/-32 in this case?)

I think we have to sort out this first. I am looking at the issue right
now and will be discussing proposed solutions shortly. Though this should
not hold you on posting the patches.

> Apart from this the risk of including these patches is low.
>
> You can drop the changes related to FS modules if you find them too
> risky.

I cannot promise I will merge your patches because it is late and risky.
Though when we can see the patches we can decide what we can do or cannot.

Daniel

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel