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 like:
if (booted via UEFI); then if (booted using U-Boot); then echo MBR else echo GPT fi else echo MBR fi
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!
[0] http://share.loverpi.com/board/libre-computer-project/libre-computer-board-a...
Cheers,