Update patches to grub version 2.04
Closed this issue · 7 comments
Hi!
Grub was updated to version 2.04 at 2019-07-05 (https://ftp.gnu.org/gnu/grub/).
Please update patches.
P. S.
I refer to patches at https://grub.johnlane.ie/ which are reffered by archlinux aur package https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=grub-luks-keyfile
Compilation log:
=========================
grub-core/disk/cryptodisk.c: In function ‘grub_cryptodisk_open’:
grub-core/disk/cryptodisk.c:526:67: warning: passing argument 1 of ‘grub_cryptodisk_uuidcmp’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
526 | if (grub_cryptodisk_uuidcmp(name + sizeof ("cryptouuid/") - 1, dev->uuid))
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
grub-core/disk/cryptodisk.c:118:31: note: expected ‘char *’ but argument is of type ‘const char *’
118 | grub_cryptodisk_uuidcmp(char *uuid_a, char *uuid_b)
| ~~~~~~^~~~~~
grub-core/disk/cryptodisk.c: In function ‘grub_cryptodisk_get_by_uuid’:
grub-core/disk/cryptodisk.c:759:44: warning: passing argument 2 of ‘grub_cryptodisk_uuidcmp’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
759 | if (grub_cryptodisk_uuidcmp(dev->uuid, uuid))
| ^~~~
grub-core/disk/cryptodisk.c:118:45: note: expected ‘char *’ but argument is of type ‘const char *’
118 | grub_cryptodisk_uuidcmp(char *uuid_a, char *uuid_b)
| ~~~~~~^~~~~~
grub-core/disk/cryptodisk.c: In function ‘grub_cmd_cryptomount’:
grub-core/disk/cryptodisk.c:1011:13: error: too few arguments to function ‘grub_file_open’
1011 | hdr = grub_file_open (state[3].arg);
| ^~~~~~~~~~~~~~
In file included from ./include/grub/disk.h:24,
from ./include/grub/cryptodisk.h:22,
from grub-core/disk/cryptodisk.c:19:
The solution is to put GRUB_FILE_TYPE_NONE to grub_file_open()
Thank you for this. When I next do an update I will apply the fix. I'm not sure when I'll get around to it given zero interest from upstream.
Why upstream has zero interest? After reading last conversation in mailing list which happened in March 2018 (or so, I don't remember exactly) and precedinc conversations from 2016-2017, my conclusion is that patches are welcomed, but support for autogeneration is needed.
In particular, grub developers want that 'grub-mkconfig' could parse relevant settings (probably, from '40-linux.custom' config file). Isn't this what stops getting patches merged?
Hi, I have not implemented auto generation and have no plans to because I don't need it and I haven't got the time. I would be happy to accept a pull request for the functionality though.
I don't think there should be any dependency on getting what I have done adopted independently of auto generation - there is genuine interest in using the functionality without auto generation which (as you may have read on the mail archives) is actually quite tricky to solve when the devices are fully encrypted and headerless.
I tried really hard to get my work upstream, spending a considerable amout of time working and reworking things, adding features and so on, at the request of the upstream developers. I would love to be in a position to do that until it's adopted but unfortunately I don't have the time. It's just me behind these patches, no company or sponsor and I simply don't have the time to devote to it.
I do intend to update the patch set with the current master but I simply have neither the time nor any spare hardware on which to do the work. I will take pull requests if relevant, so feel free to contrinute autogeneration if you're able.
Thank you for the work, I understand that this is voluntary business.
Agreed, that functionality can be adopted with auto generation, but I am interested in getting this patches in grub. Do you think that fixing auto-generation issue (writing code to support this) will help to bring patches to mainsteam?
I don't know. You could do the work and it may still go nowhere. I made several changes on feedback from upstream but it still went nowhere. Perhaps raise this on the mailing list and try to get any commitment from them that you can (I will monitor and contribute to the thread if necessary).
If we can get this adopted I will do what I can, and I would appreciate the help!
Thank you for your interest in these Grub crypto extensions. Your issue here has been closed now that similar features have been implemented in Grub. Please direct your query to a Grub mailing list if your issue remains relevant.