I downloaded the genericx86-64 balenaOS image from our application.
The image has “legacy mbr” in the name implying it is partitioned using the MBR scheme.
The fdisk and gdisk utilities on linux support the idea that it is partitioned using MBR.
Hexdumping the first 512 bytes also supports this as the MBR is clearly visible.
The only thing that throws me off is:
- the presence of
mnt/EFI/BOOT/bootx64.efi in the first bootable partition.
- the fact that our boards UEFI boots the UEFI boot option (I guess it must be detecting the MBR and falling back to legacy/compat mode automatically) - yet fails to boot the legacy boot option for the same drive
Could you shed some light into the presence of that .efi file and if you are doing anything special that might cause problems booting explicitly from legacy mode as opposed to UEFI compat mode?
Hi, all MBR partitioned x86_64 images contain legacy BIOS code in the first sector of the boot partition so that both legacy BIOS and UEFI systems on CDS mode can boot them.
They also contain an EFI directory so they can boot in UEFI mode as most UEFI firmware have no problem identifying a FAT partition on an MBR partition table as the ESP and will use the EFI firmware on it.
I find some of these concepts well explained in [SOLVED] UEFI system booting from MBR partition table and GRUB legacy / Installation / Arch Linux Forums. From there:
In UEFI boot, the firmware does not access the MBR boot code region. It reads the partition table of the disk, finds the FAT32 formatted UEFISYS partition, launches the *.efi application from that partition.
In BIOS boot (normal case in non-UEFI firmwares or CSM in UEFI firmwares) does not read the partitition table (atleast it is supposed to be dumb in this regard), it simply launches whatever boot code exists in the 1st 440-byte of the MBR region.