[Bug 1166082] New: Fedora 21 Atomic Image: docker service is not starting during boot as it is not enabled by-default
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1166082
Bug ID: 1166082
Summary: Fedora 21 Atomic Image: docker service is not starting
during boot as it is not enabled by-default
Product: Atomic
Component: docker-io
Severity: medium
Assignee: alexl(a)redhat.com
Reporter: lmohanty(a)redhat.com
CC: admiller(a)redhat.com, extras-qa(a)fedoraproject.org,
golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com,
jchaloup(a)redhat.com, jperrin(a)centos.org,
lsm5(a)fedoraproject.org, mattdm(a)redhat.com,
mgoldman(a)redhat.com, miminar(a)redhat.com, s(a)shk.io,
thrcka(a)redhat.com, vbatts(a)redhat.com
Depends On: 1166076
+++ This bug was initially created as a clone of Bug #1166076 +++
Description of problem:
Docker service is not starting during boot of Atomic image of Fedora 21 as it
is not enabled in systemd.
bash-4.3# systemctl status docker
● docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled)
Active: active (running) since Thu 2014-11-20 10:43:03 UTC; 47min ago
Docs: http://docs.docker.com
Main PID: 907 (docker)
CGroup: /system.slice/docker.service
└─907 /usr/bin/docker -d -H fd:// --selinux-enabled --storage-opt
dm.fs=xfs --storage-opt dm.datadev=/dev/atomicos/docker-data --storage...
Version-Release number of selected component (if applicable):
Fedora-Cloud-Atomic-20141112-21.x86_64.qcow2
How reproducible:
Always
Steps to Reproduce:
1. use Fedora-Cloud-Atomic-20141112-21.x86_64.qcow2 to boot.
2. check if docker service is running
3.
Actual results:
Expected results:
Additional info:
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1166076
[Bug 1166076] Fedora 21 Atomic Image: docker service is not starting during
boot as it is not enabled by-default
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 2 months
[Bug 1166918] New: Docker exec causes Error response from daemon: Unsupported: Exec is not supported by the lxc driver
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1166918
Bug ID: 1166918
Summary: Docker exec causes Error response from daemon:
Unsupported: Exec is not supported by the lxc driver
Product: Fedora EPEL
Version: el6
Component: docker-io
Assignee: lsm5(a)fedoraproject.org
Reporter: jltronson(a)directv.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
hushan.jia(a)gmail.com, jchaloup(a)redhat.com,
jperrin(a)centos.org, lsm5(a)fedoraproject.org,
mattdm(a)redhat.com, mgoldman(a)redhat.com,
miminar(a)redhat.com, s(a)shk.io, thrcka(a)redhat.com,
vbatts(a)redhat.com
Description of problem:
When I attempt to run Docker exec on a running container I get the following
error:
Error response from daemon: Unsupported: Exec is not supported by the lxc
driver
Version-Release number of selected component (if applicable):
# uname -a
Linux 2.6.32-504.el6.x86_64 #1 SMP Tue Oct 14 01:47:47 PDT 2014 x86_64 x86_64
x86_64 GNU/Linux
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.6 (Santiago)
# docker version
Client version: 1.3.1
Client API version: 1.15
Go version (client): go1.3.3
Git commit (client): 4e9bbfa
OS/Arch (client): linux/amd64
Server version: 1.3.1
Server API version: 1.15
Go version (server): go1.3.3
Git commit (server): 4e9bbfa
How reproducible: 100%
Steps to Reproduce:
1. $ docker exec -it my_docker_image bash
Actual results:
Error response from daemon: Unsupported: Exec is not supported by the lxc
driver
Expected results:
The expected result is that I get a bash prompt.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 2 months
[Bug 1169334] New: docker run fails with " The database file is locked: database is locked"
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1169334
Bug ID: 1169334
Summary: docker run fails with " The database file is locked:
database is locked"
Product: Fedora
Version: rawhide
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: lsm5(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, 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
Description of problem:
$ sudo docker run -it fedora:rawhide bash
FATA[0000] Error response from daemon: The database file is locked: database is
locked
Version-Release number of selected component (if applicable):
docker-io-1.3.2-3.git353ff40.fc22.x86_64
How reproducible: while this may not be seen for the first few docker runs, it
will pretty much show up by the 3rd-4th docker run
Steps to Reproduce:
1. install docker
2. run aforementioned command (try different image if need be)
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 2 months
[Bug 1152862] New: autofs shouldn't have kernel as a dependency
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1152862
Bug ID: 1152862
Summary: autofs shouldn't have kernel as a dependency
Product: Red Hat Enterprise Linux 7
Version: 7.1
Component: autofs
Severity: medium
Assignee: ikent(a)redhat.com
Reporter: ikent(a)redhat.com
QA Contact: fs-qe(a)redhat.com
CC: admiller(a)redhat.com, extras-qa(a)fedoraproject.org,
golang(a)lists.fedoraproject.org, hushan.jia(a)gmail.com,
ikent(a)redhat.com, jpazdziora(a)redhat.com,
lsm5(a)fedoraproject.org, mattdm(a)redhat.com,
mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com
Depends On: 1113601
+++ This bug was initially created as a clone of Bug #1113601 +++
Description of problem:
When kernel is installed as a dependency of autofs, various errors concerning
/var are shown in posttrans.
Version-Release number of selected component (if applicable):
docker-io-1.0.0-4.fc20.x86_64
fedora:20 image as of today: 3f2fed40e4b0
How reproducible:
Deterministic.
Steps to Reproduce:
1. Have Dockerfile:
FROM fedora:20
RUN yum install -y autofs
2. Run docker build -t autofs-test .
Actual results:
# docker build -t autofs-test .
Sending build context to Docker daemon 2.56 kB
Sending build context to Docker daemon
Step 0 : FROM fedora:20
---> 3f2fed40e4b0
Step 1 : RUN yum install -y autofs
---> Running in 9b0bbf2f654d
http://mirrors.zimcom.net/pub/fedora/linux/updates/20/x86_64/repodata/rep...:
[Errno 14] curl#7 - "Failed to connect to 2607:f550:100:33::23: Network is
unreachable"
Trying other mirror.
Resolving Dependencies
--> Running transaction check
---> Package autofs.x86_64 1:5.0.7-40.fc20 will be installed
--> Processing Dependency: kernel >= 2.6.17 for package:
1:autofs-5.0.7-40.fc20.x86_64
--> Processing Dependency: libtirpc.so.1()(64bit) for package:
1:autofs-5.0.7-40.fc20.x86_64
--> Processing Dependency: libhesiod.so.0()(64bit) for package:
1:autofs-5.0.7-40.fc20.x86_64
--> Running transaction check
---> Package hesiod.x86_64 0:3.2.1-2.fc20 will be installed
---> Package kernel.x86_64 0:3.14.8-200.fc20 will be installed
--> Processing Dependency: linux-firmware >= 20130724-29.git31f6b30 for
package: kernel-3.14.8-200.fc20.x86_64
---> Package libtirpc.x86_64 0:0.2.4-3.0.fc20 will be installed
--> Running transaction check
---> Package linux-firmware.noarch 0:20140605-38.gita4f3bc03.fc20 will be
installed
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
autofs x86_64 1:5.0.7-40.fc20 updates 524 k
Installing for dependencies:
hesiod x86_64 3.2.1-2.fc20 fedora 29 k
kernel x86_64 3.14.8-200.fc20 updates 32 M
libtirpc x86_64 0.2.4-3.0.fc20 updates 83 k
linux-firmware noarch 20140605-38.gita4f3bc03.fc20 updates 21 M
Transaction Summary
================================================================================
Install 1 Package (+4 Dependent packages)
Total download size: 53 M
Installed size: 192 M
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
warning:
/var/cache/yum/x86_64/20/fedora/packages/hesiod-3.2.1-2.fc20.x86_64.rpm: Header
V3 RSA/SHA256 Signature, key ID 246110c1: NOKEY
Public key for hesiod-3.2.1-2.fc20.x86_64.rpm is not installed
Public key for autofs-5.0.7-40.fc20.x86_64.rpm is not installed
--------------------------------------------------------------------------------
Total 4.0 MB/s | 53 MB 00:13
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-x86_64
Importing GPG key 0x246110C1:
Userid : "Fedora (20) <fedora(a)fedoraproject.org>"
Fingerprint: c7c9 a9c8 9153 f201 83ce 7cba 2eb1 61fa 2461 10c1
Package : fedora-release-20-3.noarch (@fedora-updates/$releasever)
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-x86_64
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : hesiod-3.2.1-2.fc20.x86_64 1/5
Installing : libtirpc-0.2.4-3.0.fc20.x86_64 2/5
Installing : linux-firmware-20140605-38.gita4f3bc03.fc20.noarch 3/5
Installing : kernel-3.14.8-200.fc20.x86_64 4/5
Installing : 1:autofs-5.0.7-40.fc20.x86_64 5/5
No '/dev/log' or 'logger' included for syslog logging
mknod: '/var/tmp/initramfs.aD5A0T/dev/null': Operation not permitted
mknod: '/var/tmp/initramfs.aD5A0T/dev/kmsg': Operation not permitted
mknod: '/var/tmp/initramfs.aD5A0T/dev/console': Operation not permitted
No '/dev/log' or 'logger' included for syslog logging
mknod: '/var/tmp/initramfs.XRmzzi/dev/null': Operation not permitted
mknod: '/var/tmp/initramfs.XRmzzi/dev/kmsg': Operation not permitted
mknod: '/var/tmp/initramfs.XRmzzi/dev/console': Operation not permitted
/usr/lib/kernel/install.d/51-dracut-rescue.install: line 59:
/boot/loader/entries/5b2a1f96231d4de69964798a33d2add8-0-rescue.conf: No such
file or directory
warning: %posttrans(kernel-3.14.8-200.fc20.x86_64) scriptlet failed, exit
status 1
Non-fatal POSTTRANS scriptlet failure in rpm package
kernel-3.14.8-200.fc20.x86_64
Verifying : 1:autofs-5.0.7-40.fc20.x86_64 1/5
Verifying : linux-firmware-20140605-38.gita4f3bc03.fc20.noarch 2/5
Verifying : libtirpc-0.2.4-3.0.fc20.x86_64 3/5
Verifying : hesiod-3.2.1-2.fc20.x86_64 4/5
Verifying : kernel-3.14.8-200.fc20.x86_64 5/5
Installed:
autofs.x86_64 1:5.0.7-40.fc20
Dependency Installed:
hesiod.x86_64 0:3.2.1-2.fc20
kernel.x86_64 0:3.14.8-200.fc20
libtirpc.x86_64 0:0.2.4-3.0.fc20
linux-firmware.noarch 0:20140605-38.gita4f3bc03.fc20
Complete!
---> e11ccfbfb8a0
Removing intermediate container 9b0bbf2f654d
Successfully built e11ccfbfb8a0
Expected results:
Either kernel not pulled in, or no (or less) errors from posttrans.
Additional info:
Using docker-io component as a start of discussion about supporting autofs in
Docker containers and if something can be changed in packaging of autofs or
kernel or in the fedora:20 image to lower the posttrans noise.
--- Additional comment from Matthew Miller on 2014-06-26 14:55:58 EDT ---
See https://lists.fedoraproject.org/pipermail/packaging/2014-March/010083.html
I thiink the only reason autofs has this requirement is that it needs to run on
a kernel newer than or equal to 2.6.17. So, I'm moving this bug to autofs.
Of course, having that kernel package installed doesn't mean that one is
running under that kernel. Docker obviously demonstrates this, but also,
there's no reason one couldn't have a kernel 2.6.17 package installed but be
running 2.6.16 since the system wasn't rebooted.
However, all of that seems pretty much moot now, since we're long past the
required kernel version in Fedora and even back to RHEL 5. My strong
recommendation is to just remove the "Requires: kernel" line.
(Another option would be to use "Conflicts: kernel < 2.6.17", but that still
has the conceptual problem with package vs. running kernel. I say just drop
it.)
--- Additional comment from Ian Kent on 2014-06-26 21:18:42 EDT ---
(In reply to Matthew Miller from comment #1)
> See
> https://lists.fedoraproject.org/pipermail/packaging/2014-March/010083.html
>
>
> I thiink the only reason autofs has this requirement is that it needs to run
> on a kernel newer than or equal to 2.6.17. So, I'm moving this bug to autofs.
>
>
> Of course, having that kernel package installed doesn't mean that one is
> running under that kernel. Docker obviously demonstrates this, but also,
> there's no reason one couldn't have a kernel 2.6.17 package installed but be
> running 2.6.16 since the system wasn't rebooted.
>
> However, all of that seems pretty much moot now, since we're long past the
> required kernel version in Fedora and even back to RHEL 5. My strong
> recommendation is to just remove the "Requires: kernel" line.
>
>
> (Another option would be to use "Conflicts: kernel < 2.6.17", but that still
> has the conceptual problem with package vs. running kernel. I say just drop
> it.)
Fair enough, I'll drop it.
--- Additional comment from Fedora Update System on 2014-10-15 00:37:14 EDT ---
autofs-5.0.7-41.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/autofs-5.0.7-41.fc20
--- Additional comment from Ian Kent on 2014-10-15 00:42:24 EDT ---
Sincere apologies for taking so long with this.
It occurs to me that while this Requires is clearly obsolete
now, for packages that need a Requires for a particular kernel,
that Docker should handle it rather than trying to pull in the
kernel dependency ....
Just a thought.
Ian
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1113601
[Bug 1113601] autofs shouldn't have kernel as a dependency
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 2 months
[Bug 1173550] New: Docker load fails to load xz-compressed image
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1173550
Bug ID: 1173550
Summary: Docker load fails to load xz-compressed image
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: masanari_iida(a)hp.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
hushan.jia(a)gmail.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
Description of problem:
Docker load fails to load xz-compressed image
Version-Release number of selected component (if applicable):
docker-io-1.3.2-4.fc20.x86_64
How reproducible:
Always
Steps to Reproduce:
cat my-image.tar.xz | docker import -
(This image was created with "supermin --format chroot" option.)
Actual results:
Error: ApplyLayer exit status 1 exec: "xz": executable file not in $PATH
Expected results:
Docker import image file without problem.
Additional info:
This is known problem which was introduced in docker-1.3.2
https://github.com/docker/docker/issues/9327
Fix
https://github.com/docker/docker/commit/001ac15b54686761960352103ebf4ff2c...
Workaround:
Downgrade to 1.3.1
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 2 months
[Bug 1029587] New: upgrade to go1.2 (once it is available)
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1029587
Bug ID: 1029587
Summary: upgrade to go1.2 (once it is available)
Product: Fedora
Version: rawhide
Component: golang
Severity: low
Assignee: adam(a)spicenitz.org
Reporter: vbatts(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: adam(a)spicenitz.org, admiller(a)redhat.com,
golang(a)lists.fedoraproject.org, lemenkov(a)gmail.com,
lsm5(a)redhat.com, renich(a)woralelandia.com,
vbatts(a)redhat.com
What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. export GOPATH=$(mktemp -d)
2. go get code.google.com/p/go.tools/cmd/oracle
3.
What is the expected output?
What do you see instead?
/tmp/tmp.cjYFzAeLWC/src/code.google.com/p/go.tools/importer/source.go:434:
n.Lparen undefined (type *ast.TypeAssertExpr has no field or method Lparen)
/tmp/tmp.cjYFzAeLWC/src/code.google.com/p/go.tools/importer/source.go:435:
n.Lparen undefined (type *ast.TypeAssertExpr has no field or method Lparen)
/tmp/tmp.cjYFzAeLWC/src/code.google.com/p/go.tools/importer/source.go:436:
n.Rparen undefined (type *ast.TypeAssertExpr has no field or method Rparen)
Which compiler are you using (5g, 6g, 8g, gccgo)?
6g
Which operating system are you using?
Red Hat Enterprise Linux Workstation release 6.4 (Santiago)
Which version are you using?
go version go1.1.2 linux/amd64 (golang-1.1.2-4.el6.x86_64)
Please provide any additional information below.
I tested against the tip of their repo (future version 1.2) (go version devel
+39c724dd7f25 Tue Nov 12 09:28:07 2013 +1100 linux/amd64)
and code.google.com/p/go.tools/cmd/oracle and
code.google.com/p/go.tools/cmd/ssadump build just fine
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 2 months
[Bug 1099074] New: Processing Dependency: golang-docs = 1.1-2.fc19 for package: golang-godoc-1.1-2.fc19.x86_64
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1099074
Bug ID: 1099074
Summary: Processing Dependency: golang-docs = 1.1-2.fc19 for
package: golang-godoc-1.1-2.fc19.x86_64
Product: Fedora
Version: 19
Component: golang
Severity: high
Assignee: adam(a)spicenitz.org
Reporter: dridi.boukelmoune(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: adam(a)spicenitz.org, admiller(a)redhat.com,
golang(a)lists.fedoraproject.org, lemenkov(a)gmail.com,
lsm5(a)redhat.com, renich(a)woralelandia.com, s(a)shk.io,
vbatts(a)redhat.com
Description of problem:
I'm trying to install the golang-godoc package but it fails. It's looking for
golang-docs which is provided by golang, but the required version doesn't
match.
Version-Release number of selected component (if applicable):
golang-1.2.1-1.fc19.x86_64
golang-godoc-1.1-2.fc19.x86_64
How reproducible: always
Steps to Reproduce:
1. sudo yum install golang
2. sudo yum install golang-godoc
Actual results:
Resolving Dependencies
--> Running transaction check
---> Package golang-godoc.x86_64 0:1.1-2.fc19 will be installed
--> Processing Dependency: golang-docs = 1.1-2.fc19 for package:
golang-godoc-1.1-2.fc19.x86_64
Package golang-docs-1.1-2.fc19.noarch is obsoleted by
golang-1.2.1-1.fc19.x86_64 which is already installed
--> Processing Dependency: golang(x86-64) = 1.1-2.fc19 for package:
golang-godoc-1.1-2.fc19.x86_64
--> Finished Dependency Resolution
Error: Package: golang-godoc-1.1-2.fc19.x86_64 (fedora)
Requires: golang(x86-64) = 1.1-2.fc19
Installed: golang-1.2.1-1.fc19.x86_64 (@updates)
golang(x86-64) = 1.2.1-1.fc19
Available: golang-1.1-2.fc19.x86_64 (fedora)
golang(x86-64) = 1.1-2.fc19
Error: Package: golang-godoc-1.1-2.fc19.x86_64 (fedora)
Requires: golang-docs = 1.1-2.fc19
Available: golang-docs-1.1-2.fc19.noarch (fedora)
golang-docs = 1.1-2.fc19
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
Expected results:
Is this ok [y/d/N]:
Additional info:
I couldn't find golang-godoc in pkgdb2, so I'm filing against golang.
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 2 months
[Bug 1128208] New: docker io not using proper DNS
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1128208
Bug ID: 1128208
Summary: docker io not using proper DNS
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)fedoraproject.org
Reporter: briemers(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, dgoodwin(a)redhat.com,
eparis(a)redhat.com, extras-qa(a)fedoraproject.org,
gansalmon(a)Gmail.com, golang(a)lists.fedoraproject.org,
hushan.jia(a)gmail.com, itamar(a)ispbrasil.com.br,
jeder(a)redhat.com, jonathan(a)jonmasters.org,
jpazdziora(a)redhat.com, jperrin(a)centos.org,
kernel-maint(a)redhat.com, lars(a)redhat.com,
lsm5(a)fedoraproject.org, madhu.chinakonda(a)gmail.com,
mattdm(a)redhat.com, mchehab(a)infradead.org,
mgoldman(a)redhat.com, pmoore(a)redhat.com,
rbriggs(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com
Depends On: 1119849
The resolution for Bug #1119849 introduced a new problem.
I have a dockerfile that uses the command:
git clone http://gitolite.corp.redhat.com/cgit/it-sales/sfjavasuite.git/
Up until the most recent update the dockerfile worked expected. Now it fails
with a hostname not found.
It seems part of the update is docker will now try and use fixed DNS values of
8.8.8.8 and 8.8.4.4. Which is of course in appropriate for anyone inside a
private network. In some cases it is even considered a security risk to have
DNS lookups leak to a public DNS server, as it gives outside user information
about the private network.
It is possible to update the docker options to work around the problem. But
of course the DNS servers obtained by DHCP, so it would require restarting
docker-io with new settings everytime a new network connection is
established...
Likewise another workaround is a set if iptable rules to override all DNS
lookups but again this introduces it's own set of problems.
And of course, I don't want to assume everyone who will use my Dockerfile has
updated their workstations and servers with whatever hack solution I use...
Reproduce steps:
1. docker run fedora cat /etc/resolv.conf
Expected results:
The DNS settings equivalent to the host, which in my case are:
$ cat /etc/resolv.conf
# Generated by NetworkManager
domain docbill.info
search docbill.info
nameserver 127.0.0.1
nameserver 172.31.253.1
nameserver 172.31.252.1
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 10.11.255.155
nameserver 10.11.255.156
nameserver 10.5.26.21
nameserver 10.7.142.20
nameserver fe80::beae:c5ff:fee8:b5e%em1
nameserver fe80::4216:7eff:feea:a5b8%em1
nameserver 2001:470:1d:8a2::1
Actual results:
$ docker run fedora cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
search docbill.info
Note: I'm not sure how the previous docker-io version got the 127.0.0.1
correct. But somehow it figured out that was an instruction to use the dnsmasq
instance on my laptop.
Bill
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1119849
[Bug 1119849] su - postgres Results in System Error inside Fedora
20/rawhide containers
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 3 months
[Bug 1170309] New: docker-io-1.2 no longer available. 1.3.1 doesn't work with RHEL 6.5.
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1170309
Bug ID: 1170309
Summary: docker-io-1.2 no longer available. 1.3.1 doesn't work
with RHEL 6.5.
Product: Fedora EPEL
Version: el6
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: kmayfiel(a)us.ibm.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
hushan.jia(a)gmail.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
Description of problem:
Incorrectly upgraded to 1.3.1. Docker service daemon fails to start (panic).
Message recommends upgrade to 3.8 kernel, which is not an option for me at this
time.
Before upgrade 1.2 was working.
Attempt to remove package and install docker-io-1.2 is impossible without
access to that package in epel repository.
Version-Release number of selected component (if applicable):
1.2
Message from 1.3.1
2014/12/02 10:00:03 docker daemon: 1.3.1 c78088f/1.3.1; execdriver: native;
graphdriver:
[f9523c24] +job serveapi(unix:///var/run/docker.sock)
[info] WARNING: You are running linux kernel version
2.6.32-431.30.1.el6.x86_64, which might be unstable running docker. Please
upgrade your kernel to 3.8.0.
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x0 pc=0x0]
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 3 months
[Bug 1173325] New: CVE-2014-9357 docker-io: docker: Escalation of privileges during decompression of LZMA archives [epel-6]
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1173325
Bug ID: 1173325
Summary: CVE-2014-9357 docker-io: docker: Escalation of
privileges during decompression of LZMA archives
[epel-6]
Product: Fedora EPEL
Version: el6
Component: docker-io
Keywords: Security, SecurityTracking
Severity: low
Priority: low
Assignee: lsm5(a)redhat.com
Reporter: vdanen(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, 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
Blocks: 1172782 (CVE-2014-9357)
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of Fedora EPEL.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
epel-6 tracking bug for docker-io: see blocks bug list for full details of the
security issue(s).
This bug is never intended to be made public, please put any public notes
in the blocked bugs.
[bug automatically created by: add-tracking-bugs]
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1172782
[Bug 1172782] CVE-2014-9357 docker: Escalation of privileges during
decompression of LZMA archives
--
You are receiving this mail because:
You are on the CC list for the bug.
9 years, 3 months