A solution needs a problem.
The problem here is the two ESP partitions on the disk, combined by a possible/probable UEFI variables reset, because of the hard shutdown.
Yes, but grub existed on some partition of some drive, as explained for OP.
Even if there is no efi file named after grub, it is common practice to copy the bootloader to the drive default efi path. Like systemd/bootctl does:
One of the two ESP partitions’ default efi path file, was a copy of some grub efi file.
I am sure that if you knew that, it would have been easier for you to decide the proper solution.
So, the solution is to know your system (because you are your system’s administrator ).
I wonder if you had tried UEFI Quick Boot menu and select other entries (like another drive).
Grub is just a , not a .
Bonus tip: When troubleshooting UEFI boot issues, this command would help
bootctl status --no-pager
I forgot:
Possibly a coincidence, or an undocumented bootctl feature. Man says:
–graceful
Ignore failure when the EFI System Partition cannot be found, when EFI variables cannot be written, or a different or newer boot loader is already installed. Currently only applies to is-installed, update, and random-seed verbs.
This is late, but since I came here and never marked anything as an answer:
The grub thing was indeed one of my drives: An old USB 16 GB drive with grub bootloader but no OS on it anymore: It’s on a tiny USB drive that looks like a wireless mouse dongle: Then I realized my newer wireless keyboard has a dongle, but it’s on a wire and is hidden behind one of my monitors!
Sorry for all of those who saw it as a big issue: It was more of a question for being such a mystery, it’s the other stuff that was going on making me think it had to do with the more important problems I mentioned. My BIOS reset itself due to the crash, once I told it which drive is the boot drive the grub screen never showed up anymore, and so I commenced to fix the other stuff.
).
, not a 
.