2

(Originally posted on stackoverflow, closed as off topic. Closing message recommended I ask on superuser instead.)

I've been reading about the Linux boot process, and tried to orient myself by looking at my machine's boot device:

mcarilli:tmp$ mount | grep boot
/dev/sdc5 on /boot type ext4 (rw,relatime)
/dev/sdc1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
root:tmp# parted -l
...
Model: ATA Samsung SSD 860 (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos (msdos = MBR, according to google)
Disk Flags: 

Number  Start   End     Size    Type      File system  Flags
 1      1049kB  538MB   537MB   primary   fat32        boot
 2      539MB   1000GB  1000GB  extended
 5      539MB   1305MB  767MB   logical   ext4
 6      1307MB  1000GB  999GB   logical

So I expect /dev/sdc1 is my EFI system partition. According to wikipedia, the EFI system partition's "ID in the master boot record (MBR) partition-table scheme is 0xEF."). As an exercise, I tried to verify this.

MBR sector layout says "Partition entry No1" (probably) starts at 0x01BE and the partition type (ID) should be found at offset 0x04 in this entry. So, on the MBR disk hosting the partition (/dev/sdc), I expect to see 0xEF at 0x01BE + 0x04 = 1C2. But I don't:

root:tmp# xxd /dev/sdc | head -n 50
...
000001b0: cd10 ac3c 0075 f4c3 b1df bbbc 0000 8004  ...<.u..........
000001c0: 0104 0bfe c2ff 0008 0000 0000 1000 00fe  ................
               ^ Expected to see "ef" here

What am I missing?

note: i don't think my machine actually starts booting with UEFI firmware, I think it uses BIOS (either natively or via CSM fallback), because after login there's no /sys/firmware/efi folder. Not sure if this is relevant to why /dev/sdc1 appears not to be tagged as 0XEF.

10
  • 1
    I don't know a whole lot about low-level disk formatting, however if this is coming out in big-endian for whatever reason then you do actually have 0xEF exactly where it should be. As a side note - if you don't have the efi folder then you probably installed your bootloader in BIOS mode into the MBR sector. This being the case, you don't even need an EFI partition at all. How exactly did you set up this disk, and what flavor of Linux are you running?
    – Layne B
    Commented Dec 31, 2020 at 0:39
  • Thanks, but I'm not sure what you mean. 0xEF is one byte, endianness shouldn't matter. And i'm fairly sure I'm looking at the right address. Where do you see 0xEF? (I think you're right my boot process starts with BIOS such that my EFI partition is unused. I'm not worried about functional correctness of my machine, just trying to understand how an MBR disk is laid out.) Commented Dec 31, 2020 at 0:49
  • 1
    So I was looking into this some more, I think you're looking in exactly the right place. 0x0B is the partition ID for Microsoft FAT32 on an MBR disk, so that's what you're seeing. This implies to me that the partition was not actually set up as a proper EFI partition but just a normal FAT32 partition. How was this disk partitioned?
    – Layne B
    Commented Dec 31, 2020 at 1:04
  • 1
    If you have parted installed you can check flags by running sudo parted -l. The far right column (flags) should say "esp" if it is flagged as an EFI partition. Also if you have fdisk you can run sudo fdisk -l which will tell you the partition type for each partition. As to why the partition would be created if it's not used - I have no idea lol. You might check if there are actually files under /boot/efi. If not, you could probably change the type to EFI system using, e.g., fdisk, and then check again, although I don't want to be responsible if this breaks stuff.
    – Layne B
    Commented Dec 31, 2020 at 1:24
  • 1
    If you're using GRUB, one possibility is that the partitions were set up manually and they simply forgot to set the partition type to EFI System. This is an easy mistake to make. If you then run the GRUB installer without specifying that you want UEFI, then GRUB may have checked for an EFI partition, realized that there isn't one, and then fell back to installing via the MBR boot sector instead.
    – Layne B
    Commented Dec 31, 2020 at 1:28

1 Answer 1

1

Your machine can't boot using UEFI because the disk uses MBR.

The boot files for BIOS are in /dev/sdc5.

You probably have a bootable fake ESP (EFI System Partition) in /dev/sdc1 for compatibility reasons. It starts on 1M and it has 500MB so you can store Windows 10 grub entries without the UEFI and the Windows complaining that you don't have GPT.

Here's material for further study, ordered from more technical to more noob friendly:

4
  • Thanks for the references, I'll check them out. "Your machine can't boot using UEFI because the disk uses MBR..." I'm not sure that's true in general, en.wikipedia.org/wiki/EFI_system_partition says "The UEFI specification requires MBR partition tables to be fully supported...." I think that means in theory UEFI can find and boot from a bootable ESP partition if present even on an MBR disk, although it may still choose to "switch to the BIOS-based CSM booting...effectively preventing UEFI booting." Commented Dec 31, 2020 at 5:02
  • 1
    UEFI can boot from MBR disks in regular non-CSM mode. It's a common misconception that it can't because Windows doesn't support it. The opposite (CSM on GPT) is possible too - again, unless you're using Windows.
    – gronostaj
    Commented Dec 31, 2020 at 6:49
  • Both assumptions are correct, however all the "tricks" to make MBR work with UEFI are non standard. Also, I didn't find any reference to master boot record in the current UEFI specification as claimed by the Wikipedia editor. Commented Jan 13, 2021 at 20:21
  • UEFI supports MBR too. That is part if the white standard, it does not for work for debian due to a bug in debian. Full stop. bugs.debian.org/cgi-bin/bugreport.cgi?bug=821341 Commented Dec 24, 2021 at 22:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .