Package Details: grub-git 2.04.rc1.r19.g4e7b5bb3b-1

Git Clone URL: (read-only, click to copy)
Package Base: grub-git
Description: GNU GRand Unified Bootloader (2)
Upstream URL:
Licenses: GPL3
Conflicts: grub
Provides: grub
Submitter: ridikulusrat
Maintainer: WoefulDerelict
Last Packager: WoefulDerelict
Votes: 11
Popularity: 0.000009
First Submitted: 2013-10-22 18:55
Last Updated: 2020-02-07 03:46

Dependencies (20)

Required by (52)

Sources (6)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 ... Next › Last »

air-g4p commented on 2020-02-14 03:41


Thank you for your very clear follow-up, which I found instructive and helpful.

I will be patient on the LUKS2 front and will keep an eye out for any future comments you may make here. Cheers....

WoefulDerelict commented on 2020-02-13 17:57

GRUB's master branch may at any time include breaking commits. There does not appear to be a continuous integration toolchain testing the build integrity of the master branch nor does there appear to be a requirement that the master branch must still compile after a commit is included. Users should not assume bleeding edge features are even usable let alone reliable enough to deploy.

RushAur: Ham fistedly editing the instructions to the build system is not the way to solve this issue.

air-g4p: I can reproduce the failure in a clean chroot; however, I have not had a chance to dig into the recent changes and find the exact nature of the breakage. Given GRUB's history of pushing incomplete feature commits to master which have broken the build in the past I suspect the new LUKS2 feature is incomplete and not presently something users can build and test.

drossbox: This is a -git PKDBUILD. Maintenance is performed when actually necessary and not every time an irresponsible commit upstream breaks things.

air-g4p commented on 2020-02-13 14:44


Thank you and good work done here, Sir!

Using your suggestions, I have successfully compiled AND INSTALLED grub-git 2.04.rc1.r19.g4e7b5bb3b-1 on two separate rigs.

One minor clarification: ./ actually appears in prepare(), not under configure().

That challenge being solved, I tried to convert my existing luks1 encrypted /boot, / and swap to luks2 using:

cryptsetup convert --type luks2 /dev/sda23

from the Arch Installation ISO, as the encrypted device cannot be mounted.

Also assuming /dev/sda23 is where your existing /boot, / and swap reside, ofc.

That command SUCCEEDS, and cryptsetup luksDump /dev/sda23 shows ALL the Keyslots having been converted to luks2.

Then I chrooted back into my install, re-ran mkinitcpio -P linux, then reinstalled grub with grub-install --target=..... then re-edited /etc/default/grub, then re-ran grub-mkconfig -o /boot/grub/grub.cfg

Following reboot, grub immediately faults into error mode: reporting grub CANNOT find my encrypted disk.

ONLY previously saving my LUKSHeaderBackup on an external device saved my ass from disaster!!

My question for you, @RushAur, (or anyone else following this thread), is it possible to compile and install grub-git 2.04.rc1.r19.g4e7b5bb3b-1, then convert the existing luks1 /boot, / and swap to luks2 - and then successfully reboot?

If anyone knows how to complete this transition, please feel free to contact me with the correct procedure at: saltedcipher AT protonmail DOT com.

Cheers from a feeling deprecated luks1 --type of guy....

rushaur commented on 2020-02-12 05:21

Hi guys, Facing same problems as in last 2 comments, I finally managed to compile grub: Here is the "working" pkgbuild:

Basically builds exclusively for 64bit efi, (errors within grub-pc), to workaround the luks2 debug thing, comment out or delete the line --enable-mm-debug argument to ../configure. To workaround errors in the gettext/Po files, comment out or delete the call to ./ in configure(). This step would make grub english only I suppose,since no language files are made.

air-g4p commented on 2020-02-08 05:06


I also would like to convert my existing encrypted /boot, / and swap from Luks 1 to Luks 2.

However, the build of grub-git 2.04.rc1.r19.g4e7b5bb3b-1 failed this way using makepkg -sric:

grub_debug_free in luks2 is not defined grub_debug_malloc in luks2 is not defined make[3]: [Makefile:49709: moddep.lst] Error 1 make[3]: Leaving directory '/home/user/.builds/grub-git/src/grub/build_i386-pc/grub-core' make[2]: [Makefile:27533: all] Error 2 make[2]: Leaving directory '/home/user/.builds/grub-git/src/grub/build_i386-pc/grub-core' make[1]: [Makefile:11755: all-recursive] Error 1 make[1]: Leaving directory '/home/user/.builds/grub-git/src/grub/build_i386-pc' make: [Makefile:3745: all] Error 2 ==> ERROR: A failure occurred in build()

This build failure appears quite similar to the failure drossbox described on 6 Feb 2020.

BTW: grub-git also failed to build in a clean chroot.

Any ideas? Thanks!

drossbox commented on 2020-02-06 17:11

Is this package no longer being maintained? I see it hasn't been updated for a while and it fails to build. It complains about grub_debug_free and grub_debug_malloc in luks2 not being defined, then fails. I'd hoped to get this working now that grub can support a luks2 encrypted boot.

WoefulDerelict commented on 2019-07-17 21:05

Peter_Littmann: rc1 was indeed to indicate release candidate 1 which was the tag present on the repository the last time this PKGBUILD required changes to cope with issues introduced upstream. As I stated earlier the -git suffix is intended to communicate that this PKGBUILD will always attempt to construct the software from the current git trunk and that pkgver will be generated at build time from data provided by the VCS. As upstream has already moved on past the 2.04 release this PKGBUILD presently generates a pkgver of 2.04.r9.g8f6843ce6-1. Users are expected to have read the relevant documentation BEFORE they visit the AUR and should be familiar with VCS packaging conventions. The ONLY supported method for building and managing packages from PKGBUILDs hosted in the AUR is makepkg. Users are expected to have read and understood what the PKGBUILD does before they download and attempt to use it. The burden of knowing when changes have occurred upstream and when to rebuild a VCS package pulling from a project's git master branch is placed entirely on the end user.

The logic in pgkver() exists to reduce the maintenance burden of VCS packages. Cluttering the AUR with unnecessary updates every time there has been a commit upstream just to keep the pkgver current is generally frowned upon.

Peter_Littmann commented on 2019-07-17 06:38

But is the name grub-git 2.04.rc1.r19.g4e7b5bb3b-1 not misleading? I thought rc1 stands for release candidate 1 and now there is a real release published as I understand. May be makepkg is called by hand and fetches the latest version, but how does pamac or yay get informed that there is a new version to start makepkg for it when alreaady installed???

WoefulDerelict commented on 2019-07-16 16:16

Peter_Littmann: This is a VCS package. The -git suffix implies that it will fetch the latest (trunk) version from the upstream git server when makepkg is called. pkgver() automatically updates the package version when it is built.

Peter_Littmann commented on 2019-07-15 20:19

It looks like grub 2.04 is released on 05. July 2019, please check this: