Package Details: grub-luks-keyfile 2:2.06-1

Git Clone URL: https://aur.archlinux.org/grub-luks-keyfile.git (read-only, click to copy)
Package Base: grub-luks-keyfile
Description: GNU GRand Unified Bootloader (2) with crypto extensions to support for DMCrypt and LUKS volumes with detached headers and key files.
Upstream URL: https://www.gnu.org/software/grub/
Licenses: GPL3
Conflicts: grub, grub-bios, grub-common, grub-efi-x86_64, grub-emu, grub-legacy
Provides: grub, grub-bios, grub-common, grub-efi-x86_64, grub-emu
Replaces: grub, grub-bios, grub-common, grub-efi-x86_64, grub-emu
Submitter: kalbasit
Maintainer: mxfm
Last Packager: mxfm
Votes: 6
Popularity: 0.000210
First Submitted: 2017-12-22 02:31 (UTC)
Last Updated: 2021-06-14 12:15 (UTC)

Required by (147)

Sources (14)

Latest Comments

mxfm commented on 2022-06-10 10:04 (UTC) (edited on 2022-06-10 10:07 (UTC) by mxfm)

Yes. The state of things with these patches is following. The 'crypto enhancement' patch series by John Lane adds following features:

  • key files

  • detached headers

  • multiple passphrase attempts

  • plain dm-crypt support

  • using device as keyfile

  • UUID hyphens

Key files were added recently by Glenn Washburn who rewrote some of these patches. Detached headers patch series will be also added soon to grub master.

Currently I am working on the third version of plain mode patch, but it will not be accepted as soon as detached headers support (according to my expectation).

Using device as a keyfile can be added as a fix to keyfiles patch series of Glen Washburn, but currently nobody is working on this. I have added support for this feature in plain mode, but it is not currently supported in LUKS mode.

Finally, supporting multiple passphrase attempts and UUID hyphens patches are not included into grub master and nobody is working on supporting them. When I started to support these patches I was interested only in plain mode. If I have spare time, I will rewrite these two minor patches (+ device as a keyfile), but they are not my priorities.

gamezelda commented on 2022-06-09 19:35 (UTC) (edited on 2022-06-09 19:35 (UTC) by gamezelda)

The 2nd patch in the series, the one which enables the key-file, keyfile-offset and keyfile-size parameters, was committed to the official GRUB repository and is included in the latest Arch GRUB package (grub 2:2.06.r261.g2f4430cc0-1).

So you may be able to switch to the official Arch package, as long as you only need the base keyfile support and not any of the extras (LUKS detached header, plain dm-crypt, whole device as keyfile, etc.).

PS: And if you switch to the official Arch package, also make sure to remove hyphens from the UUID in cryptomount (if this applies to you), that part is not in the official GRUB package yet and it will fail to find the disk unless you remove them.

acerix commented on 2021-05-11 22:07 (UTC)

Thank you for your work on this, the git version does not have the issue so I will use that for now.

mxfm commented on 2021-05-11 16:41 (UTC)

No, it is not expected, because I follow arch Grub package pkgbuild, also these patches should not explode package size.

I will investigate this in next weekend.

Can you try git version of this package?

acerix commented on 2021-05-11 00:31 (UTC)

Is it expected for this package to have a Total Installed Size of 930.45 MiB? When I build it, the .img files are much larger than the base grub package.

# grub
$ ls -l /usr/lib/grub/i386-pc/*.img
-rw-r--r-- 1 root root   512 Feb 21 15:55 /usr/lib/grub/i386-pc/boot_hybrid.img
-rw-r--r-- 1 root root   512 Feb 21 15:55 /usr/lib/grub/i386-pc/boot.img
-rw-r--r-- 1 root root  2048 Feb 21 15:55 /usr/lib/grub/i386-pc/cdboot.img
-rw-r--r-- 1 root root   512 Feb 21 15:55 /usr/lib/grub/i386-pc/diskboot.img
-rw-r--r-- 1 root root 29276 Feb 21 15:55 /usr/lib/grub/i386-pc/kernel.img
-rw-r--r-- 1 root root  1024 Feb 21 15:55 /usr/lib/grub/i386-pc/lnxboot.img
-rw-r--r-- 1 root root  2848 Feb 21 15:55 /usr/lib/grub/i386-pc/lzma_decompress.img
-rw-r--r-- 1 root root  1024 Feb 21 15:55 /usr/lib/grub/i386-pc/pxeboot.img

# grub-luks-keyfile
$ ls -l /usr/lib/grub/i386-pc/*.img
-rw-r--r-- 1 root root 134481116 May 10 19:51 /usr/lib/grub/i386-pc/boot_hybrid.img
-rw-r--r-- 1 root root 134481116 May 10 19:51 /usr/lib/grub/i386-pc/boot.img
-rw-r--r-- 1 root root 134481116 May 10 19:51 /usr/lib/grub/i386-pc/cdboot.img
-rw-r--r-- 1 root root 134480092 May 10 19:51 /usr/lib/grub/i386-pc/diskboot.img
-rw-r--r-- 1 root root     29168 May 10 19:51 /usr/lib/grub/i386-pc/kernel.img
-rw-r--r-- 1 root root 134488284 May 10 19:51 /usr/lib/grub/i386-pc/lnxboot.img
-rw-r--r-- 1 root root 134479612 May 10 19:51 /usr/lib/grub/i386-pc/lzma_decompress.img
-rw-r--r-- 1 root root 134481116 May 10 19:51 /usr/lib/grub/i386-pc/pxeboot.img

mxfm commented on 2020-03-04 10:44 (UTC)

@Martmists can you elaborate on the context of your comment? It seems you refer to some revealed bug/issue, however I do not see any links.

I use these patches in a following way. I don't have grub menu, I simply type necessary parameters upon each boot, so I don't know what happens when these patches are used together with grub menu.

Besides, these patches are developed by John Lane (https://github.com/johnlane/grub), so you can contact him to file a bug.

Martmists commented on 2020-03-02 08:27 (UTC) (edited on 2020-03-02 08:27 (UTC) by Martmists)

Grub seems to not use the -p and -k parameter BEFORE the grub menu, as they are not in the binary file on the EFI partition. The cause seems to be that in some parts of the patched code, simply cryptomount -u $uuid seems to be used, therefore not unlocking grub at boot.

mxfm commented on 2019-07-09 20:38 (UTC)

Updated.

mxfm commented on 2019-07-09 05:24 (UTC) (edited on 2019-07-09 05:25 (UTC) by mxfm)

@gamezelda, I have already opened github issue https://github.com/johnlane/grub/issues/18

Thanks for digging compilation errors up. If the author (John Lane) does not fix within days, I will patch myself.

gamezelda commented on 2019-07-08 21:34 (UTC)

At the official repos Grub 2.04 is out, and has some features that may be interesting ( https://www.phoronix.com/scan.php?page=news_item&px=GRUB-2.04-Released ).

This package's patches don't work out of the box with the new version, but are easy to fix. The grub_file_open now has one second parameter GRUB_FILE_TYPE_...., I modified the patches to pass GRUB_FILE_TYPE_NONE and I was able to compile and get it to work for me. (From my naive inspection, I wasn't able to find any better GRUB_FILE_TYPE_... constant to use for the keyfiles other than GRUB_FILE_TYPE_NONE)

mxfm commented on 2019-07-07 12:16 (UTC)

GRUB was updated to version 2.04 at 2019-07-05. Currently several patches cannot applied because of this. I has written to the author.

mxfm commented on 2018-10-16 11:08 (UTC)

Updated.

Kay94 commented on 2018-10-15 19:54 (UTC)

Hi, thanks a lot. One thing: Could you change the weblinks to the patches to https instead of http? Like: "https://grub.johnlane.ie/assets/0001-Cryptomount-support-LUKS-detached-header.patch" Regards

gamezelda commented on 2018-08-25 21:23 (UTC)

Thanks for your work! I have been able to build and install GRUB successfully with the new release.

mxfm commented on 2018-08-25 19:19 (UTC) (edited on 2018-08-25 19:20 (UTC) by mxfm)

Update. It appears that patch mentioned in forum discussion (link in previous post) was actually a fix to the issue. After letter to Christian Hesse he added the patch (https://lists.archlinux.org/pipermail/arch-commits/2018-August/527094.html) to trunk, but currently grub package is not affected because no changes were made to repo. So, manual compilation from trunk sources works, compiled grub package is still 2018-06-27.

Meanwhile, 0010-relocation patch was added here, together with xfs patch from grub trunk (looks like kalbasit left maintaining this package before the patch was added to core grub). On my machine the relocation patch works. It would be helpful if someone tests current version.

mxfm commented on 2018-08-25 08:17 (UTC)

@gamezelda, I was about to check when stock package was compiled (2018-06-27) and to write the same :)

So this may be something wrong with core package, not the way we compile ...

gamezelda commented on 2018-08-25 07:47 (UTC)

@mxfm Good to know it's definitely not a problem on my side! Not sure how I didn't find that link though.

The stock Arch package works because it was built in June, before the breakage ocurred.

mxfm commented on 2018-08-25 05:59 (UTC) (edited on 2018-08-25 07:22 (UTC) by mxfm)

@gamezelda I have just recompiled this package not in clean root - installation of x86-64_efi target failed with error you described. Then I recompiled the package in clean chroot - installation failed with the same error. So, indeed there is some problem either with the package (this patches) or with the grub.

P.S Compiled in clean chroot grub also fails upon installation. P.P.S Some explanation https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg112375.html Looks like some changes in binutils in July break grub. However, this does not explain why stock archlinux grub kernel.img is OK.

gamezelda commented on 2018-08-24 20:56 (UTC) (edited on 2018-08-24 20:57 (UTC) by gamezelda)

I've been banging my head for some hours trying to reinstall GRUB again after recompiling this package, because I was receiving an error message like 'relocation 0x4 is not implemented yet' when trying to install GRUB in EFI mode (BIOS worked file).

However, the source of the problem is not in this package, because if I recompile the original unchanged Arch GRUB package the same thing happens... it looks like there's something wrong going on with compilers/linkers/whatever and the resulting GRUB x86_64 EFI kernel binary is broken.

Anyway, I found a dirty workaround if anyone happens to stumble upon the same problem: - Build and install this package as usual - Download the compiled GRUB package binaries from https://www.archlinux.org/packages/core/x86_64/grub/ - Extract the ZIP file and replace /usr/lib/grub/x86_64-efi/kernel.img with the precompiled version from the ZIP (overwrite as root) - Now you should be able to run grub-install

DISCLAIMER: Make sure you have an alternative boot method (BIOS boot, Live Arch CD, backup, etc.) because as you may suspect, this method isn't too solid. Also check the versions, I copied the kernel of grub 2:2.02-7 over grub-luks-keyfile 2:2.02-6.

kalbasit commented on 2018-08-13 18:59 (UTC)

@mxfm if you have the time, why not! Please just claim the package and it's yours. I have already disowned it.

mxfm commented on 2018-08-13 18:32 (UTC)

@kalbasit Perhaps me?

kalbasit commented on 2018-08-13 14:15 (UTC)

I switched to NixOS recently, so I won't be maintaining this package any further, can someone please adopt it? Thank you!

mxfm commented on 2018-08-09 05:22 (UTC)

... but now it does not because of sha256 mismatch of file '0006-Cryptomount-support-for-using-whole-device-as-keyfile.patch' (likely it was updated).

mxfm commented on 2018-07-18 09:22 (UTC)

I use this package since January and did not have compilation errors. Just downloaded snapshot - it builds fine.

gamezelda commented on 2018-06-12 22:17 (UTC)

@kalbasit Sure, I’ll take a look at it tomorrow.

kalbasit commented on 2018-06-12 17:36 (UTC)

@gamezelda Care to submit a pull request with your fixes? I host this AUR package at https://github.com/kalbasit/aur_grub-luks-keyfile

gamezelda commented on 2018-06-12 15:10 (UTC) (edited on 2018-06-12 16:48 (UTC) by gamezelda)

The package does not build complaining about not finding freetype2 (despite being installed).

I have been able to install it by rebasing on the last PKGBUILD:

gamezelda commented on 2018-06-12 15:08 (UTC) (edited on 2018-06-13 16:45 (UTC) by gamezelda)

@nils_92 You need to trust those GPG keys by adding them to your keyring before trying to build the package:

gpg --recv-keys 35A93B74E82E4209
gpg --recv-keys 1A09227B1F435A33

nils_92 commented on 2018-03-26 10:12 (UTC) (edited on 2018-03-26 10:12 (UTC) by nils_92)

Unfortunately it does not build with the following error

==> Verifying source file signatures with gpg... grub-2.02.tar.xz ... FAILED (unknown public key 35A93B74E82E4209) unifont-10.0.06.bdf.gz ... FAILED (unknown public key 1A09227B1F435A33) ==> ERROR: One or more PGP signatures could not be verified! ==> ERROR: Makepkg was unable to build grub-luks-keyfile.

kalbasit commented on 2018-03-18 18:22 (UTC)

@mxfm I just pushed an update, thanks for the report!

mxfm commented on 2018-03-18 18:18 (UTC)

@kalbasit

:) Sorry, pushed wrong button...

kalbasit commented on 2018-03-18 18:16 (UTC)

@mxfm I asked for a PR not an issue :). That's fine, I can push an update myself.

mxfm commented on 2018-03-18 08:28 (UTC)

https://github.com/kalbasit/aur_grub-luks-keyfile/issues/1

However, I don't understand why I should write there. Github page appears to be exact clone of this page, which provides necessary infrastruction to deal with those problems.

kalbasit commented on 2018-03-18 06:14 (UTC)

@mxfm I pushed this repo to https://github.com/kalbasit/aur_grub-luks-keyfile would you be able to send me a PR? Thank you!

mxfm commented on 2018-03-18 06:10 (UTC)

It seems John Lane updated patches (from http://grub.johnlane.ie/):

"Patches compatible with upstream HEAD (28b0d190) at time of writing, 2018/03/14. Patches 6 and 7 are contributed pull requests."

mxfm commented on 2018-03-18 05:59 (UTC) (edited on 2018-03-18 06:07 (UTC) by mxfm)

Unfortunately I cannot compile the package anymore because some patches fail source check. For example, for "0001-Crypmount..." my sha526sum is: f7790e7fd4641eed8347039ebb44b67a3f517f2bc4de213fe34d2ae887c03b92 0001-Cryptomount-support-LUKS-detached-header.patch

It is missing in sha256sums() function in PKGBUILD.

==> Validating source files with sha256sums...

grub-2.02.tar.xz ... Passed
grub-2.02.tar.xz.sig ... Skipped
grub-extras-f2a079441939eee7251bf141986cdd78946e1d20.tar.gz ... Passed
unifont-10.0.06.bdf.gz ... Passed
unifont-10.0.06.bdf.gz.sig ... Skipped
0002-intel-ucode.patch ... Passed
0003-10_linux-detect-archlinux-initramfs.patch ... Passed
0004-add-GRUB_COLOR_variables.patch ... Passed
0005-Allow_GRUB_to_mount_ext234_filesystems_that_have_the_encryption_feature.patch ... Passed
0006-tsc-Change-default-tsc-calibration-method-to-pmtimer-on-EFI-systems.patch ... Passed
0001-Cryptomount-support-LUKS-detached-header.patch ... FAILED
0002-Cryptomount-support-key-files.patch ... FAILED
0003-Cryptomount-luks-allow-multiple-passphrase-attempts.patch ... FAILED
0004-Cryptomount-support-plain-dm-crypt.patch ... FAILED
0005-Cryptomount-support-for-hyphens-in-UUID.patch ... FAILED
0006-Cryptomount-support-for-using-whole-device-as-keyfile.patch ... Passed
grub.default ... Passed
grub.cfg ... Passed

==> ERROR: One or more files did not pass the validity check!

mxfm commented on 2018-01-13 16:25 (UTC)

Hi!

First of all, I am glad to see this package because I am interested in having support plain dm-crypt, in particular support for dm-crypt options for 'cryptomount' command.

How old is grub in this version comparing with upstream? AFAIK, these patches are by John Lane written in 2015. Are they still revelant? 2-3 years ago I tried to apply them on upstream version and failed because grub was updated.

Since John is not working on new versions, it seems that either 1) one can use old version from 2015 with these patches 2) forget about these features and use upstream version or 3) update patches manually after (possibly) each new version.