refind lists "ghost" GRUB entry

[whatever]

Some time ago I wiped the entire disk and installed windows and then arch with grub because I didn't care what piece of bytes points to the linux kernel until I saw a themed refind menu.
Removing package and boot entry via efibootmgr suprisingly wasn't enough, refind listed and even correctly booted to fully operating grub. Then I remembered that for correct dual boot where linux goes on top of windows, I had to execute bcdedit /set {efibootmgr} path \EFI\GRUB\whatever.efi. I reverted the changes and now windows boot loader recovers windows boot manager instead of grub when deleting corresponding boot entry. Still the same. I pulled out my infinity gauntlet and simply rm -rfed everything that contained 'grub' in /boot and /efi. Refind relentlessly shows grub boot entry, but now it is broken at least. I know that I could just hide this entry but pressing minus and delete did nothing.
Both efibootmgr and bcdedit don't have a damn clue about any grub, showing just WBM and refind.

efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0000
Boot0000  Windows Boot Manager  HD(1,GPT,61239d2e-7488-4f0d-b524-e40059eb8045,0x800,0xee000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...t............. ...
Boot0001* rEFInd Boot Manager   HD(1,GPT,61239d2e-7488-4f0d-b524-e40059eb8045,0x800,0xee000)/File(\EFI\refind\refind_x64.efi)

[Roderick W. Smith]

rEFInd scans for boot loaders when it starts, so chances are the "ghost" entry you're seeing is a real boot loader program that still exists on your ESP, or conceivably on another partition. GRUB normally resides in a subdirectory of the EFI directory, named after the distribution, on the ESP -- for instance, EFI/ubuntu for Ubuntu's GRUB. Try looking there for the offending program.

It's also possible that the offending program exists on another partition entirely. For instance, if you created (intentionally or not) two ESPs, rEFInd will scan both of them. Thus, the program might exist on a partition other than the ESP on which rEFInd resides.

Note that rEFInd will tell you where the file is in text under the icons when you highlight the menu entry. It displays both the filename (with path) and a volume name or description.

There's a slim chance that rEFInd is showing an entry defined as a manual boot stanza in refind.conf; however, none are active by default. Thus, if this was the cause, you would probably remember having set up the entry.

[mcloaked]

I have just come across a problem booting the 5.7.2 kernel - with my
pre-existing configs for refind it did not boot but gave a screen with the
message:

EFI stub: ERROR: failed to open file /boot/intel-ucode.img
Error: Not Found returned from vmlinuz-linux

After some research I discovered that the problem arose because of the use
of forward slashes in the refind_linux.conf file as well as in refind.conf
- with lines in the refind_linux.conf such as

"Boot with defaults" "root=PARTUUID=850c708f-e49d-4644-b2a5-2e7f2e4f179a rw
initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img
rootfstype=ext4 systemd.unit=graphical.target"

needing to be changed to

"Boot with defaults" "root=PARTUUID=850c708f-e49d-4644-b2a5-2e7f2e4f179a rw
initrd=boot\intel-ucode.img initrd=boot\initramfs-linux.img rootfstype=ext4
systemd.unit=graphical.target"

and the menuentry stanza in refind.conf with an options line:
options "rw root=UUID=7ca56a4d-53d8-4b15-9d31-b303b2e50061
PARTUUID=850c708f-e49d-4644-b2a5-2e7f2e4f179a initrd=/boot/intel-ucod
e.img quiet"
changed to:
options "rw root=UUID=7ca56a4d-53d8-4b15-9d31-b303b2e50061
PARTUUID=850c708f-e49d-4644-b2a5-2e7f2e4f179a initrd=boot\intel-ucod
e.img quiet"

After those changes then it would boot the efitub kernel version 5.7.2 in
arch linux. Fortunately I had previously set up a submenu section to boot
grub as a fallback and this allowed me to boot the system and makes the
necessary config changes and then reboot. However it came as something of
a shock to have the system non-bootable after many years of having no
problem at all booting with refind. I did note that in the run up to the
release of the 5.7.2 kernel there were some comments and commites in lkml
concerning efi stub! Is it worth changing the relevant section in
https://www.rodsbooks.com/refind/configfile.html where it mentions:
"complete EFI path to the initrd file with this option, as in initrd
EFI/linux/initrd-3.3.0-rc7.img." and uses forward slashes as the example.

--
mike c

[mcloaked]

It would seem that the use of the initrd kernel parameter passed for boot
is now deprecated is in the commit at:
https://github.com/torvalds/linux/commit/cf6b83664895a5c7e97710df282e220bd047f0f5

where it says: "Loading an initrd passed via the kernel command line is
deprecated: it
is limited to files that reside in the same volume as the one the kernel
itself was loaded from, and we have more flexible ways to achieve the
same. So make it configurable so new architectures can decide not to
enable it."

How does this impact the use of refind? Will refind need to change to
accommodate this and if we are long standing users of refind to boot our
machines will we need to change any of the config files?

--
mike c