[Bug 1046717] New: Cancel run or pull operation doesn't actually stop the ongoing task
by Red Hat Bugzilla
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.
8 years, 11 months
[Bug 1087704] New: repetition of signal 21 with --sig-proxy and SIGSTOP of docker
by Red Hat Bugzilla
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.
8 years, 11 months
[Bug 1087720] New: signal 27 (SIGPROF) not passed to container using --sig-proxy
by Red Hat Bugzilla
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.
8 years, 11 months
[Bug 1166312] New: etcd unit should support command line options
by Red Hat Bugzilla
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.
8 years, 11 months
[Bug 1166950] New: Unable to run "mysql" docker image on Fedora atomic due to selinux
by Red Hat Bugzilla
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.
8 years, 11 months
[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
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.
9 years
[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
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.
9 years
[Bug 1166918] New: Docker exec causes Error response from daemon: Unsupported: Exec is not supported by the lxc driver
by Red Hat Bugzilla
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.
9 years
[Bug 1152862] New: autofs shouldn't have kernel as a dependency
by Red Hat Bugzilla
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/rep...:
[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.
9 years