Confused About Partition Table and Boot Mode – Legacy Boot but UEFI-Like Layout

Problem Description:
I recently had trouble booting my Fedora system and had to manually boot from /dev/sda2, where my kernel and initramfs files are located. I noticed that /dev/sda3 (inside the root00 subvolume) also has kernel and initramfs files in the /boot directory. My system seems to be booting in Legacy mode, but the partition table looks more like it’s set up for UEFI, which is confusing.

Environment:

  • Distribution: Fedora 40
  • Filesystem: Btrfs with subvolumes root00 (containing /boot) and home00.
  • Partitions:
    • /dev/sda1 (1MB)
    • /dev/sda2 (1GB, contains kernel and initramfs files)
    • /dev/sda3 (Btrfs with subvolumes root00 and home00, also has kernel and initramfs files in /boot)

Boot Mode:

  • The BIOS shows the drive booting in Legacy mode.
  • The partition layout seems more like it’s set up for UEFI (e.g., the 1GB /dev/sda2).

Questions:

  1. Why does my partition table look like it’s set up for UEFI when the system is booting in Legacy mode?
  2. Is there an issue with having kernel and initramfs files in both /dev/sda2 and /dev/sda3 (inside the root00 subvolume)?
  3. Should I be concerned about this partition setup, and how should I adjust it?

Recent Changes:
I was experimenting with NixOS on a different drive recently, which seems to have affected the Fedora boot process. There were no other significant updates or changes before this issue.

Any advice or insight would be greatly appreciated!

The /boot directory should be a mountpoint. The files shown under /boot should be stored on /dev/sda2, not /dev/sda3. Try running the findmnt command to get a overview of what partitions are mounted where.

Having a separate partition for the bootloader isn’t a new UEFI-only concept. It was introduced around the turn of the century due to limitations in the older BIOS systems that prevented them from being able to access files if they ended up being saved to disk sectors with high address values (Cylinder 1024 - Wikipedia). By creating a separate and smaller partition for the bootloader (and making it the first partition on the disk), it was possible to make sure that the bootloader could be accessed by the BIOS.

Newer UEFI systems also require a separate partition for accessing the bootloader, though the reason is different. UEFI systems need a dedicated partition because they cannot access the more elaborate file systems used by Linux (e.g. Btrfs). UEFI systems require that the bootloader be stored on a FAT32 filesystem.

Note: The two problems are not mutually exclusive, so it is possible for one partition to serve as both a BIOS boot partition (located at the start of the disk and smaller than 2 GiB) and and UEFI boot partition (formatted with FAT32). In fact, you can install two bootloaders – one BIOS (e.g. Syslinux) and one UEFI (e.g. sd-boot) – on the same boot partition/ESP and a PC that is capable of booting in either BIOS or UEFI mode will use whichever bootloader is appropriate (or you could even transpose a disk from a BIOS-only system to a UEFI-only system and it would still boot).

1 Like

That clearly shows legacy boot with sda1 at that size.

1 Like

/dev/sda1 looks like BIOS Boot Partition. It allows legacy BIOS to load grub2 from that partition, which then recognizes GPT partition and boot from it.

/dev/sda2 looks like EFI System Partition that UEFI system can recognize and boot from. It should be mounted at /boot/efi. If you are looking at /boot, you are actually seeing /dev/sda3 /boot. You should check /boot/efi instead.

/dev/sda3 would be the usual Linux root (/) partition. Since you didn’t create a separate /boot partition, /boot would be inside here.

Run

gdisk -l /dev/sda

and verify that /dev/sda1 is code EF02 (BIOS Boot Partition), and /dev/sda2 is code EF00 (EFI System Partition).

The whole idea behind BIOS Boot Partition is to allow legacy BIOS to boot GPT-partitioned drive, so you can have both worlds: Install the drive to any system, whether BIOS or UEFI, and it will boot. Also, you can take advantage of GPT-partitioning feature, such as large hard drives that BIOS MBR cannot fully access.

When a system is installed in legacy boot mode there is no efi partition created. Instead only the /boot and btrfs partitions are created beyond the bios boot partition. Suggesting to relocate where that partition is mounted is counterproductive since it would break the system.

For legacy boot sda2 & sda3 appear absolutely correct.

In general the partitioning that is automatically created is like this

LEGACY BOOT
sda1        BIOS boot
sda2        /boot
sda3        btrfs and contains the root and home subvolumes

UEFI BOOT
sda1        EFI partiton mounted at /boot/efi
sda2        /boot
sda3        btrfs and contains the root and home subvolumes

For legacy boot sda1 would be 1 MB and must be located at the first writable sector of the drive (sector 2048).
For uefi boot sda1 would be approx 600 MB.

For uefi boot the physical location of the efi partition is immaterial and may be anywhere on the drive, though by default on a new installation it will begin at sector 2048 on the drive

Not that it matters, but between the MBR sector and the BIOS boot partition you do have the entire GPT partition table. The grub software in the MBR sector has hardcoded sector addresses of the rest of the grub software.

As example

Device         Start       End   Sectors   Size Type
/dev/sda1       4096   4980735   4976640   2,4G Linux filesystem
/dev/sda2    4980736 286480383 281499648 134,2G Linux filesystem
/dev/sda3  286480384 296572927  10092544   4,8G Linux swap
/dev/sda4       2048      4095      2048     1M BIOS boot
/dev/sda5  296572928 625141759 328568832 156,7G Linux filesystem
1 Like

Thanks
I should have stated that it begins at sector 2048 which is the actual requirement.
My bad!

It is true that it must be located at the very beginning of the writable area on the drive. I edited my post above.

I suspect that it could be placed anywhere reachable by the bios, but I need a test to verify that.

After testing a new installation I could get

Device       Start      End  Sectors  Size Type
/dev/vda1     2048   356351   354304  173M Linux filesystem
/dev/vda2   356352   358399     2048    1M BIOS boot
/dev/vda3   358400  2455551  2097152    1G Linux extended boot
/dev/vda4  2455552 41940991 39485440 18.8G Linux filesystem

The partition/dev/vda1 was created before starting anaconda and letting it auto-create the remaining partitions.