Description of problem: I have a test version of the fedora 21 image available at lsm5/fedora21-new (https://registry.hub.docker.com/u/lsm5/fedora21-new/) Version-Release number of selected component (if applicable): 3.2-27 How reproducible: always Steps to Reproduce: Haven't tested this on a bare-metal f21 host but: 1. sudo yum install docker-io 2. sudo docker run -it lsm5/fedora21-new bash 3. yum update (on container shell) Actual results: Tail end of yum update: ------------- Running transaction Updating : kmod-libs-19-1.fc21.x86_64 1/14 Updating : 1:grub2-tools-2.02-0.12.fc21.x86_64 2/14 Updating : 1:grub2-2.02-0.12.fc21.x86_64 3/14 Updating : kmod-19-1.fc21.x86_64 4/14 Updating : filesystem-3.2-28.fc21.x86_64 5/14 Error unpacking rpm package filesystem-3.2-28.fc21.x86_64 error: unpacking of archive failed on file /sys: cpio: chmod Updating : tzdata-2014j-1.fc21.noarch 6/14 error: filesystem-3.2-28.fc21.x86_64: install failed Updating : grep-2.21-1.fc21.x86_64 7/14 install-info: No such file or directory for /usr/share/info/grep.info.gz Cleanup : 1:grub2-2.02-0.11.fc21.x86_64 8/14 Cleanup : tzdata-2014i-1.fc21.noarch 9/14 error: filesystem-3.2-27.fc21.x86_64: erase skipped Cleanup : kmod-18-4.fc21.x86_64 10/14 Cleanup : kmod-libs-18-4.fc21.x86_64 11/14 Cleanup : 1:grub2-tools-2.02-0.11.fc21.x86_64 12/14 Cleanup : grep-2.20-6.fc21.x86_64 13/14 Verifying : grep-2.21-1.fc21.x86_64 1/14 Verifying : tzdata-2014j-1.fc21.noarch 2/14 Verifying : 1:grub2-tools-2.02-0.12.fc21.x86_64 3/14 Verifying : kmod-19-1.fc21.x86_64 4/14 Verifying : kmod-libs-19-1.fc21.x86_64 5/14 Verifying : 1:grub2-2.02-0.12.fc21.x86_64 6/14 Verifying : 1:grub2-tools-2.02-0.11.fc21.x86_64 7/14 Verifying : kmod-18-4.fc21.x86_64 8/14 Verifying : 1:grub2-2.02-0.11.fc21.x86_64 9/14 Verifying : tzdata-2014i-1.fc21.noarch 10/14 Verifying : grep-2.20-6.fc21.x86_64 11/14 filesystem-3.2-27.fc21.x86_64 was supposed to be removed but is not! Verifying : filesystem-3.2-27.fc21.x86_64 12/14 Verifying : filesystem-3.2-28.fc21.x86_64 13/14 Verifying : kmod-libs-18-4.fc21.x86_64 14/14 Updated: grep.x86_64 0:2.21-1.fc21 grub2.x86_64 1:2.02-0.12.fc21 grub2-tools.x86_64 1:2.02-0.12.fc21 kmod.x86_64 0:19-1.fc21 kmod-libs.x86_64 0:19-1.fc21 tzdata.noarch 0:2014j-1.fc21 Failed: filesystem.x86_64 0:3.2-27.fc21 filesystem.x86_64 0:3.2-28.fc21 Complete! -------------
hmm, looks like this might be a docker specific bug. Feel free to close this if f21 elsewhere doesn't see this issue.
It looks like sys in docker image has different permission than the one in filesystem package - and this causes conflict. The permissions on /sys dir was changed to 555 by kernel, and I adjusted the permissions in filesystem-3.2-22 (Dec 4th 2013, bz #1037862). I haven't seen this issue before on "real machine", as you said, it might be docker specific bug - but still worth to investigate it and possibly reassign... Can you please check the permissions on /sys dir in the base docker image? (I'll close this bugzilla in ~1 month if we will not find better place to reassign or to reproduce it with "common" Fedora )
This doesn't seem to occur anymore, even in a docker container. Closing..
This is happening every time I try to build an image from a Dockerfile. To reproduce, just try to build anything from Fedora-Dockerfiles repo [1]. I have tested it by building redis[2], following its readme[3]. [1]: https://github.com/fedora-cloud/Fedora-Dockerfiles [2]: https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/redis [3]: https://github.com/fedora-cloud/Fedora-Dockerfiles/blob/master/redis/README.md
I see this bug too on a virtual machine running fedora-21. On my laptop (f21 upgrade) this bug does not occur. The virtual machine is fully up to date and based on the fedora 21 cloud image for openstack.
As I said in comment #2, permissions in the base image are probably wrong - which causes the failure of the update. Nothing to do on the side of filesystem package - and if you find what actually modifies /sys from 555 to 755, we can reassign it there - but I can't do much with this issue.
My assumption => older kernel => different /sys permissions defaults => new filesystem conflicts with that.
I tried this with the F21 docker image [1] with F21 cloud image [2] and with centos6 cloud image [3]. I see the filesystem error with centos6 but not with F21. In F21 the version of some components are: [root@t21 ~]# rpm -qa kernel-core docker-io kernel-core-3.17.4-301.fc21.x86_64 docker-io-1.5.0-1.fc21.x86_64 In CentOS6 the versions of some components are: [root@t6 ~]# rpm -q kernel docker-io kernel-2.6.32-504.1.3.el6.x86_64 docker-io-1.4.1-3.el6.x86_64 The general workflow was: - Start instance - Install docker - Start docker - Download F21 docker image [1] - docker load -i Fedora-Docker-Base-20141203-21.x86_64.tar.gz - docker run -it --rm Fedora-Docker-Base-20141203-21.x86_64 bash - # yum update -y On CentOS6 it fails with: Updating : filesystem-3.2-28.fc21.x86_64 5/136 Error unpacking rpm package filesystem-3.2-28.fc21.x86_64 error: unpacking of archive failed on file /sys: cpio: chmod Updating : tzdata-2015a-1.fc21.noarch 6/136 error: filesystem-3.2-28.fc21.x86_64: install failed - Dusty [1] -http://download.fedoraproject.org/pub/fedora/linux/releases/21/Docker/x86_64/Fedora-Docker-Base-20141203-21.x86_64.tar.gz [2] - http://download.fedoraproject.org/pub/fedora/linux/releases/21/Cloud/Images/x86_64/Fedora-Cloud-Base-20141203-21.x86_64.qcow2 [3] - http://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud-20141129_01.qcow2.xz
Yes, because underlying kernel has /sys with different permissions. For me, not a bug in filesystem package itself, as in F21, /sys should have 555 . It has to be handled in docker itself somehow.
Ondrej are you saying that if I run a CentOS 6 box and run a fedora 21 base image, yum update will fail because /sys is mounted as 755?
I don't think so, Daniel. I'm seeing what appears to be the same problem when doing a "yum update" after an initial standard install of FedoraMATE Workstation on an arm system (raspberry pi 2). Here I get error: unpacking of archive failed on file /bin: cpio: rename Verifying : filesystem-3.2-28.fc21.armv7hl filesystem-3.2-27.fc21.armv7hl was supposed to be removed but is not! Same problem with attempting just "yum reinstall filesystem.armv7hl" Stock permissions of /sys and /bin are both 555. Changing them to 755 doesn't help. (Yes, I changed them back to 555 after the test.). Filesystem is ext4 on an sd card...
(In reply to Daniel Walsh from comment #10) > Ondrej are you saying that if I run a CentOS 6 box and run a fedora 21 base > image, yum update will fail because /sys is mounted as 755? This is probably more question for Dusty. I can imagine different /sys permissions can cause these troubles, but personally, I haven't tried to further debug this.
I looked into see if we could check the underlying /sys and get its permissions from the base image, but it looks like /sys in out base image is set to 555. Not 755 on rhel6.
It looks like on CentOS 6 it's different: [root@cent6 ~]# rpm -ql --verbose filesystem-2.4.30-3.el6.x86_64 | grep " /sys" drwxr-xr-x 2 root root 0 Sep 23 2011 /sys This seems to carry through into the container: [root@cent6 ~]# docker run -it --rm Fedora-Docker-Base-20141203-21.x86_64 ls -ld /sys drwxr-xr-x 13 root root 0 Mar 11 14:50 /sys It is also mounted readonly so when the filesystem package for F21 gets installed the strace output shows: chmod("/sys", 0555) = -1 EROFS (Read-only file system) And the transaction fails showing the output from comment #8.
Right which is not something we can fix. So I guess we have to close this as wontfix.
H(In reply to Daniel Walsh from comment #13) > I looked into see if we could check the underlying /sys and get its > permissions from the base image, but it looks like /sys in out base image is > set to 555. Not 755 on rhel6. I'm seeing something different (at least on the latest RHEL6.6 cloud image): [root@rh66 ~]# rpm -ql --verbose filesystem-2.4.30-3.el6.x86_64 | grep " /sys" drwxr-xr-x 2 root root 0 Jun 28 2011 /sys So this will fail the same way as in CentOS 6. I know Docker isn't officially supported on RHEL 6 and I'm not saying we should fix it but I think this is an interesting situation where the host is influencing what's inside the container and causing failures. As long as the distros all "agree" on what the perms of the toplevel mounts are (the ones that are mounted read-only) then this isn't a problem. But if they start to differ then this could be a problem when trying to run containers of different distros or even different versions of the same distro if they decided to make a change (which is what happened in this case, moving from 755 to 555). Can anyone think of a way that we could modify Docker to handle this? Just for clarity here is the behavior on F21, RHEL66, and CentOS: [root@fed21 ~]# mkdir /tmp/sys755 [root@fed21 ~]# mkdir /tmp/sys555 [root@fed21 ~]# chmod 755 /tmp/sys755/ [root@fed21 ~]# chmod 555 /tmp/sys555/ [root@fed21 ~]# mount -t sysfs sysfs /tmp/sys755/ [root@fed21 ~]# mount -t sysfs sysfs /tmp/sys555/ [root@fed21 ~]# ls -ld /tmp/sys755/ dr-xr-xr-x. 13 root root 0 Mar 11 20:33 /tmp/sys755/ [root@fed21 ~]# ls -ld /tmp/sys555/ dr-xr-xr-x. 13 root root 0 Mar 11 20:33 /tmp/sys555/ [root@cent6 ~]# mkdir /tmp/sys755 [root@cent6 ~]# mkdir /tmp/sys555 [root@cent6 ~]# chmod 755 /tmp/sys755/ [root@cent6 ~]# chmod 555 /tmp/sys555/ [root@cent6 ~]# mount -t sysfs sysfs /tmp/sys755/ [root@cent6 ~]# mount -t sysfs sysfs /tmp/sys555/ [root@cent6 ~]# ls -ld /tmp/sys755/ drwxr-xr-x. 13 root root 0 Mar 11 18:50 /tmp/sys755/ [root@cent6 ~]# ls -ld /tmp/sys555/ drwxr-xr-x. 13 root root 0 Mar 11 18:50 /tmp/sys555/ [root@rh66 ~]# mkdir /tmp/sys755 [root@rh66 ~]# mkdir /tmp/sys555 [root@rh66 ~]# chmod 755 /tmp/sys755/ [root@rh66 ~]# chmod 555 /tmp/sys555/ [root@rh66 ~]# mount -t sysfs sysfs /tmp/sys755/ [root@rh66 ~]# mount -t sysfs sysfs /tmp/sys555/ [root@rh66 ~]# ls -ld /tmp/sys755/ drwxr-xr-x. 13 root root 0 Mar 15 13:26 /tmp/sys755/ [root@rh66 ~]# ls -ld /tmp/sys555/ drwxr-xr-x. 13 root root 0 Mar 15 13:26 /tmp/sys555/
Digging in a little more.. Here is an example where I am running Fedora 21 as a host and then doing a "downgrade" of the filesystem package within a centos:centos6 container image. I had to do a downgrade because there were no newer versions of the filesystem package to upgrade to. The downgrade is enough to prove a point. [root@fed21 ~]# docker run -it --rm centos:centos6 bash [root@60b32f524e0d /]# [root@60b32f524e0d /]# yum install -y wget ... [root@60b32f524e0d /]# wget http://vault.centos.org/6.0/os/x86_64/Packages/filesystem-2.4.30-2.1.el6.x86_64.rpm ... [root@60b32f524e0d /]# yum downgrade filesystem-2.4.30-2.1.el6.x86_64.rpm Loaded plugins: fastestmirror Setting up Downgrade Process Examining filesystem-2.4.30-2.1.el6.x86_64.rpm: filesystem-2.4.30-2.1.el6.x86_64 Resolving Dependencies --> Running transaction check ---> Package filesystem.x86_64 0:2.4.30-2.1.el6 will be a downgrade ---> Package filesystem.x86_64 0:2.4.30-3.el6 will be erased --> Finished Dependency Resolution Dependencies Resolved ===================================================================================================== Package Arch Version Repository Size ===================================================================================================== Downgrading: filesystem x86_64 2.4.30-2.1.el6 /filesystem-2.4.30-2.1.el6.x86_64 0.0 Transaction Summary ===================================================================================================== Downgrade 1 Package(s) Is this ok [y/N]: y Downloading Packages: Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Installing : filesystem-2.4.30-2.1.el6.x86_64 1/2 Error unpacking rpm package filesystem-2.4.30-2.1.el6.x86_64 error: unpacking of archive failed on file /proc: cpio: chown Cleanup : filesystem-2.4.30-3.el6.x86_64 2/2 Verifying : filesystem-2.4.30-3.el6.x86_64 1/2 Verifying : filesystem-2.4.30-2.1.el6.x86_64 2/2 Removed: filesystem.x86_64 0:2.4.30-3.el6 Failed: filesystem.x86_64 0:2.4.30-2.1.el6 Complete! [root@60b32f524e0d /]# echo $? 1 [root@60b32f524e0d /]# rpm -q filesystem package filesystem is not installed Basically if we want to be able to run older software and handle "updates" to the filesystem package then we are going to hit this. Dusty
Would it be better to make the filesystem package handle this more gracefully. IE Don't report the error if it attempts to change the permissions on a directory that is read only.
(In reply to Daniel Walsh from comment #18) > Would it be better to make the filesystem package handle this more > gracefully. IE Don't report the error if it attempts to change the > permissions on a directory that is read only. That may be the most practical solution. The one thing I don't like about it is that (I think) it would require other distros to do something similar. I know we aren't responsible for them, but it would be nice if there was a solution that could be implemented at the "Docker" level. Another thing to think about is that we would need to release an updated version of the filesystem package for those older OSes. Is that a big deal? I don't know.
%verify(not mode) /sys may be an option. Adding Jan Zeleny. Honzo, is there some other alternative what can be used here? Is %verify(not mode) safe way to resolve this issue caused by underlying kernel?
No idea ... redirecting to our rpm developers ...
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
No.
You could try marking /sys %ghost. But that means you need to create the directory in a %post script if it doesn't exist.
*** Bug 1188400 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.