if [[ "$grub_type" == "EFI" ]] && [[ -e "/boot/grub/$efi_target/core.efi" ]] \
&& [[ -e "$efi_source_file" ]]; then
_grub_install="grub-install --no-nvram --target=$efi_target --efi-directory=$efi_directory \
--bootloader-id=$bootloader_id --recheck --force" && did_update=true
...
fi
if [[ -z "$_grub_install" ]]; then
echo "WARNING: Grub is not properly installed, system may not be bootable or other bootloader is used" >&2
exit 1
fi
It boils down to the existence of $efi_source_file, which is in your case /efi/EFI/Manjaro/grubx64.efi. So how is your special setup of your grub install made? Maybe give me a tree output of your files related to EFI to understand more. On my end it works.
Hmm, so it is mounted and not a normal folder. Odd. Can you modify the script based on install-grub ($976) · Snippets · GitLab to be more verbose like this:
for path in /boot /efi; do
if [[ -e $path ]]; then
efi_directory="$(find $path -name $efi_grub_file | awk -F '/EFI' '{print $1}')"
echo "EFI Dir: $efi_directory"
tree "$efi_directory"
if [[ ! -z "$efi_directory" ]]; then
efi_source_file="$(find $efi_directory/EFI/$bootloader_id -name $efi_grub_file)"
efi_target_file="$(find $path -name $efi_boot_file)"
echo "Source: $efi_source_file"
echo "Target: $efi_target_file"
if [[ -e "$efi_source_file" ]] && [[ -e "$efi_target_file" ]]; then
echo "Execute cmp"
cmp -s "$efi_source_file" "$efi_target_file" && fallback_is_same=true
fi
break
fi
fi
done
Some is there with mounting the ESP somehow. cmp has an error with it and more or less we have -e vs -f:
-eFILE - True if the FILE exists and is a file, regardless of type (node, directory, socket, etc.).
-fFILE - True if the FILE exists and is a regular file (not a directory or device).
$ sudo install-grub4
EFI Dir:
/usr/bin/install-grub4: line 90: tree: command not found
EFI Dir: /efi
/efi
/usr/bin/install-grub4: line 90: tree: command not found
Source: /efi/EFI/Manjaro/grubx64.efi
/efi/EFI/OLDGRUB/grubx64.efi
/efi/EFI/Manjaro/grubx64.efi
Target: /efi/EFI/Boot/bootx64.efi
WARNING: Grub is not properly installed, system may not be bootable or other bootloader is used
I did not have tree installed.
I went ahead and added it, which resulted in
$ sudo install-grub4
EFI Dir:
[error opening dir]
0 directories, 0 files
EFI Dir: /efi
/efi
/efi\012/efi [error opening dir]
0 directories, 0 files
Source: /efi/EFI/Manjaro/grubx64.efi
/efi/EFI/OLDGRUB/grubx64.efi
/efi/EFI/Manjaro/grubx64.efi
Target: /efi/EFI/Boot/bootx64.efi
WARNING: Grub is not properly installed, system may not be bootable or other bootloader is used
… I then realized that maybe the OLDGRUB directory (temporary and from an accidental install command earlier)
for path in /boot /efi; do
if [[ -e $path ]]; then
efi_directory="$(find $path -name $efi_grub_file | awk -F '/EFI' '{print $1}')"
if [[ ! -z "$efi_directory" ]]; then
efi_source_file="$efi_directory/EFI/$bootloader_id/$efi_grub_file"
efi_target_file="$(find $path -name $efi_boot_file)"
if [[ -e "$efi_source_file" ]] && [[ -e "$efi_target_file" ]]; then
cmp -s "$efi_source_file" "$efi_target_file" && fallback_is_same=true
fi
break
fi
fi
done
We need to make the efi_grub_file specific but still search for the backup file
$ sudo install-grub4
Grub will be installed on: EFI
Installing for x86_64-efi platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-linux-amd-znver3
Found initrd image: /boot/amd-ucode.img /boot/initramfs-linux-amd-znver3.img
Found initrd fallback image: /boot/initramfs-linux-amd-znver3-fallback.img
Found linux image: /boot/vmlinuz-6.1-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-6.1-x86_64.img
Found initrd fallback image: /boot/initramfs-6.1-x86_64-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
Found memtest86+ EFI image: /boot/memtest86+/memtest.efi
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
Adding reboot option.
Adding poweroff option.
done
I just created an OLDGRUB folder with some grub file in it and failed. Have to debug more.
it will find both files and errors out. We need to specify the folder of the wanted only:
sudo sh ./install-grub
EFI_DIR: !/boot/efi/EFI/Manjaro/grubx64.efi
/boot/efi/EFI/OLDGRUB/grubx64.efi!
Source: !/boot/efi/EFI/Manjaro/grubx64.efi
/boot/efi/EFI/OLDGRUB/grubx64.efi/EFI/Manjaro/grubx64.efi!
Target: !/boot/efi/EFI/boot/bootx64.efi!
WARNING: Grub is not properly installed, system may not be bootable or other bootloader is used
Hmm, seems this warning has something to do with adding the memtest option to the grub menu and it is fine to ignore. Can be ignored or “solved” by uninstalling memtest packages or getting rid of /etc/grub.d/60_memtest86+.
If I read those checks properly, this only results in a warning, and proceeds to overwrite an existing boot file in the fallback location, regardless. It’s something, I suppose; and I appreciate the complication involved in trying to achieve much more than that.
Perhaps something could be added to the relevant Wiki pages for the sake of those who actually read them. For those who don’t, the forthcoming BSOD might be a consideration. Only half-joking.
With respect rEFInd, reinstalling usually resolves the scenario previously mentioned. Even if it has been previously relocated to the fallback location, rEFInd successfully checks for, and remedies the situation by replacing the fallback Grub boot file.
I do not think the purpose of this project should be to cover all scenarios, including a very broken system without ESP, kernel, and so on. It should be a hook at grub update, then assuming a working system detecting where the bootloader is and updating it or throwing an error as is now.
I thought that was exactly what it was supposed to be, because experienced users knows where the stuff is anyway and most likely wont use this.
If not, you are correct.
Since it involves other distros in the checking, I would assume it could be a great feature if it also checks fstab.
How will it handle a live environment?
If you chroot, and the boot is for some reason not getting mounted correctly/not there, what would happen?
A fstab check would fix that, at least the path. Assuming the fstab is not the REASON for the fail, but then find might figure it out instead.
IDK, I feel like it could be done if done cleverly.
cat /etc/fstab | grep 'boot' | awk '{print $2}'
Edit
Wait, that won’t work with cscs setup, hmmm.
But then again the find would fix it in that case…
I feel the idea is there, execution, not so much.
