Not to mention that those issues are very similar to the topic’s issue
The problem is most probably because of UEFI firmware, in which case a reset would clear up the situation.
Although some UEFI firmware have a Fast boot/startup setting, that has to be disabled, the same setting (fast boot) has to be disabled from Windows as well.
It was not clear from which OS the OP did Restart or Power down, to have different behavior.
If this was from Windows, is exactly doing a FastBoot (using Restart).
IIRC from when I had last time used Windows, there was a setting for “What should the Power Off action actually do”, and needs to be set to completely power down.
When, how does this happen? Usually after Windows updates. I thought it was common knowledge to keep an eye when those take place, as they almost always change bootloader order and/or delete foreign OSes entries in UEFI.
This is strange to me as i never seem to have this issue. I have numerous dual boot Windows with EndeavourOS or Arch. When i have Windows updates i make sure that i always boot to Windows and complete any updates that have initiated.
After removing /boot/efi/EFI/endeavouros directory the UEFI Setting menu come back available. I guess that there’s something in endeavouros bootloader that causes block of uefi settings from acer efi system.
This looks like an invitation for trolling… , but I"l pass.
The actual problem, which everybody (that read Archwiki articles) knows, is that several vendors supply their hardware with bad UEFI protocol implementation (bad is the lightest word I could easily find). After this, Linux utilities that act on the UEFI area may fail in various ways, which leads tech people to try and find workarounds to help those users who want Linux on their Windows focused/targeted hardware.
I stop here… I need to go to church tomorrow in peace.
is written by grub or not ? ( grub is the bootloader but it is NOT developed by EndeavourOS ) i see users have firmware reset to boot in CSM mode after the grub issue… but could be also something they have done randomly caused by not being able to boot…
Another thing is that using efibootmgr can harm firmware in cases where it is not showing the F12 menu anymore… I saw that on one of my systems and was able to resolve it by redone the boot order using all boot entries in the command…
and reading the solution from the link @ringo gave … it seems this is one workaround to get back into firmware (removing vendor files from the esp) the other would have been to remove the boot entry only using efibootmgr
This is what i read from the Acer forum which i provided a link to in a previous post. This is back from 2020 so i think the problem exits before any of this grub issue.
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
When you do grub-install its name is from osrelease…and the fwsetup is changed in grub. That coulf be the issue or not…didnt looked further in this. But is a gues…
) i see users have firmware reset to boot in CSM mode after the grub issue… but could be also something they have done randomly caused by not being able to boot…