Good suggestion, but busybox is not in the opensuse/tumbleweed archive. It is in the opensuse/busybox image, but that image is too minimal for my needs (doesn't have zypper). On 3/7/21 2:44 PM, Stefan Seyfried wrote:

If busybox is in the container, then use that:

    busybox linux32 zypper ...

Have fun,

Thanks for the tip, it works fine. It would indeed be great to make 'arch = i686' the default for relevant docker images as zypper would 'just work'. The setarch command included in the image would still be useful for other software needing correct 'arch' or 'uname -m' output to work properly. Ideally this should be fixed at the docker/podman level so these commands return the proper arch, but I could not find anything about it. That's curious since these commands return expected arch for containers run with the linux/arm64 and linux/arm docker platforms. On 3/7/21 3:52 PM, Fabian Vogt wrote:

This can be overridden in /etc/zypp/zypp.conf:

sed -i 's/# arch = s390/arch = i686/' /etc/zypp/zypp.conf

For 32bit x86, this could possibly be overwritten in the image itself. For x86_64, autodetection could also result in packages for e.g. "znver2" to be selected, which hardcoding would break. For container images that might be a good thing though, to make them more portable.

On Monday 08 March 2021 15:22:47 Fabian Vogt wrote:

Moin,

Am Sonntag, 7. März 2021, 16:35:26 CET schrieb Michael Pujos:

...

Thanks for the tip, it works fine. It would indeed be great to make 'arch = i686' the default for relevant docker images as zypper would 'just work'.

For 32bit ARM/x86 I don't see any reason against this.

I'm wondering whether forcing it to "arch = $(rpm -q --qf %{arch} glibc)" would be a good idea for container images in general. I CC'd some relevant people. That way, installing possibly build-system dependent packages is "opt-in" instead of "opt-out". I don't think we have any in the distro yet (except for i586 vs i686), but that might change in the future and third-party repos also exist.

Only downside I can think of is that when using the same host for building an image and running tasks inside, it might pick the generic x86_64, ... package instead of a possibly better matching arch.

Zypp will obey to arch= if runnig inside the container. From the outside '--root /the/container' it will use the outer systems arch. Depending on your settings it might not be a good idea to mix both ways. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres, E&I, ma@suse.com, Phone: ++49 (0)911 - 74 053-0 +------------------------------------------------------------------+ SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg Germany, (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer +------------------------------------------------------------------+

On Tue, Mar 9, 2021 at 3:03 PM Cristian Rodríguez wrote:

...

Shouldn't (personality (0xffffffff) & PER_LINUX_32BIT) return true when called from a process that is using a different execution domain.. Can kernel péople comment on what is the right thing to test for ?

It appears to be PER_LINUX32 .. so.. if uname machine is x86_64 && (personality (0xffffffff) & PER_LINUX32) then zypp should install 32 bit resolvables..

On 3/8/21 3:22 PM, Fabian Vogt wrote:

For 32bit ARM/x86 I don't see any reason against this.

I'm wondering whether forcing it to "arch = $(rpm -q --qf %{arch} glibc)" would be a good idea for container images in general. I CC'd some relevant people. That way, installing possibly build-system dependent packages is "opt-in" instead of "opt-out". I don't think we have any in the distro yet (except for i586 vs i686), but that might change in the future and third-party repos also exist.

Only downside I can think of is that when using the same host for building an image and running tasks inside, it might pick the generic x86_64, ... package instead of a possibly better matching arch.

In my experience, this issue only exist when building (or running) linux/386 containers under a x86_64 host. I found what must be done for 'arch' and 'uname -m' value to be correct (i686) at the docker level. Docker must run the container via qemu-i386 with binfmt. This binfmt (and many others) can be registered with: docker run --privileged --rm tonistiigi/binfmt --install 386 (github project: https://github.com/tonistiigi/binfmt This is what recommended to use in conjunction with docker buildx) Then we have our i386 binfmt: $cat  /proc/sys/fs/binfmt_misc/qemu-i386 enabled interpreter /usr/bin/qemu-i386 flags: OCF offset 0 magic 7f454c4601010100000000000000000002000300 mask fffffffffffefe00fffffffffffffffffeffffff And we can run the i386 container with the proper arch: docker run --platform linux/386 --rm -it opensuse/tumbleweed arch i686 Interestingly, openSUSE provides its own package (qemu-linux-user) to register binfmt for many qemu archs. To register i386: #HOST_ARCH must be set to a non x86 family arch for the script to accept to register i386 ! sudo HOST_ARCH=arm /usr/sbin/qemu-binfmt-conf.sh --systemd i386 sudo /usr/lib/systemd/systemd-binfmt However, all binfmt registered this way are not compatible with docker (it will refuse to use them). Here the binfmt registered above for i386: cat  /proc/sys/fs/binfmt_misc/qemu-i386 enabled interpreter /usr/bin/qemu-i386-binfmt flags: P offset 0 magic 7f454c460201010000000000000000000200b700 mask ffffffffffffff00fffffffffffffffffeffffff Notice the interpreter and flags that are different from binfmt registered with tonistiigi/binfmt, and that are not what docker expects. It's a bit unfortunate that qemu-binfmt-conf.sh does not generate binfmt entries compatible with docker.

On Monday 08 March 2021 17:57:17 Jan Engelhardt wrote:

It's how gcc works for example, so yeah. However, such default should not be in a config file, but be really built-in into the program (just like in gcc's case).

Well, gcc knows it runs only if a glibc to query is installed. Zypp however, e.g. when setting up a system via --root, does not know the arch of the target system in advance. In general ZYPP needs to now the architecture before any repos are loaded and OTOH applications (zypper/yast/pk) are not forced to set up the target(rpmdb) before they set up the repos. That's no issue, if the hardware determines the architecture. But if the target system defines the architecture, it may become a chicken/egg issue. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres, E&I, ma@suse.com, Phone: ++49 (0)911 - 74 053-0 +------------------------------------------------------------------+ SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg Germany, (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer +------------------------------------------------------------------+

On Mon, Mar 8, 2021 at 6:52 PM Jan Engelhardt wrote:

On Tuesday 2021-03-09 00:43, Michael Andres wrote:

...

On Monday 08 March 2021 17:57:17 Jan Engelhardt wrote:

...

It's how gcc works for example, so yeah. However, such default should not be in a config file, but be really built-in into the program (just like in gcc's case).

Zypp however, e.g. when setting up a system via --root, does not know the arch of the target system in advance.

Well, since we're talking *defaults*, it should be the same as the zypper in the source system. If you need a different arch in the target, you can always put a zypp.conf into $chroot/etc/ before running zypper itself. Just as you have to put some .repo files in $chroot/etc/zypp/repos.d before zypper is willing to install anything.

For some comparison, you can tell DNF to force a specific architecture when building chroots from the command-line. On my openSUSE Tumbleweed system, the following works (I'm using dnf + rpm-repos-openSUSE-Tumbleweed):

sudo mkdir -p /var/lib/machines/opensuse-32bit sudo dnf --installroot=/var/lib/machines/opensuse-32bit --forcearch=i586 install openSUSE-release bash coreutils-single chroot /var/lib/machines/opensuse-32bit

This feature is used by Mock[1] (along with qemu-user-static) to be able to build packages for foreign architectures (like ARM, POWER, and s390x) when native support is not present. Mageia has a note on their wiki about using DNF this way with custom repo sets from the CLI[2], which can be helpful in scenarios where the repo definition on the host wouldn't work for making the chroot. [1]: https://github.com/rpm-software-management/mock/wiki/Feature-forcearch [2]: https://wiki.mageia.org/en/Using_DNF#Setting_up_a_container_for_a_non-native... -- 真実はいつも一つ！/ Always, there's only one truth!

On Tue, 9 Mar 2021, Michael Andres wrote:

On Monday 08 March 2021 17:57:17 Jan Engelhardt wrote:

...

It's how gcc works for example, so yeah. However, such default should not be in a config file, but be really built-in into the program (just like in gcc's case).

Well, gcc knows it runs only if a glibc to query is installed.

Zypp however, e.g. when setting up a system via --root, does not know the arch of the target system in advance. In general ZYPP needs to now the architecture before any repos are loaded and OTOH applications (zypper/yast/pk) are not forced to set up the target(rpmdb) before they set up the repos.

That's no issue, if the hardware determines the architecture. But if the target system defines the architecture, it may become a chicken/egg issue.

Yeah. I've long wanted a way to deploy an arm "chroot" in /usr/arm-suse-linux/sysroot for the purpose of cross-compiling. You might remember talking about this a few (10) years ago. See also https://hackweek.suse.com/projects/package-proper-cross-compilers It _should_ be as simple as # zypper --root /usr/arm-suse/linux/sysroot --arch arm {--noscripts,--scripts=qemu} install glibc-devel Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Am 09.03.21 um 09:48 schrieb Michael Andres:

On Tuesday 09 March 2021 08:51:52 Richard Biener wrote:

...

Yeah. I've long wanted a way to deploy an arm "chroot" in /usr/arm-suse-linux/sysroot for the purpose of cross-compiling. You might remember talking about this a few (10) years ago.

See also https://hackweek.suse.com/projects/package-proper-cross-compilers

It _should_ be as simple as

# zypper --root /usr/arm-suse/linux/sysroot --arch arm {--noscripts,--scripts=qemu} install glibc-devel Well 'ZYPP_TESTSUITE_FAKE_ARCH=arm zypper --root /usr/arm-suse/linux/sysroot...' could do the trick, though the variables name looks a bit hackisch. It was introduced in a time where you didn't have things images in mind.

Anyhow, turning the VAR into a --arch option to overwrite the auto detection is no big deal, if you find this helpful. It could be tied it to the usage of --root to prevent accidentally damaging the outer system.

We then should think about using qemu-user to run scripts in the chroot targets, debootstrap does that and we used the same trick to boostrap cross compile chroots in my previous job. -- Benjamin Zeller Systems Programmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuremberg, Germany Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer