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.

[ColorfulRhino]

@meganukebmp Which board have you tried this with? Most boards should use GPT and not the ancient msdos partition table. GPT shouldn't have such a problem.

[SteeManMI]

The aml-s9xx-box builds have a fat boot partition (so users can edit the extlinux.conf file for their specific type of TV Box). I've see reports of issues in the forums (since the move to armbian-next where I think this change was introduced) that users can no longer see the fat partition on Windows machines (often TV Box users don't have other linux machines to use to pop their sd card into to edit).
This is something I've wanted to followup on, but haven't had the time.

[ColorfulRhino]

The aml-s9xx-box builds have a fat boot partition (so users can edit the extlinux.conf file for their specific type of TV Box).

Do you know if there is a specific need to use the ancient msdos partiton table instead of standard GPT partition tables? I don't have insights into all SoC families. But with GPT we wouldn't have this issue. If Armbian could switch to GPT-only, this would not only get rid of that specifi issue but also simplify things and reduce complexity. Not sure if I'm opening a rats nest trying to remove this though 😅

[SteeManMI]

I don't know. For my use case, as long as the SD card boot partition is readable by modern Windows OSs and MacOS that is my particular issue. I can't speak for the original author of this particular issue as to what his use case was.

[ColorfulRhino]

For my use case, as long as the SD card boot partition is readable by modern Windows OSs and MacOS that is my particular issue.

No worries there, even Windows XP can read a device with a GPT partition table 😄
And MacOS as well. Basically every modern system can. This is why I was asking if there is a specific need for MBR table. Maybe I'll need to ask this on the forums :) Thanks for your reply!

https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq

[SteeManMI]

@ColorfulRhino I think you are really discussing a separate issue (MBR vs GPT). This issue could probably be solved by changing the partition type from 0xEA to either 0x0B or 0x0C. The change to 0xEA occurred in the move to the new framework. I don't know if @rpardini had a particular reason for the change or not.

[rpardini]

On Amlogic, we can't have GPT and u-boot on the same media, as the load offsets conflict.
It is possible to use for example u-boot in SPI and a GPT SD, but not on the same media

[rpardini]

Relevant function: main/lib/functions/image/partitioning.sh#L188

Nah. That is for legacy BIOS -- a x86 thing controlled by UEFISIZE > 0 and BIOSSIZE > 0

[rpardini]

Armbian build sets the boot partition as type 0xEA.

That's done here: https://github.com/armbian/build/blob/main/lib/functions/image/partitioning.sh#L200-L210

I can't remember writing this code. git blame says it's mine. intriguing

[rpardini]

I didn't write this code, but we've split it around during armbian-next. This used to be on the old debootstrap.sh, heh.

See #4189 -- thus @hzyitc

[rpardini]

The change to 0xEA occurred in the move to the new framework. I don't know if @rpardini had a particular reason for the change or not.

See above. I'm fine with changing it. I personally don't use /boot partition as much as possible, as their presence is generally indicative of legacy bootloaders.

[ColorfulRhino]

@ColorfulRhino I think you are really discussing a separate issue (MBR vs GPT). This issue could probably be solved by changing the partition type from 0xEA to either 0x0B or 0x0C.

Yes, apologies for the confusion. Changing the partition type is probably the "easy" fix, but when seeing this I thought "do we even need to support MBR at all"? Since not using MBR would get rid of this issue as well (GPT is using totally different IDs for partitions).

Relevant function: main/lib/functions/image/partitioning.sh#L188

Nah. That is for legacy BIOS -- a x86 thing controlled by UEFISIZE > 0 and BIOSSIZE > 0

I believe the link is just not correct anymore since it doesn't link to the old version of the code :)

But yes, in addition there is legacy BIOS stuff, which is again different than MBR. This is why this is a bit complex imo.

Which is why I was thinking, if there is no real reson to support all this legacy stuff (MBR as well as legacy boot), we could simplify the code massively :) But I have no idea if this stuff is maybe needed for something? This is why I was asking instead of just rushing to remove more stuff again xD

On Amlogic, we can't have GPT and u-boot on the same media, as the load offsets conflict.
It is possible to use for example u-boot in SPI and a GPT SD, but not on the same media

But from this, I assume MBR is needed for Amlogic? What a shame :( Whyyyy Amlogic? I am disappointed yet again by vendors doing weird stuff.

[ColorfulRhino]

I personally don't use /boot partition as much as possible, as their presence is generally indicative of legacy bootloaders.

I believe /boot will also be created if you choose a different filesystem than ext4 for root. In that case, /boot is ext4 and / is whatever you chose.

[rpardini]

But from this, I assume MBR is needed for Amlogic? What a shame :( Whyyyy Amlogic? I am disappointed yet again by vendors doing weird stuff.

This has a long history. Even MBR was a challenge. https://github.com/u-boot/u-boot/blob/master/doc/board/amlogic/boot-flow.rst & LibreELEC/amlogic-boot-fip#8

I've no idea if Amlogic changed this for their new (S4/T7+) SoCs though.

[rpardini]

Which is why I was thinking, if there is no real reson to support all this legacy stuff (MBR as well as legacy boot), we could simplify the code massively :) But I have no idea if this stuff is maybe needed for something? This is why I was asking instead of just rushing to remove more stuff again xD

That is all absolutely needed, either for x86 legacy BIOS (part of uefi-x86) or for non-GPT-capable boards.
Here we only need to fix the type as @meganukebmp indicated.

[ColorfulRhino]

This has a long history. Even MBR was a challenge. https://github.com/u-boot/u-boot/blob/master/doc/board/amlogic/boot-flow.rst & LibreELEC/amlogic-boot-fip#8

Sounds rough 😅

That is all absolutely needed, either for x86 legacy BIOS (part of uefi-x86) or for non-GPT-capable boards.

I see, thanks for the insights!
How does uefi-x86 use legacy BIOS though? isn't legacy BIOS the opposite of UEFI?

[hzyitc]

This is why: util-linux/util-linux@d0c4300

BTW, IIRC, Windows doesn't mount boot partition by default. As you can see that the EFI boot partition doesn't be shown in explorer. It maybe a safety feature.

[rpardini]

How does uefi-x86 use legacy BIOS though? isn't legacy BIOS the opposite of UEFI?

It's... mashed together. Some machines, even though they're in theory UEFI, use a CSM -- the CSM will end up booting a legacy BIOS thing. Other machines (eg virtual machines), without OVMF, will also default to BIOS booting.

[ColorfulRhino]

BTW, IIRC, Windows doesn't mount boot partition by default. As you can see that the EFI boot partition doesn't be shown in explorer. It maybe a safety feature.

Yeah this makes total sense! I forgot about that.
In this case it also makes sense why changing it to 0x0b makes it visible since this is the marker for "FAT32 partition". But then again, changing it to this in Armbian would not be great either since /boot isn't always FAT but can also be ext4 (this is the case for rk3588 devices for example, just create an image with ROOTFS_TYPE=btrfs for example).

Maybe the best would be to document how to make /boot discoverable in Windows in its current state?

It's... mashed together. Some machines, even though they're in theory UEFI, use a CSM -- the CSM will end up booting a legacy BIOS thing. Other machines (eg virtual machines), without OVMF, will also default to BIOS booting.

Oh god, whyyyyyy are they doing this 😭

[ColorfulRhino]

Actually, I think something in Armbian's logic is not correct. As per https://uapi-group.org/specifications/specs/boot_loader_specification/

• On disks with an MBR partition table:

  • The boot partition — a partition with the type ID of 0xEA — shall be used as the single location for boot loader menu entries.

• On disks with GPT (GUID Partition Table)

  • The EFI System Partition (ESP for short) — a partition with a GPT type GUID of c12a7328-f81f-11d2-ba4b-00a0c93ec93b — may be used as one of two locations for boot loader menu entries.

  • Optionally, an Extended Boot Loader Partition (XBOOTLDR partition for short) — a partition with GPT type GUID of bc13c2ff-59e6-4262-a352-b275fd6f7172 — may be used as the second of two locations for boot loader menu entries. This partition must be located on the same disk as the ESP.

So our GPT partitioned images should not have a /boot partition (Extended Boot Loader Partition) at all, or am I reading this wrong?

Edit: I think I'm wrong after some further research, e.g. https://wiki.archlinux.org/title/Partitioning#/boot

[SteeManMI]

• On disks with an MBR partition table:

  • The boot partition — a partition with the type ID of 0xEA — shall be used as the single location for boot loader menu entries.

Getting back to the original issue that was logged. The above behavior (which isn't really intended for classic u-boot senarios from my understanding) breaks existing functionality. It is desired and has long been the case that you can take an SD card with an Armbian image (for those builds that still use a FAT partition for /boot) and pop it into a windows machine to tweek things (armbianEnv being one and extlinux.conf being another). This change breaks that long standing capability. So until we move to modern booting systems, we really need to go back to the /boot partition being 0x02 for MBR cases when the board configures the boot partition as a fat file system type. (I'm not sure what should be done for GPT cases as my boards are MBR).

[ColorfulRhino]

The above behavior (which isn't really intended for classic u-boot senarios from my understanding) breaks existing functionality.

It depends how you define "existing", since this 0xEA has been in use for 2 years now 😅
Nevertheless, it's not like the partition is gone. But it's a good thing to help users get this functionality back. What do you think about documenting how to make /boot discoverable in Windows?
Otherwise, I don't really have any objections to changing it to 0x08 if whoever changes it can test that it works. I do not and will never use MBR, so I don't care much about 0xEA vs 0x08, do what works and is valid 😄

(I'm not sure what should be done for GPT cases as my boards are MBR).

For GPT, this specific partition type has a special flag for boot (I checked earlier with fdisk) and is likely important to keep functionality. Arch wiki says

XBOOTLDR partition must have a partition type GUID of bc13c2ff-59e6-4262-a352-b275fd6f7172

[rpardini]

We just need to change the (MBR-only) type back and be done with it for a while.

Further changes should be carefully considered -- we've already lost capabilities that were result of hard labor and were removed in the interest of "keeping it simple". It's a thin line, but booting on exotic hardware is one of Armbian's strengths -- let's not throw that away.

[ColorfulRhino]

Further changes should be carefully considered -- we've already lost capabilities that were result of hard labor and were removed in the interest of "keeping it simple". It's a thin line, but booting on exotic hardware is one of Armbian's strengths -- let's not throw that away.

Keeping it simple/not too complex is important for maintainability in my opinion. But of course, throwing stuff away is also not so good. It's a thin line indeed and Armbian should always keep maintanability in balance. So far I've had multiple encounters of almost throwing the towel because some stuff was too complex and I had to spend hours just to understand/follow the current logic so that I could find a good way to implement a change. Newcomers often won't have the time or patience, so keeping the complexity in balance should not be underrated.

we've already lost capabilities that were result of hard labor and were removed

I believe this can at least sometimes be prevented by careful design considerations from the beginning, instead of just starting to implement something. Of course, this will take more time 😅