https://bugzilla.redhat.com/show_bug.cgi?id=1113601
Bug ID: 1113601
Summary: When kernel is installed as a dependency of autofs,
various errors are shown
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)switzerlandmail.ch
Reporter: jpazdziora(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, lsm5(a)switzerlandmail.ch,
mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io,
vbatts(a)redhat.com
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/repom…:
[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.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1146705
Bug ID: 1146705
Summary: docker.sock owned by docker group but docker needs
root
Product: Fedora
Version: rawhide
Component: docker-io
Assignee: lsm5(a)fedoraproject.org
Reporter: lsm5(a)fedoraproject.org
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, thrcka(a)redhat.com,
vbatts(a)redhat.com
Description of problem:
$ ls -al /var/run/docker.sock
srw-rw----. 1 root docker 0 Sep 25 14:45 /var/run/docker.sock
$ docker pull fedora
2014/09/25 14:48:04 Post
http:///var/run/docker.sock/images/create?fromImage=fedora&tag=: dial unix
/var/run/docker.sock: permission denied
$ sudo docker pull fedora
Pulling repository fedora
f1515fbc671c: Download complete
22499213da48: Download complete
b5751574adac: Download complete
511136ea3c5a: Download complete
ff75b0852d47: Download complete
Version-Release number of selected component (if applicable):
docker-1.2.0-2.fc22
How reproducible:
always
Steps to Reproduce:
1. install docker
2. use docker
Expected results:
docker commands should work without need for root
Additional info:
systemd-216-6.fc22.x86_64
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1147326
Bug ID: 1147326
Summary: CVE-2014-7189 golang: TLS client authentication issue
fixed in version 1.3.2 [epel-6]
Product: Fedora EPEL
Version: el6
Component: golang
Keywords: Security, SecurityTracking
Severity: medium
Priority: medium
Assignee: admiller(a)redhat.com
Reporter: mmcallis(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)fedoraproject.org, s(a)shk.io
Blocks: 1147324 (CVE-2014-7189)
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 golang: see blocks bug list for full details of the
security issue(s).
[bug automatically created by: add-tracking-bugs]
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1147324
[Bug 1147324] CVE-2014-7189 golang: TLS client authentication issue fixed
in version 1.3.2
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1147327
Bug ID: 1147327
Summary: CVE-2014-7189 golang: TLS client authentication issue
fixed in version 1.3.2 [epel-7]
Product: Fedora EPEL
Version: epel7
Component: golang
Keywords: Security, SecurityTracking
Severity: medium
Priority: medium
Assignee: admiller(a)redhat.com
Reporter: mmcallis(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)fedoraproject.org, s(a)shk.io
Blocks: 1147324 (CVE-2014-7189)
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-7 tracking bug for golang: see blocks bug list for full details of the
security issue(s).
[bug automatically created by: add-tracking-bugs]
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1147324
[Bug 1147324] CVE-2014-7189 golang: TLS client authentication issue fixed
in version 1.3.2
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1099206
Bug ID: 1099206
Summary: timestamps of libraries and artifacts out of sync
Product: Fedora
Version: rawhide
Component: golang
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, s(a)shk.io,
vbatts(a)redhat.com
Description of problem:
https://gist.github.com/ncdc/1a6bcb988a700d52dfec
Version-Release number of selected component (if applicable):
1.2.2-2
How reproducible:
consisten
Steps to Reproduce:
1. build something that uses stdlib
2.
3.
Actual results:
agoldste@localhost:~/go/src/github.com/openshift/docker-source-to-images/go/sti
(master) go install
go install runtime/cgo: open /usr/lib/golang/pkg/linux_amd64/runtime/cgo.a:
permission denied
Expected results:
successful compile
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1096816
Bug ID: 1096816
Summary: useradd within EL6 container fails: failure while
writing changes to /etc/passwd
Product: Red Hat Enterprise Linux 6
Version: 6.5
Component: libselinux
Assignee: dwalsh(a)redhat.com
Reporter: dwalsh(a)redhat.com
QA Contact: qe-baseos-security(a)redhat.com
CC: admiller(a)redhat.com, dcleal(a)redhat.com,
dwalsh(a)redhat.com, golang(a)lists.fedoraproject.org,
jpazdziora(a)redhat.com, jumanjiman(a)gmail.com,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com
Depends On: 1096123
+++ This bug was initially created as a clone of Bug #1096123 +++
Description of problem:
Between docker-io-0.10.0-2.fc20 and docker-io-0.11.1-1.fc20, the following has
started failing:
$ docker run -t centos /usr/sbin/useradd test
useradd: failure while writing changes to /etc/passwd
'centos' is the official CentOS 6 image (0b443ba03958).
The Fedora 20 host has SELinux enforcing, and the same issue occurs when set to
permissive. No AVCs are seen.
Version-Release number of selected component (if applicable):
docker-io-0.11.1-1.fc20.x86_64
kernel-3.14.2-200.fc20.x86_64
How reproducible:
Always
Steps to Reproduce:
1. docker pull centos
2. docker run -t centos /usr/sbin/useradd test
Actual results:
useradd: failure while writing changes to /etc/passwd
Expected results:
no output
Additional info:
On 0.10.0, an strace of useradd shows:
open("/etc/group", O_RDONLY|O_CLOEXEC) = 11
fstat(11, {st_mode=S_IFREG|0644, st_size=379, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7feb5efe5000
read(11, "root:x:0:\nbin:x:1:bin,daemon\ndae"..., 4096) = 379
close(11) = 0
munmap(0x7feb5efe5000, 4096) = 0
fchown(10, 500, 12) = 0
fchmod(10, 0660) = 0
fsync(10) = 0
close(10) = 0
fstat(6, {st_mode=S_IFREG|0644, st_size=670, ...}) = 0
gettid() = 14
open("/proc/self/task/14/attr/fscreate", O_RDONLY) = 10
read(10, "", 4095) = 0
close(10) = 0
gettid() = 14
open("/proc/self/task/14/attr/fscreate", O_RDWR) = 10
write(10, "system_u:object_r:file_t:s0\0", 28) = 28
close(10) = 0
fstat(6, {st_mode=S_IFREG|0644, st_size=670, ...}) = 0
umask(077) = 022
open("/etc/passwd-", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 10
umask(022) = 077
lseek(6, 0, SEEK_SET) = 0
read(6, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 670
fstat(10, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7feb5efe5000
read(6, "", 4096) = 0
write(10, "root:x:0:0:root:/root:/bin/bash\n"..., 670) = 670
While on 0.11.1, strace shows:
open("/etc/group", O_RDONLY|O_CLOEXEC) = 10
fstat(10, {st_mode=S_IFREG|0644, st_size=379, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f2905a38000
read(10, "root:x:0:\nbin:x:1:bin,daemon\ndae"..., 4096) = 379
close(10) = 0
munmap(0x7f2905a38000, 4096) = 0
fchown(9, 500, 12) = 0
fchmod(9, 0660) = 0
fsync(9) = 0
close(9) = 0
fstat(5, {st_mode=S_IFREG|0644, st_size=675, ...}) = 0
gettid() = 30
open("/proc/self/task/30/attr/fscreate", O_RDONLY) = 9
read(9, "", 4095) = 0
close(9) = 0
gettid() = 30
open("/proc/self/task/30/attr/fscreate", O_RDWR) = -1 EROFS (Read-only file
system)
write(2, "useradd: failure while writing c"..., 54useradd: failure while
writing changes to /etc/passwd
) = 54
--- Additional comment from Dominic Cleal on 2014-05-09 07:13:07 EDT ---
useradd is just calling libselinux's setfscreatecon, which is being blocked.
On 0.11.1, this library call fails, on 0.10.0/0.9 it works.
--- Additional comment from Paul Morgan on 2014-05-09 09:55:15 EDT ---
when selinux=disabled, i cannot reproduce the bug.
when selinux is enabled (permissive), the bug is always reproducible.
i reproduced using two docker service configs:
* first, use default systemd unit
* second, add `--selinux-enabled` as described at
http://blog.docker.io/2014/05/docker-0-11-release-candidate-for-1-0/
override default systemd unit...
# cp /usr/lib/systemd/system/docker.service /etc/systemd/system/
# vim /etc/systemd/system/docker.service
# cat !$
[Unit]
Description=Docker Application Container Engine
Documentation=http://docs.docker.io
After=network.target
[Service]
ExecStart=/usr/bin/docker -d --selinux-enabled
Restart=on-failure
LimitNOFILE=1048576
LimitNPROC=1048576
[Install]
WantedBy=multi-user.target
# systemctl restart docker.service
# systemctl status docker.service
docker.service - Docker Application Container Engine
Loaded: loaded (/etc/systemd/system/docker.service; enabled)
Active: active (running) since Fri 2014-05-09 09:52:25 EDT; 4s ago
Docs: http://docs.docker.io
Main PID: 997 (docker)
CGroup: /system.slice/docker.service
└─997 /usr/bin/docker -d --selinux-enabled
other system info:
$ rpm -q selinux-policy-targeted
selinux-policy-targeted-3.12.1-158.fc20.noarch
$ uname -a
Linux f20-01.example.com 3.13.9-200.fc20.x86_64 #1 SMP Fri Apr 4 12:13:05 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux
$ rpm -q docker-io
docker-io-0.11.1-1.fc20.x86_64
$ docker version
Client version: 0.11.1
Client API version: 1.11
Go version (client): go1.2.1
Git commit (client): fb99f99/0.11.1
Server version: 0.11.1
Server API version: 1.11
Git commit (server): fb99f99/0.11.1
Go version (server): go1.2.1
Last stable version: 0.11.1
$ docker images | grep '^centos'
centos centos6 0b443ba03958 3 weeks ago
297.6 MB
centos latest 0b443ba03958 3 weeks ago
297.6 MB
centos 6.4 539c0211cd76 13 months ago
300.6 MB
--- Additional comment from Lokesh Mandvekar on 2014-05-09 13:41:51 EDT ---
I have a new scratch build
http://kojipkgs.fedoraproject.org//work/tasks/2230/6832230/docker-io-0.11.1…
with this build, this error doesn't occur with fedora:20, but still does with
centos
dwalsh, comments?
--- Additional comment from Dominic Cleal on 2014-05-09 13:45:57 EDT ---
Comparing the straces between el6 and fedora:20, I don't see any of the same
accesses to attr/fscreate on f20 that are in the bug description. The source
of shadow-utils between el6 & f20 looks very different too, I can't see any
setfscreatecon calls in the useradd code path.
--- Additional comment from Daniel Walsh on 2014-05-09 16:51:06 EDT ---
The problem is inside the container it sees SELinux as being enabled, which is
the bug.
If you do id -Z, does it complain inside the container?
docker run --rm -t -i fedora sh
sh-4.2# id -Z
id: --context (-Z) works only on an SELinux-enabled kernel
sh-4.2# mount | grep /sys
sysfs on /sys type sysfs (ro,relatime,seclabel)
SELinux sees the container as being disabled since /sys/fs/selinux is mounted
as read/only, this will tell useradd NOT to try to do any SELinux stuff while
in the container.
--- Additional comment from Fedora Update System on 2014-05-10 00:04:23 EDT ---
docker-io-0.11.1-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/docker-io-0.11.1-3.fc20
--- Additional comment from Dominic Cleal on 2014-05-10 08:01:14 EDT ---
(In reply to Daniel Walsh from comment #5)
> The problem is inside the container it sees SELinux as being enabled, which
> is the bug.
>
> If you do id -Z, does it complain inside the container?
No, it runs and reports a context.
> docker run --rm -t -i fedora sh
> sh-4.2# id -Z
> id: --context (-Z) works only on an SELinux-enabled kernel
> sh-4.2# mount | grep /sys
> sysfs on /sys type sysfs (ro,relatime,seclabel)
$ rpm -q docker-io
docker-io-0.9.1-1.fc20.x86_64
$ docker run -i -t centos /bin/bash
bash-4.1# id -Z
system_u:system_r:docker_t:s0
bash-4.1# mount | grep sys
sysfs on /sys type sysfs (rw,seclabel,nosuid,nodev,noexec,relatime)
$ rpm -q docker-io
docker-io-0.11.1-3.fc20.x86_64
$ docker run -i -t centos /bin/bash
bash-4.1# id -Z
system_u:system_r:svirt_lxc_net_t:s0:c231,c400
bash-4.1# mount | grep /sys
sysfs on /sys type sysfs (ro,seclabel,relatime)
> SELinux sees the container as being disabled since /sys/fs/selinux is
> mounted as read/only, this will tell useradd NOT to try to do any SELinux
> stuff while in the container.
/sys is correctly read-only as you expected, but it seems useradd's still doing
SELinux stuff then. These packages are installed inside the EL6 container:
libselinux-2.0.94-5.3.el6_4.1.x86_64
libselinux-utils-2.0.94-5.3.el6_4.1.x86_64
shadow-utils-4.1.4.2-13.el6.x86_64
Calling is_selinux_enabled() on Fedora is returning 0, while on EL6 it's
returning 1. Another difference - on Fedora, getenforce returns "Disabled" but
on EL6 it prints:
# getenforce
getenforce: getenforce() failedbash-4.1#
/selinux exists within the container, but nothing is actually mounted there.
It appears to be simply a directory on the root filesystem (/selinux/booleans
exists as an empty dir). No other SELinux mounts are visible.
Looking at libselinux-2.0.94, I think it's seeing selinuxfs listed in
/proc/filesystems and assuming SELinux is enabled because of this.
libselinux-2.2.1 on F20 doesn't seem to have this code.
libselinux-2.0.94/src/enabled.c:
/* Drop back to detecting it the long way. */
fp = fopen("/proc/filesystems", "r");
if (!fp)
return -1;
__fsetlocking(fp, FSETLOCKING_BYCALLER);
while ((num = getline(&buf, &len, fp)) != -1) {
if (strstr(buf, "selinuxfs")) {
enabled = 1;
break;
}
}
# grep selinux /proc/filesystems
nodev selinuxfs
(All the above was tested with docker-io-0.11.1-3.fc20)
--- Additional comment from Fedora Update System on 2014-05-12 01:28:00 EDT ---
Package docker-io-0.11.1-3.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing docker-io-0.11.1-3.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-6281/docker-io-0.11.1-3…
then log in and leave karma (feedback).
--- Additional comment from Dominic Cleal on 2014-05-12 06:34:11 EDT ---
(In reply to Dominic Cleal from comment #7)
> Looking at libselinux-2.0.94, I think it's seeing selinuxfs listed in
> /proc/filesystems and assuming SELinux is enabled because of this.
> libselinux-2.2.1 on F20 doesn't seem to have this code.
Bug #835146 (against EL6) seems to confirm this, suggesting a backport of the
patch that removes the /proc/filesystems based check.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1096123
[Bug 1096123] useradd within EL6 container fails: failure while writing
changes to /etc/passwd
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1124065
Bug ID: 1124065
Summary: /usr/bin/gear from geard conflicts with
rubygem-openshift-origin-node
Product: Fedora
Version: 20
Component: geard
Severity: medium
Assignee: lsm5(a)fedoraproject.org
Reporter: tdawson(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)fedoraproject.org
Description of problem:
/usr/bin/gear from geard conflicts with the same file in
rubygem-openshift-origin-node
Version-Release number of selected component (if applicable):
geard-0-0.14.git06df437
rubygem-openshift-origin-node-1.18.0.1-2
How reproducible:
100%
Steps to Reproduce:
1. yum install geard rubygem-openshift-origin-node
2.
3.
Actual results:
...
Running transaction check
Running transaction test
Transaction check error:
file /usr/bin/gear conflicts between attempted installs of
geard-0-0.3.gitb31df16.fc20.x86_64 and
rubygem-openshift-origin-node-1.18.0.1-1.fc20.noarch
Expected results:
Both packages should be installed.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.