1:33 p.m.
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