[Bug 1176302] New: /var/log/docker incorrectly asserts that kernel 2.6.32* "might be unstable running docker"
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1176302
Bug ID: 1176302
Summary: /var/log/docker incorrectly asserts that kernel
2.6.32* "might be unstable running docker"
Product: Fedora EPEL
Version: el6
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: afoxson(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: adimania(a)gmail.com, 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:
The following warning appears in /var/log/docker:
"WARNING: You are running linux kernel version 2.6.32-504.1.3.el6.x86_64, which
might be unstable running docker. Please upgrade your kernel to 3.8.0."
Version-Release number of selected component (if applicable):
docker-io-1.3.2-2.el6.x86_64.rpm
How reproducible:
Consistently.
Steps to Reproduce:
1. Run docker in daemon mode.
2. Review /var/log/docker.
Actual results:
The aforementioned warning appears in /var/log/docker.
Expected results:
The aforementioned warning not appearing in /var/log/docker.
Additional info:
This warning is incorrect as per:
https://github.com/docker/docker/issues/407#issuecomment-43206662
which states:
"Kernels older than 3.8 aren't supported. That means technical support isn't
provided and you might run into unexpected behavior, even if it seems like it's
working. The only exception is the kernel provided by RHEL6 (2.6.32xxxxxx)
which was patched and improved to work properly with Docker."
It seems that an environment variable is available for this situation, as per:
https://github.com/shykes/docker-dev/commit/2c2a655da14f6de9353454673f2a1...
which states:
"set DOCKER_NOWARN_KERNEL_VERSION=1 to disable the warning for RHEL 6.5"
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 9 months
[Bug 1184710] New: dnsmasq needs to be restarted after reboot for dns to work in a Docker container
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1184710
Bug ID: 1184710
Summary: dnsmasq needs to be restarted after reboot for dns to
work in a Docker container
Product: Fedora
Version: 21
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: jshepherd(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: adimania(a)gmail.com, 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
External Bug ID: Red Hat Bugzilla 1128208
External Bug ID: Red Hat Bugzilla 1128208
Description of problem:
Docker replies on dnsmasq to have 'listen-address' set to the docker bridge,
and have bind-interfaces option turned on. However in this configuration
dnsmasq has to start after docker in order for DNS to work in a docker
container.
Version-Release number of selected component (if applicable):
docker-io 1.4.0
dnsmasq 2.72
How reproducible:
Reboot the system with docker, and dnsmasq enabled.
Steps to Reproduce:
1. Ensure docker is using the default dns option of 172.17.42.1
2. Use the attached dnsmasq.conf
3. Reboot the system
4. Launch a docker container:
`docker run -i -t centos /usr/bin/ping www.redhat.com`
Actual results:
Cannot resolve hostname
Expected results:
Response from 'akamai' or similar
Additional info:
See related issue #1128208
I tried added a systemd 'After' for dnsmasq on docker.service, but it doesn't
seem to be honoured by systemd.
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 9 months
[Bug 1108349] New: remove golang-github-syndtr-gocapability from epel7
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1108349
Bug ID: 1108349
Summary: remove golang-github-syndtr-gocapability from epel7
Product: Fedora EPEL
Version: epel7
Component: golang-github-syndtr-gocapability
Assignee: vbatts(a)redhat.com
Reporter: lsm5(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: golang(a)lists.fedoraproject.org, lsm5(a)redhat.com,
vbatts(a)redhat.com
Description of problem:
remove this package from epel7 as it's now available in rhel7 proper.
Version-Release number of selected component (if applicable):
golang-github-syndtr-gocapability-0-0.5.git3454319.el7
Additional info:
retired from dist-git:
http://pkgs.fedoraproject.org/cgit/golang-github-syndtr-gocapability.git/...
For pkgdb, Vincent could you run this for the epel7 branch (I'm not an admin
for this one):
pkgdb-cli orphan --retire golang-github-syndtr-gocapability epel7
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 9 months
[Bug 1100502] New: golang-1.2.2-2 update breaks GOROOT path
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1100502
Bug ID: 1100502
Summary: golang-1.2.2-2 update breaks GOROOT path
Product: Fedora
Version: 20
Component: golang
Assignee: adam(a)spicenitz.org
Reporter: porjo38(a)yahoo.com.au
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
Since updating to golang-1.2.2-2, I get error "go: cannot find GOROOT
directory: /usr/lib64/golang" when trying to run a go program e.g. "go run
main.go"
Adding a symbolic link fixes the issue:
ln -s /usr/lib/golang/ /usr/lib64/golang
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 9 months