Description of problem: After I move everything to /usr and then upgrade to the latest NM, I don't seem to be able to add to any new wifi networks. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. move /usr 2. start gnome 3. switch wifi icon to new network 4. there are no messages in log and nothing happens Everything seems to work if I switch between preexisting networks. Perhaps a problem with usermode. I would expect when switching to a new network that I would see a root window letting me enter a new password.
really nothing in /var/log/syslog ?
CC: (none) => mageia
Yes nothing in syslog. I think I know why. What happens when you switch net applet to another access point, a dialog comes up asking for root so that you can enter the AP password. This root dialog is not coming up. So this may be an issue with polkit or usermode. Because NM never gets contacted, nothing goes to syslog.
I found the problem. It's likely because there is an older polkit-gnome Running the polkit-gnome daemon on the command line gives me an assertion ** (polkit-gnome-authentication-agent-1:26149): CRITICAL **: polkit_agent_listener_initiate_authentication: assertion `identities != NULL' failed
Summary: networkmanager doesn't switch between wifi networks after /usr move => networkmanager doesn't switch between wifi networks after gnome 3.5 update
@Joseph What package was the old one? polkit-gnome 0.105 seems to be the newest version available. Not sure about the assertion you encounter, but I certainly have the daemon running here and it seems to run without any issues :s
Seems to be related to this issue... https://bugzilla.redhat.com/show_bug.cgi?id=834494 running policykit directly seems to lock.... [joe@mcdull ~]$ sudo /usr/lib/polkit-1/polkitd --replace & [1] 5807 [joe@mcdull ~]$ pkexec bash
polkit may be a red herring since I got it to work for non-networkmanager things Maybe wpa_supplicant is a problem? I'm getting this e-mail message when try to switch wifi Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory /sbin/ifdown: interface wlan0 is controlled by NetworkManager; skipping. /sbin/ifup: interface wlan0 is controlled by NetworkManager; skipping.
No. There is definitely something odd about polkit. When I change polkit_agent_listener_initiate_authentication so that all of the auth_admin_keep's are changed to yes, everything seems to work although it's not asking for root passwords. I'm wondering if the usr move changed something that polkit-gnome is looking for? Also I'm running zh-TW.
Summary: networkmanager doesn't switch between wifi networks after gnome 3.5 update => networkmanager doesn't switch between wifi networks after update to polkit 0.106
FOUND IT!!!!! - It's a 0.106 issue when the conversion to javascript The problem was that /etc/polkit-1/rules.d/50-default.rules contains only the unix-group:wheel but not that the unix-user tag Since there is no user, polkit just drops the request since the unix-user is NULL. Changing 50-default.rules to return return ["unix-group:wheel", "unix-user:root"]; makes everything work.
I would like to confirm the existence of this bug in cauldron on the way to mga3. I could launch the network manager connection editor but it wouldn't allow me to edit connections due to root password dialog not appearing. I would also like to add that the fix proposed in the previous comment works. After editing 50-default.rules, I am now able to use network manager as expected.
CC: (none) => philippe.l
Keywords: (none) => PATCHTarget Milestone: --- => Mageia 3Source RPM: networkmanager-0.9.5.96-1.mga3 => polkit
CC: (none) => olav, tmb
Blocks: (none) => 7557
I can't seem to reproduce this error. Whenever I try to switch to a new network, the first time I try I have to enter my user password via a Gnome Shell auth dialog popup. Once this is done, I can attempt happily to switch to other networks without further authentication (i.e. it's remembered my auth). I don't know but polkit-gnome-authentication-agent-1 is likely not needed under recent gnome-shell which perhaps has a built in agent? I did all this via the gnome-shell UI. Running nm-connection-editor as my user, and deleting some old wifi networks, I was also prompted for my user password before being allowed to make changes, but this all worked fine. It could be that I'm prompted for my user password rather than the root one as I'm in the wheel group, but I'd imagine the glue that makes this all work would be the same regardless (i.e. the bit that makes the dialog pop up appears to be working). Any progress on your side?
Please refer to the discussion in bug#7873 and bug#2160 and see if your problems with NM go away if you either allow GNOME (if you have it installed) to activate it or you install plasma-network-management under KDE, add it to your panel, and use it to configure your SSID. For NM to handle wireless correctly, it needs to create SSID-specific files of its own by parsing the ifcfg files produced by drakconnect. GNOME's nm-applet does this automatically, since it has no option to *not* use NM, but since NM isn't the default yet for other desktops, it doesn't happen automatically there. You'll need to install NM and let it start, and recreate your wireless interface with drakconnect specifying "Allow NM to control this interface". Please test and post your results, as whether NM works for all the chips involved when it's properly configured will have a significant impact on how it needs to be handled for non-GNOME desktops in MGA3.
(In reply to comment #11) n/a here
CC: (none) => ftg
Keywords: (none) => NEEDINFO
@Joseph : Can you report of comment 11 solve your problem ? Roelof
CC: (none) => r.wobben
Comment 11 was auto-added to all outstanding NM bugs. I then went through them individually. Per comment 12, it doesn't apply here.
Colin, Joseph, what's the status of this bug? Was the patch from comment #8 applied? Thanks!
CC: (none) => stormi
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as OLD.
Status: NEW => RESOLVEDCC: (none) => nicResolution: (none) => OLD
CC: (none) => ankesaini99