We are using the balenaOS 2.58.6+rev1 genericx86_64 legacy MBR image and flashing via balenaEtcher to our target x86_64 computer on an mSATA 1Tb drive.
After flashing, the units show a single boot option in the UEFI for the mSATA device (calling this boot option “legacy”) which works fine.
However, I have found several long running units that now show 2 boot options in the UEFI for the single mSATA device (one legacy and one UEFI boot option). The legacy boot option fails to boot on these devices but the UEFI boot option succeeds to boot.
On these devices that fail to boot the legacy option I can see the contents of the MBR are different. The bootloader is all zeros and only the partition table is still present.
I suspect the UEFI is smart enough to detect the MBR is missing the bootloader and this is why the additional UEFI option is presented. However I’m not sure WHY the MBR bootloader is missing.
I have run disk checks using badblocks and smartctl which indicate the disk is fine.
Also repeated flashing of these devices using the USB created by balenaEtcher does not fix the MBR and the flash process doesn’t fail or complain afaik.
I’m in contact with the computer vendor but wanted to ask here also.
Is it possible that balenaOS upgrades or flashing could result in this empty MBR?
Does flashing with balenaEtcher not format the disk?
Have you seen any issues like this previously?
So I think I realised the issue. It seems like the USB drive created by balenaEtcher based on the legacy MBR image can flash the device in TWO ways. One where if flashes in legacy mode and writes the MBR and another in UEFI where it writes a protective MBR (which is I think what I’m seeing).
It wasn’t long running units, it was just somehow they were flashed with the UEFI mode whereas others were flashed with the MBR mode.
Does that make sense? I’ll be confirming tomorrow.
Confirmed.
The part that caused us confusion is that on a fresh device (NVRAM cleared) the default boot option in the UEFI/BIOS is legacy mode. But if I then try to flash the same device again the default boot option is UEFI mode.
In our case the cause was clear - the CMOS battery was becoming disconnected.
But what tripped me up was:
We flashed a USB drive with the balena generic x86_64 legacy MBR image using balena etcher.
When booting from the USB there are two boot options: legacy and UEFI.
If we boot using the legacy option then after flashing is complete there is 1 disk boot option (legacy) and it boots fine.
But if instead we boot the USB using the UEFI option then after flashing is complete there are 2 disk boot options: legacy and UEFI. But the legacy fails to boot (because upon inspection the MBR bootloader section is completely zeroed, while the UEFI boots fine.
The particularly tricky part was that not only was the disk MBR bootloader section zeroed, but the USB MBR booteloader section was ALSO zeroed - and this had the consequence of impacting all future flashing attempts; in other words after booting the USB in UEFI mode, every subsequent attempt to boot in legacy mode would fail (because the MBR bootloader was zeroed).
I don’t have previous experience with UEFI/BIOS and disk partition schemes so most was learned as I went here, but my best guess as to whats going on is that the UEFI boots in native (UEFI) mode and sees that the disk has a valid MBR bootloader and decides to heal this to a protective MBR by zeroing it.