Description of problem: I just updated f20 to f21 and I started getting this error message on startup boot messages. Version-Release number of selected component: initial-setup-0.3.23-2.fc21 Additional info: reporter: libreport-2.2.3 cmdline: python -m initial_setup executable: /usr/lib/python2.7/site-packages/initial_setup/__main__.py kernel: 3.16.1-300.fc21.x86_64 runlevel: unknown type: Python uid: 0 Truncated backtrace: socket.py:224:meth:error: [Errno 111] Connection refused Traceback (most recent call last): File "/usr/lib64/python2.7/runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/lib64/python2.7/runpy.py", line 72, in _run_code exec code in run_globals File "/usr/lib/python2.7/site-packages/initial_setup/__main__.py", line 37, in <module> anaconda_log.init() File "/usr/lib64/python2.7/site-packages/pyanaconda/anaconda_log.py", line 252, in init logger = AnacondaLog() File "/usr/lib64/python2.7/site-packages/pyanaconda/anaconda_log.py", line 119, in __init__ self.forwardToSyslog(logr) File "/usr/lib64/python2.7/site-packages/pyanaconda/anaconda_log.py", line 204, in forwardToSyslog logr.name) File "/usr/lib64/python2.7/site-packages/pyanaconda/anaconda_log.py", line 80, in __init__ SysLogHandler.__init__(self, address, facility) File "/usr/lib64/python2.7/logging/handlers.py", line 760, in __init__ self._connect_unixsocket(address) File "/usr/lib64/python2.7/logging/handlers.py", line 788, in _connect_unixsocket self.socket.connect(address) File "/usr/lib64/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args) error: [Errno 111] Connection refused Local variables in innermost frame: self: <socket._socketobject object at 0x7f559eb45fa0> args: ('/dev/log',) name: 'connect'
Created attachment 930497 [details] File: backtrace
Created attachment 930498 [details] File: dso_list
Created attachment 930499 [details] File: environ
Could you please test this with the 'selinux=0' boot option? Seems like an selinux policy issue to me. If that fixes the issue, please attach the /var/log/audit/audit.log file. Thanks!
I was badly in need of wifi working on this updated system but getting ModemManager service failure issue. Later on I saw selinux policy denial for this. I then edited /etc/selinux/config and set machine in permissive mode and WiFi started. so this is a selinux policy issue. I will attach audit.log files. You can see in top lines the selinux policy denial. But I also see abrt is still catching this traceback as per timestamp updated in abrt but since I disabled selinux, above traceback is not getting printed while starting a machine to boot GNOME session.
Created attachment 930797 [details] audit.log.1.gz
Created attachment 930798 [details] audit.log.gz
Looks like an issue with NetworkManager/ModemManager and selinux policy.
What is running as unconfined_service_t? # ps -efZ |grep unconfined_service_t It looks like the system is mislabeled and we see unconfined_service_t which is for unconfined services.
http://ur1.ca/i2dkg Above is fpaste link that will provide output on my system which is currently running in permissive mode.
Ok the system is mislabeled at all after upgrade. You will need to run # touch /.autorelabel # reboot to fix labeling and get the right SELinux domains.
AFAIK we fix labeling on the update?
How was the system upgraded? Are there logs from the upgrade that you can attach to this bug? Relabeling is handled by the selinux-policy package scripts.
(In reply to Miroslav Grepl from comment #12) > AFAIK we fix labeling on the update? I meant additional restorecon after an upgrade.
If upgrading with fedup, there is no full relabel after an upgrade, because again: selinux-policy is supposed to handle that. Just like upgrading the policy package within a release.
I just installed new fedora-release and fedora-repos and did "sudo dnf update" and updated to f21 and reboot and got this issue. I did what asked in comment 11 and my system is now running with selinux enforcing and no issues with wifi connection also.
So we have a labeling issue which I guess is caused by a transaction issue.
As has already been said relabeling is handled by the selinux-policy package scripts so it's a package issue. Parag, you didn't see any error during dnf transaction, right?
Parag, was your F20 working correctly before update? And what was your steps to upgrade to F21 using dnf?
I installed fedora-release and fedora-repos from f21 and then directly ask dnf to update the system. I got some issues like broken deps so carried couple of transaction to have dnf update carrying big update without any more broken deps and this last big transaction then worked fine. Then after every reboot I am seeing that error which also caused my networking not to work. but after implementing solution in comment#11. My system started working fine. Now I don't have case to reproduce this and I am fine if you people want to close this as NOTABUG. Thanks.
I have carried many dnf transactions on this system since I reported this bug so can't help here with any more information.
It could be caused by your troubles with the upgrade. I would close this bug.