99

makeuseof.com explains that Windows 8 certified hardware has a new way to enter the UEFI setup screen (equivalent to BIOS). From How To Access The BIOS On A Windows 8 Computer:

No longer do we press a certain key during the boot process to reveal the BIOS – instead, an option to access the BIOS is located in Windows 8’s boot options menu... If you’re just here to access your computer’s UEFI BIOS, click the Troubleshoot tile.

The main developer of Secure Boot for Linux says that alternative OS's can't assume the old way will continue to work. So does Linux also have a new way to enter UEFI setup?

I have an ASUS motherboard. It suggests that an upgraded version of the firmware contains a fast boot option. The flip side is that the option might make it even harder to "reveal the BIOS" than it already is.

I don't mind tinkering. Just if this is known to be a bad idea, I don't want to go through the risk of a firmware upgrade for nothing (and maybe have to pop the case off, reset the settings and have to set them all up again).


Alternatively, how is this handled for Windows 7 users? If they optimistically select the fast boot option, how do they get access to the "BIOS" setup again when they need it?

sourcejedi
  • 3,860

6 Answers6

160

On modern Linux distributions using systemd, you can go straight to the Firmware setup menu using:

systemctl reboot --firmware-setup

Documentation: https://www.freedesktop.org/software/systemd/man/systemctl.html#--firmware-setup

Lekensteyn
  • 6,982
9

I've written a small tool to do this without systemd, https://github.com/adoakley/efi-boot-to-fw-ui.

9

I'm not sure how exactly Windows 8 does this, but I can guess that it takes advantage of UEFI variables used for boot options.

You can use efibootmgr to determine the meanings of the various boot variables. On my system, Boot0000 is Setup, so using efibootmgr -n 0 should cause the system to boot into setup on the next boot.

6

I have tried EFI booting with Ubuntu 12.04, and found an answer to my own question.

(I haven't upgraded my firmware. I misread the release notes originally - it probably wouldn't be any faster).

Entering firmware setup from the grub-efi boot menu

efibootmgr doesn't seem to support rebooting to firmware setup for me. But grub-efi does. It's able to create an entry for firmware setup in the GRUB boot menu.

You can enter the GRUB boot menu by holding down the shift key "early in the boot process". I press it down immediately after the NumLock light turned on on the keyboard, and that works for me.

If you're curious, I looked at the command as well: it's "fwsetup". I.e. you can enter the GRUB menu, follow the on-screen instructions to switch to the command line, then type "fwsetup" and hit return.

If you do an EFI install from scratch, I believe the menu item will be created automatically. I didn't install as EFI, which meant I had to kick it (see below, step 4).

Converting from BIOS-GPT boot to UEFI-GPT boot without burning an EFI boot CD?

EDIT: this section may work on some systems. However I now believe it relies on extra behaviour which is not part of the UEFI standard. Some day I'll figure out what's happening here.

I was converting an existing install to EFI, without an EFI-enabled boot CD. Some people think this isn't possible. Admittedly, there are a couple of confusing warning messages. I had a look at what was going on. If you can currently enter the firmware setup, then it's not all that bad.

The hard part is you're probably still using an MBR partition table, and you almost certainly need to convert it to GPT. I'm not going to cover conversion from MBR to GPT. Partitioning is always a bit dangerous. gdisk can convert, but there are quite a few fiddly bits. I haven't listed them all here. But for one, you probably need to shrink the last partition, to make space for the end-of-disk GPT. You can't do that if the partition is mounted, so you'll want to use a boot CD. (I also staged the conversion, making sure I could boot from BIOS-GPT before I tried UEFI-GPT, which involved having to create yet another type of boot partition.).

Assuming you've got GPT set up:

  1. Install grub-efi. This removed grub-pc, and stopped it from working. (grub-efi actually still worked after I removed it!). Fedora seems a bit different; I've only tried this on Ubuntu. During the install, you will see errors about not being able to access EFI variables, which is because you didn't boot by EFI.
  2. Shutdown.
  3. Power on. Make sure you boot through EFI! This is the system-dependent and worrying part. My system happened to default to MBR boot to start with, so I saw a scary error from GRUB - but it was from the old grub-pc. On my system, it was easy to enter the firmware setup screen at this point (see below), and change the boot priority to "ubuntu" (which was the entry for booting my OS via EFI).
  4. Now you can redo the grub installation (grub-install, or grub2-install on Fedora), and it won't show any errors. And now, running update-grub (or grub2-mkconfig -o /boot/grub/grub.cfg, on Fedora) will create the menu item for entering firmware setup.

Entering the firmware setup/boot menu on my ASUS system

DISCLAIMER: this is not the very latest firmware/board. Your ASUS system may act differently from mine.

My current ASUS firmware notices when the "boot configuration" has changed - e.g. when I installed grub-efi. There's text saying that it's changed if you look at the initial "EZ setup" screen. And, when it detects such a change, it makes it easier to enter the setup screen. What it does is it shows the splash screen with "press DEL to enter setup" for a few seconds. (If you've enabled the "fast boot" option, it normally skips the splash screen).

I think it's also possible to trigger the splash screen by you powering off the system and unplugging it for a minute or so, before rebooting.

On my current firmware, I can enter the firmware setup by blitzing the DEL key during boot, even without the splash screen. However, this is conditional on enabling keyboard support in the firmware.

It's possible to switch the firmware not to probe for keyboards during boot, which is supposed to speed things up. I guess this is the next experiment to try, now I'm more confident about this EFI stuff! (It's plausible it could kill keyboard support in the GRUB boot menu as well. But I should still be able to use grub-set-default, so that GRUB boots the fwsetup entry, and recover that way).

sourcejedi
  • 3,860
3

Building on @Lekensteyn's answer, I made a UI shortcut (in the Administration menu if your environment still has one of those). Useful if your keyboard never seems to work until after POST.

/usr/share/applications/uefi-reboot.desktop

[Desktop Entry]
Name=UEFI Firmware Setup (Reboot)
Comment=Access the motherboard configuration utility
Exec=systemctl reboot --firmware-setup
Icon=system-restart
Terminal=false
Type=Application
Categories=System;Settings;
krispy
  • 141
0

If you're using cpe:/a:kde:plasma-workspace, invoking kcm_smserver with systemsettings (or, for V5 or V6, kcmshell5 or kcmshell6, respectively) shall provide this:

Screenshot

If you're using cpe:/a:kde:plasma-workspace ≥ V5 with cpe:/a:systemd_project:systemd, please note that systemctl reboot --firmware-setup does not appear to send a SIGTERM to Plasma's processes, when it kills them. Instead, it appears to SIGKILL them, which is undesirable. Consequently, you should instead invoke the undermentioned:

#!/usr/bin/env sh
sudo qdbus --system org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.SetRebootToFirmwareSetup true && \
qdbus org.kde.Shutdown /Shutdown org.kde.Shutdown.logoutAndReboot