Bug 1071896
| Summary: | Fedora base image update failure in trusted builds at Docker index | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Navid Shaikh <nshaikh> |
| Component: | docker-io | Assignee: | Lokesh Mandvekar <lsm5> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | admiller, dwalsh, gamemastermj, golang-updates, jkeck, lsm5, mattdm, mgoldman, skottler, vbatts |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-05-28 17:03:56 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Navid Shaikh
2014-03-03 12:27:56 UTC
Please change the FROM command in your Dockerfile to: FROM fedora:latest And try again afterwards. The "fedora" image a a semi-official one, the "stackbrew/fedora" isn't at all. I modified Dockerfile with suggested changes [1], however build is failing with similar error [2]. [1] https://github.com/swordphilic/redis-fedora/commit/3c0d6f3b3ec2c488ffa2a997b4eb64495d0eff7e [2] https://index.docker.io/builds/github/2159/swordphilic/redis-fedora/builds/blqvekduvvjheavzyzcbsnd/ (In reply to Navid Shaikh from comment #2) > I modified Dockerfile with suggested changes [1], however build is failing > with similar error [2]. > > [1] > https://github.com/swordphilic/redis-fedora/commit/ > 3c0d6f3b3ec2c488ffa2a997b4eb64495d0eff7e > > [2] > https://index.docker.io/builds/github/2159/swordphilic/redis-fedora/builds/ > blqvekduvvjheavzyzcbsnd/ [2] shows 404 to me. Would 'yum -y update --skip-broken' help? I tried using --skip-broken option as well, still no success! The command yum -y update --skip-broken returned non-zero code. Error logs pasted from index.docker.io, in case link is not accessible. https://index.docker.io/builds/github/2159/swordphilic/redis-fedora/builds/bpz3nn55hcva7dyw9jfj2o9/ Failed: systemd.x86_64 0:208-9.fc20 systemd.x86_64 0:208-14.fc20 Complete! Error: build: The command [/bin/sh -c yum -y update --skip-broken] returned a non-zero code: 1 That's weird, I don't see this on my system (neither via 'docker build .' nor via entering docker shell and entering the yum commands) are you using docker-io-0.8.1-1 ? Here's the output of update section from yum update (systemd is in there too): Updated: audit-libs.x86_64 0:2.3.3-1.fc20 ca-certificates.noarch 0:2013.1.96-1.fc20 coreutils.x86_64 0:8.21-20.fc20 curl.x86_64 0:7.32.0-5.fc20 dbus.x86_64 1:1.6.12-8.fc20 dbus-libs.x86_64 1:1.6.12-8.fc20 elfutils-libelf.x86_64 0:0.158-1.fc20 fedora-release.noarch 0:20-3 file-libs.x86_64 0:5.14-15.fc20 glibc.x86_64 0:2.18-12.fc20 glibc-common.x86_64 0:2.18-12.fc20 grep.x86_64 0:2.18-1.fc20 initscripts.x86_64 0:9.51-1.fc20 iproute.x86_64 0:3.12.0-2.fc20 keyutils-libs.x86_64 0:1.5.9-1.fc20 kpartx.x86_64 0:0.4.9-56.fc20 krb5-libs.x86_64 0:1.11.5-4.fc20 less.x86_64 0:458-6.fc20 libblkid.x86_64 0:2.24.1-1.fc20 libcurl.x86_64 0:7.32.0-5.fc20 libmount.x86_64 0:2.24.1-1.fc20 libselinux.x86_64 0:2.2.1-6.fc20 libuuid.x86_64 0:2.24.1-1.fc20 nss.x86_64 0:3.15.4-1.fc20 nss-softokn.x86_64 0:3.15.4-1.fc20 nss-softokn-freebl.x86_64 0:3.15.4-1.fc20 nss-sysinit.x86_64 0:3.15.4-1.fc20 nss-tools.x86_64 0:3.15.4-1.fc20 nss-util.x86_64 0:3.15.4-1.fc20 openldap.x86_64 0:2.4.39-2.fc20 openssl.x86_64 1:1.0.1e-37.fc20 openssl-libs.x86_64 1:1.0.1e-37.fc20 p11-kit.x86_64 0:0.20.2-1.fc20 p11-kit-trust.x86_64 0:0.20.2-1.fc20 pcre.x86_64 0:8.33-4.fc20 popt.x86_64 0:1.16-2.fc20 procps-ng.x86_64 0:3.3.8-15.fc20 python.x86_64 0:2.7.5-11.fc20 python-libs.x86_64 0:2.7.5-11.fc20 python-pycurl.x86_64 0:7.19.3-1.fc20 rpm.x86_64 0:4.11.2-2.fc20 rpm-build-libs.x86_64 0:4.11.2-2.fc20 rpm-libs.x86_64 0:4.11.2-2.fc20 rpm-python.x86_64 0:4.11.2-2.fc20 rsync.x86_64 0:3.1.0-2.fc20 sed.x86_64 0:4.2.2-6.fc20 sqlite.x86_64 0:3.8.3-1.fc20 systemd.x86_64 0:208-14.fc20 systemd-libs.x86_64 0:208-14.fc20 arch 0:2013i-2.fc20 util-linux.x86_64 0:2.24.1-1.fc20 vim-minimal.x86_64 2:7.4.179-1.fc20 yum.noarch 0:3.4.3-137.fc20 Complete! (In reply to Lokesh Mandvekar from comment #5) > That's weird, I don't see this on my system (neither via 'docker build .' I also build the image locally on my system. > nor via entering docker shell and entering the yum commands) > > are you using docker-io-0.8.1-1 ? If image is building at index.docker.io as trusted build (with source from github) , why docker version would matter? My bad I didn't pay much attention to the trusted build thing. Yes, I do see this issue in trusted build too. Would it work for you to simply do the container setup on a local machine and then commit and push to docker's index? Comments, anyone? (In reply to Lokesh Mandvekar from comment #8) > My bad I didn't pay much attention to the trusted build thing. Yes, I do see > this issue in trusted build too. > > Would it work for you to simply do the container setup on a local machine > and then commit and push to docker's index? > Comments, anyone? I had all ready built same container on my local machine, and I can push it to index. However, my concern is, if I can build it on local machine, (in ideal scenario) it should have built on Docker index as well. I filed same issue with Docker index as well (there is no mode to track issues filed on Docker index, as such). I will update this bug, as they (Docker folks) update ticket. The image isn't just updates -- any package installation where the package contains filesystem capabilities will fail. (httpd is a prime example) This is an upstream/docker problem isn't it? (In reply to Daniel Walsh from comment #11) > This is an upstream/docker problem isn't it? Yes. And maybe one that's fixed now? (Also, it's not really with docker, it's with their trusted build process.) (In reply to Matthew Miller from comment #12) > (In reply to Daniel Walsh from comment #11) > > This is an upstream/docker problem isn't it? > > Yes. And maybe one that's fixed now? > > (Also, it's not really with docker, it's with their trusted build process.) All right, I am closing the BUG then. |