X64 system discovery: BIOS vs. UEFI

For Developers
1

Let's say, I have an OpenWrt device, but someone else installed OpenWrt on it and I don't know whether the system was installed from a BIOS image or a UEFI image. How can I tell? Assume that I am accessing the device over SSH, so a direct peek into the BIOS is not in the cards right now...

The "general Linux" way, checking for /sys/firmware/efi, doesn't seem to work on OpenWrt, as there is no /sys/firmware/efi on UEFI systems (at least there isn't one on the SquashFS / UEFI box I am testing right now). It appears that lsblk -o PATH,SIZE,PARTUUID can provide some insight here.

Here's what happens on a BIOS system:

root@BIOSsystem:~# lsblk -o PATH,SIZE,PARTUUID
PATH       SIZE PARTUUID
/dev/sda  14.9G
/dev/sda1   16M abeae232-01
/dev/sda2 14.9G abeae232-02

And here's a UEFI system:

root@UEFIsystem:~# lsblk -o PATH,SIZE,PARTUUID
PATH         SIZE PARTUUID
/dev/loop0  59.6G
/dev/sda    59.6G
/dev/sda1     16M abeae232-5289-82a1-0e57-2f2fe899f401
/dev/sda2   59.6G abeae232-5289-82a1-0e57-2f2fe899f402
/dev/sda128  239K abeae232-5289-82a1-0e57-2f2fe899f480

So, can I conclude with a reasonable degree of confidence that the presence of the small third partition (/dev/whatever128) on the primary storage device in addition to /dev/whatever1 and /dev/whatever2 is an indicator of the system being UEFI? How about the length and format of partition IDs? Are they a reliable indicator?

Or perhaps there's a more obvious way to tell, which I am totally overlooking?

Thanks in advance for any ideas!

2

Hi.
Not sure that this is easiest way but ... install fdisk, and than run the command fdisk -l
If disklabel type is DOS, than you have a mbr disk
Another solution would be to boot a partition tool such as gparted from a USB stick.

3

The kernel log (LuCi and dmsg) should show something like „blabla EFI blablaa“ on any UEFI systems:

[ 0.000000] efi: EFI v2.70 by American Megatrends

4

I'm quite a fan of file -s /dev/sdx, if I remember correctly that tells me the boot sector type, mbr or gpt. Not completely sure if it tells me if uefi or not.

Addition: I installed the OpenWrt x86-64 combined ext4 EFI image into a virtual machine and file -s doesn't help but /sys/firmware/efi/ does exist.

And another addition: Based a virtual machine installation on OpenWrt x86-64 combined squashfs EFI image and here /sys/firmware/efi/ does exist for me too.

5

I don't understand how that can be. AFAICS, you will have at least /sys/firmware/efi/fw_platform_size if CONFIG_EFI is enabled and efi_enabled(EFI_BOOT) is true.

1 Like
6

I am confused by this, too... If you are (or anyone else is) interested in digging into this some more, please let me know what you would like me to run on this anomalous box of mine, and I'll post the output here.

7

What OpenWrt version are you running and on what platform (ubus call system board)?

For me on both ext4 and squashfs EFI images of OpenWrt 22 /sys/firmware/efi did exist. And the log was no help.

8

Here's some diagnostic data... First, the anomaly:

root@[Redacted]:~# ls /sys/firmware/efi
ls: /sys/firmware/efi: No such file or directory

Next, as suggested by @badulesia:

root@[Redacted]:~# fdisk -l
Disk /dev/loop0: 59.61 GiB, 64001351168 bytes, 125002639 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sda: 59.63 GiB, 64023257088 bytes, 125045424 sectors
Disk model: ADATA_IM2S3134N-
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: [Redacted]

Device      Start       End   Sectors  Size Type
/dev/sda1     512     33279     32768   16M Linux filesystem
/dev/sda2   33280 125045390 125012111 59.6G Linux filesystem
/dev/sda128    34       511       478  239K BIOS boot

Partition table entries are not in disk order.

Next, as @Pico suggested:

root@[Redacted]:~# dmesg | grep EFI
[    0.012783] ACPI: UEFI 0x0000000079E6EEE0 000042 (v01 ALASKA A M I    00000000      00000000)
[    0.012875] ACPI: Reserving UEFI table memory at [mem 0x79e6eee0-0x79e6ef21]

Finally, per @patient0 recommendation:

root@[Redacted]:~# file -s /dev/sda
-ash: file: not found

What package should I install to make file available?

9

The package is also called file.

And running fdisk seems to be a good indicator:

  • disk label gpt
  • a /dev/sda128 of type BIOS boot

On both my EFI VM installation this was exactly the same:

root@OpenWrt:~# fdisk -lu /dev/sda
GPT PMBR size mismatch (246303 != 246334) will be corrected by write.
The backup GPT table is not on the end of the device.
Disk /dev/sda: 120.28 MiB, 126123520 bytes, 246335 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: ABEAE232-5289-82A1-0E57-FLUFFYBUNNY

Device      Start    End Sectors  Size Type
/dev/sda1     512  33279   32768   16M Linux filesystem
/dev/sda2   33280 246271  212992  104M Linux filesystem
/dev/sda128    34    511     478  239K BIOS boot

Partition table entries are not in disk order.
10

Here's what I have, with a few lines edited out:

root@[Redacted]:~# ubus call system board
{
        "kernel": "5.10.161",
        "system": "Intel(R) Atom(TM) Processor E3930 @ 1.30GHz",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "22.03.3",
                "revision": "r20028-43d71ad93e",
                "target": "x86/64",
                "description": "OpenWrt 22.03.3 r20028-43d71ad93e"
        }
}
11

Thank you! Here's the output:

root@[Redacted]:~# file -s /dev/sda
/dev/sda: DOS/MBR boot sector, extended partition table (last)

Does it mean I actually have a BIOS system?

12

Nope, on an BIOS system the output is:

root@VMOpenWrt:~# file -s /dev/sda
/dev/sda: DOS/MBR boot sector

Plus, the fact that you have a gpt label type and a /dev/sda128 would suggest an EFI system.
Now there is still the question why no /sys/firmware/efi folder exists. Your on latest stable as I am.

Is your device a Sophos SG105 by any chance? Reminds me of mine :slight_smile:

What does find /sys -iname '*efi* report? Any entries with 'efi' in it's name? For me it reports:

root@OpenWrt:~# find /sys -iname '*efi*'
/sys/devices/platform/rtc-efi.0
/sys/devices/platform/efivars.0
/sys/bus/platform/devices/rtc-efi.0
/sys/bus/platform/devices/efivars.0
/sys/bus/platform/drivers/efi-framebuffer
/sys/firmware/efi
/sys/firmware/efi/efivars

The efi-framebuffer also exists on the BIOS system, the others not.

13

I assume you have kmod-fs-efivarfs installed?

14

Nope:

root@OpenWrt:/proc# opkg list-installed | fgrep -i kmod-fs-efivarfs
root@OpenWrt:/proc#
15

It's basically a test bench based on one...

16

This:

# find /sys -iname '*efi*'
/sys/bus/platform/drivers/efi-framebuffer
/sys/firmware/acpi/tables/UEFI
17

Would you mind running dmesg | fgrep -i efi (like above but case insensitive). For me that outputs:

root@OpenWrt:/proc/sys# dmesg | fgrep -i efi
[    0.000000] efi: EFI v2.70 by VMware, Inc.
[    0.000000] efi: SMBIOS=0xe04c000 MEMATTR=0xf8a1198 ACPI 2.0=0xfbeb000
[    0.515521] ACPI: SRAT 0x000000000FBEB0C0 0008A8 (v03 VMWARE EFISRAT  06040001 VMW  000007CE)
[    0.515545] ACPI: APIC 0x000000000FBFA000 000742 (v03 VMWARE EFIAPIC  06040001 VMW  000007CE)
[    0.515549] ACPI: MCFG 0x000000000FBFA742 00003C (v01 VMWARE EFIMCFG  06040001 VMW  000007CE)
[    0.539375] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    1.382247] pci 0000:00:0f.0: BAR 1: assigned to efifb
[    1.751822] Registered efivars operations
[    3.981687] tsc: Refined TSC clocksource calibration: 2208.000 MHz

You got something similar like the 2nd last line?
[ 1.751822] Registered efivars operations

18

Here:

# dmesg | fgrep -i efi
[    0.012783] ACPI: UEFI 0x0000000079E6EEE0 000042 (v01 ALASKA A M I    00000000      00000000)
[    0.012875] ACPI: Reserving UEFI table memory at [mem 0x79e6eee0-0x79e6ef21]
[    0.026303] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns

The last line appears to be unrelated to the topic at hand (rEFIned)...

19

Btw. while I am booting via UEFI, I'm not getting /sys/firmware/efi either:

Host/Kernel/OS "gateprotect" running Linux 5.15.102 x86_64 [ OpenWrt SNAPSHOT r22287-86cf0f93f1 ]
System         R & S Cybersecurity gateprotect GmbH GP-7543
CPU Info       4x Intel Celeron J1900 @ 1024 KB cache flags( sse3 ht nx lm vmx ) clocked at [ 1332.800 MHz ]
Videocard      Intel Atom Processor Z36xxx/Z37xxx Series Graphics & Display  tty resolution (  )
Network cards  4x Intel I211 Gigabit Network Connection, at ports: d000 c000 b000 a000 
Processes 115 | Uptime 2days | Memory 102.8/3832.5MB | HDD 32GB SATA Flash Size 32GB (0%used) | Infobash v3.60

# ls -ld /sys/firmware/efi
ls: /sys/firmware/efi: No such file or directory

# find /sys -iname '*efi*'
/sys/bus/platform/drivers/lakefield-pinctrl
/sys/bus/platform/drivers/efi-framebuffer
/sys/firmware/acpi/tables/UEFI

# dmesg | fgrep -i efi
[    0.010140] ACPI: UEFI 0x000000007959FC30 000042 (v01 ALASKA A M I    00000000      00000000)
[    0.010211] ACPI: Reserving UEFI table memory at [mem 0x7959fc30-0x7959fc71]
[    0.034464] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns

While parsing the partitioning would be technically possible, it's not very reliable.

20

Mmmmh, I'm out of my depth here. I assume it has to be some oddity with older CPU and the BIOS implementation, or CSM mode enabled.

Since both of you got /sys/firmware/acpi/tables/UEFI then maybe a check for /sys/firmware/efi and if it doesn't exist then check for /sys/firmware/acpi/tables/UEFI. The later doesn't exist on my EFI VMs.