After reading this thread, and this thread:
https://community.acer.com/en/discussion/541950/acer-spin-5-booting-into-uefi-menu-is-broken/p2



jici79's answer:

The other thread: https://community.acer.com/en/discussion/541950/acer-spin-5-booting-into-uefi-menu-is-broken/p2
This thread: https://community.acer.com/en/discussion/538305/cant-access-uefi-after-installing-linux-dual-boot/p4


Since there are links in the other thread pointing to this thread, I thought I'd put this here


Again, even though I'm not OP, thank you everyone, you have solved more people's problems than just the OP's

Hi everyone, sorry for resurrecting an "old" topic but this is coming up in Google for people with the same problem.

I want to share how I fixed this and what I learned about the issue.

To summarise, The Acer firmware has a fault where the existence of certain entries in the UEFI boot list prevent the UEFI setup from loading, and it crashes on F2.  It doesn't interfere with actual booting, so if you have no reason to get back into the UEFI setup, well maybe you don't mind.  It also doesn't interfere with the F12 boot menu if that was enabled before this happened.

First, what you DON'T need to do:

- You don't need to reflash firmware.  Doing that carries inherent risk, and in this case isn't the cause of the issue.
- You don't need to disable secure boot.  In fact, the secure boot setting appears not to have any effect on my system, but perhaps that's because the UEFI already trusts the boot executables.  I'd like to think it's that, and not that Secure Boot simply doesn't work.  In any case, some of the below steps require secure boot to be ON, so I'd recommend leaving it on, unless you need to turn it off temporarily to boot your installation media.
- You may find instructions online for configuring your distro to place a boot entry into the *fallback* directory in your EFI partition.  This is designed to work around some buggy UEFI implementations, but is not a solution to this and isn't recommended here.

For me, it was Debian GNU/Linux that I was installing but this should be relevant for most Linux distros, indeed it appears that it's the boot entry that Grub-EFI inserts into the firmware that it has a problem with.  For other distros, where I refer to "debian" it will simply say something else instead.

After installation, you should notice that booting into the new system is successful, but loading UEFI setup on F2 fails (crashes with a cursor in the top left).

Steps to fix:

1. You need to get the UEFI boot entry out of the firmware.  You can do this in either of two ways. One is to temporarily remove vendor files in your EFI partition from a Live USB.  But, probably a better one is to use the *efibootmgr* tool in Linux to remove the boot entry, if only because it may prevent the need to boot to a Live USB:
2. Boot into your Linux install.  From a root prompt in the terminal window, run *efibootmgr -v* to list the install boot entries.
3. Note the number of the boot entry you want to delete.  It'll be the big long one that ends in something like *File(\EFI\debian\shimx64.efi)* where "debian" is the vendor of your Linux (eg it might be "Ubuntu", etc).
4. Delete that entry with *efibootmgr -b 0001 -B*  (where 0001 is the number of the boot entry from the previous step).
5. You may need to do the same if you have other Linux or grub related entries in there, but any generic looking entries are probably OK to leave, and entries that refer to Windows can also be left if Windows is still installed as well (you may have additional difficulties dual booting, but that's not relevant to this issue).
6. Reboot the system into the UEFI setup using F2.  It should work.  Now though your firmware won't know how to boot into Linux, but you can do the following:
7. Make sure secure boot is on, and go into the setting where you add a trusted executable to secure boot.  This will guide you through browsing your EFI partition, where you should navigate to HDD0 -> EFI -> debian -> shimx64.efi (or equivalent).  Note that on distros that use a shim bootloader (shimx64.efi) you may see multiple entries including a "grubx64.efi" as well, but in this case "shimx64.efi" is what you want.  If only grubx64.efi is listed, that's probably what you want, though I haven't tested on such a distro.
8. When prompted if you want to add a boot entry for this, select Yes.
9. Save settings and boot.  It should work.

If you're unable to get everything booting again after step 4, you can get back to where you were at the start using a Live USB, mounting everything in a chroot and running a grub reinstall (there are instructions for this online) but that just gets you back to where you were at the start and UEFI setup probably won't work again.

Due to messing around I ended up with some extra entries in the boot order, but that's ok because the one that works is there and is used first.  You can use efibootmgr to further clean up boot entries if you know what you're doing.

Note that the problem may re-appear if you ever need to do a "grub reinstall" in the future, though normal updates just to grub configuration or patches to grub *should* not affect it.

To be clear, there is nothing wrong with the boot entry that Debian or Grub added - the issue was that the Acer device's firmware doesn't seem to like it, not because they don't want you to use alternative OSes but they probably just didn't test it extensively with operating systems other than Windows.

Thanks PlanetMercury.  I've had a similar problem after installing Fedora32 alongside Windows and openSUSE Tumbleweed. Being introduced to efibootmgr was the key to solving my problem. See https://community.acer.com/en/discussion/comment/913757#Comment_913757