golang November 2014

golang@lists.fedoraproject.org

9 participants
498 discussions

[Bug 1165690] New: Please update golang-github-coreos-go-systemd to at least a606a1e936df81b70d85448221c7b1c6d8a74ef1
by Red Hat Bugzilla 21 Apr '15

21 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1165690 Bug ID: 1165690 Summary: Please update golang-github-coreos-go-systemd to at least a606a1e936df81b70d85448221c7b1c6d8a74ef1 Product: Fedora Version: rawhide Component: golang-github-coreos-go-systemd Assignee: lsm5(a)fedoraproject.org Reporter: jchaloup(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: bobbypowers(a)gmail.com, golang(a)lists.fedoraproject.org, lsm5(a)fedoraproject.org Blocks: 1165688 Description of problem: flannel packages imports github.com/coreos/go-systemd/daemon, which is not available right now. Version-Release number of selected component (if applicable): golang-github-coreos-go-systemd-devel-2-1 How reproducible: always Actual results: github.com/coreos/go-systemd/daemon missing Expected results: github.com/coreos/go-systemd/daemon not missing Additional info: If possible, update to the latest commit Update on all branches Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1165688 [Bug 1165688] Review Request: flannel - Flannel is an etcd backed network fabric for containers -- You are receiving this mail because: You are on the CC list for the bug.

1 32

[Bug 1046717] New: Cancel run or pull operation doesn't actually stop the ongoing task
by Red Hat Bugzilla 15 Apr '15

15 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1046717 Bug ID: 1046717 Summary: Cancel run or pull operation doesn't actually stop the ongoing task Product: Fedora Version: 20 Component: docker-io Severity: medium Assignee: lsm5(a)redhat.com Reporter: baptiste.millemathias(a)gmail.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 Description of problem: I've downloaded a docker image using "docker pull bradrydzewski/mongodb:2.4" and when I wanted to run it I did a "docker run bradrydzewski/mongodb" as the image name was named like that, and I saw docker pulling another image (the size was different), so I hit Ctrl+C thinking to going kill the operation. However a ps fax showed me dockerd was still downloading something, certainly image bradrydzewski/mongodb Version-Release number of selected component (if applicable): docker-io-0.7.0-14.fc20.x86_64 How reproducible: 100 % Steps to Reproduce: 1. docker pull bradrydzewski/mongodb:2.4 (let the complete operation happens) 2. docker run bradrydzewski/mongodb, and hit ctrl+c after few seconds Actual results: Dockerd still download image Expected results: docker client should ask Dockerd to cancel the download of the image -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1087704] New: repetition of signal 21 with --sig-proxy and SIGSTOP of docker
by Red Hat Bugzilla 15 Apr '15

15 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1087704 Bug ID: 1087704 Summary: repetition of signal 21 with --sig-proxy and SIGSTOP of docker Product: Fedora Version: 20 Component: docker-io Severity: low Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(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 Description of problem: I noticed weird reaction to SIGSTOP signal. When you start container with --sig-proxy, ignore all signals in container and from OS use kill -SIGSTOP to the `docker run` process, it's put into background. (so far correct behavior) Than when you use kill -SIGCONT, it's resumed (still in background) and it's continuing to send signal 21 to the container (100% CPU utilization). This disappears once you attach the process with fg. Version-Release number of selected component (if applicable): docker-io-0.9.1-1.fc21.x86_64 How reproducible: always Steps to Reproduce: 1. /usr/bin/docker -D run --tty=false --rm -i --name test_eoly localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' 2. ps ax |grep docker 3. kill -SIGSTOP $PID 4. kill -SIGCONT $PID Actual results: [1]+ Pozastavena /usr/bin/docker -D run --tty=false --rm -i --name test_eoly localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' [root@t530 ~]# Received 21, ignoring... Received 21, ignoring... Received 21, ignoring... Received 21, ignoring... Received 21, ignoring... Received 21, ignoring... ... (100% CPU utilization, when you use fg it stops and you can use the container again...) Expected results: [1]+ Pozastavena /usr/bin/docker -D run --tty=false --rm -i --name test_eoly localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' [root@t530 ~]# Received 21, ignoring... Additional info: I'm not definitely sure if this is really required as it's not a common usage. But as there is no way to detach the process apart from kill -SIGSTOP people might use it and get to this problem... -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 1087720] New: signal 27 (SIGPROF) not passed to container using --sig-proxy
by Red Hat Bugzilla 15 Apr '15

15 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1087720 Bug ID: 1087720 Summary: signal 27 (SIGPROF) not passed to container using --sig-proxy Product: Fedora Version: 20 Component: docker-io Assignee: lsm5(a)redhat.com Reporter: ldoktor(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(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 Description of problem: When I send signal 27 to the docker process, which is running with --sig-proxy=true, it's not forwarded. Other signals are... Version-Release number of selected component (if applicable): docker-io-0.9.1-1.fc21.x86_64 How reproducible: always Steps to Reproduce: 1. /usr/bin/docker -D run --tty=false --rm -i --name test_eoly localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap "echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done' 2. ps ax |grep docker 3. kill -27 $PID Actual results: nothing Expected results: Received 27, ignoring... Additional info: When you send any other signal (apart from 19 or 9) it works fine. -- You are receiving this mail because: You are on the CC list for the bug.

1 17

[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 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 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 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
...
50
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang November 2014