Discussion:
[systemd-devel] Add ARCH parameter to /etc/os-release
Askar Safin
2013-04-06 00:50:58 UTC
Permalink
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

Askar Safin
Tollef Fog Heen
2013-04-06 07:42:19 UTC
Permalink
]] Askar Safin
Post by Askar Safin
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.
What should it look like when you have multiple architectures enabled?
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Askar Safin
2013-04-06 16:42:39 UTC
Permalink
Post by Tollef Fog Heen
What should it look like when you have multiple architectures enabled?
We can write all architectures separated
Tollef Fog Heen
2013-04-06 18:00:20 UTC
Permalink
]] Askar Safin
Post by Tollef Fog Heen
What should it look like when you have multiple architectures enabled?
We can write all architectures separated by spaces (and primary arch goes first).
What is "primary arch"? The arch of init? ls? the package manager?
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reindl Harald
2013-04-06 18:02:46 UTC
Permalink
Post by Tollef Fog Heen
]] Askar Safin
Post by Tollef Fog Heen
What should it look like when you have multiple architectures enabled?
We can write all architectures separated by spaces (and primary arch goes first).
What is "primary arch"? The arch of init? ls? the package manager?
usually the kernel ones?
Askar Safin
2013-04-06 20:37:04 UTC
Permalink
Post by Tollef Fog Heen
What is "primary arch"? The arch of init? ls? the package manager?
As far as I know today there is no true symmetric multiarch. Every multiarched system has one clear primary arch. And several additional arches. So, today (I think) the parameter ARCH should content all arches and the primary arch should go first. If this situation changes in the future, then ARCH can be list of equal arches.
Post by Tollef Fog Heen
usually the kernel ones?
Yes, this is good idea. But then, of course, this is arch of this system's own kernel,
Reindl Harald
2013-04-06 20:41:44 UTC
Permalink
Post by Askar Safin
Post by Tollef Fog Heen
What is "primary arch"? The arch of init? ls? the package manager?
As far as I know today there is no true symmetric multiarch. Every multiarched system has one clear primary arch. And several additional arches. So, today (I think) the parameter ARCH should content all arches and the primary arch should go first. If this situation changes in the future, then ARCH can be list of equal arches.
Post by Tollef Fog Heen
usually the kernel ones?
Yes, this is good idea. But then, of course, this is arch of this system's own kernel, not arch of current running kernel.
i would wonder if this below is not predictable the arch from the running kernel

[***@srv-rhsoft:~]$ /usr/bin/uname -i
x86_64
Zbigniew Jędrzejewski-Szmek
2013-04-06 22:37:49 UTC
Permalink
Post by Reindl Harald
Post by Askar Safin
Post by Tollef Fog Heen
What is "primary arch"? The arch of init? ls? the package manager?
As far as I know today there is no true symmetric multiarch. Every multiarched system has one clear primary arch. And several additional arches. So, today (I think) the parameter ARCH should content all arches and the primary arch should go first. If this situation changes in the future, then ARCH can be list of equal arches.
Post by Tollef Fog Heen
usually the kernel ones?
Yes, this is good idea. But then, of course, this is arch of this system's own kernel, not arch of current running kernel.
i would wonder if this below is not predictable the arch from the running kernel
x86_64
Exactly. Current arch is easily accessible through standard tools,
e.g. uname(1) and uname (2), and there's little point in putting
this in a static file which can become outdated on next boot. Also,
with debian/ubuntu multiarch, the difference between primary arch
and the rest is quite thin.

Zbyszek
Askar Safin
2013-04-06 23:07:06 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Also,
with debian/ubuntu multiarch, the difference between primary arch
and the rest is quite thin.
No. Debian has library multiarch only. This means you can install two libc (x86_64 and i386) but cannot install two bashes (x86_64 and i386). Moreover, "dpkg --print-architecture"
Zbigniew Jędrzejewski-Szmek
2013-04-06 23:35:37 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Also,
with debian/ubuntu multiarch, the difference between primary arch
and the rest is quite thin.
No. Debian has library multiarch only. This means you can install two libc (x86_64 and i386) but cannot install two bashes (x86_64 and i386). Moreover, "dpkg --print-architecture" will always print your primary arch.
Right, but you can install bash/amd64 and firefox/i386. And you can't
say that is more important than the other. Yes, dpkg knows the
"primary" architecture, but it's not that imporant.

Zbyszek
Tollef Fog Heen
2013-04-07 11:39:21 UTC
Permalink
]] Askar Safin
Post by Askar Safin
Post by Zbigniew Jędrzejewski-Szmek
Also,
with debian/ubuntu multiarch, the difference between primary arch
and the rest is quite thin.
No. Debian has library multiarch only. This means you can install two
libc (x86_64 and i386) but cannot install two bashes (x86_64 and
i386).
You can mix binaries from multiple architectures, though, as Zbigniew
wrote.
Post by Askar Safin
Moreover, "dpkg --print-architecture" will always print your
primary arch.
It just prints the architecture of dpkg. apt might very well be of a
different arch, for instance. There is no «primary arch» concept.

I was quite explicit about that when I initially designed multiarch. :-)
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Askar Safin
2013-04-07 13:10:53 UTC
Permalink
Post by Tollef Fog Heen
I was quite explicit about that when I initially designed multiarch. :-)
:)
Okey, okey, there is no primary arch :)
So, I think the arch which is the closest to be "primary arch" should go first.
Arch, which is the most suitable to be the arch in "setarch" command.
In some cases there is no such arch, but in the most popular cases we can pick some the most suitable arch.
I just want this to do the "setarch" trick or to do that "nspawn" trick.
It is useful to have some "default" arch.

For example, we can do the following in "nspawn":
1. If there is no any special option, it will read os-release and set (via trick similar to "setarch") arch which goes first in os-release
2. If there is some option (for example, --arch), it will set arch which is presented in this option. (Also, it may t
Koen Kooi
2013-04-07 07:56:09 UTC
Permalink
Post by Reindl Harald
Post by Askar Safin
Post by Tollef Fog Heen
What is "primary arch"? The arch of init? ls? the package manager?
As far as I know today there is no true symmetric multiarch. Every multiarched system has one clear primary arch. And several additional arches. So, today (I think) the parameter ARCH should content all arches and the primary arch should go first. If this situation changes in the future, then ARCH can be list of equal arches.
Post by Tollef Fog Heen
usually the kernel ones?
Yes, this is good idea. But then, of course, this is arch of this system's own kernel, not arch of current running kernel.
i would wonder if this below is not predictable the arch from the running kernel
x86_64
No, run that kernel on a 32bit Atom cpu and it will still return x86_64. I only /proc/cpuinfo had a standard layout :(

regards,

Koen
Reindl Harald
2013-04-07 09:47:02 UTC
Permalink
Post by Koen Kooi
Post by Reindl Harald
Post by Askar Safin
Post by Tollef Fog Heen
What is "primary arch"? The arch of init? ls? the package manager?
As far as I know today there is no true symmetric multiarch. Every multiarched system has one clear primary arch. And several additional arches. So, today (I think) the parameter ARCH should content all arches and the primary arch should go first. If this situation changes in the future, then ARCH can be list of equal arches.
Post by Tollef Fog Heen
usually the kernel ones?
Yes, this is good idea. But then, of course, this is arch of this system's own kernel, not arch of current running kernel.
i would wonder if this below is not predictable the arch from the running kernel
x86_64
No, run that kernel on a 32bit Atom cpu and it will still return x86_64
how will you do that?
Koen Kooi
2013-04-07 20:04:11 UTC
Permalink
Post by Reindl Harald
Post by Koen Kooi
Post by Reindl Harald
Post by Askar Safin
Post by Tollef Fog Heen
What is "primary arch"? The arch of init? ls? the package manager?
As far as I know today there is no true symmetric multiarch. Every multiarched system has one clear primary arch. And several additional arches. So, today (I think) the parameter ARCH should content all arches and the primary arch should go first. If this situation changes in the future, then ARCH can be list of equal arches.
Post by Tollef Fog Heen
usually the kernel ones?
Yes, this is good idea. But then, of course, this is arch of this system's own kernel, not arch of current running kernel.
i would wonder if this below is not predictable the arch from the running kernel
x86_64
No, run that kernel on a 32bit Atom cpu and it will still return x86_64
how will you do that?
Enable 64 bit support and 32 bit compat, build, boot.
Reindl Harald
2013-04-07 20:11:34 UTC
Permalink
Post by Koen Kooi
Post by Reindl Harald
Post by Koen Kooi
Post by Reindl Harald
Post by Askar Safin
Post by Tollef Fog Heen
What is "primary arch"? The arch of init? ls? the package manager?
As far as I know today there is no true symmetric multiarch. Every multiarched system has one clear primary arch. And several additional arches. So, today (I think) the parameter ARCH should content all arches and the primary arch should go first. If this situation changes in the future, then ARCH can be list of equal arches.
Post by Tollef Fog Heen
usually the kernel ones?
Yes, this is good idea. But then, of course, this is arch of this system's own kernel, not arch of current running kernel.
i would wonder if this below is not predictable the arch from the running kernel
x86_64
No, run that kernel on a 32bit Atom cpu and it will still return x86_64
how will you do that?
Enable 64 bit support and 32 bit compat, build, boot
bullshit, you can not run a 64bit kernel on a 32bit CPU
the other direction yes, but not this way

and even if - if your kernel is 64bit than your primary arch is 64 bit
Koen Kooi
2013-04-07 20:15:49 UTC
Permalink
Post by Reindl Harald
Post by Koen Kooi
Post by Reindl Harald
Post by Koen Kooi
Post by Reindl Harald
Post by Askar Safin
Post by Tollef Fog Heen
What is "primary arch"? The arch of init? ls? the package manager?
As far as I know today there is no true symmetric multiarch. Every multiarched system has one clear primary arch. And several additional arches. So, today (I think) the parameter ARCH should content all arches and the primary arch should go first. If this situation changes in the future, then ARCH can be list of equal arches.
Post by Tollef Fog Heen
usually the kernel ones?
Yes, this is good idea. But then, of course, this is arch of this system's own kernel, not arch of current running kernel.
i would wonder if this below is not predictable the arch from the running kernel
x86_64
No, run that kernel on a 32bit Atom cpu and it will still return x86_64
how will you do that?
Enable 64 bit support and 32 bit compat, build, boot
bullshit, you can not run a 64bit kernel on a 32bit CPU
the other direction yes, but not this way
Yes, you can, just set CONFIG_64BIT and 32 bit compat, the kernel will run fine on an Atom E6xx and uname will report x86_64.
Lennart Poettering
2013-04-08 13:02:47 UTC
Permalink
Post by Askar Safin
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
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
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.
Tollef Fog Heen
2013-04-08 14:23:21 UTC
Permalink
]] Lennart Poettering
Post by Lennart Poettering
c) you can convert a 32bit debian userspace into a 64bit debian
userspace with just a bit of apt package installation?
No, you can run multiple ABIs at the same time. Limiting yourself to
«32-bit» and «64-bit» is silly, you can transparently run, say, amd64,
i386 and arm code with dependencies between packages and such working
just fine. It's not conversion, it's supporting multiple ABIs at the
same time, within the same file system hierarchy, within the same
namespaces.
Post by Lennart Poettering
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?
I'm not sure what problem the proposal is trying to solve. Maybe it'd
be clearer if that was provided.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Askar Safin
2013-04-08 18:09:39 UTC
Permalink
Post by Tollef Fog Heen
I'm not sure what problem the proposal is trying to solve. Maybe it'd
be clearer if that was provided.
I want to know what is the arches of the systems on my computer. I. e. I want to do the following:

for DISK in /dev/sd*; do
mount "$DISK" /mnt
source /mnt/etc/os-release
echo "Arch of $DISK is $ARCH"
done

And I want to use this $ARCH to do "setarch", i. e.:
mount /dev/some-dev /mnt
source /mnt/etc/os-release
setarch "$ARCH" chroot /mnt
So, this /mnt system will see "uname -m" output which i
Lennart Poettering
2013-04-17 18:19:59 UTC
Permalink
Post by Askar Safin
Post by Tollef Fog Heen
I'm not sure what problem the proposal is trying to solve. Maybe it'd
be clearer if that was provided.
for DISK in /dev/sd*; do
mount "$DISK" /mnt
source /mnt/etc/os-release
echo "Arch of $DISK is $ARCH"
done
mount /dev/some-dev /mnt
source /mnt/etc/os-release
setarch "$ARCH" chroot /mnt
So, this /mnt system will see "uname -m" output which is meaningful for the system.
My suggestion would be to write a little tool that does the equivalent
to this:

readelf -h /usr/lib*/libdl*.so | grep Machine | cut -c38- | uniq

This will list you the architectures for which you have dynamic loaders
installed. Since the dynamic loaders are hardcoded in all dynamic ELF
binaries this list will tell you binaries of which archs you can execute
on your system.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Koen Kooi
2013-04-18 07:26:36 UTC
Permalink
Post by Lennart Poettering
Post by Askar Safin
Post by Tollef Fog Heen
I'm not sure what problem the proposal is trying to solve. Maybe it'd
be clearer if that was provided.
for DISK in /dev/sd*; do
mount "$DISK" /mnt
source /mnt/etc/os-release
echo "Arch of $DISK is $ARCH"
done
mount /dev/some-dev /mnt
source /mnt/etc/os-release
setarch "$ARCH" chroot /mnt
So, this /mnt system will see "uname -m" output which is meaningful for the system.
My suggestion would be to write a little tool that does the equivalent
readelf -h /usr/lib*/libdl*.so | grep Machine | cut -c38- | uniq
This will list you the architectures for which you have dynamic loaders
installed. Since the dynamic loaders are hardcoded in all dynamic ELF
binaries this list will tell you binaries of which archs you can execute
on your system.
On my i7 laptop:

[***@rrMBP mplayer2]$ readelf -h /usr/lib*/libdl*.so | grep Machine | cut -c38- | uniq
Advanced Micro Devices X86-64
Intel 80386

And on a cortex A8 device:

***@beaglebone:~# readelf -h /usr/lib*/libdl*.so | grep Machine | cut -c38- | uniq
ARM

So it returns something that could be considered usefull on my laptop, but the output on the beaglebone is useless. On ARM you need to know the following to see if you can execute the binary:

1) instruction set revision (armvX, e.g. armv5te, armv6, armv7a)
2) OABI or EABI
3) floating point calling conventions, softp vs hardfp

The first item is like i386, i486 etc. It's compatible only one way. The second is academical at this point, only luddites running kernel 2.4 are interested in OABI.
And then we get to the clusterfuck, floatingpoint ABI. I need to install binutils on my hardfloat system to see if that also says 'ARM', I bet it does.

But it does answer the "can I nspawn into this rootfs?" question for different architectures like powerpc vs x86 :)

regards,

Koen
Tollef Fog Heen
2013-04-18 08:06:20 UTC
Permalink
]] Koen Kooi
Post by Koen Kooi
But it does answer the "can I nspawn into this rootfs?" question for
different architectures like powerpc vs x86 :)
No, it doesn't. You'll have false negatives, think about binfmt_misc
combined with qemu user emulation for instance.

The right way to see if you can do that is to try. Just like you
shouldn't use access(2) and then open(2) it, you should just open it and
handle failure.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Lennart Poettering
2013-04-18 12:08:33 UTC
Permalink
Post by Koen Kooi
1) instruction set revision (armvX, e.g. armv5te, armv6, armv7a)
2) OABI or EABI
3) floating point calling conventions, softp vs hardfp
Are these even encoded in the ELF header? If you take an armv7a binary
and execute it on arm5te, what happens? will the kernel quickly say
"Nah, incompatible binary"? Or will it run until the first unknown
instruction comes and the segfault or sigbus?

Lennart
--
Lennart Poettering - Red Hat, Inc.
Askar Safin
2013-04-18 13:29:42 UTC
Permalink
Koen Kooi
2013-04-19 06:50:50 UTC
Permalink
Post by Lennart Poettering
Post by Koen Kooi
1) instruction set revision (armvX, e.g. armv5te, armv6, armv7a)
2) OABI or EABI
3) floating point calling conventions, softp vs hardfp
Are these even encoded in the ELF header? If you take an armv7a binary
and execute it on arm5te, what happens? will the kernel quickly say
"Nah, incompatible binary"? Or will it run until the first unknown
instruction comes and the segfault or sigbus?
Usually sigbus, but it depends on what you're trying to mix. It's a mess on ARM, don't try to understand it :)

regards,

Koen

Askar Safin
2013-04-08 17:59:50 UTC
Permalink
Post by Lennart Poettering
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?
I think there should be some plain text file with arch. Because this gives us chance to determine arch of some foreign system even if we cannot chroot to it. Thus, we can gather information about other systems installed on this computer, about systems presented in loop devices etc.
Post by Lennart Poettering
c) you can convert a 32bit debian userspace into a 64bit debian
userspace with just a bit of apt package installation?
No. The command "dpkg --print-architecture" prints primary arch and it cannot be changed. (Also, "dpkg --print-foreign-architectures" prints all other, i. e. foreign arches.) Yes, theoretically this is an arch of the dpkg itself. So, theoretically it is possible to remove 32-bit dpkg and install 64-bit dpkg. But this is not intended use of debian multiarch. I tried to do this and this failed. (This is log: http://paste.debian.net/248291 .) But then, I tried harder and converted 32-bit debian to 64-bit one :) This is new log: http://paste.org.ru/?6ay51x . (I used my own util asdebootstrap, which is similar to debootstrap, of course, I can show its source code.) But this was very tricky and this was complete abuse of Debian system. And of course, this is not supported at this time. Maybe in the future there will be OK to convert 32-bit system to
Greg KH
2013-04-08 18:28:54 UTC
Permalink
Post by Askar Safin
Post by Lennart Poettering
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?
I think there should be some plain text file with arch. Because this
gives us chance to determine arch of some foreign system even if we
cannot chroot to it. Thus, we can gather information about other
systems installed on this computer, about systems presented in loop
devices etc.
The problem is, as numerous people are pointing out, this is a
non-trivial thing to determine, and lots of times, there is no "correct"
value at all.

So no matter what you pick, it could be wrong, so don't pick anything
and just go with the hints that the filesystem and kernel provide you
already today, if you really need to try to determine this type of thing
(hint, I don't think it's as useful as you think...)

greg k-h
Loading...