Created attachment 326760 [details] emerge --info After I updated networkmanager to 0.9.6.0 as part of global update to gnome 3.4, I can't do anything with NM. Everything is write-protected, both in nm-connection-editor and in gnome-control-center. I can't [re]connect to any wired, wireless or vpn. Just nothing happens. The only messaage I can get is when I try to change config for openvpn: I see a "Insufficient privileges." error. All of these work under root. Can't find any relevant logs. emerge info in attach.
What happens when you run the following command as non-root (assuming you are in a gnome session)? pkcheck --action-id org.freedesktop.NetworkManager.settings.modify.system --process $(pidof gnome-session)
morse@morseworkbook ~ $ pkcheck --action-id org.freedesktop.NetworkManager.settings.modify.system --process 2264 Not authorized.
By the way, modify.own is also forbidden. Can it be somehow relevant that I'm using systemd?
(In reply to comment #3) > By the way, modify.own is also forbidden. > > Can it be somehow relevant that I'm using systemd? Yes. If systemd is not recognizing you as in an active user session, polkit will not authorize you to use networkmanager. Make sure that you have >=sys-auth/pambase-20120417-r1 with USE=systemd, and are logging in from a systemd-compatible login manager, such as gdm-3.4.1-r3 with USE=systemd. Attempting to just do "startx" will break many parts of gnome3, in particular anything related to polkit authorization. Also, check that you are using the latest version of polkit (0.107-r1) with the systemd USE flag set.
[ebuild R ~] sys-auth/pambase-20120417-r1 USE="consolekit cracklib gnome-keyring sha512 systemd -debug -minimal -mktemp -pam_krb5 -pam_ssh -passwdqc (-selinux)" 0 kB [ebuild R ~] gnome-base/gdm-3.4.1-r3 USE="consolekit gnome-shell introspection ipv6 ldap systemd tcpd xinerama xklavier -accessibility -audit -debug -fallback -fprint -plymouth (-selinux) -smartcard -test" 0 kB [ebuild R ] sys-auth/polkit-0.107-r1 USE="gtk introspection nls pam -examples -kde (-selinux) (-systemd)" 0 kB Everything looks OK. As a grand-finale I checked org.freedesktop.NetworkManager.network-control (which is "yes" for both active and inactive). Same result: Not authorized.
I have lots of these in journalctl: Oct 17 13:54:00 morseworkbook dbus[2070]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.0" (uid=0 pid=2069 comm="/usr/lib/systemd/systemd-logind ") interf ace="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.18" (uid=1000 pid=2264 comm="gnome-session ") Can it be that it's systemd trying to recognize me? Then it's dbus rules that needs fixing.
@systemd team, any suggestions?
(In reply to comment #7) > @systemd team, any suggestions? Well, let's start from the basics: what $ loginctl gives you? It should list you with a seat.
SESSION UID USER SEAT c1 1000 morse seat0 1 sessions listed.
(In reply to comment #9) > SESSION UID USER SEAT > c1 1000 morse seat0 > > 1 sessions listed. That looks fine. Is sys-apps/dbus built with USE=systemd as well?
[ebuild R ~] sys-apps/dbus-1.6.8-r1 USE="X systemd -debug -doc (-selinux) -static-libs -test" 0 kB USE="systemd" is global, every package should be built with it
Well, that's where my ideas end. Sorry.
I changed my dbus policy to allow anything. Now there are no rejected messages in the logs. Still not authorized to do a thing. Tried to login to the regular text console. That session was recognized all right: passed "active" checks from itself and "inactive" from others. Something must be wrong with gdm. Can I somehow launch all the gnome stuff without it? At least for testing purposes.
(In reply to comment #13) > I changed my dbus policy to allow anything. Now there are no rejected > messages in the logs. Still not authorized to do a thing. > > Tried to login to the regular text console. That session was recognized all > right: passed "active" checks from itself and "inactive" from others. > > Something must be wrong with gdm. Can I somehow launch all the gnome stuff > without it? At least for testing purposes. Does it make a difference if you emerge pambase and gdm with USE=-consolekit? Are there any processes hanging around from previous gnome logins (e.g. pulseaudio - see bug #435042 comment 17)? Try killing them from the console. As for launching gnome without gdm - it's complicated, and we don't have up-to-date documentation, especially for systemd users :/ See bug #436392
sys-auth/pambase[consolekit] required by (sys-auth/polkit-0.107-r1::gentoo, installed) If I start removing all this stuff, I'll end rebuilding the whole system.
I rebuilded gdm and gnome-session without "systemd" use flag, and now everything works. Surprisingly, loginctl still shows my session with a seat. Even more surprisingly, the file /usr/lib64/systemd/system/gdm.service wasn't removed (although now it's orphaned) and still works: gdm is launched by systemd. I'll check if it's gnome-session's, gdm's or both's flags that made the trick.
It's gdm.
I found the "error", it's in usr/portage/profiles/arch/amd64/package.use.mask file (in my case): # Robert Piasek <dagger@gentoo.org> (26 Apr 2012) # Packages with optional systemd support. Masked in base and unmasked on arches # where sys-apps/systemd is available. # Samuli Suominen <ssuominen@gentoo.org> (07 Sep 2012) # Masked again because this was never allowed before systemd is marked stable. #sys-auth/polkit -systemd polkit was merged without systemd support. Dear devs, please decide whether systemd is masked or merely unstable.
(In reply to comment #18) > I found the "error", it's in > usr/portage/profiles/arch/amd64/package.use.mask file (in my case): > > # Robert Piasek <dagger@gentoo.org> (26 Apr 2012) > # Packages with optional systemd support. Masked in base and unmasked on > arches > # where sys-apps/systemd is available. > # Samuli Suominen <ssuominen@gentoo.org> (07 Sep 2012) > # Masked again because this was never allowed before systemd is marked > stable. > #sys-auth/polkit -systemd > > polkit was merged without systemd support. > > Dear devs, please decide whether systemd is masked or merely unstable. It must be masked for long as it's unstable because otherwise KEYWORDS don't match. So no bug here, only user error with the USE=systemd handling. Marking as dupe of bug 439130. *** This bug has been marked as a duplicate of bug 439130 ***
