Linux shows I am using BIOS, when my motherboard runs UEFI
I ran into some boot problems on my ubuntu server installation.
Linux version 5.4.0-81-generic (buildd@lgw01-amd64-052) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04))
[GPT partition not showing up in BIOS/UEFI]
I have now realised that my ASUS Maximus VII Impact is running on UEFI, not BIOS, so the GPT partition should show up in the selection. But when I check if I run BIOS or UEFI: ls /sys/firmware/efi
I get: ls: cannot access '/sys/firmware/efi': No such file or directory
and dmesg | grep "EFI v"
returns nothing, indicating I dont run UEFI.
So how comes I am booting from BIOS when my BIOS/UEFI (whatever it is I am looking at) screen, has a modern, mouse operable interface? And how should I proceed so linux boots from UEFI?
So how comes I am booting from BIOS
Most UEFI systems (except for some extremely new ones) have a "Compatibility Support Module" (aka "CSM mode" aka "Legacy boot") which allows them to emulate the traditional BIOS boot process. When an OS is booted in this mode, the EFI System Partition is not used (the disk's bootsector is booted instead) and the OS cannot access the UEFI-specific interfaces (hence no /sys/firmware/efi).
The firmware settings screen will have an option to disable the compatibility mode and enforce native UEFI boot only. (The option may be named in several different ways, but it will be present, because Microsoft requires it as part of Secure Boot support.)
However, having the CSM enabled does not prevent an OS from being booted in native UEFI mode – it just makes both modes available. Typically in such systems, when CSM is enabled, the F8 boot menu will show both "legacy" BIOS-mode and "native" UEFI-mode items at the same time.
-
For example, if the same Ubuntu installation USB stick is compatible with both BIOS-mode boot and UEFI, then it will show up twice. This often leads to people choosing the wrong item – booting the USB stick in BIOS mode – out of habit, and the OS installer will accordingly prepare the system disk to be booted in BIOS mode as well, despite the firmware being UEFI-capable.
-
This is not the only cause of BIOS-style OS installations on UEFI-capable computers, but it's fairly common. Another common cause is programs used to write an .iso image to a USB stick – some of them insist on re-arranging the image's boot process in their own way, and this often ends up with the USB stick only being BIOS-compatible even if the original image had UEFI support. Thanks to CSM being enabled, the USB stick will still work and the user won't realize anything missing.
So you're booting in BIOS mode because 1) the firmware is capable of doing so, and 2) the OS on this particular disk was installed this way.
my BIOS/UEFI (whatever it is I am looking at) screen, has a modern, mouse operable interface?
The interface has very little to do with the firmware type. (Or maybe "correlation doesn't imply causation"?) Yes, modern, mouse-operable interfaces are common nowadays, and so are UEFI firmwares, but neither actually implies the other – text-mode setup screens are just as common in UEFI systems, while some manufacturers used to have mouse-operable BIOS interfaces 30 years ago.
And how should I proceed so linux boots from UEFI?
If the OS isn't installed yet, or you're fine with reinstalling it:
-
Go to your firmware settings and make sure to disable "CSM" or set the boot mode to "native" or "UEFI only" (or whatever it is called in ASUS firmwares).
(With Ubuntu, you can even enable Secure Boot – this will result in UEFI boot being mandatory as a side effect.)
-
Reinstall the OS.
If the OS is already installed and you want to keep it:
-
Manually create an EFI System Partition. Mount it at /boot/efi (to match what Ubuntu does).
If you don't have any more unallocated space, shrink the root partition. The EFI System Partition doesn't have to be at the beginning, but it does need to be at least 100 MB (so the existing 1 MB "BIOS boot" partition won't do).
-
Install the correct GRUB2 package (e.g.
grub-efi-amd64
) and grub-install the bootloader again. You don't need to specify "/dev/sda" this time.grub-install --target=x86_64-efi
You'll probably need to re-run
update-grub
after this.
You're misunderstanding now.
Your partitioning shows a separate /boot partition, with type BIOS. As per the Arch Wiki page I linked earlier, this indicates the installation was made useing GPT partitioning table for a system with legacy BIOS. Since it was made this way, /sys/firmware/efi doesn't exist, and dmesg can't find anything about EFI either.
Misunderstanding snipped out
Since this is a new installation, I would suggest that you simply forget trying to fix this, and just re-do the installation from the start. The only way I can imagine this happens is that something went wrong the first time. It's happened to everyone.
Verify that your BIOS is set to UEFI mode, not Legacy, and Secure Boot is disabled. Read and follow the Ubuntu Server installation instructions.
That should get you up'n running with the minimum hassle.