Hi folks, I just finished installing and setting up EndeavourOS alongside my Windows 11. I’m able to boot into either one using Grub and everything works great.
But I’m not able to access my BIOS anymore. When I hit the hotkey and enter the BIOS, I just get a blank screen with a prompt, nothing more.
Not sure if this has anything to do with anything, but I installed it in the UEFI mode. And since I already had Windows installed, I didn’t create a new boot partition, I just added a new mount (/boot/efi) to the existing windows FAT32 ESP partition. And it works fine afaik since I’m able to boot into both of them.
Has anyone faced a similar issue before? Thanks in advance for all your help.
The issue doesn’t really seem to be with the function keys, I’ve tried booting into the UEFI firmware settings through GRUB as well as through the Windows safeboot options, still getting just a black screen.
If you’re on plasma, you can restart to firmware - it’s somewhere in the settings
If you’re on a laptop - you may need to hold the function key?
You may be missing the mark timewise somehow. I’d tap like a caffinated mouse trying to get to firmware.
This is strange though. In nearly 20 computers I’ve owned and probably 500+ installs, I don’t think I’ve ever had a distro make firmware access impossible.
[derek@xfce-i3 ~]$ efibootmgr -help
efibootmgr version 17
usage: efibootmgr [options]
-a | --active sets bootnum active
-A | --inactive sets bootnum inactive
-b | --bootnum XXXX modify BootXXXX (hex)
-B | --delete-bootnum delete bootnum
-c | --create create new variable bootnum and add to bootorder
-C | --create-only create new variable bootnum and do not add to bootorder
-D | --remove-dups remove duplicate values from BootOrder
-d | --disk disk (defaults to /dev/sda) containing loader
-r | --driver Operate on Driver variables, not Boot Variables.
-e | --edd [1|3|-1] force EDD 1.0 or 3.0 creation variables, or guess
-E | --device num EDD 1.0 device number (defaults to 0x80)
-g | --gpt force disk with invalid PMBR to be treated as GPT
-i | --iface name create a netboot entry for the named interface
-l | --loader name (defaults to "\EFI\arch\grub.efi")
-L | --label label Boot manager display label (defaults to "Linux")
-m | --mirror-below-4G t|f mirror memory below 4GB
-M | --mirror-above-4G X percentage memory to mirror above 4GB
-n | --bootnext XXXX set BootNext to XXXX (hex)
-N | --delete-bootnext delete BootNext
-o | --bootorder XXXX,YYYY,ZZZZ,... explicitly set BootOrder (hex)
-O | --delete-bootorder delete BootOrder
-p | --part part partition containing loader (defaults to 1 on partitioned devices)
-q | --quiet be quiet
-t | --timeout seconds set boot manager timeout waiting for user input.
-T | --delete-timeout delete Timeout.
-u | --unicode | --UCS-2 handle extra args as UCS-2 (default is ASCII)
-v | --verbose print additional information
-V | --version return version and exit
-w | --write-signature write unique sig to MBR if needed
-y | --sysprep Operate on SysPrep variables, not Boot Variables.
-@ | --append-binary-args file append extra args from file (use "-" for stdin)
-h | --help show help/usage
[derek@xfce-i3 ~]$
I’m not great with it - so check the wiki, but it looks like you can set a bootmanager timeout and/or delete a timeout if one is set so you can access it easier?
AFAIK Linux does not touch UEFI except for boot entries.
WinOS does, though.
In such cases, you should be able to reset UEFI/BIOS, either by vendor’s instructions, or removing power/battery and empty remaining current pressing the power button several times. This may (or not) break EOS UEFI entry, so be prepared to use installer USB drive for adding that, with efibootmgr utility.
I am assuming when you say you added a new mount point that you used manual partitioning when installing Eos? You don’t add anything? You use the existing Windows efi partition and when manual partitioning you use edit and select the Windows efi partition and don’t format it and mark it to keep and flag it /boot/efi. This way it keeps the original Windows efi partition, doesn’t format it and you have flagged it /boot/efi so that the install of eos will use it. You create the partitions to install Eos on but you use the current efi from Windows.
You can post
efibootmgr
Not sure what your hardware is .
inxi -Faz --no-host | eos-sendlog
Nothing should be interfering with entering the Bios. What ever key it is you need to boot and start tapping the key multiple times.
Hi all, really appreciate all the quick replies. I’ve managed to resolve it, It turned out to be some kind of obscure bootloader bug on Acer machines caused by SecureBoot.
To anyone else facing the same issue, here’s how I solved it without any re-installation:
Login to Windows
Mount the EFI partition (ESP) and access it using an elevated explorer (like Explorer++)
Take a backup of the EndeavourOS (or your distro) directory inside the EFI directory, and then remove it from that partition
Reboot now, and you should be able to access your BIOS
Turn on SecureBoot from the BIOS and reboot into Windows again
Do step 2 again, and this time put the EndeavourOS directory back in the EFI directory
Reboot now, enter the BIOS, and turn on SecureBoot
In the security settings, you have the option to “Select a UEFI file as Trusted”, choose that and select the .efi file inside your EndeavourOS directory (that you put in the EFI partition)
Save, reboot, and enter the BIOS again
You should now be able to see EndeavourOS in the Boot Order section, change the priority to put it at the top
Done - you should ideally be able to access the Grub menu, and also the BIOS perfectly now.
(Optional) Turn off SecureBoot - In my case, I was not able to access EndeavourOS even after adding it to the Trusted UEFI files list, so I had to turn SecureBoot off to boot into the Grub menu. But now I’m still able to access the BIOS as well.
Secure boot needs to be off to install EndeavourOS this is the norm. Glad you were able to resolve it. You couldn’t access the Bios because secure boot was set up on Windows when you installed EOS. Secure boot is recommended to be turned off and i always recommend to clear the secure keys first before disabling it.
That’s the weird part, Secure Boot was already turned off. And I when I got back access to my BIOS, it was still turned off. I had to do the steps I mentioned above above to get the BIOS working with Secure Boot off I guess.
It’s probably because like i said the secure keys i always clear before disabling secure boot. That’s just the way i advise to do it so there are no issues.