I’d like to know if the install-grub script is mandatory, or if it can be skipped.
The name is too confusing, especially compared to grub-install.
Also, it’s not possible to choose the directory where grubx64.efi will be installed — it is always derived from GRUB_DISTRIBUTOR in /etc/default/grub. This can cause issues in multi-boot setups with several Manjaro-based distributions.
I also ran into problems with this script in a chrooted Manjaro system — it refused to create the /boot/efi/EFI/Manjaro directory (which didn’t exist). I had to manually change GRUB_DISTRIBUTOR to make it work.
If I don’t want to use this script, will reinstalling GRUB using the standard grub-install ... command do the same job?
It’s not mandatory. If it was, then it would have been pushed onto your system.
Not quite, because grubx64.efi will always reside in /boot/efi/EFI/manjaro. Other distributions will use another directory.
The only file that always gets put in the same location is /boot/efi/EFI/boot/bootx64.efi. Of course, what this file is, is another matter. The install-grub script makes sure that it is an identical copy of /boot/efi/EFI/manjaro/grubx64.efi, but if you dual-boot with MS-Glassware, then that will always make sure that it’s a copy of its own boot loader.
Yes, but in order to have /boot/efi/EFI/boot/bootx64.efi and /boot/efi/EFI/manjaro/grubx64.efi be identical, you would need to run grub-install with the --removable option. Otherwise it won’t update /boot/efi/EFI/boot/bootx64.efi.
Um, yes you can. Things may be different in installations from recent ISOs, but here on my system, it’s explicitly installed — as the matter of fact, I installed it only a few weeks ago — and it’s only an optional dependency of grub.
I advise against it - as I said - when grub is updated - the hook ensures the grub EFI stubs is synced.
Technically you can remove it - but it is short sighted and may create other issues given time - the update hook will fail silently - but if you system’s main entry point is pointing the default EFI/boot/bootx64.efi then the existing grub.cfg will not match that entry - and you get a shim_lock error.
This can happen - and it does - especially after a firmware update - where the EFI entries has been replaced - and therefore the firmware looks for the default.
But that is only applicable when using Secure Boot, which Manjaro does not support.
Everyone who chooses to use Secure Boot will have to assume the responsibility to make sure that their boot loader continues working properly after a system update.
You may get the shim_lock error anyhow - even if Secure Boot is not enabled - I tried it recently - on my workstation - which does not use secure boot.
As I said, I have only recently installed the install-grub script, and I have had it happen that /boot/efi/EFI/boot/bootx64.efi and /boot/efi/EFI/manjaro/grubx64.efi were different — which is why I chose to install the script in the first place, because it’s easier than comparing the two files by hand and then manually correcting the discrepancy — but I have never seen that error here on my system in the 6+ years that I’ve been running Manjaro.
That’s a difficult situation to verify, given that you and Phil took the discussion onto a third-party communications platform — Matrix.
What we discussed on Matrix was the question - if there was something the script was missing - not the issue itself - the issue and the solution is documented in the unstable July update thread.
Anyway, the bottom line is that install-grub is not mandatory and can be removed — which is what the OP was asking about, even though I do not understand why he’d want to remove it — but it is advised to keep it installed nevertheless.
I also got a shim lock error yesterday, even though Secure Boot has never been enabled on my system. The exact error message i got at boot is : error: symbol 'grub_is_shim_lock_enabled' not found
I got this error on a secondary Manjaro on my system, it’s not my main system. I access it through GRUB by adding a manual entry in /etc/grub.d/40_custom.
I tried reinstalling GRUB several times from a chroot environment (i mean the secondary GRUB, not the main one), but I was never able to boot into it successfully.
What finally fixed the issue was switching this secondary Manjaro to the testing branch — just like my main Manjaro system, which is also on the testing branch.
That may be a different issue altogether, as the grub of your initial Testing installation may have been of a later version than the one from the Stable installation, and so grub-install may have refused to overwrite a newer version of the EFI stub.
Exactly - the error message is kind’a misleading - one immediately think secure boot - while it is the efi-stubs which is out of sync and the grub.cfg cannot be understood by the efi stub reading it.
That scenario is what install-grub intends to work around.
When you have two Manjaro systems on different branches; you will have different grub packages; and the one on stable may not reflect the changes to install-grub; because they are not available on stable branch yet; this may have caused the two efi-stubs to be different;
I agree, here is the reason : I have 2 hdds, the main one with Manjaro, with its own efi partition. And a second hdd (it was my previous Manjaro system on a SATA hdd), with also it’s own efi partition. I wanted to keep it, so i made it accessible with a custom /etc/grub.d/custom_40
if [ "$grub_platform" = "efi" ]; then
menuentry 'Manjaro XFCE' {
insmod gzio
insmod part_gpt
insmod btrfs
insmod ext2
rmmod tpm
set root='hd0,gpt6'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt6 --hint-efi=hd0,gpt6 --hint-baremetal=ahci0,gpt6 70853cef-788d-4beb-9c26-56f4fd32adc2
else
search --no-floppy --fs-uuid --set=root 70853cef-788d-4beb-9c26-56f4fd32adc2
fi
set prefix="/@/boot/grub"
configfile "${prefix}/grub.cfg"
}
fi
And the same command on my secondary hdd (the SATA one), the one i repaired yesterday:
sudo mount -o subvol=@ /dev/sda6 /mnt/manjaroXFCE
sudo mount /dev/sda2 /mnt/manjaroXFCE/boot/efi
sudo tree /mnt/manjaroXFCE/boot/efi/EFI
├── BOOT
│ └── bootx64.efi
├── manjaro
│ └── grubx64.efi
What I said before in my first post — as you can see here — is that I had to change GRUB_DISTRIBUTOR from Manjaro to manjaro. Otherwise, install-grub wouldn’t work; the error I got was it couldn’t create a Manjaro directory.
install-grub - Manjaro maintenance script (like update-grub originates from Ubuntu)
That is likely because the nvram entry would collide with the existing entry.
The Manjaro install-grub script - in the latest version - will create an nvram entry only if one does not exist - thus avoiding that problem altogether.
