Patching is not an option it was changed upstream to this.

Then I would recommend either an announcement on the archlinux site to ensure more users aren't victim to this, or a patch to inform efibootmgr to change the name of the refind binary (if it isn't correct) to the new upstream version.

I wrote a preliminary patch for the error in bash. It contains two functions : update-efi-dir (which will update the efi directory information) and update-efi-nvram (which runs efibootmgr to update the nvram. The directory for refind can be set in the script via $efi_dir (in the main function).
Currently update-efi-nvram is disabled (must be called by user) since it still lacks support for detecting which boot entries are in the nvram. Specifically, one should be able to run `sudo efibootmgr | <some function>` and that will report if the updated binary is the same as the one recorded in nvram. It would run the function update-efi-nvram if it is not. Unfortunately, due to the numerous backslashes needed for efibootmgr, awk and grep didn't work for me for parsing out that information.

For that patch, it should be run after each refind package upgrade.

Updated the patch to correct some broken comments.

Just adding a post_install message about the file rename and the need to create a new efibootmgr entry should be sufficient. Although I appreciate your work on the patch, there is no need to have complex scripts for this. Some cases are best handled manually by the user.

And I don't think the users will have to efibootmgr new name as the refindx64.efi or refind_x64.efi file in EFISYS partition is managed by the user. Only the pkg installed binary file at /usr/lib/refind/refindx64.efi has been renamed. The user can always copy it to (EFISYS)/EFI/refind/refindx64.efi if (s)he wishes, in which case there is no need to run efibootmgr again as the old boot entry should work. Even if the pkg is removed only the files in /usr/{lib,share}/refind/ should be removed and not the files (EFISYS)/EFI/refind .

I am still using /boot/efi/EFI/refind/refindx64.efi , and not /boot/efi/EFI/refind/refind_x64.efi . FWIW you can even copy the file to /boot/efi/EFI/sjhdv/svhs.efi , and still refind will boot fine if you have created a efibootmgr entry for that file path. The path name refindx64.efi or refind_x64.efi filename is not hard-coded anywhere in the upstream sources in a way that affects rEFInd at runtime. Only the Makefiles use this filename.

That's excellent and all. But I think it's difficult to catch the small messages of refind when undergoing a pacman -Syu update (a lot of packages have their own messages). For users of arch linux and refind, the last name change would require arch users to boot into a usb stick to edit their EFI files, which seemed critical to me.

I have finished the patch, and it should now selectively edit the nvram.
This script has the added benefit of making future refind installations easier since it:
1) moves refind binaries into the directory suggested by the arch wiki and the refind developer
2) will update nvram and refind binary if the refind developer ever chooses to change the name of the binary again.

Yes, that is true. But, that causes the users refind binaries to look different in installation from the developer's versions.

@bluerider: "the users refind binaries to look different in installation from the developer's versions" doesn't matter. It is up to the user where to place and what filename to use for rEFInd binary in the EFISYS partition. I can always use (EFISYS)/EFI/Keshav/Keshav.efi and rEFInd will work just fine, provided I also have (EFISYS)/EFI/Keshav/refind.conf , otherwise only the upstream default config will be used.

That is true. But, I argue the severity of the consequences of screwing up this file transfer means the system won't boot up refind. Technically users are allowed to install files anywhere within a Linux file system, but for stability & compatibility reasons, we place them in specific directories. In this case the direction is \EFI\refind (or /boot/efi/EFI/refind).

Wouldn't a symlink help too?
Then no need to add install message and all is fine for new installations.

A symlink would generate multiple .efi applications. I haven't tested it yet, but this may cause multiple entries in the refind bootmenu (since it autodetects .efi applications).

In addition, if the developer chooses to change the name again, my patch will protect arch users from that situation since it dynamically updates the nvram.

I have also updated the patch to fix a critical error involving EFI variables, $boot_entry was set after `sudo modprobe efivars` which caused boot_entry to always be empty. That is now fixed.

I updated the patch to get rid of the directory limitation (refind diretory has to be a directory in /boot/efi/EFI).

I've also generated some systemd service files so that the patch will run everytime refind is updated.

Problem is, that there is no "one default" way for user to organise their efi binaries and how they are installed / updated. Some users may use the default EFI/boot/bootx64.efi path instead of a custom refind(_)x64.efi. Your patch is assuming there is a default method, that it is yours, and that is the best way. I prefer to update my refind binary manually, so this would be very annoying for me if installed by default.

The arch wiki recommends a particular way (and that's the way most users would follow). If you would like to change the directory listing in my patch, you would just change "$refind_dir" in the patch. The patch is soft coded to be somewhat flexible (originally for debugging purposes).

Your stuff is fine, but it's not upstream and so it will not make it's way into the package.
You need to add your scripts to the wiki instead.
I cannot test your things at all. I only ship the package as Rod Smith told me.

Added new install text to 0.6.5, is this now enough to close this task?

I have updated the wiki accordingly. I run the files on my own system. If the arch maintainers believe it is best for users to manually update the refind binaries and nvram (by default), then they should at least be pointed to the wiki for an automatic method. They don't need to use my method, I just feel it's very inconvenient (and potentially dangerous). In that case, close the bug if this will be the arch stance.