How does Linux know there is a MBR partition table?

Question

You might think this question is trivial because an msdos partition table MBR ends with 55 AA (hex). But it's not because disks formatted as FAT32 (with no partition table) end with 55 AA too.

I formatted a disk like this:

mkfs.vfat -F32 /dev/sdX

Such a disk has no partition table and is recognized on both Linux and Windows. The first 512 bytes end with 55 AA.

How does Linux know that on such a disk there is no valid partition table even though it ends with 55 AA?

Answer 1

How does the Linux kernel know that this is not an MBR, although it is the first sector of a block device and ends with 0x55 0xAA?

The answer is in the code: https://elixir.bootlin.com/linux/latest/source/block/partitions/msdos.c#L616

First it tries to interpret the data in this sector as a partition table, then as FAT metadata. In the second case you won't have any partitions created for the block device. This is sort of a heuristic, so maybe there could be some edge case where it misdetects a non-existent partition table in a PBR.

---

This is how the original DOS boot process worked:

The first sector contained the Master Boot Record with the partition table and a small piece of code. This code on a modern system calls into a more complex boot loader. Back then it looked at the partition table entries, and started to execute the first sector of the first active (bootable) partition.

This first sector was the Boot Record of a FAT partition (https://wiki.osdev.org/FAT#Boot_Record) that also contained a small piece of code - which was the whole boot loader needed for DOS (its task was to load the IO.SYS and MSDOS.SYS files).

Both the Partition Boot Record and the Master Boot Record have a signature of 0x55 0xAA. Now on removable drives like floppies it made no sense to have a partition table just to waste space, so the disk started with the FAT partition and its Boot Record. This made no difference to the BIOS since the loader code starts at offset 0 just as for the MBR, so it only needed to execute whatever was there.

Of course the PBR has a different structure to the MBR, describing the FAT filesystem's characteristics.

Answer 2

How does Linux know

We got to be clear about terms here: What's Linux in this case?

• Linux (or any other OS boot process): your mkfs.vfat formatted disk does start with an MBR boot sector, and a partition table with only one entry The computer will execute that upon boot. Check man mkfs.vfat's section on --mbr=no:
  

  Fill (fake) MBR table with disk signature one partition which starts at sector 0 (includes MBR itself) and spans whole disk device. It is needed only for non-removable disks used on Microsoft Windows systems and only when formatting whole unpartitioned disk. Location of the disk signature and partition table overlaps with the end of the first FAT sector (boot code location), therefore there is no additional space usage.

  • Linux tooling for partitioning will also detect that table: fallocate -l 100M fatimg; mkfs.vfat -F32 fatimg; echo print all | parted fatimg
• Note, however, that there seems to be a bug in modern mkfs.vfat so that --mbr=no is generally ignored, at least when formatting files.
• Linux kernel partition scanning will only care for MBR tables where they are expected, i.e., at the beginning of disks
• When Linux sees a partition, the mount tools probe for file systems; it's easy to check for VFAT. Whether that VFAT file system also contains an MBR record: irrelevant for that. The file system driver doesn't care.

Answer 3

It is not Linux that must know it, but the BIOS.

The BIOS will load the boot sector (the first sector of the disk) and execute it (it has the signature you wrote). The last part of the boot sector contains 4 partitions. The boot code will just find the active partition, load it in memory and execute it (because the boot sector is expected on a precise point of memory, there is also a copy of actual sector and jump into it). The new boot sector may boot the operating system, or just it may be very similar to a MBR, but in this case it is a secondary partition table), and so recursively. GRUB just modify boot sector, and it uses the fact that disk sector are larger then 512 bytes (size of floppy sectors) to store more code (to load secondary GRUB code).

That is about how the execution of code is done.

Programs in Linux (and also Linux) known about table structure of MBR (and other partition table formats, as you see, it is just a convention), so they know that in hard disk it should be on the first sector, and every extended table should have one partition and eventually an additional link to a extended table.

If the program or kernel cannot recognize it, you cannot edit it. But possibly BIOS can boot (or better the code in the boot sector can do it). We are talking with old programs, with very limited memory, so do not expect much logic. Worst case: "Press any key to reboot".