Question: how to identify vendor firmware setups conflicting with disk partitions?

Steve McIntyre steve.mcintyre at
Thu Feb 28 17:12:25 UTC 2019

Hi folks,

I've just been having a discussion with folks about installing Debian
on an arm64 device. Another developer is booting via U-Boot with UEFI
and things are working OK, except...

The intructions for their board [0] include writing things raw to both
sector 0 and sector 1 of an SD card, meaning that both MBR and GPT
partitioning schemes are likely to break. Ugh. :-/

So, I have two (related) worries:

 1. At the moment in Debian, our installer will default to using GPT
    for arm64 machines (where disks are not already formatted). That
    was fine when we were expecting server systems booting using edk2,
    but it looks like that's now a dangerous assumption, as more and
    more U-Boot devices are out there which will be wanting to load
    firmware from low-numbered LBAs.

 2. I'm just in the middle of adding EFI armhf installer support, and
    that is also (currently) defaulting to GPT if you've booted via
    EFI. This is fine for VMs booted using a 32-bit Arm build of edk2,
    but also it's starting to look like a bad option for real boards
    booting using U-Boot's EFI support (for similar reasons).

The "Firmware Storage" section of EBBR v0.6 touches on this and
describes how to store firmware in a safer manner, but obviously
(some/many) vendors are not following the spec thus far. What are
other folks doing in this area? How do you recognise which devices
it's safe to use GPT on, for example?

I'm now looking at updating our logic on armhf/arm64 to do something

if (booted via UEFI); then
  if (booted using U-Boot); then
    echo MBR
    echo GPT
  echo MBR

but I'll need to find a sane way to detect U-Boot->UEFI boot. For now
I'm looking at parsing dmesg output to look for something like

[    0.000000] efi: EFI v2.70 by Das U-Boot

but I'm hoping for a better solution. This is also somewhat assuming
that detecting U-Boot in the boot chain is a valid indicator for
"unsafe location for firmware", but I'm not sure of a better way!


Steve McIntyre                                steve.mcintyre at
<> | Open source software for ARM SoCs

More information about the boot-architecture mailing list