Description of problem: After a minimal install from the 19 Alpha TC1 DVD (either i386 or x86_64), the network is down. "systemctl start NetworkManager" fails. "systemctl start network" succeeds but any attempt to use the network gives the error "connect: Network is unreachable". Please reassign to the correct Component if necessary. Version-Release number of selected component (if applicable): 19.12 (from 19 Alpha TC1) How reproducible: always
Well, let's start with systemd. They'll know how to help you debug the boot process so you can assign to the correct component.
What is the output of? # systemctl start NetworkManager.service # systemctl status NetworkManager.service # journalctl -u NetworkManager.service # journalctl -ab _SYSTEMD_UNIT=NetworkManager.service You might want to save the output to a USB stick or similar.
Created attachment 716084 [details] screenshot containing requested output Should also add that I have not tried minimal netinstall yet, so the problem could also exist with that.
After reading https://lists.fedoraproject.org/pipermail/test/2013-March/114462.html , I confirmed that by using enforcing=0, the network comes up.
After bringing up the network, I did a yum update which pulled in selinux-policy and selinux-policy-targeted, version 3.12.1-23.fc19.noarch. (There was no systemd update.) A plain reboot after that has the network running. Reassigning to selinux-policy.
Something else is broken. I just did a text install (which pulls in updates by default, so selinux-policy-3.12.1-23.fc19.noarch is installed. But the network still doesn't come up unless I use "enforcing=0". In the previous install, I did a non-networked TC1 install, then used "enforcing=0" to apply all updates. I don't know why the network is up in one and not the other.
So it also does not work with permissive mode, right?
I'm fairly ignorant about SELinux, so I'd rather let someone else more knowledgeable run these tests. Sorry.
Do you see any AVC's? ausearch -m avc Also is /var/run labeled correctly. ls -lZ /var/run
It appears /var/run was incorrectly labeled as system_u:object_r:var_t:s0. Running "restorecon -v /var/run" relabeled it to system_u:object_r:var_run_t:s0 which is the same as on my F18 host. After a reboot, the F19 guest's network is up.
*** This bug has been marked as a duplicate of bug 919374 ***