Open damovsky opened 9 years ago
Hm, too bad step 1 immediately fails :-( Can only guess why unpacking the archive doesn't work. Disk full? Maybe it's possible to get yum to report more error details?
Op Sun Dec 14 2014 at 20:28:32 schreef damovsky notifications@github.com:
Steps to reproduce:
- download oracle files into step1
- docker build -t oracle-12c:step1 step1 this failed on error:
2014/12/14 20:03:04 The command [/bin/sh -c yum -y install binutils compat-libcap1 compat-libstdc++-33 compat-libstdc++-33.i686 gcc gcc-c++ glibc.i686 glibc glibc-devel glibc-devel.i686 ksh libgcc.i686 libgcc libstdc++ libstdc++.i686 libstdc++-devel libstdc++-devel.i686 libaio libaio.i686 libaio-devel libaio-devel.i686 libXext libXext.i686 libXtst libXtst.i686 libX11 libX11.i686 libXau libXau.i686 libxcb libxcb.i686 libXi libXi.i686 make sysstat vte3 smartmontools] returned a non-zero code: 1
I found those logs in console:
Running transaction Installing : libX11-common-1.6.0-2.1.el7.noarch 1/100 Installing : fontpackages-filesystem-1.44-8.el7.noarch 2/100 Installing : hicolor-icon-theme-0.12-7.el7.noarch 3/100 Installing : kernel-headers-3.10.0-123.13.1.el7.x86_64 4/100 Installing : libstdc++-devel-4.8.2-16.2.el7_0.x86_64 5/100 Installing : libgcc-4.8.2-16.2.el7_0.i686 6/100 Installing : nss-softokn-freebl-3.16.2.3-1.el7_0.i686 7/100 Installing : glibc-2.17-55.0.4.el7_0.1.i686 8/100 Installing : freetype-2.4.11-9.el7.x86_64 9/100 Installing : fontconfig-2.10.95-7.el7.x86_64 10/100 Updating : systemd-libs-208-11.0.1.el7_0.5.x86_64 11/100 Updating : systemd-208-11.0.1.el7_0.5.x86_64 12/100Error unpacking rpm package systemd-208-11.0.1.el7_0.5.x86_64
error: unpacking of archive failed on file /usr/bin/systemd-detect-virt: cpio: cap_set_file
docker version Client version: 1.3.0 Client API version: 1.15 Go version (client): go1.3.3 Git commit (client): c78088f OS/Arch (client): darwin/amd64 Server version: 1.3.1 Server API version: 1.15 Go version (server): go1.3.3 Git commit (server): 4e9bbfa — Reply to this email directly or view it on GitHub https://github.com/wscherphof/oracle-12c/issues/1.
From my point of view, the docker build fails since it requires some special rights (set_file)...this could be solved by running docker build with privileged mode, but there is no such a privileged mode for docker build. So I have to run the container manually with privileged mode and execute all commands from Dockerfile manually
I found related issue here https://bugs.centos.org/view.php?id=7480
I wonder how you could build the step1 on your machine...strange :-(
This error is noticeable in boot2docker. The build works fine in CoreOS though.
@sjoerd-michels Did you make this container work using CoreOS instead of Oracle Linux ?
@damovsky Systemd is updated when installing other packages. When he built the machine, the systemd update was probably still not released.
After looking around a while, this seems to me a Docker issue. I get this failure when I use Debian Jessie as a host OS, but not when I use CentOS 7.
I observe that by default Debian uses the aufs storage driver, meanwhile in CentOS the devicemapper one is used.
Anyone has workaround this? Same issue in my Ubuntu 14.04
Hello, my workaround was to upgrade the base container inside a RHEL 7 VM.
This is an issue relating to the storage driver Docker is using.
thx, would give me more detailed instruction on this?
发自nubia手机
Jose Antonio Insua notifications@github.com编写:
Hello, my workaround was to upgrade the base container inside a RHEL 7 VM.
This is an issue relating to the storage driver Docker is using.
— Reply to this email directly or view it on GitHub.
I hit the same issue and tried to sidestep it by using a CoreOS docker host, but that also failed #4 ... :-(
The same happened to me (using boot2docker on MacOS), have a look at http://pkgfarm.tumblr.com/post/114104687791/fixing-yum-install-on-boot2docker Basically, you can circumvent this issue by running following which disable aufs
$ boot2docker ssh
docker@boot2docker:~$ echo "EXTRA_ARGS='--storage-driver=devicemapper'" | sudo tee -a /var/lib/boot2docker/profile
docker@boot2docker:~$ sudo /etc/init.d/docker restart
Fix for Ubuntu host:
echo 'DOCKER_OPTS="--storage-driver=devicemapper"' >> /etc/default/docker && service docker restart
The existing images and containers may be lost.
@Oro Thanks! Works here as well (same setup as you, boot2docker and MacOS).
I also did a boot2docker destroy and boot2docker init to reclaim disk space.
Steps to reproduce:
I found those logs in console: