Created attachment 1100975 [details] boot.log Description of problem: My system boots, but stops at: Failed to start GNOME Display Manager. See "systemctl status gdm.service" for details. Starting Terminate Plymouth Boot Screen... Version-Release number of selected component (if applicable): selinux-policy-targeted-3.13.1-128.21.fc22.noarch libselinux-devel-2.3-10.fc22.x86_64 libselinux-python-2.3-10.fc22.x86_64 rpm-plugin-selinux-4.12.0.1-14.fc22.x86_64 rpm-plugin-selinux-4.12.0.1-12.fc22.x86_64 libselinux-utils-2.3-10.fc22.x86_64 selinux-policy-3.13.1-128.21.fc22.noarch libselinux-2.3-10.fc22.x86_64 libselinux-2.3-10.fc22.i686 docker-selinux-1.8.2-7.gitcb216be.fc22.x86_64 How reproducible: every time Steps to Reproduce: 1. upgrade packages 2. reboot Actual results "Starting Terminate Plymouth Boot Screen..." (and all previous messages) remains on my screen and the login screen never appears. Expected results: gnome login screen displayed Additional info: appending selinux=0 to the kernel boot line gets around this every time. I rebooted with selinux reenabled and the filesystems was relabled, but this didn't help. I also did a reinstall of the selinux policies but am still in the same boat.
boot in permissive mode enforcine=0 and then collect the avcs ausearch -m avc
Created attachment 1101674 [details] avc denials
Have you been playing with containers?
Yep.
Did you volume mount in /run with a :Z? This would cause /run to be mislabeled. This is a bad idea, if you want to share /run into a container, you need to run --privileged. restorecon -R -vF /run Should fix the labels.
I personally have not volume-munted in /run. The only thing I ever -v is my pwd (while in my docker github repo) when running the tests. I run the docker test suites a lot, but I don't see anything with Z and run. # grep -r Z integration-cli/* | grep "\-v" comes back empty. The only thing I see after a few more greps is TestRunTmpfsMounts has some interesting mounts of /run, but nothing with :Z.
There was a bug in an older version of docker which was always doing a relabel, which could have caused the problem. I think it was in docker-engine, but I don't think Fedora released it.
I've kept Fedora versions of docker on my workstation since I installed it a few months ago -- currently Client/Server Version: 1.8.2-fc22. I can always try the relabel and see if I can recreate it. I'll wait to hear a "yes" from you guys though, in case you want any other debug info.
No that should be fine. You should fix the labels.
Created attachment 1103693 [details] ausearch outputs after restorecon
Created attachment 1103694 [details] ls -laZ of /run
Hm, so, the relabel didn't get me around the boot issue. The labels look okay after the restorecon (although I didn't check them before, and I also am not an selinux expert). I attached the output of ls -laZ /run, and also the denials again after an enforcing=1 and an enforcing=0 boot. I also triggered a relabel at boot (selinux=0 then selinux=1), which didn't change anything as far as I can tell. I can't quite piece together how the svirt_sandbox_file_t type comes into play here. They are all tclass=lnk_file. Is this device-mapper related?
ls -lZ /var/run lrwxrwxrwx. 1 root root system_u:object_r:var_run_t:s0 6 Oct 21 2014 /var/run -> ../run
This is mine: > ls -lZ /var/run lrwxrwxrwx. 1 root root system_u:object_r:svirt_sandbox_file_t:s0:c513,c1004 6 May 21 2015 /var/run -> ../run
Which is wrong. Fix that with the restorecon command restorecon -F /var/run