4

This comment by OrangeDog on another question brings up an interesting point:

I find it odd that Linux has separate identifiers for each CPU architecture, when that's irrelevant to a filesystem [...]

Indeed, if you take a look at Wikipedia, you find that the root partition type GUID for x86_64 is 4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709, but it's 69DAD710-2CE4-4E3C-B16C-21A1D49ABED3 for ARM. What gives? Windows doesn't make this distinction yet Windows for ARM exists.

Surely, a root partition containing the filesystem for an ARM computer can be mounted and read just fine from any x86_64 computer? the programs won't be executable without a translation layer or virtualization, but that's besides the point.

Themoonisacheese
  • 688
  • As I said in the original comment, you can also build a root and/or boot partition that will execute on multiple architectures. Raspberry Pi OS images work on both "ARM" and "AArch64", for example. Yet they have separate type GUIDS. – OrangeDog Jun 24 '25 at 19:39
  • @OrangeDog realistically this is more that it happens to be possible to boot the same image on both platforms (and it problably is possible on x86 and x68_64 too) rather than a choice that was made at some point. – Themoonisacheese Jun 24 '25 at 21:19
  • 1
    @Themoonisacheese No, the choice to support that was almost certainly actively made when creating the specification. And, with UEFI in the mix, you can in fact make disk images that will boot on any platform supported by both UEFI and Linux without hard-coding filesystem UUIDs. In fact, I have a flash drive set up to boot into a custom-built recovery environment on any of 32-bit x86 UEFI systems, 64-bit x86 UEFI systems, and 64-bit ARM UEFI systems. – Austin Hemmelgarn Jun 25 '25 at 02:22

1 Answers1

4

This is part of the Discoverable Partitions Specification.

The link above gives one of the reasons this choice was made:

On systems with matching architecture, the first partition with this type UUID on the disk containing the active EFI ESP is automatically mounted to the root directory

The general advantages of the DPS are eloquently stated in this answer, but it does not mention the reasoning behind the different GUIDs per CPU architecture.

Themoonisacheese
  • 688
  • It follows from the rationale for DSP, no? A system booting up will mount partitions automatically using DSP, but in the presence of multiple disks (or images for containers), this will prevent it from mounting a filesystem meant for ARM64 on an x86-64 system (or vice versa). Quoting the explanation section from that page: "On systems with matching architecture ..." – muru Jun 25 '25 at 07:47
  • ...yes? that's exactly what i cited in my answer. – Themoonisacheese Jun 25 '25 at 08:13
  • And you seemed to have missed the point, if you're still looking for a "reasoning behind the different GUIDs per CPU architecture" – muru Jun 25 '25 at 08:15