Fail to build image with --isolation chroot #1568

42wim · 2019-05-02T20:53:33Z

Description

Fails to build an image using --isolation chroot (works fine with default setting)

Steps to reproduce the issue:

Use Dockerfile

FROM centos:7
RUN yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
RUN yum -y install npm
RUN npm version

Run buildah bud --isolation chroot .

Describe the results you received:

npm version fails

STEP 4: RUN npm version
module.js:478
    throw err;
    ^

Error: Cannot find module 'npmlog'
    at Function.Module._resolveFilename (module.js:476:15)
    at Function.Module._load (module.js:424:25)
    at Module.require (module.js:504:17)
    at require (internal/module.js:20:19)
    at /usr/bin/npm:19:13
    at Object.<anonymous> (/usr/bin/npm:75:3)
    at Module._compile (module.js:577:32)
    at Object.Module._extensions..js (module.js:586:10)
    at Module.load (module.js:494:32)
    at tryModuleLoad (module.js:453:12)
subprocess exited with status 1
subprocess exited with status 1
error building at STEP "RUN npm version": exit status 1

Describe the results you expected:
The output of buildah bud .

STEP 4: RUN npm version
{ npm: '3.10.10',
  ares: '1.10.1-DEV',
  http_parser: '2.8.0',
  icu: '50.1.2',
  modules: '48',
  napi: '3',
  node: '6.16.0',
  openssl: '1.0.2k-fips',
  uv: '1.27.0',
  v8: '5.1.281.111',
  zlib: '1.2.7' }
STEP 5: COMMIT
Getting image source signatures
Copying blob d69483a6face skipped: already exists
Copying blob b89848b8c540 done
Copying config 1e8125779f done
Writing manifest to image destination
Storing signatures
--> 1e8125779fdeb3c0b15bda39773271835bd90e223f6d846ee6e90b5c477b1f1a

Output of buildah version:

Running 1.8.1 but same issue on 1.6 and 1.7.x

Version:         1.8.1
Go Version:      go1.12.4
Image Spec:      1.0.0
Runtime Spec:    1.0.0
CNI Spec:        0.4.0
libcni Version:  v0.7.0-rc2
Git Commit:      3b1400e
Built:           Thu May  2 10:42:49 2019
OS/Arch:         linux/amd64

Tested on centos 7.5
Linux test-1 3.10.0-862.14.4.el7.x86_64 #1 SMP Wed Sep 26 15:12:11 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

And centos 7.6
Linux test-2 5.0.5-1.el7.elrepo.x86_64 #1 SMP Wed Mar 27 13:30:25 EDT 2019 x86_64 x86_64 x86_64 GNU/Linux

The text was updated successfully, but these errors were encountered:

rhatdan · 2019-05-02T20:56:32Z

Any idea what NPM is doing?

TomSweeneyRedHat · 2019-05-02T20:56:43Z

Thanks @42wim for the issue. Just to make sure, were you running as a root or non-root user?

42wim · 2019-05-02T21:02:13Z

Running as root user on all tests.
First test was in a docker container hence the --isolation chroot, other tests where on the different hosts.

Also just did the test as a non-root user (only on the system with 5.x kernel) with exactly the same result

buildah bud . works fine
buildah bud --isolation chroot . fails

42wim · 2019-05-02T21:04:28Z

Any npm command fails btw, not only the version.
Tried to debug it myself but got stuck.

rhatdan · 2019-05-02T21:05:18Z

Most likely something to do with the way /proc or /sys is setup in the chroot. It would be really helpful if we could see exactly what is failing in npm

Could you add strace to your container and then run strace npm version
And see if that gives us anything useful.

rhatdan · 2019-05-02T21:13:26Z

BTW This worked for me.

buildah bud --isolation chroot /tmp/
...
{ npm: '3.10.10',
  ares: '1.10.1-DEV',
  http_parser: '2.8.0',
  icu: '50.1.2',
  modules: '48',
  napi: '3',
  node: '6.16.0',
  openssl: '1.0.2k-fips',
  uv: '1.27.0',
  v8: '5.1.281.111',
  zlib: '1.2.7' }
STEP 5: COMMIT
Getting image source signatures
Copying blob d69483a6face skipped: already exists
Copying blob 33415a147f41 done
Copying config 4b5a980aaa done
Writing manifest to image destination
Storing signatures
--> 4b5a980aaa3e04d6533447fa2fff23f2b61a435bc01f9e171f724144f4e5e769

rhatdan · 2019-05-02T21:13:44Z

buildah version
Version: 1.8.0
Go Version: go1.12.2
Image Spec: 1.0.0
Runtime Spec: 1.0.0
CNI Spec: 0.4.0
libcni Version:
Git Commit:
Built: Wed Dec 31 19:00:00 1969
OS/Arch: linux/amd64

42wim · 2019-05-02T21:18:18Z

Is this what you mean?
Doesn't give much info

FROM centos:7
RUN yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
RUN yum -y install npm strace
RUN strace -s4000 -o /tmp/strace/output -ff npm version

buildah bud -v $PWD/output:/tmp/strace --isolation chroot .

ls -al output/*
-rw-r--r-- 1 root root 28 May  2 23:09 output/output
-rw-r--r-- 1 root root 22 May  2 23:11 output/output.20842

# cat output/*
19543 +++ exited with 1 +++
+++ exited with 1 +++

42wim · 2019-05-02T21:28:53Z

Didn't try on 1.8.0 but juist build it, same results for me (as in still failing)

Version:         1.8.0
Go Version:      go1.12.4
Image Spec:      1.0.0
Runtime Spec:    1.0.0
CNI Spec:        0.4.0
libcni Version:  v0.7.0-rc2
Git Commit:      4aa16cf
Built:           Thu May  2 23:25:13 2019
OS/Arch:         linux/amd64

TomSweeneyRedHat · 2019-05-02T21:30:25Z

Maybe runc? What version do you have @42wim?

42wim · 2019-05-02T21:37:27Z

On the centos 7.5 box the default centos one: runc-1.0.0-59.dev.git2abd837.el7.centos.x86_64
On the centos 7.6 box a newer version: runc-1.0.0-89.dev.git029124d.el7

42wim · 2019-05-02T22:33:09Z

Did some more testing with running different container images:

docker run --privileged --rm -ti distribution:tag /bin/bash
install buildah in the container
same Dockerfile

FROM centos:7
RUN yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
RUN yum -y install npm
RUN npm version

run buildah bud --isolation chroot .

Using fedora:latest => works
Using ubuntu:latest => works
Using archlinux/base:latest => works
Using centos:latest => fails

So something strange in centos that causes it to fail, I'm pretty sure it was working a month or two ago.

TomSweeneyRedHat · 2019-05-02T23:16:42Z

Interesting, thanks for all the testing and info @42wim !

rhatdan · 2019-05-03T01:25:56Z

Not runc, --chroot does not use runc

rhatdan · 2019-05-03T01:26:53Z

Always the same stack trace?

42wim · 2019-05-04T22:26:22Z

A strace of the buildah process itself near the end where it actually opens /usr/bin/npm gives the output below.

syscall_332 is statx, which also fails on the successful builds
the 2 failing reads are strange.

72234 open("/usr/bin/npm", O_RDONLY|O_CLOEXEC) = 11</tmp/buildah311006848/mnt/rootfs/usr/lib/node_modules/npm/bin/npm-cli.js>
72234 syscall_332(0xb, 0x7f2496e02589, 0x1000, 0xfff, 0x7fff72ebd7f0, 0) = -1 (errno 38)
72234 read(11</tmp/buildah311006848/mnt/rootfs/usr/lib/node_modules/npm/bin/npm-cli.js>, 0x1c554a0, 8192) = -1 ENOSYS (Function not implemented)
72234 read(11</tmp/buildah311006848/mnt/rootfs/usr/lib/node_modules/npm/bin/npm-cli.js>, 0x1c68be0, 8192) = -1 ENOSYS (Function not implemented)
72234 close(11)                         = -1 ENOSYS (Function not implemented)
72234 futex(0x7f249700b198, FUTEX_WAKE_PRIVATE, 2147483647) = -1 ENOSYS (Function not implemented)
72234 prctl(PR_SET_NAME, "npm\0\0\0\0\0Pe\300\1\0\0\0\0") = 0
72234 syscall_332(0xffffff9c, 0x7fff72ebd5e8, 0, 0xfff, 0x7fff72ebd1c0, 0x7fff72ebd338) = 0
72234 syscall_332(0xffffff9c, 0x7fff72ebd5e8, 0, 0xfff, 0x7fff72ebd1c0, 0x7fff72ebd338) = -1 (errno 38)
72234 write(2</dev/pts/0>, "module.js:478\n    throw err;\n    ^\n\nError: Cannot find module 'npmlog'\n    at Function.Module._resolveFilename (module.js:476:
15)\n    at Function.Module._load (module.js:424:25)\n    at Module.require (module.js:504:17)\n    at require (internal/module.js:20:19)\n    at /usr/bin/npm:
19:13\n    at Object.<anonymous> (/usr/bin/npm:75:3)\n    at Module._compile (module.js:577:32)\n    at Object.Module._extensions..js (module.js:586:10)\n    a
t Module.load (module.js:494:32)\n    at tryModuleLoad (module.js:453:12)\n", 509) = -1 ENOSYS (Function not implemented)
72234 close(5)                          = -1 ENOSYS (Function not implemented)
72234 close(7)                          = -1 ENOSYS (Function not implemented)

rhatdan · 2019-05-05T11:28:41Z

That is a seccomp failure. Latest seccomp.json file allows statx.

If you grab the one from upstream it should fix the issue.

rhatdan · 2019-05-05T11:29:56Z

We need an updated version of containers-common on Centos.

42wim · 2019-05-05T11:46:18Z

That's unfortunately not the issue, seccomp.json is the latest on centos:7:
c05a93ec748a9bf136724e9b627f36c0 /usr/share/containers/seccomp.json

The rpm is containers-common-0.1.35-2.git404c5bd.el7.centos.x86_64

Same version as on https://src.fedoraproject.org/rpms/skopeo/raw/master/f/seccomp.json and as on fedora:latest

This is how the strace looks when it works (eg on fedora:latest also the ENOSYS on statx)

2226  statx(AT_FDCWD, "/usr/bin/npm", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe345e3680) = -1 ENOSYS (Function not implemented)
2226  stat("/usr/bin/npm", {st_mode=S_IFREG|0755, st_size=1996, ...}) = 0
2226  lstat("/usr", {st_mode=S_IFDIR|0755, st_size=54, ...}) = 0
2226  lstat("/usr/bin", {st_mode=S_IFDIR|0555, st_size=29, ...}) = 0
2226  lstat("/usr/bin/npm", {st_mode=S_IFLNK|0777, st_size=38, ...}) = 0
2226  stat("/usr/bin/npm", {st_mode=S_IFREG|0755, st_size=1996, ...}) = 0
2226  readlink("/usr/bin/npm", "../lib/node_modules/npm/bin/npm-cli.js", 4096) = 38
2226  lstat("/usr/lib", {st_mode=S_IFDIR|0555, st_size=66, ...}) = 0
2226  lstat("/usr/lib/node_modules", {st_mode=S_IFDIR|0755, st_size=17, ...}) = 0
2226  lstat("/usr/lib/node_modules/npm", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
2226  lstat("/usr/lib/node_modules/npm/bin", {st_mode=S_IFDIR|0755, st_size=98, ...}) = 0
2226  lstat("/usr/lib/node_modules/npm/bin/npm-cli.js", {st_mode=S_IFREG|0755, st_size=1996, ...}) = 0
2226  open("/usr/lib/node_modules/npm/bin/npm-cli.js", O_RDONLY|O_CLOEXEC) = 11
2226  fstat(11, {st_mode=S_IFREG|0755, st_size=1996, ...}) = 0
2226  read(11, "#!/usr/bin/env node\n;(function () { // wrapper in case we're in module_context mode

I'm wondering if it doesn't have something to do with the symlink

rhatdan · 2019-05-05T11:54:04Z

Have you tried this on a newer kernel? IE Do you see the same issue on Fedora?

42wim · 2019-05-05T11:59:14Z

The tests in my previous comment: #1568 (comment) are all running in docker containers on the same centos 7 host (3.10.0-862.14.4.el7.x86_64) and only the centos:latest container fails.

So this doesn't look like a kernel issue as they all are using the same kernel.

But I also ran on a 5.0.5-1.el7.elrepo.x86_64 kernel, with the same issues (I don't have a "physical" fedora host)

rhatdan · 2019-05-05T12:01:55Z

Ok so this is container image specific, most likely not a Buildah bug. Has any Centos image ever worked?

42wim · 2019-05-05T12:40:56Z

Yes, we're using buildah (in a centos docker container) in our Jenkins pipeline (since October last year), mostly building centos images.

They all worked fine and all them still do except the ones with a npm command in it.
Without the --isolation chroot it still builds, but this doesn't work inside a docker container.

42wim · 2019-05-05T14:07:53Z

Progress!
Thinking about your seccomp remark I tried with
buildah bud --security-opt seccomp=unconfined --isolation chroot . and the image works again!

rhatdan · 2019-05-05T19:15:44Z

Grab this seccomp.json file and see replace the one in /etc/share/containers/seccomp.json
https://github.com/containers/libpod/blob/master/seccomp.json

42wim · 2019-05-05T19:25:41Z

Still fails with that seccomp.json

rhatdan · 2019-05-06T14:36:41Z

Strange. I will have to try this here.

grep statx /usr/share/containers/seccomp.json

42wim · 2019-05-06T15:11:58Z

I did an strace again on the build with --security-opt seccomp=unconfined and the syscall_332 gives a -1

1022 syscall_332(0xffffff9c, 0x7ffe29ae6848, 0, 0xfff, 0x7ffe29ae6420, 0x88) = -1 (errno 38)

While on the failing build the syscall_332 passes....

1527 syscall_332(0xffffff9c, 0x7ffc7dce0618, 0, 0xfff, 0x7ffc7dce01f0, 0x88) = 0

For both builds makes no difference if statx is in /usr/share/containers/seccomp.json or not.

Without --security-opt seccomp=unconfined

1527  syscall_332(0xffffff9c, 0x7ffc7dce0618, 0, 0xfff, 0x7ffc7dce01f0, 0x88) = 0
1527  syscall_332(0xffffff9c, 0x7ffc7dce0538, 0x100, 0xfff, 0x7ffc7dce00e0, 0x3) = 0
1527  open("/usr/bin/npm", O_RDONLY|O_CLOEXEC) = 11</tmp/buildah565640668/mnt/rootfs/usr/lib/node_modules/npm/bin/npm-cli.js>
1527  syscall_332(0xb, 0x7f1d30d10589, 0x1000, 0xfff, 0x7ffc7dce0510, 0x243d778ba4920) = -1 (errno 38)
1527  read(11</tmp/buildah565640668/mnt/rootfs/usr/lib/node_modules/npm/bin/npm-cli.js>, 0x2499f80, 8192) = -1 ENOSYS (Function not implemented)
1527  read(11</tmp/buildah565640668/mnt/rootfs/usr/lib/node_modules/npm/bin/npm-cli.js>, 0x249bf90, 8192) = -1 ENOSYS (Function not implemented)
1527  close(11)                         = -1 ENOSYS (Function not implemented)
1527  futex(0x7f1d30f19198, FUTEX_WAKE_PRIVATE, 2147483647) = -1 ENOSYS (Function not implemented)
1527  prctl(PR_SET_NAME, "npm\0\0\0\0\0P\365?\2\0\0\0\0") = 0
1527  syscall_332(0xffffff9c, 0x7ffc7dce0308, 0, 0xfff, 0x7ffc7dcdfee0, 0x7ffc7dce0058) = -1 (errno 38)
1527  open("/usr/bin/node_modules/npmlog/package.json", O_RDONLY|O_CLOEXEC) = 0</dev/pts/0>
1527  syscall_332(0xffffff9c, 0x7ffc7dce0268, 0, 0xfff, 0x7ffc7dcdfe40, 0x243d860) = 0
1527  open("/usr/bin/node_modules/npmlog/package.json", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1527  syscall_332(0xffffff9c, 0x7ffc7dce0268, 0, 0xfff, 0x7ffc7dcdfe40, 0x7ffc7dce0298) = 0
1527  syscall_332(0xffffff9c, 0x7ffc7dce0268, 0, 0xfff, 0x7ffc7dcdfe40, 0x7ffc7dce0298) = 0
1527  syscall_332(0xffffff9c, 0x7ffc7dce0308, 0, 0xfff, 0x7ffc7dcdfee0, 0x7ffc7dce0370) = -1 (errno 38)
1527  open("/usr/node_modules/npmlog/package.json", O_RDONLY|O_CLOEXEC) = 0</dev/pts/0>
1527  syscall_332(0xffffff9c, 0x7ffc7dce0268, 0, 0xfff, 0x7ffc7dcdfe40, 0x7ffc7dce0298) = 0
1527  open("/usr/node_modules/npmlog/package.json", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1527  syscall_332(0xffffff9c, 0x7ffc7dce0268, 0, 0xfff, 0x7ffc7dcdfe40, 0x7ffc7dce0298) = 0
1527  syscall_332(0xffffff9c, 0x7ffc7dce0268, 0, 0xfff, 0x7ffc7dcdfe40, 0x7ffc7dce0298) = 0
1527  syscall_332(0xffffff9c, 0x7ffc7dce0308, 0, 0xfff, 0x7ffc7dcdfee0, 0x7ffc7dce0370) = 0
1527  open("/usr/lib/node/npmlog/package.json", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1527  syscall_332(0xffffff9c, 0x7ffc7dce0268, 0, 0xfff, 0x7ffc7dcdfe40, 0x7ffc7dce0298) = 0
1527  syscall_332(0xffffff9c, 0x7ffc7dce0268, 0, 0xfff, 0x7ffc7dcdfe40, 0x7ffc7dce0298) = -1 (errno 38)
1527  open("/usr/lib/node/npmlog/package.json", O_RDONLY|O_CLOEXEC) = 0</dev/pts/0>
1527  syscall_332(0xffffff9c, 0x7ffc7dce0268, 0, 0xfff, 0x7ffc7dcdfe40, 0x7ffc7dce0298) = 0
1527  write(2</dev/pts/0>, "module.js:478\n    throw err;\n    ^\n\nError: Cannot find module 'npmlog'\n    at Function.Module._resolveFilename (module.js:476:

With --security-opt seccomp=unconfined

1022  syscall_332(0xffffff9c, 0x7ffe29ae6848, 0, 0xfff, 0x7ffe29ae6420, 0x88) = -1 (errno 38)
1022  stat("/usr/bin/npm", {st_mode=S_IFREG|0755, st_size=1996, ...}) = 0
1022  lstat("/usr", {st_mode=S_IFDIR|0755, st_size=54, ...}) = 0
1022  lstat("/usr/bin", {st_mode=S_IFDIR|0555, st_size=29, ...}) = 0
1022  lstat("/usr/bin/npm", {st_mode=S_IFLNK|0777, st_size=38, ...}) = 0
1022  stat("/usr/bin/npm", {st_mode=S_IFREG|0755, st_size=1996, ...}) = 0
1022  readlink("/usr/bin/npm", "../lib/node_modules/npm/bin/npm-cli.js", 4096) = 38
1022  lstat("/usr/lib", {st_mode=S_IFDIR|0555, st_size=66, ...}) = 0
1022  lstat("/usr/lib/node_modules", {st_mode=S_IFDIR|0755, st_size=17, ...}) = 0
1022  lstat("/usr/lib/node_modules/npm", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
1022  lstat("/usr/lib/node_modules/npm/bin", {st_mode=S_IFDIR|0755, st_size=98, ...}) = 0
1022  lstat("/usr/lib/node_modules/npm/bin/npm-cli.js", {st_mode=S_IFREG|0755, st_size=1996, ...}) = 0
1022  open("/usr/lib/node_modules/npm/bin/npm-cli.js", O_RDONLY|O_CLOEXEC) = 11</tmp/buildah767858916/mnt/rootfs/usr/lib/node_modules/npm/bin/npm-cli.js>
1022  fstat(11</tmp/buildah767858916/mnt/rootfs/usr/lib/node_modules/npm/bin/npm-cli.js>, {st_mode=S_IFREG|0755, st_size=1996, ...}) = 0
1022  read(11</tmp/buildah767858916/mnt/rootfs/usr/lib/node_modules/npm/bin/npm-cli.js>, "#!/usr/bin/env node\n;(function () { // wrapper in case we're in module_context mode\n  // windows: running \"npm blah\" in this folder will invoke WSH, not node.\n  /*global WScript*/\n  if (typeof WScript !== 'undefined') {\n    WScript.echo(\n      'npm does not work when run\\n' +\n        'with the Windows Scripting Host\\n\\n' +\n        \"'cd' to a different directory,\\n\" +\n        \"or type 'npm.cmd <args>',\\n\" +\n        \"or type 'node npm <args>'.\"\n    )\n    WScript.quit(1)\n    return\n  }\n\n  process.title = 'npm'\n\n

rhatdan · 2019-05-10T21:33:42Z

@pcmoore Any ideas on this?

rhatdan · 2019-05-10T21:37:22Z

@weirdwiz PTAL

pcmoore · 2019-05-11T11:56:43Z

From what I can tell it looks like statx(...) is allowed by the seccomp filter so it makes me wonder if there is another problem somewhere. What is the host system running distribution wise? What version of libseccomp is on the host (NOTE: libseccomp v2.4.1 is current)?

42wim · 2019-05-11T12:34:25Z

@pcmoore the host doesn't seem to matter you should be able to reproduce this by just running docker as described in #1568 (comment)

Originally tested on a centos 7.5 and centos 7.6 host

I just spun up a ubuntu 18.04 LTS on digitalocean and ran the same commands, with the same issue.
The complete logfile can be found here https://gist.github.com/42wim/41a91a3a60959bdf5c0f51bd0769f098

Only difference is that I needed to use the vfs storage driver.

pcmoore · 2019-05-11T15:52:38Z

Okay, I just wanted to make sure the host's libseccomp filter wasn't the issue. Looking closer at the log it appears that this is just the libseccomp filter for buildah and not the entire container that is the problem, yes?

Assuming that is the case I suspect the problem is the old version of libseccomp that ships in Centos. The libseccomp v2.3.x stream has a number of bugs and is no longer supported upstream. Can you confirm the version of libseccomp present in the fedora/ubuntu/archlinux:latest?

It may be that CentOS/RHEL simply needs to update their libseccomp package.

42wim · 2019-05-11T19:07:56Z

@pcmoore that was the solution!
I've made a centos rpm of 2.4.1 and the issue is fixed. (default version is libseccomp-2.3.1-3.el7)

pcmoore · 2019-05-11T19:15:11Z

Glad to hear you got it working @42wim! @rhatdan should be able to talk to the right people to get RH to update the package; that's out of my hands now.

rhatdan · 2019-05-12T09:56:46Z

@42wim Could you open a Bugzilla, on this issue on RHEL7 at bugzilla.redhat.com. CC Me on this bug and reference this issue.

42wim · 2019-05-20T19:22:18Z

Done

rhatdan · 2019-06-08T18:56:10Z

@42wim Could you link the bugzilla here?

42wim · 2019-06-09T19:26:16Z

Bugzilla issue can be found on https://bugzilla.redhat.com/show_bug.cgi?id=1712146

rhatdan · 2019-06-10T09:45:27Z

Thanks, I will close the issue and follow the progress there.

42wim · 2019-07-13T17:08:27Z

TLDR; Redhat is not rebasing it, centos7/rhel7 users are out of luck.
But you can easily build your own RPM from https://src.fedoraproject.org/rpms/libseccomp or migrate to another distribution :-)

rhatdan · 2019-07-14T10:08:30Z

Well it does work on RHEL8.

rhatdan closed this as completed Jun 10, 2019

jhfrontz mentioned this issue Oct 23, 2019

Compiler doesn't work when using Docker rust-lang/rust#65662

Closed

github-actions bot added the locked - please file new issue/PR label Sep 15, 2023

github-actions bot locked as resolved and limited conversation to collaborators Sep 15, 2023

Fail to build image with --isolation chroot #1568

Fail to build image with --isolation chroot #1568

Comments

42wim commented May 2, 2019

rhatdan commented May 2, 2019

TomSweeneyRedHat commented May 2, 2019

42wim commented May 2, 2019 • edited Loading

42wim commented May 2, 2019

rhatdan commented May 2, 2019

rhatdan commented May 2, 2019

rhatdan commented May 2, 2019

42wim commented May 2, 2019

42wim commented May 2, 2019 • edited Loading

TomSweeneyRedHat commented May 2, 2019

42wim commented May 2, 2019

42wim commented May 2, 2019

TomSweeneyRedHat commented May 2, 2019

rhatdan commented May 3, 2019

rhatdan commented May 3, 2019

42wim commented May 4, 2019 • edited Loading

rhatdan commented May 5, 2019

rhatdan commented May 5, 2019

42wim commented May 5, 2019 • edited Loading

rhatdan commented May 5, 2019

42wim commented May 5, 2019

rhatdan commented May 5, 2019

42wim commented May 5, 2019

42wim commented May 5, 2019 • edited Loading

rhatdan commented May 5, 2019

42wim commented May 5, 2019

rhatdan commented May 6, 2019

42wim commented May 6, 2019

rhatdan commented May 10, 2019

rhatdan commented May 10, 2019

pcmoore commented May 11, 2019 • edited Loading

42wim commented May 11, 2019

pcmoore commented May 11, 2019

42wim commented May 11, 2019 • edited Loading

pcmoore commented May 11, 2019

rhatdan commented May 12, 2019

42wim commented May 20, 2019

rhatdan commented Jun 8, 2019

42wim commented Jun 9, 2019

rhatdan commented Jun 10, 2019

42wim commented Jul 13, 2019

rhatdan commented Jul 14, 2019

42wim commented May 2, 2019 •

edited

Loading

42wim commented May 2, 2019 •

edited

Loading

42wim commented May 4, 2019 •

edited

Loading

42wim commented May 5, 2019 •

edited

Loading

42wim commented May 5, 2019 •

edited

Loading

pcmoore commented May 11, 2019 •

edited

Loading

42wim commented May 11, 2019 •

edited

Loading