Update GRUB submodule to 2.14 and adapt EfiFs for API changes#50
Update GRUB submodule to 2.14 and adapt EfiFs for API changes#50drolevar wants to merge 2 commits intopbatard:masterfrom
Conversation
|
Fixes #44 |
|
Thanks, but as you can see... I'm aware of the 2.14 release of GRUB, so I was kind of planning to do this anyway. I believe part of the breakage has to do with the fact that we are pulling the latest EDK2, especially since it dropped support for ARM compilation last year, so I was planning to switch to pulling the 2025.08 stable for one final release with ARM, before dropping support for it completely. However, some of the other issues I see appear to have to do with forgetting to add Ideally, you should clone this repository and test the GitHub workflow build from this cloned repo before submitting a PR, as that's kind of the point of having GitHub Actions as part of the project (it's not just so that we can publish binaries), especially as it will allow you to test Windows/gnu-efi builds even if you don't have a Visual Studio + gnu-efi environment. Or maybe I just want someone to sympathise with what I have to go through every year or so, when I decide to update the project, and find that the build process has been broken for one reason or another... 😉 Or you can just wait until I (find enough spare time to) update the project's toolchains to fix whatever breakage has appeared in them, and resubmit the PR after I do that... though I will probably update GRUB myself as part of that process anyway. |
|
@pbatard I've made a fix. The error was in bfs.c due to the fact that |
|
@pbatard I have also updated safemath.h to use type-specific Microsoft functions, which fixed certain warnings for types other than grub_size_t. |
|
Out of curiosity, what keeps this grub patch from being upstreamed? |
|
@Conan-Kudo, I'm not sure what you're talking about when you say "this grub patch" especially in the context of upstreaming. If you are talking about the patch associated with this PR, then it has been upstreamed the moment the PR was created. Now, me being able to review, fix and integrate the patch (since the build currently breaks) is another story, for which I cannot currently provide a timeline, as EfiFs is one of the many secondary projects that I maintain (and to be honest, no I don't see anything in here that warrants an urgent update of EfiFs as it only benefits people who need to use the very latest features of xfs and as far as erofs is concerned, we already provide a driver for it). If you are talking about upstreaming the 0001-GRUB-fixes.patch to the GRUB project, so that we don't have to maintain it, well, a lot of that code relates to being able to compile GRUB for MSVC, which I don't think the GRUB folks will be that interested in maintaining, especially as, even if we were to add automated build tests for it as part of GRUB CI, nobody is going to be that thrilled having to fix code, that they won't be able to test locally, because MSVC builds broke (and I certainly won't have the time to do that for them either). Anyway, as usual, the answer to your question regardless of what you mean by it is: there simply enough hours in a day and enough willing people to spend time on it or within a delay that people who aren't used to work on Open Source projects will find amenable, especially if it also means continuing to invest time on it in the long run. |
Update GRUB submodule to 2.14, which adds support for newer XFS v5 features (EXCHRANGE, PARENT, METADIR) and EROFS. Regenerate 0001-GRUB-fixes.patch for the new GRUB codebase. Adapt src/grub.c and src/grub_file.c for GRUB 2.14 API changes: - gcry_md_init_t now takes an extra 'flags' parameter - gcry_md_spec_t struct layout changed (use designated initializers) - grub_dl_ref/grub_dl_unref now return grub_uint64_t instead of int
|
@pbatard Pinned EDK2 to edk2-stable202508.01 as you have mentioned. Now all workflows complete successfully. |
|
Thanks for this. That's what I was planning to work on first before integrating your work, so this will definitely save some time. And don't worry about the merge-artifacts task failing, as it shouldn't run on PRs anyway and I need to add a filter to make sure it doesn't. |
|
Okay, let me first try a patch that includes your latest EDK2 pinning and that updates all our dependencies to latest (including the new GRUB project git repo) and sorts the merge-artifacts issue. Once/if that works, I'll move to applying your GRUB update. Oh, and whereas I do not credit you fully on that first patch, since there are quite a few additional changes, you will of course get the full credit for the next one. |
* With thanks to Andrij Abyzov for parts of this patch (#50).
* With thanks to Andrij Abyzov for parts of this patch (#50).
* Also update the GRUB git URI to its mew gitlab.freedesktop.org repo. * With thanks to Andrij Abyzov for parts of this patch (#50).
* Also update the GRUB git URI to its mew gitlab.freedesktop.org repo. * With thanks to Andrij Abyzov for parts of this patch (#50).
|
Okay, I expect the upcoming closing commit to work. Once we have validated it does, I will produce a new release that includes your changes. Thanks again for the PR! |
* Also update the GRUB git URI to its new gitlab.freedesktop.org repo. * With thanks to Andrij Abyzov for parts of this patch (#50).
* Update GRUB submodule to 2.14, which adds support for XFS v5 features (EXCHANGE, PARENT, METADIR) and formally integrates EROFS. * Adapt grub.c and grub_file.c for the GRUB 2.14 API changes: - gcry_md_init_t now takes an extra 'flags' parameter - gcry_md_spec_t struct layout changed (use designated initializers) - grub_dl_ref/grub_dl_unref now return grub_uint64_t instead of int * Closes #50.
3 participants
Update GRUB submodule to 2.14, which adds support for newer XFS v5 features (EXCHRANGE, PARENT, METADIR) and EROFS. Regenerate 0001-GRUB-fixes.patch for the new GRUB codebase. Adapt src/grub.c and src/grub_file.c for GRUB 2.14 API changes:
Fixes #44