[systemd-devel] Add ARCH parameter to /etc/os-release

[Lennart Poettering]

On Sat, 06.04.13 04:50, Askar Safin (safinaskar at mail.ru) wrote:

>  Please standardize and recommend new /etc/os-release parameter:
>  ARCH. It will content architecture of this distro (i. e. i386,
>  x86_64, ...). There are some cases when this value differs from
>  current kernel architecture (as typically reported by uname -m). For
>  example, when you are in chroot environment or when you just mounted
>  some other OS and want to know what is architecture of this OS.
> 
> I. e. I suggest this parameter to contain architecture of the distro,
> i. e. userspace, not kernel. So, you can even name it USERSPACE_ARCH
> or DISTRO_ARCH, but I think this is too long.
> 
> I think this should be GNU architecture (i386, x86_64) and not Debian
> architecture (i386, amd64). Because GNU architecture is (as far as I
> know) more widely used. Also, this enables you to compare it with
> "uname -m" output. And this allow you to use "setarch" (see below)
> 
> This parameter will be very useful if you want to chroot to some
> distro. First, you can read this parameter to determine whenever you
> can chroot to this OS. Second, you can read this parameter and then
> set arch (which you just read) via the setarch (8) util from
> util-linux-ng. This useful trick will let programs in chroot think
> they are on native arch. I. e. this will make the following code
> possible:
> 
> source /target/etc/os-release setarch "$ARCH" chroot /target
> 
> Also, I recommend to add similar trick to systemd-nspawn!
> 
> Also, maybe this is good idea to set this parameter to particular CPU
> instruction set (i386, i486, ...). Or even to add two options: one for
> widely used architecture name (for example, i386) and another more
> specific name (for example, i486). Of course, this parameters will not
> refer to kernel arch nor to arch of current machine. They will refer
> to arch this distro compiled for.
> 
> Probably this is good idea to add parameter even for GNU triplet. Of
> course, you can determine it via "gcc -v", but this raises two issues:
>
> 1. gcc may be not installed on the system 2. this will not work if you
> cannot even chroot to target system

Hmm, so reading though this thread it appears that:

a) uname()'s machine field doesn't actually indicate what mode the
   kernel is running in.

b) there appears to be no sane way to figure out which ELF binary
   architectures the current cpu+kernel+ld.so support?

c) you can convert a 32bit debian userspace into a 64bit debian
   userspace with just a bit of apt package installation? Which
   essential makes the primary userspace arch a changeble user setting
   rather than a fixed property of the distribution? (Which is different
   from Fedora, where we support multilib too, but where one arch is
   always the clear primary, and all others just secodnary...)

So, the desire is to somehow expose a list of arch specifiers that are
supported by all three of the current CPU, the current kernel and the
installed ld.sos. 

Now, on Fedora at least the package containing /etc/os-release is
arch-independent. It installs the exact same file on all archs, and I
figure that might actually be a good thing. Which makes it a bit
unsuitable for configuring the arch...

I wonder if it wouldn't be a better idea to somehow provide a sane API
for this functionality rather than defining a configuration file format
for it?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.