[Bug 1090071] New: `docker start` doesn't fail on started container
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1090071
Bug ID: 1090071
Summary: `docker start` doesn't fail on started container
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: ldoktor(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com
Description of problem:
On older (0.9) docker, the `docker start $running_container` failed. The new
0.10.2 version just prints the container name and proceeds.
Version-Release number of selected component (if applicable):
docker-io-0.10.0-2.fc20.x86_64
How reproducible:
Always
Steps to Reproduce:
1. docker run -i -t -name test fedora bash
2. docker start test
Actual results:
[root@t530 ~]# docker start test
test
[root@t530 ~]# echo &?
0
Expected results:
[root@t530 ~]# docker start test
Error: Cannot start container test: The container
429d709bc86c037b09e9f74dfab40aa33dc19bcf3109daf3f5b2fbbd3c6df297 is already
running.
2014/04/22 15:29:28 Error: failed to start one or more containers
[root@t530 ~]# echo &?
1
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1140398] New: Catastrophic failure saving large images
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1140398
Bug ID: 1140398
Summary: Catastrophic failure saving large images
Product: Fedora
Version: 20
Component: docker-io
Severity: medium
Assignee: lsm5(a)fedoraproject.org
Reporter: briemers(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
hushan.jia(a)gmail.com, jperrin(a)centos.org,
lsm5(a)fedoraproject.org, mattdm(a)redhat.com,
mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com
Description of problem:
Large docker images are saved written first to temp. As such when one does a
"docker save" for a large image the save process will error out with a disk
full error. Afterwards, there will be mounting error if attempting to save
the image again after resizing tmp.
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1. Create an image much larger than your /tmp space
2. Attempt to save
3.
Actual results:
[briemers@briemersw staging]$ docker save -o /data/oracle-xe-prod.dimg
oracle-xe-prod
2014/09/10 16:41:23 Error: write
/tmp/docker-export-336322967/dd28f4e8cb55517c4a97560a6adc9d2032b9fdfe4fb744857648067f66125a38/layer.tar:
no space left on device
[briemers@briemersw staging]$ sudo mount -o remount,size=20g /tmp
[sudo] password for briemers:
[briemers@briemersw staging]$ docker save -o /data/oracle-xe-prod.dimg
oracle-xe-prod
2014/09/10 16:43:25 Error: Error mounting
'/dev/mapper/docker-253:2-2097434-dd28f4e8cb55517c4a97560a6adc9d2032b9fdfe4fb744857648067f66125a38'
on
'/var/lib/docker/devicemapper/mnt/dd28f4e8cb55517c4a97560a6adc9d2032b9fdfe4fb744857648067f66125a38':
device or resource busy
[briemers@briemersw staging]$ sudo service docker restart
Redirecting to /bin/systemctl restart docker.service
[briemers@briemersw staging]$ docker save -o /data/oracle-xe-prod.dimg
oracle-xe-prod
2014/09/10 16:43:52 Error: Error mounting
'/dev/mapper/docker-253:2-2097434-dd28f4e8cb55517c4a97560a6adc9d2032b9fdfe4fb744857648067f66125a38'
on
'/var/lib/docker/devicemapper/mnt/dd28f4e8cb55517c4a97560a6adc9d2032b9fdfe4fb744857648067f66125a38':
device or resource busy
Expected results:
I would not expect the process to need massive amounts of /tmp space, if so it
should have an option to specify where the tmp files are written. Also, the
process needs to clean-up it's locks so subsiquent commands don't fail.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1096269] New: lost signals when sending lots of signals using --sig-proxy to docker
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1096269
Bug ID: 1096269
Summary: lost signals when sending lots of signals using
--sig-proxy to docker
Product: Red Hat Enterprise Linux 7
Version: 7.1
Component: docker
Assignee: lsm5(a)redhat.com
Reporter: ldoktor(a)redhat.com
QA Contact: virt-bugs(a)redhat.com
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, skottler(a)redhat.com,
vbatts(a)redhat.com
Depends On: 1087700
+++ This bug was initially created as a clone of Bug #1087700 +++
Description of problem:
When I send lots of signals to the running docker with --sig-proxy (actual kill
signals, not `docker kill`), most of them got lost.
Version-Release number of selected component (if applicable):
docker-0.10.0-8.el7.x86_64
docker-io-0.9.1-1.fc21.x86_64
How reproducible:
always
Steps to Reproduce:
1. /usr/bin/docker -D run --tty=false --rm -i --name test_eoly
localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap
"echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done'
2. ps ax |grep docker
3. for AAA in `seq 1 32`; do [ $AAA -ne 9 ] && [ $AAA -ne 20 ] && [ $AAA -ne 19
] && kill -s $AAA $PID; done
Actual results:
Output of the docker is:
Received 1, ignoring...
Received 2, ignoring...
Expected results:
Messages for all of the `Received $NUM, ignoring...` printed (order doesn't
matter)
Additional info:
Skipping 9, 19, 20 as they are a bit too special..
--- Additional comment from Lukas Doktor on 2014-05-05 04:10:09 EDT ---
The same results with upstream docker dc9c28f/0.10.0:
Output:
Received 1, ignoring...
[debug] stdcopy.go:111 framesize: 24
Received 2, ignoring...
Daemon output:
2014/05/05 10:08:45 POST
/v1.10/containers/b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5/kill?signal=HUP
[/home/medic/Work/Projekty/Docker/root|fa3816b6] +job
kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, HUP)
[/home/medic/Work/Projekty/Docker/root|fa3816b6] -job
kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, HUP) =
OK (0)
2014/05/05 10:08:45 POST
/v1.10/containers/b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5/kill?signal=INT
[/home/medic/Work/Projekty/Docker/root|fa3816b6] +job
kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, INT)
[/home/medic/Work/Projekty/Docker/root|fa3816b6] -job
kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, INT) =
OK (0)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1087700
[Bug 1087700] lost signals when sending lots of signals using --sig-proxy
to docker
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1087697] New: man page inaccuracy about --sig-proxy and --tty
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1087697
Bug ID: 1087697
Summary: man page inaccuracy about --sig-proxy and --tty
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: ldoktor(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, skottler(a)redhat.com,
vbatts(a)redhat.com
Description of problem:
Hi guys,
the man page states:
--sig-proxy=true: Proxify all received signal to the process (even
in non-tty mode)
But the real behavior is, that sig-proxy doesn't work when --tty=true. It
should be mentioned in there, taht --sig-proxy is incompatible with --tty.
Version-Release number of selected component (if applicable):
docker-io-0.9.1-1.fc21.x86_64
How reproducible:
always
Steps to Reproduce:
1. man docker
Actual results:
man page says it works even in non-tty
Expected results:
man page warns that --tty can't be used with --sig-proxy
How to verify:
1. docker run --tty=true -i --rm fedora bash -c 'for NUM in `seq 1 64`; do trap
"echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done'
2. ps -ax | grep docker
3. kill -SIGUSR1 $PID
4. (with --tty=true no signals are received, when you try the same with
--tty=false, signals are proxified and messages are displayed)
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1140405] New: systemctl start docker fails because systemd continuously restarts the daemon
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1140405
Bug ID: 1140405
Summary: systemctl start docker fails because systemd
continuously restarts the daemon
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)fedoraproject.org
Reporter: a.badger(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
hushan.jia(a)gmail.com, jperrin(a)centos.org,
lsm5(a)fedoraproject.org, mattdm(a)redhat.com,
mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com
Description of problem:
I've installed docker for the first time and tried to start it with "systemctl
start docker". The systemctl command returns successfully but then trying to
run docker client commands against the daemon timed out. After some poking
around I discovered that systemd was starting docker. Docker was taking quite
a while to do various initialization tasks including invoking mkfs. systemd
decided that docker was unresponsive and terminated it and then restarted it.
Because mkfs hadn't finished, docker had to try running mkfs again. This cycle
kept continuing and would probably have prevented docker from fully starting up
forever.
I worked around the problem by telling systemd not to start docker, running the
docker daemon manually from a shell, waiting until the mkfs had completed, then
shutting down my daemon and rerunning systemctl start docker. After that, the
docker service runs fine.
Version-Release number of selected component (if applicable):
docker-io-1.2.0-2.fc20.x86_64
How reproducible:
Everytime for me until after I ran docker as a daemon manually. I don't know
how to reproduce once docker has initialized (Probably removing some file or
volume but I don't know what it would be).
Steps to Reproduce:
1. On a system that hasn't had docker running before
2. yum install docker-io
3. systemctl start docker
4. watch the output of systemctl status docker -l
Actual results:
systemctl status docker -l will report that docker is in state Activating for
several minutes, then show that systemd decided docker wasn't responding,
terminate it, and restart. The -l output will also show that docker is running
mkfs for most of that time and is still running it when docker is terminated.
Expected results:
systemctl status docker -l will show that the state has gone to active
(running)
Additional info:
* My filesystem is ext4. The docker initialization is running mkfs.ext4
* I'm using a 4-5 year old laptop with platter HDs. A faster machine or SSD
drives might run mkfs quickly enough to not see this issue.
* This might be "fixed" by adding some documentation that says to perform
certain steps to initialize docker before running systemctl start docker rather
than changing docker code to finish initialization sooner.
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1123057] New: warning: file /usr/bin/gofmt: remove failed: No such file or directory while removing golang packages
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1123057
Bug ID: 1123057
Summary: warning: file /usr/bin/gofmt: remove failed: No such
file or directory while removing golang packages
Product: Fedora
Version: 20
Component: golang
Assignee: vbatts(a)redhat.com
Reporter: dominik(a)greysector.net
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lemenkov(a)gmail.com, lsm5(a)fedoraproject.org,
renich(a)woralelandia.com, s(a)shk.io, vbatts(a)redhat.com
Description of problem:
There are two warnings while removing golang-pkg-bin-linux-amd64 package:
warning: file /usr/bin/gofmt: remove failed: No such file or directory
warning: file /usr/bin/go: remove failed: No such file or directory
Version-Release number of selected component (if applicable):
1.2.2-7.fc20
How reproducible:
Always
Steps to Reproduce:
1. yum install golang
2. yum remove golang\*
Actual Results:
# yum remove golang\*
Loaded plugins: changelog, langpacks
Resolving Dependencies
--> Running transaction check
---> Package golang.x86_64 0:1.2.2-7.fc20 will be erased
---> Package golang-pkg-bin-linux-amd64.x86_64 0:1.2.2-7.fc20 will be erased
---> Package golang-pkg-linux-amd64.noarch 0:1.2.2-7.fc20 will be erased
---> Package golang-src.noarch 0:1.2.2-7.fc20 will be erased
--> Finished Dependency Resolution
[...]
Running transaction (shutdown inhibited)
Erasing : golang-pkg-linux-amd64-1.2.2-7.fc20.noarch 1/4
Erasing : golang-pkg-bin-linux-amd64-1.2.2-7.fc20.x86_64 2/4
warning: file /usr/bin/gofmt: remove failed: No such file or directory
warning: file /usr/bin/go: remove failed: No such file or directory
Erasing : golang-1.2.2-7.fc20.x86_64 3/4
Erasing : golang-src-1.2.2-7.fc20.noarch 4/4
Verifying : golang-src-1.2.2-7.fc20.noarch 1/4
Verifying : golang-1.2.2-7.fc20.x86_64 2/4
Verifying : golang-pkg-bin-linux-amd64-1.2.2-7.fc20.x86_64 3/4
Verifying : golang-pkg-linux-amd64-1.2.2-7.fc20.noarch 4/4
Removed:
golang.x86_64 0:1.2.2-7.fc20
golang-pkg-bin-linux-amd64.x86_64 0:1.2.2-7.fc20
golang-pkg-linux-amd64.noarch 0:1.2.2-7.fc20
golang-src.noarch 0:1.2.2-7.fc20
Expected Results:
no warning about missing files
Additional Information:
It looks like the links maintained by update-alternatives are not marked as
%ghost in the spec file:
[...]
ifarch x86_64
%files pkg-bin-linux-amd64
%{goroot}/bin/linux_amd64/
# binary executables
%{_bindir}/go
%{_bindir}/gofmt
[...]
This is required by the Alternatives guideline:
https://fedoraproject.org/wiki/Packaging:Alternatives .
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1075232] New: 0.9.0 Adds virtual interface, NetworkManager attempts to assign dhcp address to it
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1075232
Bug ID: 1075232
Summary: 0.9.0 Adds virtual interface, NetworkManager attempts
to assign dhcp address to it
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: admiller(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, skottler(a)redhat.com,
vbatts(a)redhat.com
Created attachment 873221
--> https://bugzilla.redhat.com/attachment.cgi?id=873221&action=edit
snippet from /var/log/messages for my laptop around the virtual interface
events
Description of problem:
When you install docker-io-0.9.0 on Fedora 20, it creates a new virtual
interface
13: vethf3e3: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master docker0
state UP group default qlen 1000
link/ether 1a:9c:40:61:1e:8b brd ff:ff:ff:ff:ff:ff
inet6 fe80::189c:40ff:fe61:1e8b/64 scope link
valid_lft forever preferred_lft forever
Something (I'm thinking dbus or udev) causes NetworkManager to launch dhclient
for the new interface, and if you're running with a Desktop Environment this
causes a visual change to the NM applet which can be confusing. It doesn't ever
do anything, NM eventually times out and gives up and this doesn't appear to
impact docker's functionality at all (or at least not yet in my tests have I
found an issue, networking works fine).
Version-Release number of selected component (if applicable):
docker-io-0.9.0-2.fc20.x86_64
How reproducible:
Always
Steps to Reproduce:
1. yum install docker-io #on a machine with a GUI/DE up and running with
NetworkManager
Actual results:
NetworkManager attempts to get a dhcp lease on the new virtual interface.
Expected results:
NetworkManager probably shouldn't attempt to get a dhcp lease on the new
virtual interface, this seems odd.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1221688] New: Docker fails mounting a volume as readonly on files located under /usr
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1221688
Bug ID: 1221688
Summary: Docker fails mounting a volume as readonly on files
located under /usr
Product: Red Hat Enterprise Linux 7
Version: 7.1
Component: docker
Severity: high
Priority: high
Assignee: dwalsh(a)redhat.com
Reporter: jhunsaker(a)redhat.com
QA Contact: lsu(a)redhat.com
CC: adimania(a)gmail.com, admiller(a)redhat.com,
bugzilla.redhat.com(a)trancecode.co.uk,
dustymabe(a)redhat.com, extras-qa(a)fedoraproject.org,
golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com,
ichavero(a)redhat.com, jchaloup(a)redhat.com,
jperrin(a)centos.org, lsm5(a)redhat.com,
mattdm(a)redhat.com, mgoldman(a)redhat.com,
miminar(a)redhat.com, s(a)shk.io, thrcka(a)redhat.com,
vbatts(a)redhat.com, yann.robert(a)anantaplex.fr
Depends On: 1216151
Group: redhat
+++ This bug was initially created as a clone of Bug #1216151 +++
Description of problem:
Docker fails to run a container with a volume on files located under /usr (or
on symbolic link to files located under /usr) if the ":ro" specification is
used to mount it as readonly
Version-Release number of selected component (if applicable):
docker-io-1.6.0-2.git3eac457.fc21.x86_64
How reproducible: 100%
Steps to Reproduce:
1. install docker package docker-io-1.6.0-2.git3eac457.fc21.x86_64
2. restart the docker service
3. run the following command
docker run -ti -v /etc/localtime:/etc/localtime:ro busybox echo hello
Actual results:
get exit code 1
and message FATA[0000] Error response from daemon: Cannot start container
4bb87515e4eb828b295eb4718a7159c958a1154ed839b29fd213a597b91a200e: [8] System
error: Relabeling content in /usr is not allowed.
Expected results:
get exit code 0
and message "hello"
Additional info:
please refer to initial bug report on docker repository at github
https://github.com/docker/docker/issues/12811
--- Additional comment from colin on 2015-05-12 17:48:40 EDT ---
I see this also on F22
[root@kvm124 ~]# rpm -q docker
docker-1.6.0-3.git9d26a07.fc22.x86_64
This no longer works
docker run -d --sig-proxy --name $CT_name --net=none \
-v /etc/localtime:/etc/localtime:ro \
Editing out the :ro stops the Failure
docker run -d --sig-proxy --name $CT_name --net=none \
-v /etc/localtime:/etc/localtime \
FATA[0000] Error response from daemon: Cannot start container
925387bd2b2988b1a10ff87e68e188f3a579e68d3d5fc1f31d40a648cd9cb6d2: [8] System
error: Relabeling content in /usr is not allowed.
-------------------------------------------
Cloning this to RHEL as I didn't see a RHEL BZ for this.
This also affects RHEL Atomic Host 7.1.2.
Version:
docker-1.6.0-11.el7.x86_64
How reproducible:
100%
Steps to reproduce:
1. Use the :ro parameter when volume mounting something like /etc/localtime to
a container
Actual results:
# docker run --rm -ti -v /etc/localtime:/etc/localtime:ro rhel7 /bin/bash
Timestamp: 2015-05-14 09:24:34.832162133 -0400 EDT
Code: System error
Message: Relabeling content in /usr is not allowed.
Frames:
---
0: setupRootfs
Package: github.com/docker/libcontainer
File: rootfs_linux.go@34
---
1: Init
Package: github.com/docker/libcontainer.(*linuxStandardInit)
File: standard_init_linux.go@52
---
2: StartInitialization
Package: github.com/docker/libcontainer.(*LinuxFactory)
File: factory_linux.go@223
---
3: initializer
Package: FATA[0002] Error response from daemon: Cannot start container
7be2ae04a120232345b5edbf18e487965b5418bb1ee9354e406d7b9f675c6091: [8] System
error: Relabeling content in /usr is not allowed.
Excepted results:
Container should start normally
Additional notes:
As mentioned in the Fedora bug, removing the :ro will allow the container to
start, however this is not desirable for things like /etc/localtime as we don't
want the container to be able to change that.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1216151
[Bug 1216151] Docker fails mounting a volume as readonly on files located
under /usr
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1218639] New: docker push to dockerhub does not work (docker 1.16)
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1218639
Bug ID: 1218639
Summary: docker push to dockerhub does not work (docker 1.16)
Product: Red Hat Enterprise Linux 7
Version: 7.1
Component: docker
Keywords: Extras
Severity: high
Assignee: dwalsh(a)redhat.com
Reporter: miminar(a)redhat.com
QA Contact: lsu(a)redhat.com
CC: adimania(a)gmail.com, admiller(a)redhat.com,
agoldste(a)redhat.com, extras-qa(a)fedoraproject.org,
golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com,
ichavero(a)redhat.com, jalmansor(a)gmail.com,
jchaloup(a)redhat.com, jhonce(a)redhat.com,
jperrin(a)centos.org, lsm5(a)redhat.com,
maszulik(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, miminar(a)redhat.com, s(a)shk.io,
spousty(a)redhat.com, thrcka(a)redhat.com,
vbatts(a)redhat.com
Depends On: 1217987
Keywords: Extras
+++ This bug was initially created as a clone of Bug #1217987 +++
Description of problem:
I can build and tag a docker image on my local machine but I can not push it to
dockerhub. I am sure I have a dockerhub account and I can push with F20 and
docker 15. Maceij can push with Ubuntu and Docker 16.
Version-Release number of selected component (if applicable):
Docker version 1.6.0, build 3eac457/1.6.0
How reproducible:
Always
Steps to Reproduce:
1. Make a local docker image
2. Tag it
3. Try to push it to dockerhub
Actual results:
$ sudo docker build -t thesteve0/openshift-qpid:latest .
Sending build context to Docker daemon 2.048 kB
Sending build context to Docker daemon
Step 0 : FROM fedora/qpid
---> 6b45d8271e13
Step 1 : MAINTAINER spousty <spousty(a)redhat.com>
---> Using cache
---> 32b450b8f57a
Step 2 : ENV IMAGE_DESCRIPTION QPID C++ AMQP Server 0.30.3
---> Using cache
---> 03be2f186029
Step 3 : ENV IMAGE_TAGS qpid,qpid030,
---> Using cache
---> 13797654c23f
Step 4 : ENV IMAGE_EXPOSE_SERVICES 5672:qpid
---> Using cache
---> 3a0843e1e66e
Step 5 : EXPOSE 5672
---> Using cache
---> 465c93d05637
Step 6 : ENTRYPOINT qpidd -t --auth=no
---> Using cache
---> 4ff0b3679c09
Successfully built 4ff0b3679c09
$ sudo docker images
REPOSITORY TAG IMAGE ID
CREATED VIRTUAL SIZE
thesteve0/openshift-qpid latest 4ff0b3679c09 2
minutes ago 607.1 MB
$ sudo docker push thesteve0/openshift-qpid:latest
Do you really want to push to public registry? [Y/n]: Y
The push refers to a repository [docker.io/thesteve0/openshift-qpid] (len: 1)
FATA[0001] Repository does not exist: docker.io/thesteve0/openshift-qpid
Expected results:
The image should be pushed to dockerhub
Additional info:
--- Additional comment from Steven Citron-Pousty on 2015-05-03 17:11:15 EDT ---
See the thread starting here for this issue hitting another user a few days ago
https://forums.docker.com/t/docker-push-error-fata-0001-respository-does-...
--- Additional comment from Andy Goldstein on 2015-05-03 22:14:23 EDT ---
The current workaround: sudo docker push
docker.io/thesteve0/openshift-qpid:latest. You need to include the docker.io/
prefix when pushing to the Hub.
--- Additional comment from Jason Al-Mansor on 2015-05-04 11:39:52 EDT ---
I've noticed this issue as well. I tried swapping the package binary with the
binary from docker and it worked fine and it didn't display the public registry
prompt.
--- Additional comment from Michal Minar on 2015-05-05 07:24:17 EDT ---
Thank you Steven for reporting this. PR
https://github.com/rhatdan/docker/pull/48 fixes it.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1217987
[Bug 1217987] docker push to dockerhub does not work (docker 1.16)
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1214619] New: Tracker for golang-github-onsi-ginkgo
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1214619
Bug ID: 1214619
Summary: Tracker for golang-github-onsi-ginkgo
Product: Fedora
Version: rawhide
Component: golang-github-onsi-ginkgo
Assignee: jchaloup(a)redhat.com
Reporter: jchaloup(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: extras-qa(a)fedoraproject.org,
golang(a)lists.fedoraproject.org, jchaloup(a)redhat.com,
lsm5(a)redhat.com, mattdm(a)redhat.com, vbatts(a)redhat.com
Tracker for async updates of golang-github-onsi-ginkgo for rawhide and other
fedora distribution.
As golang devel packages are used only as a build-time dependency at the
moment, this tracker keeps updates and other information about this package,
e.g. broken dependencies, exceptions, important pieces of information and other
issues.
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months