Description of problem: systemd requires container=docker set in env and /run, /tmp to be mountpoints start successfully. In my opinion, we should add ENV container=docker VOLUME ['/run', '/tmp'] to the base image Dockerfile. Command docker run --it --rm -v /sys/fs/cgroup:/sys/fs/cgroup:ro fedora:rawhide /usr/sbin/init would then be all an user would need to "boot" systemd in a container. I've already made some changes in KS file - remove fstab and machine-id, mask mount units... which make the boot sequence smooth. More changes to boot sequence will probably come later (f.e. switch from graphical.target to multi-user target) I'd also like to suggest new Rawhide build to be pushed to registry. This one works for me quite well: http://koji.fedoraproject.org/koji/taskinfo?taskID=8883309
ack, will build and send a new image over to hub
Is this complete?
This pull request wasn't merged, https://github.com/docker-library/official-images/pull/497. I'll be sending updated images without the systemd fixes though once I check with dgilmore.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Lokesh lets get the patches into Fedora for docker-1.6 and then most of this is taken care of via docker itself. Fixed in docker-1.6
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Adam, could you take a look at this one? I've been out of the 'base images' loop for a while.
We are working this out separately. Do not change the base image for this. We are introducing oci-systemd and oci-register-machine packages which will make this possible without modification of the base image.
oci-register-machine has made its way into rawhide. Next up oci-systemd-hook
https://github.com/projectatomic/oci-systemd-hook
Fixed in current release.
Dan, what is the minimal execution environment for systemd? The ENV container=docker that the comment 0 asks for does not seem to be present in current fedora:rawhide, for example: # docker run -ti --rm fedora:rawhide bash -c 'set | grep container' BASH_EXECUTION_STRING='set | grep container' Also the /run and /tmp VOLUMEs do not seem to be defined: # docker run -ti --rm fedora:rawhide mount | egrep '/run|/tmp' /dev/mapper/fedora_cloud--qe--14-root on /run/secrets type xfs (rw,relatime,seclabel,attr2,inode64,noquota) The net effect is that # docker run -it --rm -v /sys/fs/cgroup:/sys/fs/cgroup:ro fedora:rawhide /usr/sbin/init hangs with no output produced. Adding -e container=docker to the command line shows # docker run -it --rm -e container=docker -v /sys/fs/cgroup:/sys/fs/cgroup:ro fedora:rawhide /usr/sbin/init Failed to mount tmpfs at /run: Operation not permitted [!!!!!!] Failed to mount API filesystems, freezing. Freezing execution. Only another --tmpfs /run or -v /run makes systemd actually start, and adding --tmpfs /tmp makes the error tmp.mount: Mount process exited, code=exited status=32 [FAILED] Failed to mount Temporary Directory. See 'systemctl status tmp.mount' for details. tmp.mount: Unit entered failed state. go away. From this point of view, the current fedora:rawhide does not seem to have made running systemd easier. This is with docker.io/fedora rawhide d93e998fad14 3 months ago 250.7 MB -- if there is some newer image somewhere, having a way to test it (name/tag) would be nice.
The docker library folks weren't receptive to CentOS (or anyone else) defining volumes for /tmp and /run. They felt (at the time, dunno if it's changed) that this should be for users to do, and didn't belong in the base containers.
Jan were you testing with oci-sytemd-hook and oci-register-machine installed?
(In reply to Jim Perrin from comment #13) > The docker library folks weren't receptive to CentOS (or anyone else) > defining volumes for /tmp and /run. They felt (at the time, dunno if it's > changed) that this should be for users to do, and didn't belong in the base > containers. The content of the images really should be up to the image authors. On the other hand, bug 1283891 and bug 1331781 show that having the VOLUMEs defined can cause issues as well.
(In reply to Daniel Walsh from comment #14) > Jan were you testing with oci-sytemd-hook and oci-register-machine installed? This is on Fedora (23) where they are not available.
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.
With docker-1.12.6-6.gitae7d637.fc25.x86_64 and fedora:rawhide, the issue is still present: $ docker run -ti --rm registry.fedoraproject.org/fedora:rawhide /usr/sbin/init Mount failed for selinuxfs on /sys/fs/selinux: No such file or directory Failed to set up the root directory for shared mount propagation: Operation not permitted OTOH, with -e container=docker running the container does not fail. Do we have any hope of adding that ENV container=docker which still does not seem to be present?
RHEL images seem to define the container environment variable: $ docker run -ti --rm registry.access.redhat.com/rhel7 bash -c 'set | grep container' BASH_EXECUTION_STRING='set | grep container' container=oci Compare: $ docker run -ti --rm registry.fedoraproject.org/fedora:rawhide bash -c 'set | grep container' BASH_EXECUTION_STRING='set | grep container' DISTTAG=f27container
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.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days