golang January 2015

golang@lists.fedoraproject.org

10 participants
512 discussions

[Bug 1166312] New: etcd unit should support command line options
by Red Hat Bugzilla 13 Apr '15

13 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1166312 Bug ID: 1166312 Summary: etcd unit should support command line options Product: Fedora Version: 21 Component: etcd Assignee: lacypret(a)gmail.com Reporter: lars(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: eparis(a)redhat.com, golang(a)lists.fedoraproject.org, jchaloup(a)redhat.com, lacypret(a)gmail.com, lemenkov(a)gmail.com The "etcd.service" unit distributed with Fedora 21 (atomic) does not contain any facilities for passing arguments to etcd. That is, it looks like this: [Service] Type=simple StandardOutput=null WorkingDirectory=/var/lib/etcd User=etcd ExecStart=/usr/bin/etcd This means that if a deployer wants to pass arguments to etcd at boot (such as a discovery URL), the only option is to introduce a new unit file in /etc/systemd/system. This works, but it seems like a heavy hammer. It seems as if a better choice would be to introduce an EnvironmentFile directive like we do for so many other units. Something like: [Service] Type=simple StandardOutput=null WorkingDirectory=/var/lib/etcd User=etcd EnvironmentFile=/etc/sysconfig/etcd ExecStart=/usr/bin/etcd $OPTIONS -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1166950] New: Unable to run "mysql" docker image on Fedora atomic due to selinux
by Red Hat Bugzilla 13 Apr '15

13 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1166950 Bug ID: 1166950 Summary: Unable to run "mysql" docker image on Fedora atomic due to selinux Product: Fedora Version: 21 Component: docker-io Assignee: lsm5(a)fedoraproject.org Reporter: lars(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)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 The "mysql" Docker image creates a volume on /var/lib/mysql inside the container. At runtime, the entrypoint script attempts to chown this directory to the mysql user, which leads to the following error: # docker run -e MYSQL_ROOT_PASSWORD=secret mysql FATAL ERROR: Could not chown directory /var/lib/mysql And the following AVC: type=AVC msg=audit(1416629737.562:201): avc: denied { setattr } for pid=22615 comm="mysql_install_d" name="d27cb6010a47942d7dc4826ebfe138ea62888fc9a5dedcaf14ebb3a1f45781c2" dev="dm-0" ino=6329484 scontext=system_u:system_r:svirt_lxc_net_t:s0:c190,c586 tcontext=system_u:object_r:docker_var_lib_t:s0 tclass=dir permissive=0 Which translates to: module docker 1.0; require { type svirt_lxc_net_t; type docker_var_lib_t; class dir setattr; } #============= svirt_lxc_net_t ============== allow svirt_lxc_net_t docker_var_lib_t:dir setattr; A simple reproducer is to create a Dockerfile with the following: FROM fedora VOLUME /var/lib/myvolume RUN chown nobody /var/lib/myvolume And attempt to "docker build .": Sending build context to Docker daemon 2.56 kB Sending build context to Docker daemon Step 0 : FROM fedora ---> 7d3f07f8de5f Step 1 : VOLUME /var/lib/myvolume ---> Running in 5f2e6a9a51e0 ---> ea49c8d042b2 Removing intermediate container 5f2e6a9a51e0 Step 2 : RUN chown nobody /var/lib/myvolume ---> Running in d1083d0ccc68 chown: changing ownership of '/var/lib/myvolume': Permission denied 2014/11/22 04:27:19 The command [/bin/sh -c chown nobody /var/lib/myvolume] returned a non-zero code: 1 -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1186669] New: Failed to start Docker Application Container Engine.
by Red Hat Bugzilla 31 Mar '15

31 Mar '15

https://bugzilla.redhat.com/show_bug.cgi?id=1186669 Bug ID: 1186669 Summary: Failed to start Docker Application Container Engine. Product: Fedora Version: 21 Component: docker-io Severity: high Assignee: lsm5(a)redhat.com Reporter: bugzilla.redhat.com(a)trancecode.co.uk 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 Created attachment 985059 --> https://bugzilla.redhat.com/attachment.cgi?id=985059&action=edit grep -i 'docker' /var/log/audit/audit.log | tail Description of problem: I yum-updated to F21 latest and now docker service fails to start on boot. This update included reboot to new kernel 3.18 [root@vm117 ~]# uname -a Linux vm117 3.18.3-201.fc21.x86_64 #1 SMP Mon Jan 19 15:59:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Maybe this could be related to the other new warning that I see in joutnalctl -b SELinux is preventing sm-notify from write access on the file nlm_end_grace. For complete SELinux messages. run sealert and Dependency failed for Network Manager Wait Online. Which I assume is new with 3.18 since web search found this: https://www.kernel.org/pub/linux/utils/nfs-utils/1.3.1/1.3.1-Changelog I don't see anything notable in /var/log/messages Will attach a grep of /var/log/audit/audit.log Version-Release number of selected component (if applicable): [root@vm117 ~]# yum info docker-io.x86_64 Loaded plugins: langpacks Installed Packages Name : docker-io Arch : x86_64 Version : 1.4.1 Release : 5.fc21 Size : 19 M Repo : installed >From repo : updates How reproducible: 100% Service Fails to start on every boot. Steps to Reproduce: 1. Reboot Fedora 2. systemctl status docker.service 3. Actual results: Expected results: Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1165615] New: Docker needs at least device-mapper-libs-1.02.90-1 to start correcty as a systemd service
by Red Hat Bugzilla 22 Mar '15

22 Mar '15

https://bugzilla.redhat.com/show_bug.cgi?id=1165615 Bug ID: 1165615 Summary: Docker needs at least device-mapper-libs-1.02.90-1 to start correcty as a systemd service Product: Fedora Version: 21 Component: docker-io Severity: low Priority: low Assignee: lsm5(a)fedoraproject.org Reporter: jchaloup(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, miminar(a)redhat.com, s(a)shk.io, thrcka(a)redhat.com, vbatts(a)redhat.com Description of problem: After installing docker on clean installation of F21, systemctl start docker fails. Version-Release number of selected component (if applicable): docker-io-1.3.1-2.fc21.x86_64 device-mapper-libs-1.02.88-2.fc21.x86_64 How reproducible: Always Steps to Reproduce: 1. install F21 2. yum install docker 3. systemctl start docker Actual results: docker does not start Expected results: docker starts Additional info: I don't update the system (no yum update), because I don't want to increase system's size in virtual machine. Thus device-mapper-libs does not get updated to the latest build. # systemctl start docker Job for docker.service failed. See 'systemctl status docker.service' and 'journalctl -xn' for details. # status docker.service -l ● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled) Active: failed (Result: exit-code) since Wed 2014-11-19 06:04:42 EST; 1min 16s ago Docs: http://docs.docker.com Process: 2473 ExecStart=/usr/bin/docker -d -H fd:// $OPTIONS $DOCKER_STORAGE_OPTIONS (code=exited, status=127) Main PID: 2473 (code=exited, status=127) Nov 19 06:04:42 localhost.localdomain docker[2473]: 2014/11/19 06:04:42 docker daemon: 1.3.1 4e9bbfa/1.3.1; xecdriver: native; graphdriver: Nov 19 06:04:42 localhost.localdomain docker[2473]: [54d8ccdb] +job serveapi(fd://) Nov 19 06:04:42 localhost.localdomain docker[2473]: [info] Listening for HTTP on fd () Nov 19 06:04:42 localhost.localdomain docker[2473]: /usr/bin/docker: relocation error: /usr/bin/docker: symbol dm_task_get_info_with_deferred_remove, version Base not defined in file libdevmapper.so.1.02 with link time reference Nov 19 06:04:42 localhost.localdomain systemd[1]: docker.service: main process exited, code=exited, status=127/n/a Nov 19 06:04:42 localhost.localdomain systemd[1]: Failed to start Docker Application Container Engine. Nov 19 06:04:42 localhost.localdomain systemd[1]: Unit docker.service entered failed state. Among others: /usr/bin/docker: relocation error: /usr/bin/docker: symbol dm_task_get_info_with_deferred_remove, version Base not defined in file libdevmapper.so.1.02 with link time reference Update of device-mapper-libs to device-mapper-libs-1.02.90-1 solves the problem. Proposing to add device-mapper-libs >= 1.02.90-1 to spec file. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1173950] New: docker-io can't be installed on rhel 6.5 due to requirement device-mapper-libs >= 1.02.90-1
by Red Hat Bugzilla 20 Mar '15

20 Mar '15

https://bugzilla.redhat.com/show_bug.cgi?id=1173950 Bug ID: 1173950 Summary: docker-io can't be installed on rhel 6.5 due to requirement device-mapper-libs >= 1.02.90-1 Product: Fedora EPEL Version: el6 Component: docker-io Severity: high Assignee: lsm5(a)redhat.com Reporter: abonas(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 Description of problem: docker-io.x86_64 0:1.3.2-2.el6 can't be installed on rhel 6.5 due to requirement device-mapper-libs >= 1.02.90-1: How reproducible: Steps to Reproduce: (on rhel 6.5) 1. sudo yum install docker-io 2. device-mapper-libs can't be upgraded to the requested version. 3. Actual results: error: Running transaction check ---> Package docker-io.x86_64 0:1.3.2-2.el6 will be installed --> Processing Dependency: device-mapper-libs >= 1.02.90-1 for package: docker-io-1.3.2-2.el6.x86_64 --> Finished Dependency Resolution Error: Package: docker-io-1.3.2-2.el6.x86_64 (epel) Requires: device-mapper-libs >= 1.02.90-1 Installed: device-mapper-libs-1.02.79-8.el6.x86_64 (@production-rhel-x86_64-workstation-6.5) device-mapper-libs = 1.02.79-8.el6 Available: device-mapper-libs-1.02.53-8.el6.i686 (production-rhel-x86_64-workstation-6.5) device-mapper-libs = 1.02.53-8.el6 Available: device-mapper-libs-1.02.53-8.el6_0.2.i686 (production-rhel-x86_64-workstation-6.5) device-mapper-libs = 1.02.53-8.el6_0.2 Available: device-mapper-libs-1.02.53-8.el6_0.3.i686 (production-rhel-x86_64-workstation-6.5) device-mapper-libs = 1.02.53-8.el6_0.3 Available: device-mapper-libs-1.02.53-8.el6_0.4.i686 (production-rhel-x86_64-workstation-6.5) device-mapper-libs = 1.02.53-8.el6_0.4 Available: device-mapper-libs-1.02.62-3.el6.i686 (production-rhel-x86_64-workstation-6.5) device-mapper-libs = 1.02.62-3.el6 Available: device-mapper-libs-1.02.66-6.el6.i686 (production-rhel-x86_64-workstation-6.5) device-mapper-libs = 1.02.66-6.el6 Available: device-mapper-libs-1.02.74-10.el6.i686 (production-rhel-x86_64-workstation-6.5) device-mapper-libs = 1.02.74-10.el6 Available: device-mapper-libs-1.02.74-10.el6_3.2.i686 (production-rhel-x86_64-workstation-6.5) device-mapper-libs = 1.02.74-10.el6_3.2 Available: device-mapper-libs-1.02.74-10.el6_3.3.i686 (production-rhel-x86_64-workstation-6.5) device-mapper-libs = 1.02.74-10.el6_3.3 Available: device-mapper-libs-1.02.77-9.el6.i686 (production-rhel-x86_64-workstation-6.5) device-mapper-libs = 1.02.77-9.el6 Available: device-mapper-libs-1.02.77-9.el6_4.2.i686 (production-rhel-x86_64-workstation-6.5) device-mapper-libs = 1.02.77-9.el6_4.2 Available: device-mapper-libs-1.02.77-9.el6_4.3.i686 (production-rhel-x86_64-workstation-6.5) device-mapper-libs = 1.02.77-9.el6_4.3 Expected results: Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[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 09 Mar '15

09 Mar '15

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.

1 13

[Bug 1166918] New: Docker exec causes Error response from daemon: Unsupported: Exec is not supported by the lxc driver
by Red Hat Bugzilla 09 Mar '15

09 Mar '15

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.

1 3

[Bug 1182596] New: AVC denials when running docker build
by Red Hat Bugzilla 09 Mar '15

09 Mar '15

https://bugzilla.redhat.com/show_bug.cgi?id=1182596 Bug ID: 1182596 Summary: AVC denials when running docker build Product: Fedora Version: 21 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: pkamenickova(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 Description of problem: Sometimes when running docker build, these AVC denials appear: type=AVC msg=audit(1421329727.232:1403): avc: denied { name_connect } for pid=14266 comm="yum" dest=21 scontext=system_u:system_r:docker_t:s0 tcontext=system_u:object_r:ftp_port_t:s0 tclass=tcp_socket permissive=1 type=AVC msg=audit(1421329730.463:1404): avc: denied { name_connect } for pid=14266 comm="yum" dest=55226 scontext=system_u:system_r:docker_t:s0 tcontext=system_u:object_r:ephemeral_port_t:s0 tclass=tcp_socket permissive=1 type=AVC msg=audit(1421329735.658:1405): avc: denied { name_connect } for pid=14327 comm="urlgrabber-ext-" dest=63179 scontext=system_u:system_r:docker_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=1 Note: Because we are not sure what is correct behaviour of this, I have opened it as docker-io issue, not selinux. Version-Release number of selected component (if applicable): selinux-policy-3.13.1-103.fc21.noarch docker-io-1.4.1-4.fc21.x86_64 How reproducible: Force yum to use some ftp repository, use RUN yum install command in Dockerfile Example: RUN yum install --enablerepo=fedoraftp -y zsh Run docker build Steps to Reproduce: 1. yum install --enablerepo=updates-testing -y docker-io 2. service docker start 3. fedoraftp.repo: [fedoraftp] name=fedoraftp baseurl=ftp://ftp.linux.cz/pub/linux/fedora/linux/releases/20/Everything/x86_64/os/ gpgcheck=0 enabled=1 4. Dockerfile: FROM fedora:20 ADD fedoraftp.repo /etc/yum.repos.d/fedoraftp.repo RUN yum install --disablerepo='*' --enablerepo=fedoraftp -y zsh 5. docker build -t example . Actual results: Expected results: No AVC denial Additional info: Output of sesearch on Fedora21: sesearch --allow -s docker_t -t ftp_port_t Found 6 semantic av rules: allow docker_t port_type : tcp_socket name_bind ; allow docker_t port_type : udp_socket { recv_msg send_msg name_bind } ; allow nsswitch_domain port_type : tcp_socket { recv_msg send_msg } ; allow nsswitch_domain port_type : udp_socket { recv_msg send_msg } ; allow docker_t port_type : tcp_socket { recv_msg send_msg name_connect } ; allow nsswitch_domain reserved_port_type : tcp_socket name_connect ; I've tried to reproduce this issue on Fedora 20 (selinux-policy-3.12.1-196.fc20.noarch) and RHEL 7 (selinux-policy-3.12.1-153.el7.noarch) - it seems these versions of selinux already have the rules for this kind of thing (maybe ??). Fedora20 sesearch: sesearch --allow -s docker_t -t ftp_port_t Found 10 semantic av rules: allow corenet_unconfined_type port_type : tcp_socket { recv_msg send_msg name_bind name_connect } ; allow corenet_unconfined_type port_type : udp_socket { recv_msg send_msg name_bind } ; allow corenet_unconfined_type port_type : rawip_socket name_bind ; allow corenet_unconfined_type port_type : dccp_socket { recv_msg send_msg name_bind name_connect } ; allow docker_t port_type : tcp_socket name_bind ; allow docker_t port_type : udp_socket { recv_msg send_msg name_bind } ; allow nsswitch_domain port_type : tcp_socket { recv_msg send_msg } ; allow nsswitch_domain port_type : udp_socket { recv_msg send_msg } ; allow nsswitch_domain reserved_port_type : tcp_socket name_connect ; allow docker_t port_type : tcp_socket { recv_msg send_msg name_connect } ; -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1169334] New: docker run fails with " The database file is locked: database is locked"
by Red Hat Bugzilla 06 Mar '15

06 Mar '15

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.

1 12

[Bug 1152862] New: autofs shouldn't have kernel as a dependency
by Red Hat Bugzilla 05 Mar '15

05 Mar '15

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/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. --- 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.

1 9

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang January 2015