UEFI startup randomly gets longer

Question

My startup is randomly getting very long at the UEFI screen (the one with the motherboard logo and the shortcut list : F2 for BIOS, F11 for Boot list ...). For like ~30seconds my keyboard is unresponsive and if I want to go to the UEFI I have to begin pressing F2 after those 30seconds have passed.

I say it is random but this bug seems to occur when I do operations on a USB drive such as burning an .iso on it or rewriting its partition table, it happened to me while modifying partition tables on both window and linux. I say it is random because it happened to me last night and the problem would stay even after reboots or shutdowns. Then I went to sleep and the next day the problem had disappeared. Now it happened to me again but I won't go off despite prolonged shutdons. I can fix it by clearing CMOS but I'm tired of clearing CMOS every time it happens because then I have to reconfigure the motherboard. CSM is disabled.

Is there a known bug that has such symptoms on UEFI motherboards, some kind of VRAM bug or something ? (I have an Asrock fatality x99x killer 3.1)

Edit : nvm just shuting down the power switch is sufficient to fix the problem, no need to reset CSMOS, still any idea on what is happening ?

Edit : Happened again when I tried to boot ubuntu live USB except it is stuck on the black screen with the message Ignoring BGRT: invalid status 0 (expected 1) I left it for 1min and did that. Had to shutdown power to restore it.

Answer 1

A number of possibilities occur to me:

• Firmware bug -- A firmware bug could be causing a slowdown. In this case, updating your firmware (what the manufacturer probably calls a "BIOS") might fix the problem. Although a firmware update is always at least a little risky, I'd try this first, or at least early, since it strikes me as one of the more likely causes of the problem.
• Firmware settings -- A firmware setting might be triggering the problem. If so, this is likely something of a special case of the "firmware bug" possibility; but in this case, changing the setting might work around the problem even if a bug fix isn't available. I can't be more specific about this possibility, but you may want to go in and start playing with firmware options. Be aware, though, that some settings can cause even worse problems, so if you're not used to mucking with firmware settings, you should be cautious or get help from a friend who understands such things. If you've already modified your settings in an effort to overclock or otherwise optimize your setup, it's conceivable that you've stumbled across a bad combination. In this case, resetting to the system defaults might be the best option.
• Garbage collection -- EFIs store data in NVRAM, and as NVRAM contents change, they must periodically clean that up. This process is called "garbage collection," and it can take a few seconds to complete. Ordinarily, you'll see garbage collection only once in a while; however, if the firmware has a bug, it may be doing this more often, or if something is storing data unnecessarily in NVRAM, that could be triggering too-frequent garbage collection. If the problem occurs more frequently after rebooting from one OS than from the other, you might look into the OS that triggers the problem for EFI-aware tools that might be writing data into NVRAM. It could also be that an EFI application (like a third-party boot loader or other pre-boot application) is writing to NVRAM and therefore triggering garbage collection. These would all be fairly non-standard tools, so you'd probably be aware if you'd installed them. One specific issue related to this may be a growing boot options list. This would be revealed by efibootmgr in Linux or via a tool like EasyUEFI in Windows. I've heard of bugs in the Fedora/Red Hat boot loader stack that can cause the boot list to grow with duplicate entries with every boot.
• Damaged filesystem or partition table -- It's conceivable that a damaged filesystem or partition table is causing problems. Most EFIs can read nothing but FAT, so you might try backing up all your FAT filesystems, re-creating them (with mkdosfs in Linux, for instance), and restoring your data. This may require modifying /etc/fstab or other configuration files that refer to filesystems by their serial numbers (dubiously called "UUIDs" in some Linux tools). Likewise, a damaged partition table could conceivably cause problems. Check this with the v option in gdisk; if it reports problems, you may need to repair them.
• Defective device -- A hardware device (built into the motherboard, plugged into the motherboard, or plugged into a USB port) could conceivably cause a slowdown. If possible, I'd strip the system down to the bare minimum of devices to test for as long a period as possible. If the problem goes away, add devices back one at a time until the problem recurs.

Answer 2

I actually encountered this and the problem was to damage of the filesystem. The main hard drive had bad sectors at the W10 filesystem area. As soon as the HDD was disconnected, boot process speed was normal. Practically, UEFI attempts to boot and tries to re-read sectors that are damaged. Also, the same thing may happen if you have other devices the system may attempt to boot from attached. If you have nothing attached, do a complete scan of your boot hard drive, it may be damaged.