golang August 2014

golang@lists.fedoraproject.org

6 participants
316 discussions

[Bug 1113601] New: When kernel is installed as a dependency of autofs, various errors are shown
by Red Hat Bugzilla 28 Oct '14

28 Oct '14

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.

1 8

[Bug 1099206] New: timestamps of libraries and artifacts out of sync
by Red Hat Bugzilla 17 Oct '14

17 Oct '14

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.

1 48

[Bug 1096816] New: useradd within EL6 container fails: failure while writing changes to /etc/passwd
by Red Hat Bugzilla 14 Oct '14

14 Oct '14

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.

1 13

[Bug 1124065] New: /usr/bin/gear from geard conflicts with rubygem-openshift-origin-node
by Red Hat Bugzilla 03 Oct '14

03 Oct '14

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.

1 10

[Bug 1109537] New: gear command line cannot be run with a confined user
by Red Hat Bugzilla 28 Sep '14

28 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1109537 Bug ID: 1109537 Summary: gear command line cannot be run with a confined user Product: Fedora Version: 20 Component: geard Assignee: lsm5(a)redhat.com Reporter: misc(a)zarb.org QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org, lsm5(a)redhat.com Description of problem: $ gear zsh: permission denied: gear $ id -Z staff_u:staff_r:staff_t:s0-s0:c0.c1023 WIth setenforce 0, it work fine. # rpm -q selinux-policy selinux-policy-3.12.1-166.fc20.noarch I am not sure if gear can be run as a simple user, but i would at least expect to be able to see the command line options, since there is no manpage. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1069718] New: Kernel container scalability issue in docker - VFS and mount path consuming too much CPU
by Red Hat Bugzilla 15 Sep '14

15 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1069718 Bug ID: 1069718 Summary: Kernel container scalability issue in docker - VFS and mount path consuming too much CPU Product: Red Hat Enterprise Linux 7 Version: 7.0 Component: systemd Severity: urgent Priority: urgent Assignee: systemd-maint(a)redhat.com Reporter: sct(a)redhat.com QA Contact: qe-baseos-daemons(a)redhat.com CC: agk(a)redhat.com, alexl(a)redhat.com, fs-maint(a)redhat.com, fweimer(a)redhat.com, golang(a)lists.fedoraproject.org, ikent(a)redhat.com, jeder(a)redhat.com, jpoimboe(a)redhat.com, lsm5(a)redhat.com, lvm-team(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, mjenner(a)redhat.com, perfbz(a)redhat.com, rwheeler(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Depends On: 1061359, 1064929 Group: private Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1061359 [Bug 1061359] improve docker devicemapper backend scalability https://bugzilla.redhat.com/show_bug.cgi?id=1064929 [Bug 1064929] Kernel container scalability issue in docker - VFS and mount path consuming too much CPU -- You are receiving this mail because: You are on the CC list for the bug.

1 27

[Bug 1064929] New: Kernel container scalability issue in docker devicemapper backend
by Red Hat Bugzilla 15 Sep '14

15 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1064929 Bug ID: 1064929 Summary: Kernel container scalability issue in docker devicemapper backend Product: Red Hat Enterprise Linux 7 Version: 7.0 Component: kernel Severity: high Assignee: kernel-mgr(a)redhat.com Reporter: sct(a)redhat.com QA Contact: kernel-qe(a)redhat.com CC: agk(a)redhat.com, alexl(a)redhat.com, golang(a)lists.fedoraproject.org, jeder(a)redhat.com, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, skottler(a)redhat.com, vbatts(a)redhat.com Depends On: 1061359 Blocks: 1064012 Group: private Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1061359 [Bug 1061359] improve docker devicemapper backend scalability https://bugzilla.redhat.com/show_bug.cgi?id=1064012 [Bug 1064012] improve docker devicemapper backend scalability -- You are receiving this mail because: You are on the CC list for the bug.

1 22

[Bug 1064012] New: improve docker devicemapper backend scalability
by Red Hat Bugzilla 15 Sep '14

15 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1064012 Bug ID: 1064012 Summary: improve docker devicemapper backend scalability Product: Red Hat Enterprise Linux 7 Version: 7.0 Component: docker Severity: high Assignee: lsm5(a)redhat.com Reporter: jeder(a)redhat.com QA Contact: virt-bugs(a)redhat.com CC: agk(a)redhat.com, alexl(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: 1061359 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1061359 [Bug 1061359] improve docker devicemapper backend scalability -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1061359] New: improve docker devicemapper backend scalability
by Red Hat Bugzilla 15 Sep '14

15 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1061359 Bug ID: 1061359 Summary: improve docker devicemapper backend scalability Product: Fedora Version: rawhide Component: docker-io Severity: high Assignee: lsm5(a)redhat.com Reporter: jeder(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: 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 -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1111233] New: RHEL6: docker run fails on --privileged
by Red Hat Bugzilla 15 Sep '14

15 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1111233 Bug ID: 1111233 Summary: RHEL6: docker run fails on --privileged Product: Fedora Version: rawhide Component: docker-io Assignee: lsm5(a)redhat.com Reporter: vbatts(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)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: running a privileged container should not fail, but it does Version-Release number of selected component (if applicable): docker-io-1.0.0-3.el6.x86_64 How reproducible: consistent Steps to Reproduce: 1. docker run -it --rm --privileged fedora echo HOWDY 2. 3. Actual results: 2014/06/19 09:58:45 Error: Cannot start container 807ea2ed77cdd98dd7dd5600aa363be6ae64c022a03dde70e033d5e7283808ab: stat /dev/.udev/db/bsg:0:0:0:0: no such file or directory Expected results: HOWDY Additional info: This appears to already be resolved in docker/master branch. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

← Newer
1
2
3
4
5
6
7
8
9
...
32
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang August 2014