Yes, but not all UNIX tools for searching a matching filename are case-insensitive. The clue is in how they handle their command-line arguments before searching the filesystem(s).
GNU find may be one of those finicky tools.
# find /boot/efi -iwholename "*BooT/BooTx64.efi"
/boot/efi/EFI/boot/bootx64.efi
From the man page… 
-ipath pattern
Like -path. but the match is case insensitive.
-iregex pattern
Like -regex, but the match is case insensitive.
-iwholename pattern
See -ipath. This alternative is less portable than -ipath.
Like I said, it’s finicky. You have to explicitly tell it to ignore the case. This is irrelevant with regard to whether the filesystem is case-sensitive or not, because it’s in how the find command itself interprets the string passed to it as an argument. 
Yes - and the script does exactly that - which is why the comment on the case sensitivity is null and void.
1 Like
If I am looking at the correct script, one use of find does use -iwholename (which ignores case) but one uses -name, which does not ignore the case (even for FAT32). I have not studied the script enough to know if it matters:
efi_target_file="$(find $path -name $efi_boot_file)"
~ > sudo find /boot/efi -iwholename '*Bootx64.efi' INT
/boot/efi/EFI/boot/bootx64.efi
~ > sudo find /boot/efi -name '*Bootx64.efi'
~ >
3 Likes
I am not the author of the script - but I do see your point - better ask the author @philm.
It could pose an issue when searching for the fallback entry uses -name instead of -iname but only if the fallback boot64.efi has been replaced by e.g. Windows BOOTX64.EFI.
1 Like
$ tree /boot/efi
/boot/efi
└── EFI
├── BOOT
│ └── BOOTX64.EFI
├── boot.7z
├── Manjaro
│ └── grubx64.efi
└── MemTest86-20221226-023337.log
4 directories, 4 files
only ever installed Manjaro and Manjaro installed grub (since 2019). Couple of times done system rescue / grub re-install with Manjaro boot media, because the boot was unupdated and unbootable after motherboard firmware update (or actual motherboard change) and back then didn’t know what caused this.
No Windows ever in this computer. Only Manjaro did this. Manjaro installed the first caps lock /boot/efi/EFI/BOOT/BOOTX64.EFI in 2019. I think the file name case sticks no matter how many times you overwrite it, unless you delete it first and then write new lowercase filename file.
When I installed Manjaro on this desktop in December 2024, it did this:
/boot/efi
├── EFI
│ ├── Boot
│ │ └── bootx64.efi
│ ├── Manjaro
│ │ └── grubx64.efi
│ └── Microsoft
│ ├── Boot
So far I’ve updated the bios several times since (yes there’s been frequent bios updates), I guess it depends on the vendor (Asus if anyone is wondering) whether or not it messes with efi entries (I’ve been lucky I guess that I’ve had no problems).
(*I excluded all files listed under Microsoft)
Yes, vfat has support for case retention, but of course, case retention is not case-sensitivity.
The case-sensitivity in this, um, case, comes from the way UNIX tools parse their command-line arguments.
2 Likes
Still a bit confused how this should work…
if [[ -e "$efi_source_file" ]] && [[ -e "$efi_target_file" ]]; then
cmp -s "$efi_source_file" "$efi_target_file" && fallback_is_same=true
$debug && [[ "$fallback_is_same" == "true" ]] && \
echo "[D] EFI Fallback matches EFI Bootloader"
fi
I assumed, that if before upgrading/installing new grub, it checks, if “Manjaro” and “fallback” are in sync and tries to keep it that way => sets fallback_is_same=true. Correct?
but then…
if [[ "$grub_type" == "EFI" ]] && [[ -e "$efi_source_file" ]] && [[ -e "$efi_target_file" ]] \
&& [[ "$fallback_is_same" == "false" ]] && [[ "$failed_update" == "false" ]]; then
echo "Update UEFI Fallback file: $efi_source_file"
$interactive && yes_no
cp "$efi_source_file" "$efi_target_file"
fi
Now after the upgrade, it should keep them still in sync via cp "$efi_source_file" "$efi_target_file". Correct?
But on this case, why the if there checks if [[ "$fallback_is_same" == "false" ]] and not [[ "$fallback_is_same" == "true" ]] ? I mean right now it tries to overwrite the fallback when originally they were out of sync? And once they become in sync, then the second time it will not keep them in sync … and then 3rd time (because now they are again out of sync) it will sync them again?
So it’s starts to flip-flop the sync… every second time?
(
and if you are like me, who wanted them to be always in sync, and created the config file:
cat /etc/install-grub.conf
interactive=false
debug=true
fallback_is_same=true
it now never syncs them, because now for the syncing to happen, the fallback_is_same variable needs to stay false, but because of the config overwrite, this never happens? and files are out of sync, variable is true = “in sync”, and real file syncing never happens…
)
Am i missing something here? 
Recently GRUB no longer asks me to hit enter after not finding the boot-USB that I sometimes use for Tails. Assume this changed when I updated my kernel.