Siduction Forum

> Es ist jetzt kein Problem das Passwort nochmal einzugeben, mich interessiert halt warum das vorher ging und jetzt nicht mehr.

Is there still anyone dying to know what went wrong and how to fix it?

PS.: No one? Anyways: In post #8 hendrikL wrote:

> edit /etc/pam.d/login
> And add this at the bottom:
>
> auth optional pam_gnome_keyring.so
> session optional pam_gnome_keyring.so auto_start

And boy, was he close. The file to edit is actually /etc/pam.d/sddm from Debian package
sddm_0.21.0+git20260801.f62b7ba-3_amd64.deb. The vanilla /etc/pam.d/sddm is almost correct
except for line 31, where the following line must be added:

--- a/etc/pam.d/sddm      2026-08-23 15:05:53.000000000 +0200
+++ b/etc/pam.d/sddm      2026-09-04 22:06:54.131577353 +0200
@@ -30,6 +30,7 @@ session optional        pam_keyinit.so
session required        pam_limits.so
@include common-session
+session optional        pam_gnome_keyring.so auto_start

@include common-password
The sddm helper binary responsible for starting the PAM module (and
in turn the gnome-keyring-daemon) can only get a grip on the login
password after the common-auth section succeeds and it's only purpose
is to decrypt the gnome keyring masterkey before the login password
is wiped and overwritten. The sddm daemon must keep the gnome daemon
alive once the masterkey is transfered to the daemon, which in turn forks
and execs the session gnome daemon after the common_session script.
Creating a new process of the gnome daemon before or after this tiny
window results in an empty password, which fails to decrypt the masterkey.
BTW: Your keyring should look like

$ ls -la ~/.local/share/keyrings
insgesamt 20
-rw-------  1 wt wt  601  4. Sep 16:59 login.keyring
-rw-------  1 wt wt  207  4. Sep 16:54 user.keystore
And upon login you can check an open keyring with
 
$ chromium --password-store=gnome-libsecret

Quote from: hsp on 2026/09/01, 13:25:48

Quote from: edlin on 2026/08/31, 16:22:15

Code Select Expand

cp /etc/conky/conky.conf ~/.conkyrcSolange diese Datei nicht existiert, wird die aus /etc/conf verwendet.

Falsch, das ist veraltet.

Richtig ist.

Code Select Expand

~/.config/conky/conky.conf
...

Wie ich gerade eben feststellte: "Jein"

Ich hatte - nach der Antwort von Edlin - die conky.conf nach /home kopiert und in '.conkyrc' umbenannt ... was auch mit conky funktionierte.

Nach Deinem Post habe ich meine .conkyrc nach ...
~/.config/conky/conky.conf verschoben ... was auch funktionierte. (ich musste das tun, weil ich ein bashscript eingebunden habe und das im gleichen Ordner haben wollte).

Richtig ist, dass
~/.config/conky/conky.conf von den neueren Versionen verwendet wird, aber auch der alte Speicherort noch beachtet wird.

Man sollte sich aber trotzdem auf die neue Variante einschiessen ...

+1

Danke für den Hinweis. Da ist bei conky immer noch viel Bewegung drin. Aber bei einer (noch) funktionierenden Lösung schaut man halt nicht laufend nach den Veränderungen, sondern erst, wenns nicht mehr läuft.
Betrifft ja auch, wie ich Dank @unklarer erfahren musste, own_window_transparent. Da muss man auch auf Alphakanal in own_window_colour umstellen.

edlin 

Problem: After upgrading to kernel 7.1.9 and through 7.2.2 phone was not reachable:
Solution below:

KDE Connect is now working correctly on kernel 7.2.2. ✅
My final result:

OnePlus 13: 08d76a1981a644199b60068898c92814
on 192.168.1.19 via LAN (reachable)
1 device found

And the permanent firewalld configuration is:

home zone
1716/tcp
1716/udp

Final diagnosis
The kernel upgrade itself wasn't breaking KDE Connect. The problem was that after the upgrade, my firewalld home zone no longer allowed KDE Connect's port 1716.
The decisive test was:

Phone → 192.168.1.16:1716 TCP SYN
with no SYN-ACK.


After adding:

firewall-cmd --permanent --zone=home --add-port=1716/tcp
firewall-cmd --permanent --zone=home --add-port=1716/udp
the phone immediately became:

via LAN (reachable)

Quote from: edlin on 2026/08/31, 16:22:15

Code Select Expand

cp /etc/conky/conky.conf ~/.conkyrcSolange diese Datei nicht existiert, wird die aus /etc/conf verwendet.

Falsch, das ist veraltet.

Richtig ist.
~/.config/conky/conky.conf
...

Recht herzlichen Dank ... hast mir mal wieder sehr gehilft

Danke für den Hinweis. Das mit der Transparenz wäre wohl zukünftig nicht nur mir auf die Füße gefallen; also gleich Alphakanal verwenden.

edlin

Ich bin jetzt wieder zu Hause.
Mit der neuen conky-Version gibt es ein paar Änderungen:
apt policy conky-all
conky-all:
  Installiert:          1.24.2+dfsg-1
  Installationskandidat: 1.24.2+dfsg-1
  Versionstabelle:
 *** 1.24.2+dfsg-1 500
        500 https://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
Der Aufruf dieser Version im Terminal bringt jetzt:
[2026-09-01 09:04:30.042] [info ] [src/conky.cc:2038] 'TESTwayland' modified, reloading
[2026-09-01 09:04:31.050] [warn ] [src/lua/setting.cc:218] 'own_window_transparent' is deprecated and will be removed in a future release: Use own_window_colour with alpha instead (e.g. '#00000000').
[2026-09-01 09:04:31.053] [info ] [src/output/x11.cc:695] window type - utility
[2026-09-01 09:04:31.053] [info ] [src/output/x11.cc:814] drawing to created window 0x400002
[2026-09-01 09:04:31.058] [info ] [src/lua/x11-settings.cc:67] drawing to double buffer
[2026-09-01 09:04:31.059] [warn ] [src/lua/setting.cc:218] 'own_window_argb_value' is deprecated and will be removed in a future release: Use own_window_colour with alpha instead (e.g. '#80000000').
[2026-09-01 09:04:31.059] [warn ] [src/lua/setting.cc:74] setting 'own_window_argb_visual' has been removed: ARGB is now always enabled when available. Control opacity with `own_window_colour` (e.g. '#8000').

und in deutsch:
[01.09.2026 09:04:30.042] [Info] [src/conky.cc:2038] ,,TESTwayland" geändert, wird neu geladen
[01.09.2026 09:04:31.050] [warn ] [src/lua/setting.cc:218] ,,own_window_transparent" ist veraltet und wird in einer zukünftigen Version entfernt: Verwenden Sie stattdessen ,,own_window_colour" mit Alpha-Wert (z. B. ,,#00000000").
[01.09.2026 09:04:31.053] [info ] [src/output/x11.cc:695] Fenstertyp – Dienstprogramm
[01.09.2026 09:04:31.053] [info ] [src/output/x11.cc:814] Zeichnen in das erstellte Fenster 0x400002
[01.09.2026 09:04:31.058] [info ] [src/lua/x11-settings.cc:67] Zeichnen in den Doppelpuffer
[01.09.2026 09:04:31.059] [Warnung ] [src/lua/setting.cc:218] ,,own_window_argb_value" ist veraltet und wird in einer zukünftigen Version entfernt: Verwenden Sie stattdessen ,,own_window_colour" mit Alpha-Wert (z. B. ,,#80000000").
[01.09.2026 09:04:31.059] [Warnung] [src/lua/setting.cc:74] Die Einstellung ,,own_window_argb_visual" wurde entfernt: ARGB ist nun immer aktiviert, sofern verfügbar. Steuern Sie die Deckkraft mit `own_window_colour` (z. B. ,#8000').


Yes they are installed.

@hendrikL:
Es ist jetzt kein Problem das Passwort nochmal einzugeben, mich interessiert halt warum das vorher ging und jetzt nicht mehr.