Description of problem: Cannot start kde-connect daemon Version-Release number of selected component (if applicable): $ rpm -qa kde-connect\* kde-connect-libs-22.04.1-3.el9.x86_64 kde-connect-22.04.1-3.el9.x86_64 How reproducible: Always Steps to Reproduce: 1. Open KDE Connect applet 2. Try to bind a new device in a local network Actual results: No device is shown Expected results: Available devices shown Additional info: It seems that daemon is failing to start. From 'journalctl -f' logs: gen 07 19:10:41 <myhost> plasmashell[1198]: kdeconnect.interfaces: dbus interface not valid gen 07 19:10:41 <myhost> kdeconnectd[5154]: kdeconnect.core: Certificate from "/home/<myuser>/.config/kdeconnect/certificate.pem" is not valid gen 07 19:10:41 <myhost> kdeconnectd[5154]: kdeconnect.daemon: "KDE Connect" : "Impossibile memorizzare il file del certificato: /home/<myuser>/.config/kdeconnect/certificate.pem" gen 07 19:10:41 <myhost> kernel: kdeconnectd[5154]: segfault at 0 ip 00007f59c5722526 sp 00007ffcb53807b0 error 4 in libkdeconnectcore.so.22.04.1[7f59c5704000+2d000] gen 07 19:10:41 <myhost> kernel: Code: 00 00 00 48 89 44 24 08 31 c0 48 89 e5 48 83 c6 28 48 89 ef e8 cb 5c fe ff 48 8b 04 24 48 63 50 08 48 8b 54 d0 10 49 89 14 24 <8b> 02 83 c0 01 83 f8 01 77 28 48 89 ef e8 28 9c fe ff 48 8b 44 24 It looks like [1],[2],[3]. I believe that I already have RPMs: $ rpm -qa \*qca\* qca-qt5-2.3.4-2.el9.next.x86_64 qca-qt5-ossl-2.3.4-2.el9.next.x86_64 qca-qt5-softstore-2.3.4-2.el9.next.x86_64 qca-qt5-gnupg-2.3.4-2.el9.next.x86_64 [1] https://bugs.kde.org/show_bug.cgi?id=438844 [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1187457 [3] https://bugzilla.opensuse.org/show_bug.cgi?id=1187440
Can you try with a newly created user? I am not sure it's related to the bugs you are reffering to. The outputs are not the same. You can also check `openssl x509 -in "/home/<myuser>/.config/kdeconnect/certificate.pem" -text` and see if the certificate is really valid.
I just tested using a newly created user named 'fedora'. The result and the log are the same as above. Note that: $ openssl x509 -in "/home/$USER/.config/kdeconnect/certificate.pem" -text Could not read certificate from /home/fedora/.config/kdeconnect/certificate.pem Unable to load certificate Because the file is empty: $ ls /home/$USER/.config/kdeconnect/ -l totale 8 -rw-------. 1 fedora fedora 0 8 gen 15.56 certificate.pem -rw-r--r--. 1 fedora fedora 25 8 gen 15.52 config -rw-------. 1 fedora fedora 1704 8 gen 15.52 privateKey.pem
I also tried switching from X11 to Wayland session with no success. Please note that "Impossibile memorizzare il file del certificato" means (from italian): Failed to store certificate file. I also added, to be sure, all qca-qt5* available packages: $ rpm -qa qca-qt5\* qca-qt5-2.3.4-2.el9.next.x86_64 qca-qt5-ossl-2.3.4-2.el9.next.x86_64 qca-qt5-softstore-2.3.4-2.el9.next.x86_64 qca-qt5-gnupg-2.3.4-2.el9.next.x86_64 qca-qt5-pkcs11-2.3.4-2.el9.next.x86_64 qca-qt5-nss-2.3.4-2.el9.next.x86_64 qca-qt5-gcrypt-2.3.4-2.el9.next.x86_64 qca-qt5-logger-2.3.4-2.el9.next.x86_64 qca-qt5-cyrus-sasl-2.3.4-2.el9.next.x86_64
After some further investigation I found [1]. So I tried: $ cd $HOME/.config/kdeconnect/ $ openssl req -new -x509 -sha256 -newkey rsa:2048 -nodes -keyout privateKey.pem -days 3650 -out certificate.pem -subj "/O=KDE/OU=KDE Connect/CN=_e6e29ad4_2b31_4b6d_8f7a_9872dbaa9095_" Now KDE Connect works. This is a workaround. [1] https://github.com/KDE/kdeconnect-kde/blob/master/core/kdeconnectconfig.cpp#L327
I'm looking into this. This is still happening on epel9-next that just had an update.
I am having an issue in CentOS Stream 9. Phone connects but on boot the daemon stops repeatedly until I reconnect the phone. Anyway to prevent this?
I'm still working on a real fix, but the workaround for CentOS Stream 9 is the same as above. cd $HOME/.config/kdeconnect/ openssl req -new -x509 -sha256 -newkey rsa:2048 -nodes -keyout privateKey.pem -days 3650 -out certificate.pem -subj "/O=KDE/OU=KDE Connect/CN=_e6e29ad4_2b31_4b6d_8f7a_9872dbaa9095_" CentOS Stream 9 has the same versions of packages as above, and this isn't failling on Fedora, so I'm puzzled why it's happening.
> > CentOS Stream 9 has the same versions of packages as above, and this isn't > failling on Fedora, so I'm puzzled why it's happening. It could be something related to basic libraries (glib, openssl, whatever...) Is CS plasma using the same init system than Fedora? If I well remember systemd is optional for plasma.
Running kconnectd by hand I get $ rm -rf $HOME/.config/kdeconnect/ $ /usr/libexec/kdeconnectd libEGL warning: failed to get driver name for fd 0 libEGL warning: MESA-LOADER: failed to retrieve device information libEGL warning: failed to get driver name for fd 0 kdeconnect.core: Certificate from "/home/quake/.config/kdeconnect/certificate.pem" is not valid kdeconnect.daemon: "KDE Connect" : "Could not store certificate file: /home/quake/.config/kdeconnect/certificate.pem" $ ls -lh $HOME/.config/kdeconnect/ total 8.0K -rw-------. 1 quake quake 0 Oct 31 15:07 certificate.pem -rw-r--r--. 1 quake quake 24 Oct 31 15:07 config -rw-------. 1 quake quake 1.7K Oct 31 15:07 privateKey.pem I'm pretty sure the libEGL warnings have nothing to do with the problem. If we look at the kdeconnect code we can find that error here https://github.com/KDE/kdeconnect-kde/blob/master/core/kdeconnectconfig.cpp#L321 So it is creating the privateKey, but is unable to write the certificate.pem with the correct permissions. I have tried turning off selinux, so it's not that. I've tweaked the .config file settings as well, that didn't help either. From what I've read, qca-qt5-ossl is the things doing the certificate stuff. I've tried rebuilding qca a couple of different ways. First was with the normal epel9-next packages. I also tried rebuilding Fedora's qt5 on CentOS Stream 9, and then rebuilding qca with that. Neither ways helped. I'm pretty sure that you are right, that it's some library, I'm betting it's openssl. But at this moment, I'm running out of ideas. I've also tried
> > I have tried turning off selinux, so it's not that. > I also suspected this, but it doesn't matter. The most relevant KDE bug I found is [1] (already mentioned). After reading this very interesting article [2], I suggest to modify the workaround as: cd $HOME/.config/kdeconnect/ openssl req -new -x509 -sha256 -newkey rsa:2048 -nodes -keyout privateKey.pem -days 3650 -out certificate.pem -subj "/O=KDE/OU=KDE Connect/CN=$(uuidgen -r)" [1] https://bugs.kde.org/show_bug.cgi?id=438844 [2] https://blog.inoki.cc/2021/02/07/KDEConnect-iOS-dev-dairy-3/
(In reply to Massimiliano from comment #10) > > The most relevant KDE bug I found is [1] (already mentioned). > [1] https://bugs.kde.org/show_bug.cgi?id=438844 It sounds similar, but it is something different. We already have all the packages installed that they have missing. We are also able to create the private key, just not the certificate. I have created a new bug https://bugs.kde.org/show_bug.cgi?id=476422 > > After reading this very interesting article [2], I suggest to modify the > workaround as: > > cd $HOME/.config/kdeconnect/ > openssl req -new -x509 -sha256 -newkey rsa:2048 -nodes -keyout privateKey.pem -days 3650 -out certificate.pem -subj "/O=KDE/OU=KDE Connect/CN=$(uuidgen -r)" > > [2] https://blog.inoki.cc/2021/02/07/KDEConnect-iOS-dev-dairy-3/ Good article. It helped me know more of what is going on, but I still couldn't figure out the real problem or solution. I opened the bug.