Armbian boot partition unreadable on Windows machines due to weird partition type

[meganukebmp]

What happened?

Armbian build sets the boot partition as type 0xEA. This partition type is not standard in any specific distribution or operating system. As such Windows is unable to discover and mount the partition which makes it impossible to mount and modify the network config or other first boot configurations on Windows machines. After changing the partition type to either 0x0B or 0x0C, for DOS FAT32, the partition mounts correctly and is editable fine.

I haven't observed any side effects of doing so, u-boot seems to correctly discover and use these partitions regardless.

I tried tracking down this change and why it was set to 0xEA but found no definitive answer, it might very well be intentional and in that case, I'd like to know as to why.

How to reproduce?

N/A

Branch

main (main development branch)

On which host OS are you observing this problem?

Jammy

Relevant log URL

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

Jira ticket: AR-1975

[meganukebmp]

Relevant function: https://github.com/armbian/build/blob/main/lib/functions/image/partitioning.sh#L188

[meganukebmp]

Some relevant links to this discussion would be:

https://en.wikipedia.org/wiki/Partition_type - which lists the MBR partition types that are IBM PC compatible (any relevant OS will likely support identifying ones in this list)

https://uapi-group.org/specifications/specs/boot_loader_specification/ - The Linux Userspace API docs (from freedesktop and systemd devs) Suggest the use of 0xEA, however I am yet to actually see this utilized in any distribution by default.

pbatard/rufus#609 - Popular image flashing tool Rufus, uses 0xEA as extra metadata partition for itself. The developers claim they've used it for longer than the UAPI spec. Users might be using this tool to image their SDcards which might lead to potential conflicts.