Search Criteria
Package Details: grub-git 2.06.rc1.r0.ga53e530f8-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/grub-git.git (read-only, click to copy) |
---|---|
Package Base: | grub-git |
Description: | GNU GRand Unified Bootloader (2) |
Upstream URL: | https://www.gnu.org/software/grub/ |
Licenses: | GPL3 |
Conflicts: | grub |
Provides: | grub |
Submitter: | ridikulusrat |
Maintainer: | WoefulDerelict |
Last Packager: | WoefulDerelict |
Votes: | 16 |
Popularity: | 0.024744 |
First Submitted: | 2013-10-22 18:55 (UTC) |
Last Updated: | 2021-03-25 00:55 (UTC) |
Dependencies (20)
- device-mapper (device-mapper-git, device-mapper-noudev)
- freetype2 (freetype2-minimal-git, freetype2-ttmetrics, freetype2-v35, freetype2-git, freetype2-ultimate5, freetype2-infinality-remix)
- fuse2
- gettext (gettext-git)
- sdl (sdl-openglhq, sdl-nokbgrab, sdl-openglhq-nokbgrab, sdl-git, sdl2_compat12-git, sdl12-compat-git, sdl12-compat)
- autogen (make)
- bdf-unifont (make)
- git (git-git, git-vfs, git-run-command-patch-git) (make)
- help2man (help2man-git) (make)
- libusb (libusb-git) (make)
- python (python38, python37, python3.7, nogil-python, python39, python36, python311, python32) (make)
- rsync (rsync-git) (make)
- texinfo (texinfo-git) (make)
- ttf-dejavu (ttf-dejavu-ib, ttf-dejavu-emojiless) (make)
- dosfstools (dosfstools-git) (optional) – For grub-mkrescue FAT FS and EFI support
- efibootmgr (efibootmgr-git) (optional) – For grub-install EFI support
- libisoburn (libisoburn-git) (optional) – Provides xorriso for generating grub rescue iso using grub-mkrescue
- libusb (libusb-git) (optional) – For grub-emu USB support
- mtools (mtools-svn) (optional) – For grub-mkrescue FAT FS support
- os-prober (os-prober-git, os-prober-btrfs) (optional) – To detect other OSes when generating grub.cfg in BIOS systems
Required by (144)
- admin-git (requires grub) (optional)
- apple_set_os (requires grub) (optional)
- arch-grub2-theme (requires grub)
- arch-matrix-grub-theme-git (requires grub)
- archiso-git (requires grub)
- archuseriso (requires grub)
- bieaz (requires grub)
- bieaz-git (requires grub)
- booty-git (requires grub)
- cryptboot (requires grub)
- cyberpunk-grub-theme-git (requires grub)
- dedsec-grub2-theme (requires grub)
- dracula-grub-theme-git (requires grub)
- endeavouros-galleon-grub (requires grub)
- grml-iso (requires grub)
- grml-rescueboot (requires grub)
- grml2usb (requires grub) (optional)
- grub-btrfs-git (requires grub)
- grub-custom-simona (requires grub)
- grub-editor (requires grub)
Latest Comments
callmejoe commented on 2021-11-02 03:53 (UTC) (edited on 2022-05-29 16:17 (UTC) by callmejoe)
@rushaur: yes I guess you're right. i rarely install from git pkgs, and forgot that's how it goes.
EDIT: turns out my system was woefully out of date. upgrading solved everything
rushaur commented on 2021-11-02 01:47 (UTC)
@callmejoe: That is the thing with git packages, they can break anytime. I would suggest to check the grub source repo for commits that deal with fixing build errors and rebuild when new stuff is committed.
callmejoe commented on 2021-11-02 01:35 (UTC)
having trouble building. getting a lot of configure.ac warnings&errors.
https://imgur.com/HpTcFta.png
any ideas? thanks
qupfer commented on 2021-09-24 12:56 (UTC) (edited on 2021-09-24 13:00 (UTC) by qupfer)
Hi, I modified air-g4p's script and it works great with btrfs and background image. Thanks.
Also give attention, if you change your Passphrase that it will have pbkdf2 again
sudo cryptsetup luksChangeKey --hash sha512 --pbkdf=pbkdf2 --pbkdf-force-iterations=500000 /dev/sdb2
The Background lays next to the BOOTX64.EFI file (unencrypted)
aizomul commented on 2021-06-25 17:19 (UTC) (edited on 2021-06-25 17:22 (UTC) by aizomul)
Does anyone know how to include a keyfile unlocking on the early boot passphrase? Since the cryptomount -u UUID doesn't include a keyfile option, I'm stuck.....
dani0854 commented on 2021-04-30 15:52 (UTC) (edited on 2021-05-01 08:20 (UTC) by dani0854)
I am trying to setup lvm on luks2 with boot inside lvm.
cryptomount
works, andls
in grub rescue shows all the volumes, but it can't identify their filesystem (error: unknown filesystem
), includingArchNVMe-root
andnvme0n1p2
. On wiki it says that it can happen if BIOS boot partition outside of the first 2TiB. But I didn't create BIOS boot partition because it also says that UEFI systems don't need one. Anyone has seen errors like that? Thanks in advance.EDIT: I have tried with BIOS boot partition, it didn't change anything, still getting that error.
EDIT2: The issue was that I didn't install ext2 module
air-g4p commented on 2021-04-20 15:37 (UTC) (edited on 2021-04-20 15:39 (UTC) by air-g4p)
@rushaur - You're welcome, but thank you for testing the with and without 'crypto modules' cases, both without the modified grub-mkimage script!
No surprises here, but now we know for a for a fact that having the correct grub-install --modules="...." statement AND a correct grub-mkimage script (both adapted for each user's system) are mandatory for successful LUKS2 /boot unlocking!
Hopefully, this will save others wasting time speculating and to immediately begin efficiently implementing the correct grub 2.06 LUKS2 encrypted /boot upgrade procedure as documented below.
Cheers!
trumee commented on 2021-04-20 03:47 (UTC)
Anybody used this with ZFS (ZFS on LUKS), with /boot in the pool or outside the pool?
rushaur commented on 2021-04-20 00:35 (UTC) (edited on 2021-04-20 00:36 (UTC) by rushaur)
@air-g4p: I tested in a VM and here my results so far:
grub-install without --modules=".." and without auto unlock script --> grub rescue.
grub-install with --modules=".." and without auto unlock script --> grub rescue.
grub-install with --modules=".." and with auto unlock script --> success!
So, seems both are required for grub 2.06-rc to successfully unlock a LUKS2 container. Thanks for your reply and your effort!
air-g4p commented on 2021-04-19 15:09 (UTC) (edited on 2021-04-19 20:18 (UTC) by air-g4p)
@rushaur: I am not sure, because I have not tested
grub-install
under grub 2.06 without adding the modules.You are correct that 2.06 does not yet support Argon2. In fact, a grub developer told me, today, he is actively working on this problem, but that Argon2 support will not become available until a subsequent version is released.
I do KNOW the modules="...." were required under grub-git - and the cryptographic modules I listed (specific for my system) were very likely also required for successful grub 2.06 installation, thereby enabling support for grub's subsequent encrypted LUKS2 /boot (Keyslot 1) unlocking.
As you may know, once grub unlocks Keyslot 1 (encrypted /boot), initramfs and the kernel then unlock Keyslot 0 (your LUKS2 encrypted / and any underlying LVs).
If you want to answer your own query, please have a go and document your results for the benefit of others.
Cheers
rushaur commented on 2021-04-19 12:00 (UTC)
@air-g4p: With grub 2.06 is it really required to include/specify the modules to unlock a LUKS2 container? If grub 2.06 "supports" LUKS2, doesn't this "support" include auto detection of the modules? I thought, the only thing that is not yet supported is argon2. I might be confusing something :-)
air-g4p commented on 2021-04-17 17:40 (UTC) (edited on 2021-04-19 09:59 (UTC) by air-g4p)
As a heads up to all who are interested in native grub LUKS2 automated encrypted /boot, /, and swap unlocking:
grub 2:2.06rc1-1 - is now available from the Arch TESTING repo - and 2.06 DOES support native LUKS2 unlocking. I know that because I am using it to boot from both my LUKS2 laptops.
If that is the package you want, this is the correct upgrade process:
A. Replace grub-git with grub (2.06). This will overwrite your existing
/etc/default/grub
, so you might want to make a backup, first.B. Reinstall grub, depending on your cryptsetup options and / filesystem choice, with something like:
C. For those desiring to automate their LUKS2 GRUB encrypted /boot unlocking process, Patrick Steinhardt (of grub-dev) was kind enough to develop and share with me a generic grub-mkimage unlocking script, which obviously needs to be modified in accordance with the specifics of your system.
The following script includes the modifications I made to unlock my system with grub 2.06, while remaining consistent with my prior system setup comments, which are now a few pages back within these grub-git comments.
D. Save your correctly modified script to a file. I call mine
luks2.sh
.E. Run:
F. Ensure your
/etc/default/grub
is correct.G. We need to overwrite our existing grubx64.efi payload with the image created by our
luks2.sh
script. Run something like:H. Generate and write your final grub configuration with:
I. Finally, run:
Cheers, and enjoy native grub LUKS2 automated encrypted /boot, /, and swap unlocking!!!
Dylan14 commented on 2021-03-14 05:08 (UTC) (edited on 2021-03-14 06:14 (UTC) by Dylan14)
The section of util/grub-mkconfig.in that the add-GRUB_COLOR_variables.patch references has shifted up a few lines in recent commits. It now starts at line 214 instead of 218. This is causing the build to fail.
Edit: Fixed patch here: https://github.com/Dylan1496/aur-pkgbuilds/blob/master/add-GRUB_COLOR_variables.patch Note, it appears by default os-prober is disabled. Another patch will probably be needed to fix that.
ciocio.la commented on 2021-02-13 04:26 (UTC)
For the other space cadets out there...
cryptomount will only detect your luks2 partition UUID if there is no dashes in the identifier otherwise you will be greeted with
no such cryptodisk found
.Thanks for making this accessible everybody.
archabuser commented on 2021-01-31 16:55 (UTC) (edited on 2021-01-31 17:05 (UTC) by archabuser)
@ceri This is due to grub-install not correctly configuring your grub EFI-Image. It seems to be one of the limitations of upstream LUKS2 support. I ran into the same issue and then followed air-g4p's comment to add the right early config. I created a file
/boot/grub/init.cfg
with the following contents:Where <vg-uuid> and <vl-uuid> point to the lvm volume that contains your /boot directory (use
vgdisplay
andlvdisplay
for lookup). Then i rangrub-mkimage
with all the required modules and added the config with-c /boot/grub/init.cfg
.ceri commented on 2021-01-18 14:53 (UTC) (edited on 2021-01-18 14:53 (UTC) by ceri)
I'm using luks2 with pbkdf2 keys for encrypted /boot and I'm having difficultly with the grub EFI.
It complains/lies "no such cryptodisk found" with the UUID of my boot partition. If I manually unlock it, it shows the same UUID (with hyphens), and the main grub loader starts:
This is the command I'm using to build my EFI stub
Any ideas?
praise_x commented on 2020-11-27 17:20 (UTC) (edited on 2020-11-30 15:29 (UTC) by praise_x)
Here is my patch to use 4096-byte sectors with LUKS2
rushaur commented on 2020-10-07 11:19 (UTC) (edited on 2020-10-07 11:39 (UTC) by rushaur)
I finally could boot from a LUKS2 encrypted root (not converted). If someone is interested, here the steps With help from @air-g4p comments: By the way thank you!
1- As usual, partition/format the disk. I had only two partitions:
sda1 ------> /boot/efi
sda2 ------> /
2- Encryption:
AFAIK --allow-discards --persistent are LUKS2 only:
3- Make the filesystem and mount it to /mnt:
Steps to create/mount subvolumes skipped here to keep things short
4- Install the new system: the usual pacstrap /mnt pkg1 pkg2 pkgn...
5- Tweaks: Replace xxxxx with the uuid of your root: You can get it by running:
Edit (/mnt)/etc/default/grub to reflect this:
If you plan to unlock with a keyfile, luksAddKey accepts --pbkdf pbkdf2 cmdline parameter
For later reuse, let's make the script provided by @air-g4p locally available. Modified for own use case. Because I had created a subvolume @grub to be later mounted at /boot/grub; you will see the @grub notation:
It might be useless; but at least it will create the directory structure :)
Create the "new" bootloader which will include the modules/instructions needed to unlock our luks2 container:
If all goes well, you will be hopefully greeted by grub asking for enc. passphrase :)
yangsheng6810 commented on 2020-10-02 00:15 (UTC)
In case someone like me who do not know how to modify an existing LUKS2 partition with argon2 keys to make it work, here is how I did it. You may need to remove every argon2 keys to make GRUB unlocking work. (For me, those argon2 keys that uses a keyfile instead of a passphrase can be kept)
air-g4p commented on 2020-09-29 07:53 (UTC) (edited on 2020-09-29 08:20 (UTC) by air-g4p)
@drgr33n - Noted, however, if you parse through the grub-devel archives you will see there are numerous argon2 threads.
https://lists.gnu.org/archive/html/grub-devel/2020-03/msg00106.html is but one example.
From what I can discern, the devs believe that future support for argon2 will not be all that difficult to incorporate. That being said, it appears that the window for including argon2 support in 2.06 has already closed. So, we'll just have to be patient and continue our LUKS2 grub /boot unlocking with pbkdf2 until then.
Personally, I remain thankful that we now have a documented, working LUKS2 grub /boot unlocking procedure well ahead of schedule! I boot from LUKS2 /boot on both of my laptops without issue.
Cheers
drgr33n commented on 2020-09-25 22:39 (UTC)
luks2 works fine as long as you use pbkdf2. I have just set it up on my new laptop and it works great. Pitty about the argon2 support though. Hopefully that will come soon enough.
air-g4p commented on 2020-09-03 22:48 (UTC) (edited on 2021-04-17 18:02 (UTC) by air-g4p)
If anyone desires to automate their LUKS2 GRUB encrypted /boot unlocking process, Patrick Steinhardt (of grub-dev) was kind enough to develop and share with me a generic
grub-mkimage
unlocking script, which obviously needs to be modified in accordance with the specifics of your system.The following script includes the modifications I made to unlock my system, remaining consistent with my prior system setup comments.
That script when executed, generates a GRUB executable image file stored at: /tmp/image.
Finally, you need to overwrite your existing grubx64.efi file. Run something similar to:
cp /tmp/image /efi/EFI/Luks2Testing/grubx64.efi
Reboot, and enjoy automated unlocking of your LUKS2 encrypted /boot, / and swap!
air-g4p commented on 2020-08-30 09:52 (UTC) (edited on 2021-05-04 07:45 (UTC) by air-g4p)
FINALLY! The correct procedure to unlock a LUKS2 encrypted /boot:
I have been working with the fine folks on the grub-devel mailing list. Following MANY hours of testing, I have identified a process to successfully unlock a LUKS2 encrypted /boot.
This process still requires manual intervention following reboot, but the important part is that IT WORKS!
Carefully Note: I originally encrypted my partition with:
cryptsetup -c aes-xts-plain64 -h sha512 -s 512 --use-random --type luks1 luksFormat /dev/sdXZ
You may have run cryptsetup luksFormat with different options - and how you set up encryption will become important in the
grub-install
(Step 5, below). Adapt to your requirements.Then I set up two LVs: swap (512M) and / (remaining partition space). That encrypted swap LV is assigned as
dm-1
and encrypted / is assigned asdm-2
. I happen to rundm-2
with BTRFS, but any sane filesystem should also work.GRUB has always booted my LUKS1 encrypted: /boot, / and swap system without issue.
The process I used to successfully unlock my LUKS2 encrypted /boot:
UEFI boot from any reasonably recent arch iso, and run:
cryptsetup convert --type luks2 /dev/sdXZ
. That command will succeed, andluksDump
will show PBKDF: pbkdf2 for both Keyslot 0 and 1.Run
cryptsetup open /dev/sdXY <something>
Mount everything and
arch-chroot
into /Run
mkinitcpio -P linux
Run
grub-install --target=x86_64-efi --efi-directory=/efi --modules="luks2 part_gpt cryptodisk gcry_rijndael pbkdf2 gcry_sha512" --bootloader-id=<some-id>
. That installation command completes without error, ASSUMING you are actually running grub-git! If you are running Arch GRUB (version 2.04) from the mainline repos, you WILL GET a luks2.modnot found
error! Also note my use ofgcry_sha512
given my cryptsetup luksFormat options, shown above.Run
grub-mkconfig -o /boot/grub/grub.cfg
Exit, umount and reboot.
Immediately following power on: you are greeted by the dreaded: error: disk 'lvmid/some-lengthy-UUID' not found. Entering rescue mode. That lengthy UUID is the exact UUID of my
dm-2
which is my encrypted / LV.At the
grub rescue>
prompt: typels
. There I see (proc) (hd0) and (hd0,gpt1)...(hd0,gpt7) where gpt7 is my last partition and where my encrypted / and /boot reside.Still at
grub rescue>
type:cryptomount (hd0,gpt7)
which then requires my passphrase. After CORRECT passphrase entry, and hitting Enter: You should see 'Slot 0 opened' and then you are immediately returned to thegrub rescue>
prompt.From
grub rescue>
type:ls
. Unlike before, you will now see something similar to: (proc) (hd0) and (hd0,gpt1)...(hd0,gpt7) where gpt7 is my last partition and where my encrypted / resides. ADDITIONALLY, you should now also see your LVs similar to: (/lvm/ArchSDD-root) and (lvm/ArchSSD-swap) depending upon your local LV naming convention decisions. This is important PROGRESS as it demonstrates that GRUB has successfully decrypted your LUKS2 encrypted /boot using your LUKS2 key from Keyslot 1!!!From
grub rescue>
type:insmod normal
From
grub rescue>
type:normal
That should launch your typical/welcome Arch Linux and Advanced options for Arch Linux screen as controlled by /etc/default/grub and by X.
After you select the kernel to boot, GRUB hands over control to your initramfs and the corresponding kernel which uses your LUKS2 key from Keyslot 0 to decrypt your encrypted swap (
dm-1
) and your encrypted / (dm-2
).My launcher (with multiple Arch kernels, and several multi-booting OSes) works perfectly...hope yours does also!
Cheers!
trialuser commented on 2020-07-10 04:52 (UTC) (edited on 2020-07-10 05:09 (UTC) by trialuser)
i have not gotten this to work with luks2, however once in grub rescue you might try:
set debug=all
ls #find your hd and partition
cryptomount hd0,gpt2
I've noticed that using sha256 as the hash results in a failed to parse digest error, switching to sha1 results in an invalid passphrase error. Hope this helps... if you make a working setup please post here...
DDoSolitary commented on 2020-07-09 14:04 (UTC)
I'm having the same problem as @air-g4p
air-g4p commented on 2020-06-23 09:41 (UTC) (edited on 2020-06-23 17:06 (UTC) by air-g4p)
@eschwartz - grub-git still fails to boot from a LUKS2 disk.
Steps to reproduce the LUKS2 boot failure from a currently, properly booting
--type luks1
encrypted /boot Arch system:UEFI boot from any reasonably recent arch iso, and run:
cryptsetup convert /dev/sdXY --type luks2 --pbkdf pbkdf2
That command will succeed, and luksDump will showPBKDF: pbkdf2
for both keyslot 0 and 1. However, carefully note, you get the exact same pbkdf2 luksDump results by ONLY running:cryptsetup convert /dev/sdXY --type luks2
so it may be that cryptsetup is ignoring the appended--pbkdf pbkdf2
option. Additionally,man cryptsetup
does not mention the--pbkdf
option under theconvert
command. That same--pbdkf
string is a valid option under theluksConvertKey
command, but that command can only modify the pbkdf parameters for an existing LUKS2 keyslot.Run
cryptsetup open /dev/sdXY <something>
mount everything and arch-chroot into /
Run
mkinitcpio -P linux
Run
grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=<some-id>
Run
grub-mkconfig -o /boot/grub/grub.cfg
exit, umount and reboot.
Then you are greeted by the dreaded:
error: disk 'lvmid/some-lengthy-UUID' not found. Entering rescue mode.
Again, if anyone discovers the correct grub-git LUKS2 encrypted /boot procedure, please carefully document it here.
drossbox commented on 2020-06-22 18:36 (UTC)
@eschwartz apologies for not replying sooner - I got busy at work after compiling this and never switched to Luks2. I'll make a copy of my /boot onto my NFS share this weekend and try converting the existing partition to Luks2 using pbkdf2.
eschwartz commented on 2020-06-22 15:48 (UTC)
And did you use cryptsetup convert with the default pbkdf which is argon2i, or did you remember to pass --pbkdf pbkdf2 ?
The former is not yet implemented in grub and obviously cannot work. The latter is a non-default option to cryptsetup, which you may have forgotten...
I still have yet to see anyone actually confirm they tried using pbkdf2 and still got failures. I still have yet to see anyone actually confirm which one they used, in fact.
air-g4p commented on 2020-06-22 10:17 (UTC)
@WoefulDerelict - I built and installed grub-git without issue after your latest bump in February. However, after converting my / to LUKS2, reinstalling grub and re-running grub-mkconfig, my system refused to boot due to my LUKS2 conversion. Reverting back to LUKS1, of course, fixed everything.
WoefulDerelict commented on 2020-04-23 21:44 (UTC)
Builds are currently succeeding on my test machine; however, I don't use LUKS or have the time spin up and test the LUKS2 support. If any brave users are willing to experiment please report back.
I'm currently in the process of reading through the recent commits as a some of these changes appear to fix issues the PKGBUILD has been working around. Once I've got all the unnecessary workarounds trimmed out and tested the resulting build I'll push an update.
eschwartz: Thanks for all the updates.
eschwartz commented on 2020-04-22 14:19 (UTC)
@drossbox,
How did it turn out?
drossbox commented on 2020-03-13 22:18 (UTC)
@eschwartz thanks for letting me know. Built successfully, so I'll test Luks2 support over the weekend.
eschwartz commented on 2020-03-11 14:09 (UTC)
As of 17 hours ago, various build fixes have landed in upstream master.
(The Argon2 KDF feature is still being reviewed, though.)
So if anyone is interested in testing out luks2 support, now might be a good time. Especially since the code freeze for grub 2.06 is being called in less than a week.
eschwartz commented on 2020-03-08 00:45 (UTC)
The grub issues with --enable-mm-debug should hopefully be fixed by https://lists.gnu.org/archive/html/grub-devel/2020-03/msg00090.html
air-g4p commented on 2020-02-16 01:03 (UTC)
@WoefulDerelict
Thank you for taking the time to provide your superb backgrounder! Your thoughts really helped me to understand grub-git's PKGBUILD and your strategy on a much deeper level.
All the best....
WoefulDerelict commented on 2020-02-14 18:01 (UTC) (edited on 2020-02-14 18:03 (UTC) by WoefulDerelict)
air-g4p: This is an odd PKGBUILD. It attempts to balance human readability and ease of maintenance while simultaneously mirroring the package in [Core]. Each PKGBUILD contains instructions to build GRUB for up to four targets before carefully packaging the result together. This allows a single package to support both BIOS and UEFI systems. The PKGBUILD used to construct the binary package in the [Core] repository builds for three targets by default, BIOS systems, 64-bit UEFI and 32-bit UEFI. The [Core] PKGBUILD doesn't enable the fourth target, GRUB EMU, by default; however, the PKGBUILD here does.
This PKGBUILD also sources two other master branches in order to build. grub-extras and gnulib are included in the build and also have the possibility to change in a way that might cause unexpected breakage. This software is also sourced by the release package in [Core]; however, the utility to change vbemodes on Intel integrated graphics is the only part of grub-extras actually included in the build performed by the PKGBUILD for the [Core] repository. This PKGBUILD only excludes the lua module from grub-extras as it has not been updated to cope with recent changes to grub and currently fails to build. When it has been patched to cope with the offending change I'll enable it again.
As the primary audience one has targeted with this PKGBUILD is Arch Linux users who are curious about testing and contributing to GRUB's development I've erred on the side of code coverage, including extra features in the build like GRUB EMU and the other modules from grub-extras.
air-g4p commented on 2020-02-14 16:15 (UTC)
@WoefulDerelict
I think your pinning idea makes good sense if your schedule constraints at some point allow you sufficient time.
Thank you for the link. After reading Patrick's comments re: disk: Implement support for LUKS2 @ http://git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd29514c2f870b49f9755 ...
I am confident that really smart people are thinking deeply about this currently intractable problem.
WoefulDerelict, I do realize you understand and are watching upstream like a hawk, but please allow me to acknowledge the superior contributions you have made as an AUR Maintainer...@rarely found (3+ standard deviations) EXCELLENCE!
WoefulDerelict commented on 2020-02-14 06:22 (UTC)
I should probably add a pin here with a generalised warning that GRUB's master branch is on the raw side and that bleeding edge features are liable to live up to their name. I'll add that to my to do list and try to include some helpful resources for things like reporting issues upstream and browsing the commits to master from the web.
air-g4p: This may be one of those features that is best to wait until it hits a release before deploying it on an important system. The next time I'm able to build a package with this PKGBUILD I'll push the updated pkgver to the web. Check out http://git.savannah.gnu.org/cgit/grub.git/log/ for current and detailed information about commits to grub's source.
air-g4p commented on 2020-02-14 05:04 (UTC)
@RushAur: Thanks, your breakage, like mine, should serve as a heads up to everyone else interested in Grub's future LUKS2 support capabilities that we need to wait.
rushaur commented on 2020-02-14 04:06 (UTC)
@air-g4p: Couldn't answer, my spare machine broke after installing the packages. I had to revert. Good to know that you have had backups; that is was saved me.
@WoefulDerelict : You are right. TIL successfully building doesn't necessarily mean it's going a work.
air-g4p commented on 2020-02-14 03:41 (UTC)
@WoefulDerelict
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 (UTC) (edited on 2020-02-13 17:59 (UTC) by WoefulDerelict)
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 (UTC) (edited on 2020-02-13 15:06 (UTC) by air-g4p)
@RushAur
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:
./linguas.sh
actually appears inprepare()
, not underconfigure()
.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 withgrub-install --target=.....
then re-edited /etc/default/grub, then re-rangrub-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 (UTC)
Hi guys, Facing same problems as in last 2 comments, I finally managed to compile grub: Here is the "working" pkgbuild: https://gitlab.com/snippets/1940462
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 ./linguas.sh 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 (UTC) (edited on 2020-02-09 00:28 (UTC) by air-g4p)
@WoefulDerelict
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 (UTC)
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 (UTC) (edited on 2020-02-13 18:16 (UTC) by WoefulDerelict)
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 (UTC) (edited on 2019-07-17 09:24 (UTC) by Peter_Littmann)
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 (UTC)
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 (UTC)
It looks like grub 2.04 is released on 05. July 2019, please check this: https://ftp.gnu.org/gnu/grub/
Ranguvar commented on 2019-07-03 14:07 (UTC)
Fixed by completely re-syncing all source.
Ranguvar commented on 2019-07-01 03:40 (UTC)
Errors still for me: http://ix.io/1No7
WoefulDerelict commented on 2019-06-12 22:57 (UTC)
scurrvy2020: You are correct, it is an issue with the upstream source. The problem arises from a failure to properly fold in CFLAGS consistently.
I called in some help and we managed to work out what the problem was and generate a minimally invasive hack to work around it.
JohnKelley commented on 2019-05-08 02:52 (UTC) (edited on 2019-05-08 02:56 (UTC) by JohnKelley)
Breakage is tracked by https://savannah.gnu.org/bugs/?56144
Workaround: roll back to Grub commit
f8f35acb5b05d40e3707a9d2db9ede60023e4cac
Patch at http://sprunge.us/La2tKWscurrvy2020 commented on 2019-04-30 14:49 (UTC)
I'm getting this error... looks like it is probably in the source and not your packaging, however.
In file included from ../../../../grub-core/lib/gnulib/argp-fmtstream.c:26: ./wchar.h:708:1: error: unknown type name ‘mbstate_t’ _GL_FUNCDECL_RPL (mbrtowc, size_t, ^~~~~~~~~~~~~~~~ ../../../../grub-core/lib/gnulib/argp-fmtstream.c: In function ‘add_width’: ../../../../grub-core/lib/gnulib/argp-fmtstream.c:125:3: error: unknown type name ‘mbstate_t’ mbstate_t ps; ^~~~~~~~~ ../../../../grub-core/lib/gnulib/argp-fmtstream.c:155:11: warning: implicit declaration of function ‘wcwidth’; did you mean ‘mbswidth’? [-Wimplicit-function-declaration] k = wcwidth (wc); ^~~~~~~ mbswidth
Ranguvar commented on 2019-04-22 17:53 (UTC)
For me, I'm hitting an error just using makepkg by itself.
http://ix.io/1GTv
thx1138 commented on 2019-04-16 16:57 (UTC) (edited on 2019-04-16 18:06 (UTC) by thx1138)
BTW, building grub-git from pikaur or pacaur may fail with:
./bootstrap: done. Now you can run './configure'.
mkdir: cannot create directory ‘/var/build/grub-git/src/grub/build_i386-pc’: File exists
==> ERROR: A failure occurred in build().
Instead, with pacaur, first remove the build directory. With pikaur, first remove both the build dir and ~/.cache/pikaur/build/grub-git/ before running the build for a second time.
WoefulDerelict commented on 2019-04-01 22:59 (UTC)
EndlessEden: According to the updated INSTALL file bootstrap calls autogen.sh so the PKGBUILD would simply need to replace the call to autogen.sh with a call to bootstrap.
Ranguvar: Even after making the relevant changes to the PKGBUILD the build fails with unknown type name errors. This seems like an error caused by the changes upstream.
EndlessEden commented on 2019-03-21 01:13 (UTC)
needs a bootstrap first, before autogen.
Ranguvar commented on 2019-03-16 01:38 (UTC)
Not building for me as of https://git.savannah.gnu.org/cgit/grub.git/commit/?id=35b909062e7b334eb4af372be3260d0f62d85375
I'm using
git branch pre-bootstrap f8f35acb
aftercd grub
to get the commit right before it.bugsmanagement commented on 2019-03-04 01:32 (UTC) (edited on 2019-03-04 01:34 (UTC) by bugsmanagement)
Hello everyone,
FYI, if anyone runs into this:
More than likely, rsync failed silently connecting to the upstream rsync server retrieving necessary language files.
In this case, you would need to allow outgoing TCP port 873. Cheers
WoefulDerelict commented on 2019-01-21 06:49 (UTC)
The PKGBUILD has undergone a substantial rewrite and some of the behaviour has changed. grub-emu is now enabled by default. grub-extras is now included in all builds instead of cherry picking the 915resolution module for the i386-pc build.
The lua module in grub-extras currently fails to build as it has not caught up with changes to grub_file_open() [http://git.savannah.gnu.org/cgit/grub.git/commit/include/grub/file.h?id=ca0a4f689a02c2c5a5e385f874aaaa38e151564e] so I have temporarily disabled it until the problem is rectified.
WoefulDerelict commented on 2018-07-26 17:10 (UTC) (edited on 2018-09-26 18:52 (UTC) by WoefulDerelict)
The duplicate symbol issue introduced by commit 0ba90a7f017889d32a47897d9107ef45cc50a049 has been resolved upstream in commit c79ebcd18cf3e208e9dda5e2ae008f76c92fe451. The work around has been removed from the PKGBUILD. The i386-efi build completes without issues on my test machines.
This has been reported back upstream.
WoefulDerelict commented on 2018-06-14 06:01 (UTC) (edited on 2018-07-11 07:18 (UTC) by WoefulDerelict)
The issue introduced by commit 0ba90a7f017889d32a47897d9107ef45cc50a049 is that i386-efi builds now contain a pair of conflicting fuctions named
grub_reboot
. It appears as tho i386-efi builds may have never been supported properly. i386-efi builds likely should have been pulling the instructions contained ingrub-core/lib/efi/reboot.c
prior to commit 0ba90a7f017889d32a47897d9107ef45cc50a049; however, they had instead been pointed to instructions for legacy systems contained ingrub-core/lib/i386/reboot.c
andgrub-core/lib/i386/reboot_trampoline.S
. Commit 0ba90a7f017889d32a47897d9107ef45cc50a049 moved the instructions contained ingrub-core/lib/efi/reboot.c
togrub-core/grub-core/kern/efi/efi.c
. After commit 0ba90a7f017889d32a47897d9107ef45cc50a049 i386-efi builds include the functiongrub_reboot
from bothgrub-core/grub-core/kern/efi/efi.c
andgrub-core/lib/i386/reboot.c
resulting in a conflict that halts the build and displays the following messagegrub_reboot in reboot is duplicated in kernel
.I have introduced a conditional statement in the PKGBUILD’s
_build_grub-efi
function which should provide a work around for i386-efi builds until the issue is corrected upstream.jonathon commented on 2018-03-29 19:03 (UTC) (edited on 2018-03-29 19:03 (UTC) by jonathon)
That may well be because there's no immediately obvious way to open a bug report... it's hidden in a drop-down under the Bug navigation bar item... -.-
Reported: https://savannah.gnu.org/bugs/?53517
WoefulDerelict commented on 2018-03-27 17:45 (UTC)
jonathon: No, unfortunately, I don't think anyone has reported the issue upstream.
jonathon commented on 2018-03-27 09:01 (UTC)
Has anyone reported the issue upstream? This page is the only one found via a web search which references the issue.
starfry commented on 2018-03-14 11:39 (UTC)
The build failure resulting in "grub_reboot in reboot is duplicated in kernel" only happens if the EFI version is built. If you don't need the EFI version (e.g. you're using BIOS) then you can disable it by setting
_GRUB_IA32_EFI_ARCH_X64="0"
in the PKGBUILD.@WoefulDerelict - I would say this is probably something that the PKGBUILD will need to address at some point because the change looks like it was made on purpose rather than as a bug. I note that the core grub package doesn't address this either, but that's because it builds a version prior to this change being introduced.
I have tried to work out how to make it build, without success. For me, disabling EFI is an acceptible workaround until the correct fix is known.
WoefulDerelict commented on 2018-01-27 01:35 (UTC) (edited on 2018-06-14 04:41 (UTC) by WoefulDerelict)
This appears to be an issue introduced by upstream commit 0ba90a7f017889d32a47897d9107ef45cc50a049. One is able to build the previous commit b4d709b6ee789cdaf3fa7a80fd90c721a16f48c2 just fine.
timofonic: -git packages generally pull from the upstream 'master' branch. Upstream developers can introduce breaking changes at any time without warning. This is not an indication the PKGBUILD is out of date.
Please report your issues upstream where they can be addressed properly.
ArchLinuxTux commented on 2018-01-24 10:37 (UTC)
@timofonic It doesn't work for me too! Same error message "grub_reboot in reboot is duplicated in kernel" with up to date packages.
timofonic commented on 2017-11-11 04:57 (UTC)
WoefulDerelict commented on 2017-09-04 20:13 (UTC)
tyler274 commented on 2017-08-30 22:05 (UTC)
WoefulDerelict commented on 2017-03-20 15:41 (UTC)
sulaweyo commented on 2017-03-20 07:38 (UTC)
WoefulDerelict commented on 2017-02-11 17:43 (UTC)
jpbd commented on 2017-02-09 18:45 (UTC)
DragonX256 commented on 2016-08-05 08:44 (UTC)
ridikulusrat commented on 2016-03-23 00:05 (UTC)
PedroHLC commented on 2015-09-29 12:59 (UTC)
vic-t commented on 2015-09-17 12:44 (UTC)
commented on 2015-08-30 05:40 (UTC)
starfry commented on 2015-07-23 12:42 (UTC)
starfry commented on 2015-06-12 16:45 (UTC)
cedric_tools commented on 2015-03-14 02:13 (UTC)
Firefoxic commented on 2015-03-10 17:37 (UTC)
ahmedallibhoy commented on 2015-02-18 00:07 (UTC)
nemesys commented on 2015-01-17 01:28 (UTC)
walkindude commented on 2014-01-06 19:28 (UTC)
ridikulusrat commented on 2013-12-23 05:43 (UTC)
walkindude commented on 2013-12-19 14:39 (UTC)
ridikulusrat commented on 2013-11-25 16:46 (UTC)
felix.s commented on 2013-11-25 10:05 (UTC)
ridikulusrat commented on 2013-10-22 19:01 (UTC)
buhman commented on 2013-03-14 21:08 (UTC)
buhman commented on 2013-02-04 16:23 (UTC)
buhman commented on 2012-12-09 14:08 (UTC)
commented on 2012-08-06 11:33 (UTC)
ridikulusrat commented on 2012-05-15 17:09 (UTC)
Lucky commented on 2012-05-14 16:54 (UTC)
jkennedy commented on 2012-03-23 02:15 (UTC)
ridikulusrat commented on 2012-03-16 12:16 (UTC)
commented on 2012-03-16 11:51 (UTC)
Lucky commented on 2012-03-05 01:08 (UTC)
GutenYe commented on 2012-03-04 08:58 (UTC)
Thar commented on 2012-01-04 16:18 (UTC)
Thar commented on 2012-01-04 16:11 (UTC)
commented on 2011-09-01 18:20 (UTC)
commented on 2011-09-01 09:52 (UTC)
commented on 2011-08-31 11:37 (UTC)
commented on 2011-08-31 09:20 (UTC)
altkrall commented on 2011-07-31 16:03 (UTC)
commented on 2011-07-31 13:43 (UTC)
altkrall commented on 2011-07-31 12:36 (UTC)
altkrall commented on 2011-07-31 12:31 (UTC)
altkrall commented on 2011-07-30 09:51 (UTC)
cedeel commented on 2011-06-11 13:18 (UTC)
commented on 2011-04-19 07:50 (UTC)
commented on 2011-04-18 21:32 (UTC)
commented on 2011-04-18 20:28 (UTC)
commented on 2011-04-12 07:42 (UTC)
commented on 2011-04-10 12:52 (UTC)
commented on 2011-04-10 10:06 (UTC)
commented on 2011-04-10 09:46 (UTC)
commented on 2011-04-07 15:53 (UTC)
commented on 2011-04-07 15:00 (UTC)
commented on 2011-04-07 12:21 (UTC)
cedeel commented on 2011-02-23 11:45 (UTC)
commented on 2011-02-22 05:44 (UTC)
commented on 2011-02-22 01:22 (UTC)
commented on 2011-02-22 00:04 (UTC)
commented on 2011-02-20 23:09 (UTC)
commented on 2011-02-20 22:04 (UTC)
commented on 2010-12-13 15:36 (UTC)
falconindy commented on 2010-12-13 15:17 (UTC)
commented on 2010-11-27 13:42 (UTC)
commented on 2010-11-27 05:48 (UTC)
commented on 2010-11-27 00:18 (UTC)
rwd2 commented on 2010-11-23 23:33 (UTC)
rwd2 commented on 2010-11-23 23:16 (UTC)
commented on 2010-10-23 17:28 (UTC)
commented on 2010-10-21 15:31 (UTC)
commented on 2010-08-26 20:20 (UTC)