8 posts were split to a new topic: How can I install budgie-SOLUS and create new MBR?
Interesting so I always half-updated grub because I never overwrote the UEFI fallback file. Because I did not know that this is also necessary. I’m using LUKS2 and after reading an error that can occur with it I’m glad I haven’t tried it yet. 
This script is designed to only alter grub installs made with Calamares during installation of Manjaro. It has several checks. Bootloader-ID gets read out from /etc/default/grub to find the right install of Grub. You can have several ones. Fallback only gets overwritten when it was part of the Manjaro installation.
2 Likes
The correct way to fix this is to add (with KDE partition manager of GParted) the boot flag to the partition mounted as /boot/efi
You currently have the bios_grub flag, which doesn’t make sense.
Note that these two flags don’t matter for GRUB to boot the system.
I am puzzled on how did you know this!
Anyway, I did this, then run again install-grub and the partition went back to the bios_grub flag. So it was not manually changed by mistake.
I must apply my solution each time the script gets upgraded, but I know already how to solve it for me.
Really you should have the esp flag if its an ESP.
In my case I have boot and esp
(and in my case its mounted at /efi)
And I do not need to set the flags again after using this script (or doing anything else).
1 Like
@Lycan Lycan, it seems you are in some rare edge-case which is not yet detected by the automatic safety checks in the script, since this should not happen. Since this is just an automation/convenience script and is not really obligatory for a functioning system, i would uninstall it, if i were you. Once every few years, if the 2 parts of grub become incompatible with each other after some updates, you will have to manually reinstall grub if it stops booting. That is all the script does/automates.
My system was installed in 2019, I have never reinstalled. I have passed from stable to unstable to testing thorough the years. I tried making some Bluetooth driver for my BT controller, but I gave up after many kernel panics, that I have always recovered using Timeshift. This history may be relevant or not, I think it is. Anyway, my original partitions and system structure haven’t changed at all. I tried to be as mainline as possible. So, I don’t know when my system deviated from mainline.
Not sure what have caused the wrong flags. Could be many things. For example a bios update, that has reset the bios settings back to csm instead of uefi, and you have not noticed. No idea.
For a while install-grub has produced a seemingly incorrect/superficial error.
[...]
done
Warning: GRUB bootloader at /efi/EFI/Manjaro was updated,
but it seems like you are not using it by default.
Please check your EFI boot priorities!
The boot order is fine, the ESP is fine, grub is correctly updated, etc.
Ive even deleted and re-added the entries through efibootmgr and so forth.
Yet this warning is always printed.
Did you check that the efi boot file in the fallback location in fact matches that of Manjaro’s?
If I recall, install-grub will not replace the boot file in the fallback location if it differs; whether due to damage or intent; perhaps this might trigger the message. 
It comes from the very end of the script;
if [[ "$grub_type" == "EFI" ]] && [[ "${current_boot_entry,,}" != "${bootloader_id,,}" ]] \
&& [[ "$failed_update" == "false" ]]; then
echo "Warning: GRUB bootloader at $(dirname $efi_source_file) was updated,
but it seems like you are not using it by default.
Please check your EFI boot priorities!"
fi
And… I figured it out.
bootloader_id is equal to GRUB_DISTRIBUTOR which is in /etc/default/grub as Manjaro.
While the current_boot_entry is defined in the script as efibootmgr | awk 'match($0,/^BootCurrent: ([0-9a-fA-F]{4})$/,out) { current=out[1] } match($0,/^Boot([0-9a-fA-F]{4})\*? ([^:]+)\t/,out) { if (out[1]==current) print out[2] }' (or the EFI label) which is Grub - as its a bit silly to label the entry ‘Manjaro’ when it is in fact Grub and from there can boot multiple OSs.
Anyhoo. Thats why. I could circumvent this a few ways.
But apparently not by changing GRUB_DISTRIBUTOR to Grub - as install-grub immediately fails out if it is not Manjaro. So it may appear that the only solution would be to change to the incorrect efi label or to simply live with the incorrect error. 
And as bootloader_id also defines the directory containing Manjaro’s efi files; which also differentiates it from other distributions potentially installed (multi-boot); living with it works for me.
Either that, or changing the wording to something like;
"Warning: GRUB bootloader at $(dirname $efi_source_file) was updated. If you are not using this instance of GRUB by default, please check your EFI boot priorities!"
15 posts were split to a new topic: Questions about the install-gub script
It’s been installed for a long time, and I forgot, So, yeah, no problems.
Big thanks to whoever wrote install-grub. It would be useful for less knowledgeable users to know for certain whether they should install & run this script before or after the update.
It seemed logical to me to run it before the update, which I did & thankfully it worked out.
Thanks for another great update.
Is has a hook and runs automatically after update, actually.
2 Likes
@philm could it be possible to get the install-grub fixed as below? (Can’t log into gitlab.manjaro.org to post issue there.)
$diff /usr/bin/install-grub install-grub-fixed
127c127
< efi_target_file="$(find $path -name $efi_boot_file)"
---
> efi_target_file="$(find $path -iname $efi_boot_file)"
because for some reason install-grub doesn’t do it’s job correctly without the extra i there and I have to manually fix the issue as this:
$ l /boot/efi/EFI/BOOT/BOOTX64.EFI
.rwxr-xr-x 139264 root 7 jaan 20:31 /boot/efi/EFI/BOOT/BOOTX64.EFI
$ l /boot/efi/EFI/Manjaro/grubx64.efi
.rwxr-xr-x 151552 root 13 apr 18:17 /boot/efi/EFI/Manjaro/grubx64.efi
as we can see, they get de-synced as the script is now.
So I need to manually fix it every time I need them to be in sync… although I have the install-grub package installed… and hooked etc.
$ sudo grub-install --removable
[sudo] password for deemon:
Installing for x86_64-efi platform.
Installation finished. No error reported.
$ l /boot/efi/EFI/Manjaro/grubx64.efi
.rwxr-xr-x 151552 root 13 apr 18:17 /boot/efi/EFI/Manjaro/grubx64.efi
$ l /boot/efi/EFI/BOOT/BOOTX64.EFI
.rwxr-xr-x 151552 root 23 apr 09:43 /boot/efi/EFI/BOOT/BOOTX64.EFI
(or patch the /usr/bin/install-grub after every update to it.)
For me personally /boot/efi/EFI/BOOT/BOOTX64.EFI is more important, because the boot entry for Manjaro in UEFI gets wiped every time with motherboard firmware/UEFI update (OR you put your Manjaro disk to entirely new/different computer, because uefi boot parameters are written into UEFI cmos or rom something, not to disk, so they stay with the old motherboard), and all is left is the default… which needs to be up to date for it to work or you get boot problems and need to fix installation with installer media… which could be avoided if they stayed in sync (or Manjaro used default /boot/efi/EFI/BOOT/BOOTX64.EFI instead of insisting creating it’s own duplicate entry for no apparent reason). Which they don’t. Because your script searches for efi_boot_file="bootx64.efi" but the grub-install installs BOOTX64.EFI (because case insensitive vfat partition or something else) and they don’t match with find -name, so your script thinks, it doesn’t exist, so it doesn’t update the actually existing /boot/efi/EFI/BOOT/BOOTX64.EFI.
4 Likes