Re: Installing some packages from opensuse/tumbleweed docker i586 image tries to install x86_64 packages
The problem comes from docker, returning x86_64 (the arch of the host) in both 'uname -m' and arch outputs: $docker run --platform linux/386 -it registry.opensuse.org/opensuse/tumbleweed arch x86_64 This confuses zypper, not retrieving the correct arch repo for the container. There does not see to be a solution at the docker/podman level to return the proper output for these commands. A workaround with to use setarch: $setarch i586 zypper ... or its linux32 shortcut: $linux32 zypper.... The problem is that setarch part of util-linux, which cannot be installed with zypper. So it would be a good idea to include the linux32 command in the i586 containers, without the entire util-linux package. For the time being, I'm copying in the Dockerfile the setarch 32-bit binary into the image and use that.
This happens installing some packages (here wget, but also java-1_8_0-openjdk-headless, shadow) with zypper in the i586 (linux/386 platform in docker parlance) flavor of the tumbleweed docker image. Noticed that as I'm trying to build a custom multiarch docker image based on opensuse/tumbleweed
///
docker run --platform linux/386 -it registry.opensuse.org/opensuse/tumbleweed Problem: wget-1.21.1-1.2.x86_64 requires libc.so.6(GLIBC_2.33)(64bit), but this requirement cannot be provided not installable providers: glibc-2.33-2.1.x86_64[repo-oss] Solution 1: Following actions will be done: architecture change of glibc-2.33-2.1.i586 to glibc-2.33-2.1.x86_64 architecture change of libgpgme11-1.15.1-1.2.i586 to libgpgme11-1.15.1-1.2.x86_64 architecture change of libidn2-0-2.3.0-3.3.i586 to libidn2-0-2.3.0-3.3.x86_64 architecture change of libopenssl1_1-1.1.1j-1.1.i586 to libopenssl1_1-1.1.1j-1.1.x86_64 architecture change of libproxy1-0.4.17-1.2.i586 to libproxy1-0.4.17-1.2.x86_64 architecture change of libpsl5-0.21.1-1.3.i586 to libpsl5-0.21.1-1.3.x86_64 architecture change of libz1-1.2.11-18.2.i586 to libz1-1.2.11-18.2.x86_64 architecture change of libassuan0-2.5.4-1.2.i586 to libassuan0-2.5.4-1.2.x86_64 architecture change of libgpg-error0-1.41-1.2.i586 to libgpg-error0-1.41-1.2.x86_64 architecture change of libunistring2-0.9.10-2.9.i586 to libunistring2-0.9.10-2.9.x86_64 architecture change of libgcc_s1-11.0.0+git183291-1.2.i586 to libgcc_s1-11.0.0+git183291-1.2.x86_64 architecture change of libstdc++6-11.0.0+git183291-1.2.i586 to libstdc++6-11.0.0+git183291-1.2.x86_64 Solution 2: do not install wget-1.21.1-1.2.x86_64 Solution 3: break wget-1.21.1-1.2.x86_64 by ignoring some of its dependencies
On 07.03.21 13:55, Michael Pujos wrote:
A workaround with to use setarch:
$setarch i586 zypper ...
or its linux32 shortcut:
$linux32 zypper....
The problem is that setarch part of util-linux, which cannot be installed with zypper.
So it would be a good idea to include the linux32 command in the i586 containers, without the entire util-linux package. If busybox is in the container, then use that:
busybox linux32 zypper ... Have fun, -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
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,
Hi, Am Sonntag, 7. März 2021, 13:55:13 CET schrieb Michael Pujos:
The problem comes from docker, returning x86_64 (the arch of the host) in both 'uname -m' and arch outputs:
$docker run --platform linux/386 -it registry.opensuse.org/opensuse/tumbleweed arch x86_64
This confuses zypper, not retrieving the correct arch repo for the container.
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. Cheers, Fabian
There does not see to be a solution at the docker/podman level to return the proper output for these commands.
A workaround with to use setarch:
$setarch i586 zypper ...
or its linux32 shortcut:
$linux32 zypper....
The problem is that setarch part of util-linux, which cannot be installed with zypper.
So it would be a good idea to include the linux32 command in the i586 containers, without the entire util-linux package.
For the time being, I'm copying in the Dockerfile the setarch 32-bit binary into the image and use that.
This happens installing some packages (here wget, but also java-1_8_0-openjdk-headless, shadow) with zypper in the i586 (linux/386 platform in docker parlance) flavor of the tumbleweed docker image. Noticed that as I'm trying to build a custom multiarch docker image based on opensuse/tumbleweed
///
docker run --platform linux/386 -it registry.opensuse.org/opensuse/tumbleweed Problem: wget-1.21.1-1.2.x86_64 requires libc.so.6(GLIBC_2.33)(64bit), but this requirement cannot be provided not installable providers: glibc-2.33-2.1.x86_64[repo-oss] Solution 1: Following actions will be done: architecture change of glibc-2.33-2.1.i586 to glibc-2.33-2.1.x86_64 architecture change of libgpgme11-1.15.1-1.2.i586 to libgpgme11-1.15.1-1.2.x86_64 architecture change of libidn2-0-2.3.0-3.3.i586 to libidn2-0-2.3.0-3.3.x86_64 architecture change of libopenssl1_1-1.1.1j-1.1.i586 to libopenssl1_1-1.1.1j-1.1.x86_64 architecture change of libproxy1-0.4.17-1.2.i586 to libproxy1-0.4.17-1.2.x86_64 architecture change of libpsl5-0.21.1-1.3.i586 to libpsl5-0.21.1-1.3.x86_64 architecture change of libz1-1.2.11-18.2.i586 to libz1-1.2.11-18.2.x86_64 architecture change of libassuan0-2.5.4-1.2.i586 to libassuan0-2.5.4-1.2.x86_64 architecture change of libgpg-error0-1.41-1.2.i586 to libgpg-error0-1.41-1.2.x86_64 architecture change of libunistring2-0.9.10-2.9.i586 to libunistring2-0.9.10-2.9.x86_64 architecture change of libgcc_s1-11.0.0+git183291-1.2.i586 to libgcc_s1-11.0.0+git183291-1.2.x86_64 architecture change of libstdc++6-11.0.0+git183291-1.2.i586 to libstdc++6-11.0.0+git183291-1.2.x86_64 Solution 2: do not install wget-1.21.1-1.2.x86_64 Solution 3: break wget-1.21.1-1.2.x86_64 by ignoring some of its dependencies
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.
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. Input welcome. Cheers, Fabian
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 Mon, Mar 8, 2021 at 12:34 PM Michael Andres <ma@suse.com> wrote:
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.
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.
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 ?
On Tue, Mar 9, 2021 at 3:03 PM Cristian Rodríguez <crrodriguez@opensuse.org> 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 Tuesday 2021-03-09 19:03, Cristian Rodríguez wrote:
On Mon, Mar 8, 2021 at 12:34 PM Michael Andres <ma@suse.com> wrote: 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.
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.
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 ?
I don't think the personality bits are the right thing. uname *certainly* isn't the right thing. Think of systems comprised of "aarch64ilp32" or "sparcv9" packages, for example.
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 2021-03-08 15:22, Fabian Vogt wrote:
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'.
I'm wondering whether forcing it to "arch = $(rpm -q --qf %{arch} glibc)" would be a good idea for container images in general.
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).
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 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.
On Mon, Mar 8, 2021 at 6:52 PM Jan Engelhardt <jengelh@inai.de> 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 Mon, Mar 8, 2021 at 8:38 PM Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, Mar 8, 2021 at 6:52 PM Jan Engelhardt <jengelh@inai.de> 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...
I also just verified that this can be trivially tested using the opensuse/tumbleweed-dnf container in Podman, too. :) $ podman run --rm -it opensuse/tumbleweed-dnf The commands I listed earlier work inside it just fine. :) -- 真実はいつも一つ！/ 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 <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
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. -- 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 +------------------------------------------------------------------+
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 <bzeller@suse.de> 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
On Tue, 9 Mar 2021, Michael Andres wrote:
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.
Yeah, it definitely would be nice. I'm not sure whether rpm stores some "global" architecture in the rpmdb so further sanitization based on that could be done as well. As said, scripts handling needs some magic as well, or alternatively some --noscripts option or a way to check the transaction for LUA-only scriptlets (it would be nice to have the "bootstrap" set of packages be fully LUA-only - I guess for a native install we rely on the unpack-w/o-scripts and then script invocation strathegy to handle pre-in scriptlets on an empty system) Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
participants (9)
-
Benjamin Zeller -
Cristian Rodríguez -
Fabian Vogt -
Jan Engelhardt -
Michael Andres -
Michael Pujos -
Neal Gompa -
Richard Biener -
Stefan Seyfried