DPS: clarify architecture to use for mixed 32bit/64bit installations

[helmutg]

Thanks for writing down DPS. Reading it leaves a question.

When using a 32bit userland in combination with a 64bit kernel, which of the partition UUIDs should be used?

1. The userland defines the architecture and therefore it should be the 32bit UUID.
2. The kernel defines the architecture and therefore it should be the 64bit UUID.

For example, the i386 architecture on Debian no longer comes with a kernel image. Installations are expected to combine the i386 userland with an amd64 kernel or use i386 as container environment (e.g. flatpak).

A third way of clarifying this is explicitly stating that such a mixing of architectures is out of scope for the DPS.

[bluca]

Many CPUs support multiple flavours of kernels - for example you can run an armv7 kernel on an arm64 CPU, or an i586 kernel on an x86-64 CPU, or have dual-endian CPUs like the PPCs. And then those kernel variations may themselves support multiple userspaces - an armv7 hardware float kernel may load and run an armv7 software float userspace. So the cpu and/or kernel are not a good indicator.

If this spec was meant to represent "based on this kernel and/or cpu then load THIS", it couldn't possibly work universally for the aforementioned reasons, and it would basically just work for the dumbed down, trivial cases -> x86-64 -> x86-64, arm64 -> arm64, etc.

So the next thing to consider is that a /usr/ or /root/ partition may host N binary and library userspace ABI architectures. But it will have a single well-known entry point that the initrd jumps to, /usr/sbin/init or /usr/lib/systemd/systemd.

If the main purpose of this spec is instead to allow auto-discovery and identifications of the next stage at boot, then the most logical conclusion is that it would be the 32bit UUID, as if you mount that partition and jump into its entry point (/usr/sbin/init) you'd be loading 32bit userspace, not 64bit. This allows the previous stage to know what the next stage contains, and if there are multiple options, it can use its own logic to pick the one it wants/prefers.

Basically it boils down to whether the spec's purpose is to mandate what the next stage is, or to describe what it is and let the earlier stage decide.

Unfortunately this, for unfathomable reasons, has proven to be controversial so don't expect a resolution any time soon, or ever:

systemd/systemd#33745
#110

[poettering]

note that the gpt-auto logic already supports such mixed setups: i.e. if you have an x86-64 UKI and tell it to boot from a DDI then it will first look for an x86-64 tree, and if it cannot find that, will look for an i386 tree.

So, maybe the spec currently doesn't make this clear: but my intention when i put this together originally, and the code that consumes it is that userspace picks the arch, not kernelspace, and that transitioning into a secondary narrower-width arch is a thing we should support. The root fs used is decided based on what the initial userspace is compiled for though, not what the kernel is. i.e. if the systemd binary the kernel first invokes as pid 1 is 32bit, then the whole rest will be 32bit, but if it is 64bit, then we are fine with transitioning into either 64bit or 32bit later.

patches to put this in cleaner words and adding this to the spec would be most welcome of course.