Bug 1004621 - plasma-nm doesn't attempt to connect to any listed networks on Fedora KDE live
Summary: plasma-nm doesn't attempt to connect to any listed networks on Fedora KDE live
Alias: None
Product: Fedora
Classification: Fedora
Component: kde-plasma-nm
Version: 20
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jan Grulich
QA Contact: Fedora Extras Quality Assurance
Whiteboard: https://fedoraproject.org/wiki/Common...
: 1019870 1026081 1031444 (view as bug list)
Depends On:
Blocks: F20FinalBlocker F20Blocker-kde
TreeView+ depends on / blocked
Reported: 2013-09-05 04:35 UTC by Jordan Clarke
Modified: 2013-12-10 05:10 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1045937 (view as bug list)
Last Closed: 2013-12-10 05:10:09 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1034414 0 unspecified CLOSED KDE live images with sddm > 0.2.0-0.14.20130914git50ca5b20 often boot to a blank screen (SDDM fails to start) 2021-02-22 00:41:40 UTC

Internal Links: 1034414

Description Jordan Clarke 2013-09-05 04:35:59 UTC
Description of problem:
KNetworkManager doesn't attempt to connect to any listed wireless networks when they are selected and their passwords entered.

Version-Release number of selected component (if applicable):

How reproducible:
Always occurs.

Steps to Reproduce:
1. Click on KNetworkManager in the System Tray.
2. Click a wireless network name, enter a password (if applicable) in the text box that appears, and click the connect button.

Actual results:
The text box and connect button collapse as if the network name had been clicked again, and no attempt to connect to the network is made.

Expected results:
KNetworkManager connects to the selected network, and a notification appears in the System Tray informing the user that a network connection was successfully established.

Additional info:
This issue hasn't yet been tested with an ethernet connection, although it seems likely it would occur with one.
This issue was discovered on Fedora Live KDE 20 Alpha TC3.

Comment 1 Rex Dieter 2013-09-05 05:03:55 UTC
triaging to kde-plasma-nm component

Comment 2 Jan Grulich 2013-09-05 05:27:28 UTC
What kind of network are you trying to connect to? Is it a wireless network with WEP/WPA security? Isn't it an ad-hoc connection?

Comment 3 Jan Grulich 2013-09-05 07:44:44 UTC
Can you please try to install kde-plasma-networkmanagement (the old network applet for KDE) and add it to your systray and check whether it works with this one? I would like to be sure it's our problem or some problem in NetworkManager itself.

Comment 4 Jordan Clarke 2013-09-05 12:51:05 UTC
Thanks for helping Jan!
I attempted connecting to two wireless networks - my router protected with a WPA password, and my phone without protection.  However, I've since tried using an ethernet cable with my router, which automatically connects without issue.  I installed and tried using kde-plasma-networkmanagement, which was a very helpful suggestion, as it revealed the issue to be a permissions problem.  After selecting my wireless network and typing in the password, an error dialogue displayed:

Error adding connection: Insufficient privileges.

This issue occurred in the Live session, not an installed system, which may yield different results.  If desired, I can take the time to test an installation (albeit probably not until the weekend) to see if the issue occurs again with each of a regular user and an administrator.  :)

Comment 5 Rex Dieter 2013-09-05 14:25:12 UTC
Ah, may be related to bug #1004323 , please make sure you have (at least):


and reboot/relogin, and see if problems persist.

Comment 6 Rex Dieter 2013-09-05 14:26:17 UTC
Ah, re-reading the last comment, methinks the live session you tested may have had an older/broken sddm, but since installing, you updated sddm.  (perusing /var/log/yum.log should be able to confirm this).

Does that sound about right?

Comment 7 Jordan Clarke 2013-09-05 15:05:54 UTC
Thanks for your assistance Rex!
The sddm package in F20 KDE Alpha TC3 matches the version you listed, and no updates for it were available.  However, as you suggested, I logged out, which happened to automatically log me in again, and resolved the issue!
Now to submit a bug report about the mysterious automatic login when trying to logout, shutdown or restart...
Thanks again Rex and Jan!  :)

Comment 8 Jordan Clarke 2013-09-09 02:05:37 UTC
Unfortunately I'm the harbinger of bad news.  Today I tested Fedora Live KDE 20 Alpha TC5, and I discovered that the issue is only resolved as described in my last comment if an ethernet connection is first established before attempting to log out.  Also, it appears that, for the first try only, clicking on shutdown or restart triggers the log out process instead (but works normally thereafter).  Tonight I'll try installing TC5 to see if an installed system behaves differently...

Comment 9 Lukáš Tinkl 2013-09-09 11:05:41 UTC
The shutdown vs. logout messup will be fixed in 4.11.1, FYI

Comment 10 Jordan Clarke 2013-09-18 11:07:05 UTC
My apologies for not updating this bug appropriately - I didn't install TC5 last week as I intended.  However, I did install Fedora Live KDE 20 Alpha RC3 last night, along with the updates from updates-testing (and any other repos enabled by default), and found no networking issues.  However, after applying tonight's updates (which mostly consisted of KDE 4.11.1), the applet asks me for the WPA password, as it apparently doesn't store it between reboots.  After I type it in, KWallet asks me for it's password, which I also enter.  The nm applet then simply displays 'Connecting', but never connects.  It also never successfully connects to my phone hotspot, which isn't password protected.  Does anyone know which update may have caused this issue?
Also, afaict, the update to KDE 4.11.1 hasn't resolved the shutown vs. logout issue - since installing RC3 I've had to cold shutdown my laptop every time as no dialogues display when I try to shutdown/logout/restart, and since updating to KDE 4.11.1 the issue returned after a single successful shutdown.

Comment 11 Rex Dieter 2013-11-03 14:15:55 UTC
*** Bug 1026081 has been marked as a duplicate of this bug. ***

Comment 12 Mike Ruckman 2013-11-04 21:24:15 UTC
I've confirmed this happens with F20 Beta RC2.

When running the live image (dd to USB):
1 - Attempt to connect to wireless (WPA2 Personal)
1.a - Nothing happens
2 - Attempt to log out
2.a - Automagically logged back in
3 - Attempt to connect to wireless
3.a - Connection works.

Comment 13 Adam Williamson 2013-11-05 18:33:12 UTC
Proposing this as at least a Beta freeze exception, it seems like a fairly major issue.

Comment 14 Mike Ruckman 2013-11-06 18:00:34 UTC
Discussed in 2013-11-06 Blocker Review Meeting [1]. Voted as a AcceptedFreezeException. Not working wireless connection is crucial enough to be fixed as soon as possible. This bug affects only livecd. Post-install seems to work properly.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-06/

Comment 15 Rex Dieter 2013-11-06 18:03:38 UTC
Rumor has it this sddm update helps:
(confirmed by 2 people so far)

Comment 16 Fedora Update System 2013-11-06 18:44:55 UTC
kde-settings-20-4.fc20, sddm-0.2.0-0.19.20130914git50ca5b20.fc20, heisenbug-kde-theme-19.90.5-1.fc20 has been submitted as an update for Fedora 20.

Comment 17 Jan Grulich 2013-11-07 16:02:38 UTC
*** Bug 1019870 has been marked as a duplicate of this bug. ***

Comment 18 Fedora Update System 2013-11-07 19:07:39 UTC
Package kde-settings-20-4.fc20, sddm-0.2.0-0.20.20130914git50ca5b20.fc20, heisenbug-kde-theme-19.90.5-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kde-settings-20-4.fc20 sddm-0.2.0-0.20.20130914git50ca5b20.fc20 heisenbug-kde-theme-19.90.5-1.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 19 Fedora Update System 2013-11-08 19:29:19 UTC
kde-settings-20-7.fc20, heisenbug-kde-theme-19.90.5-1.fc20, sddm-0.2.0-0.16.20130914git50ca5b20.fc20 has been submitted as an update for Fedora 20.

Comment 20 Adam Williamson 2013-11-18 01:37:14 UTC
*** Bug 1031444 has been marked as a duplicate of this bug. ***

Comment 21 Ian Malone 2013-11-23 20:07:44 UTC
Current TC2 still shows this bug, I've also just respun the Jam-KDE spin to check what the lastest packages showing up are. The following packages are installed:


Appearing to correspond to https://admin.fedoraproject.org/updates/FEDORA-2013-20946/heisenbug-kde-theme-19.90.5-1.fc20,sddm-0.2.0-0.16.20130914git50ca5b20.fc20,kde-settings-20-7.fc20
On login to the live system I cannot connect to a network through the applet or create a connection in edit connections. On trying to restart (desktop|leave|restart) I simply get logged out of the desktop (and auto-logged back in) at which point kwallet shows up and wireless connections work.

Oddly, the build with sddm-0.2.0-0.20..[etc] refd. at comment 18 seems to have been obsoleted by the current build. I'm going to try and compose a test using that package.

Comment 22 Ian Malone 2013-11-24 00:17:54 UTC
Re-spun (necessary because the problem only occurs on first boot, so can't install package to running system to test):

$ rpm -q kde-settings sddm heisenberg-kde-theme
package heisenberg-kde-theme is not installed

Problem is fixed with this package set:
1. Connection by applet works okay in first login to live system (doesn't acknowledge 'enter' after password, needs 'connect' clicked, but probably a separate usability issue.
2. Kwallet now appears once password entered (in first login).
3. Restart option works at first login (rather than just causing session to logout or crash or whatever it was actually doing previously).

Looks like sddm-0.2.0-0.20 might have been pulled due to Adam Williamson's feeback on https://admin.fedoraproject.org/updates/FEDORA-2013-19106/kde-settings-20-4.fc20,sddm-0.2.0-0.20.20130914git50ca5b20.fc20,heisenbug-kde-theme-19.90.5-1.fc20 there's a reference to irc discussion, but I can't see what the outcome was.

Comment 23 Adam Williamson 2013-11-24 01:07:28 UTC
I never really heard back after that, but I thought the KDE guys were going to look into it.

Comment 24 Adam Williamson 2013-11-25 16:45:46 UTC
Proposing as a Final blocker.

Comment 25 Fedora Update System 2013-11-25 17:40:36 UTC
sddm-0.2.0-0.21.20131125git7a008602.fc20 has been submitted as an update for Fedora 20.

Comment 26 Adam Williamson 2013-11-25 19:26:57 UTC
For the record, the reason we haven't pushed an sddm that fixes this bug stable yet is that recent sddm builds seem to cause an even more severe issue: live images based on them often boot to a blank screen. That's https://bugzilla.redhat.com/show_bug.cgi?id=1034414 . Until we fix that, we can't really close this.

Comment 27 Fedora Update System 2013-11-26 18:00:00 UTC
Package sddm-0.2.0-0.22.20131125git7a008602.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sddm-0.2.0-0.22.20131125git7a008602.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 28 Rex Dieter 2013-11-26 20:24:00 UTC
boo,  starting to think it isn't DM-related, but a genuine kde-plasma-nm bug.

testing this today with kdm, tried clicking on some access points in kde-plasma-nm systray applet, and could not get any action or connection (clicking "Connect" doesn't seem to do anything).   I had to use the connection editor to get a usable wireless connection.

Comment 29 Rex Dieter 2013-11-26 20:30:03 UTC
Oh silly silly gremlins.

On a whim, logged out, switched kdm->lightdm

then plasma-nm connects fine.

Then, logged out, switched lightdm->kdm

plasma-nm connects fine (still).

I don't know what to make of all this.

Comment 30 Rex Dieter 2013-11-26 20:36:45 UTC
and... rebooting (with kdm enabled), things still work.  maybe gremlins do appear if you're flipping between DM's sometimes, but otherwise, nothing to see here until I have more evidence.

Comment 31 Adam Williamson 2013-11-26 20:57:25 UTC
I can test the live image I built on a laptop in a sec, and see how it behaves in a 'clean' live config. I can't test an install though, really.

Comment 32 Adam Williamson 2013-11-27 17:20:27 UTC
re c#31: works fine in a KDM-based live image, for me.

Comment 33 Adam Williamson 2013-11-27 17:28:36 UTC
Discussed at 2013-11-27 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-27/f20-blocker-review-3.2013-11-27-17.01.log.txt . Accepted as a blocker per criterion "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use." - https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_panel_functionality . KDE is a release-blocking desktop.

Comment 34 Mike Ruckman 2013-12-04 19:10:04 UTC
Discussed in 2013-12-04 Blocker Review Meeting [1]. This bug is likely fixed with the recent switch from SDDM to KDM (from Final TC3 to TC4) - and requires more testing.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-04/

Comment 35 Ian Malone 2013-12-04 22:40:01 UTC
Fedora-Live-Jam-KDE-x86_64-20-TC4.iso tested on bare metal, two machines. Connect to wireless at first login on Live KDE system now works. (Previously had to log out before it would work.)
T5500 intel core 2, 945g chipset, GMA 950, iwl3945 wifi.
Athlon II x4, nforce 430, GeForce GT 640, atheros 9k wifi

Comment 36 satellitgo 2013-12-04 23:40:12 UTC
fixed in booted KDE-live TC4 x86_64 DVD. logs in to WEP AP from bottom bar after asking for password.
i7 (system 76) netbook with internal wireless

Comment 37 Adam Williamson 2013-12-05 07:43:09 UTC
Thanks folks, setting VERIFIED.

Comment 38 Adam Williamson 2013-12-10 05:10:09 UTC
The change to KDM is now 'in production', so let's close this.

Note You need to log in before you can comment on or make changes to this bug.