On 5/27/21 11:10, Michael Ivanov wrote:

Greetings!

I have some strange problem with buildah when trying to execute a command in the container being built. I have approximately following procedure:

container=`buildah from scratch` fs=$(buildah unshare buildah mount $container) dnf="dnf --release 8 --installroot=$fs"

buildah unshare mkdir -p $fs/etc/yum.repos.d $fs/etc/pki/rpm-gpg buildah unshare cp centos8-repos/*.repo $fs/etc/yum.repos.d buildah unshare cp centos8-repos/RPM-GPG-KEY* $fs/etc/pki/rpm-gpg

buildah unshare $dnf install -y -q $instopts \   redhat-release glibc-langpack-en glibc-langpack-de glibc-langpack-ru bash shadow-utils

buildah unshare ls -l $fs buildah unshare rpm -qa --root $fs | sort

buildah run $container id buildah run $container groupadd -g 1000 mygroup buildah run $container useradd -u 1001 -g mygroup -s /bin/bash -m myuser .  .  .  .  . buildah unshare $dnf clean all -y buildah unshare rm -rf $fs/var/cache/dnf

buildah unshare buildah umount $container

buildah config --label maintainer='. . . . . .' \                --label description='. . . . . .' \                --workingdir=/home/myuser \                --cmd /bin/bash \                --user myuser:mygroup $container

buildah commit $container base-cs8:$version

When I run this script in debian unstable (buildah 1.19.6), it completes successfully. But when I run same script on centos 8 with stock buildah (1.16.7), then all commands (id, groupadd and useradd) are reported as not found, even when I specify them using full names. Corresponding packages are reported to be present by rpm -qa above. Same behavior occurs when I install buildah from devel:kibic:libcontainers:stable.repo.

What do I do wrong on centos8?

Best regards,

-- \ / | | (OvO) | Михаил Иванов | (^^^) | | \^/ | E-mail:ivans@isle.spb.ru | ^ ^ | |

_______________________________________________ Buildah mailing list -- buildah@lists.buildah.io To unsubscribe send an email to buildah-leave@lists.buildah.io

Is this on a native system or running buildah within a container? This could definitely be an issue with fuse-overlay in rootless mode. Could you update to Centos 8.4 and see if the problem goes away.

The environment created by `buildah unshare` includes its own kernel mount namespace, so a filesystem that's mounted inside that environment won't be mounted for the shell (or script) that invoked `buildah unshare`, and it won't still be there for the next command. In short, a path returned by "buildah mount ..." from inside of a "buildah unshare" shell isn't guaranteed to be meaningful outside of that "buildah unshare" shell. The big exception to that is when you're using the "vfs" driver, which doesn't actually mount anything, and the "mountpoint" you get back from "buildah unshare buildah mount $container" is just a plain directory, both inside and outside of the `buildah unshare` environment. I suspect the difference in behavior you're seeing between the two cases is due to different storage drivers being used -- if one of them is using "vfs" and the other is using "overlay", for example, that would explain the difference what you're seeing. It's possible to work around that, though. The `buildah unshare` command can be told to mount the container's rootfs and set an environment variable to point to it using its "--mount" flag, and the command will be able to reference the variable if the shell that tries to expand the variable is run under `buildah unshare`. `buildah cp` will also create destination directories when it has to, so you can use it directly instead of `unshare`, and while the quoting is still a little awkward, this will probably work: container=$(buildah from scratch) buildah copy $container centos8-repos/*.repo /etc/yum.repos.d/ buildah copy $container centos8-repos/RPM-GPG-KEY* /etc/pki/rpm-gpg/ buildah unshare --mount fs=$container \ sh -c 'dnf --release 8 install -y -q --installroot $fs \   redhat-release glibc-langpack-en glibc-langpack-de \ glibc-langpack-ru bash shadow-utils' buildah run $container rpm -qa | sort At that point there will be enough in the container rootfs for `buildah run` to be able to exec things in the rootfs, and you should be all set. When I tried this on my box, dnf was looking for GPG keys outside of the chroot, i.e., in the host's /etc/pki/rpm-gpg, and dnf was new enough that it wasn't creating a database in the chroot in the same format that "rpm" on CentOS 8 expected, so "rpm -qa" produced an empty list, but those are problems that buildah isn't in a position to solve. HTH, Nalin