Fedora Update hat mir 6h Lebenszeit gekostet - Mal wieder

[MGFirewater]

Fedora 44 KDE: SDDM/Breeze nach Update defekt​

– zweiter Benutzer wird beim Login nicht mehr korrekt ausgewählt!

Ich hatte auf einem Fedora-44-KDE-System ein ziemlich merkwürdiges Loginproblem, das sich nach längerer Fehlersuche letztlich auf den SDDM/Breeze-Greeter bzw. dessen Benutzerverwaltung eingrenzen ließ.

Ausgangssituation​

System:
Fedora 44 KDE Plasma
Wayland
SDDM mit Breeze-Theme
zwei normale lokale Benutzerkonten
ein Benutzer mit Zeitbegrenzung über Timekpr-nExT
Intel HD 620 + NVIDIA 930MX
Am 17.08. funktionierte der Login beider Benutzer noch normal.
Am 22.08. wurde über Discover ein großes reguläres Fedora-Update installiert. Laut DNF-History wurden dabei 726 Pakete verändert.
Unter anderem:
KDE Frameworks 6.28 → 6.29
KWin 6.7.4-1 → 6.7.4-2
Mesa 26.1.6 → 26.1.7
Kernel 7.1.7 → 7.1.9
zahlreiche KDE Gear Pakete → 26.08.0
plasma-workspace, plasma-desktop und sddm-breeze selbst wurden bei dieser Transaktion dagegen offenbar nicht aktualisiert.

Das eigentliche Problem​

Nach diesem Update funktionierte der grafische Login für den zweiten Benutzer nicht mehr.
Der erste Benutzer konnte weiterhin über SDDM starten.
Im Journal erschien beim SDDM-Breeze-Greeter immer wieder:
qrc:/qt/qml/org/kde/breeze/components/UserList.qml:32:
TypeError: Cannot read property 'userName' of null
Teilweise stürzte der Greeter sogar komplett ab:
sddm-helper ... --start /usr/bin/sddm-greeter-qt6 ...
crashed (exit code 1)

Das Interessanteste zeigte sich aber erst bei einer gezielten Auswertung der PAM-/SDDM-Logs.
Obwohl im Greeter der zweite Benutzer ausgewählt wurde, gingen sämtliche Authentifizierungsversuche an den ersten Benutzer:
pam_unix(sddm:auth): authentication failure; ... user=<erster Benutzer>
Im gesamten untersuchten Zeitraum gab es keinen entsprechenden grafischen SDDM-Authentifizierungsversuch für den zweiten Benutzer.
Das sieht also danach aus, dass der Breeze-Greeter den ausgewählten Benutzer gar nicht korrekt an SDDM übergeben hat.

Vereinfacht:
Breeze UserList
↓
ausgewähltes Benutzerobjekt teilweise null
↓
UserList.qml kann userName nicht lesen
↓
SDDM bekommt weiterhin/fälschlich den vorherigen Benutzer
↓
PAM authentifiziert den falschen Account
Was ausgeschlossen werden konnte
Der Benutzer selbst war vollkommen in Ordnung:
UID > 1000 und im normalen SDDM-Bereich
/etc/passwd korrekt
normale Shell
Home-Verzeichnis korrekt
AccountsService erkannte den Benutzer:
/org/freedesktop/Accounts/User1001
SystemAccount=false
Anmeldung per Terminal funktionierte
PAM konnte Sitzungen für den Benutzer öffnen
Passwortänderung änderte nichts

Auch Timekpr war nicht die Ursache. Es wurde während der Fehlersuche komplett entfernt und das Problem bestand trotzdem weiter.
Ein Zurücksetzen von:
~/.config
~/.local
~/.cache
des betroffenen Benutzers brachte ebenfalls keine Änderung.
Paketquellen überprüft
Discover/PackageKit wurde ebenfalls überprüft.
Aktiv waren nur reguläre Quellen:
Fedora
Fedora Updates
RPM Fusion Free/Nonfree
RPM Fusion Updates
RPM Fusion NVIDIA
Fedora OpenH264
Timekpr COPR

Wichtig:
Fedora updates-testing: AUS
RPM Fusion testing: AUS
Auch Flatpak und Firmwarequellen waren normal.
Das Update kam also aus den regulären Fedora-44-Updates, nicht aus Testing oder einem KDE-COPR.

Reparatur
Während der Fehlersuche wurden unter anderem SDDM und PAM neu installiert, ohne Erfolg.
Erst später wurde der Plasma-/KWin-Bereich neu installiert:
dnf reinstall plasma-workspace \
plasma-workspace-libs \
plasma-workspace-common \
kwin
Anschließend wurde noch:
restorecon -RFv /home/<betroffener Benutzer>
ausgeführt und neu gestartet.
Danach funktionierte der grafische Login wieder normal.
Weil UserList.qml aus plasma-workspace stammt, passt die erfolgreiche Neuinstallation sehr gut zu dem beobachteten Fehler. Allerdings kann ich nicht zu 100 % beweisen, ob allein die Neuinstallation oder die Kombination mit restorecon den endgültigen Ausschlag gegeben hat.

Meine derzeitige Einschätzung​

Ich halte einen Regressions- oder Inkonsistenzfehler im SDDM/Breeze/KDE-QML-Unterbau nach dem heutigen Update sehr wahrscheinlich.
Bemerkenswert ist, dass die eigentliche UserList.qml offenbar nicht in genau diesem Update ersetzt wurde. Geändert wurde aber praktisch der komplette KDE-Framework-Unterbau von 6.28 auf 6.29 sowie KWin und Mesa.
Daher könnte UserList.qml lediglich die Stelle gewesen sein, an der sichtbar wurde, dass ihr Benutzerobjekt plötzlich null war.

Der entscheidende Befund ist für mich:
Benutzer 2 wird im Greeter ausgewählt
↓
UserList.qml meldet userName von null
↓
SDDM/PAM authentifiziert trotzdem Benutzer 1
↓
für Benutzer 2 existiert überhaupt kein SDDM-PAM-Versuch

Das ist deutlich etwas anderes als ein falsches Passwort oder ein kaputtes Benutzerkonto.
Falls jemand mit Fedora 44 + Plasma 6.7.4 + Frameworks 6.29 etwas Vergleichbares gesehen hat, insbesondere mit mehreren Benutzerkonten, würde mich interessieren, ob sich das reproduzieren lässt.

 

[Alexander2]

Also zumindest mit Fedora Kionite, was auch KDE ist, aber der Atomic Zweig, da hatte ich jetzt keine Probleme.
Aber gut zu wissen, das ich hier mal nachschlagen kann, wenn es dazu kommen sollte :-)

Edit:
Ich hab noch 6.28 hier.

Ich hoffe mal das der schneller weg, eben zurück auf das System, das noch da ist vor dem Update bringt auch schnellere abhilfe und die Patchen das dann noch, wenn es denn auch bei mir dazu kommt.

 

[TomTDooley]

Vom Prinzip kann man das vermeiden, wenn man sich z.B. mit "TimeShift" ein Backup erstellt hat.

 

[MGFirewater]

Und dann macht das Update danach den Fehler erneut? Fedora sollte im Release Channel einfach bisschen vorsichtiger sein.

Kubuntu ist da einfach ausgereifter nur ist die Performance ist spürbar schlechter

 

[TomTDooley]

@MGFirewater

Nun, dass kann man nicht pauschal sagen. Aber auch in dem Fall muss man keine 6 Stunden mit der Suche verbringen, weil Du den Fehler schon eingegrenzt hast.

Jenachdem ob Du über Terminal oder GUI die Updates machst, könnte man sich so an das "fehlerhafte" Update herantasten.

 

[tomgit]

Fedora sollte im Release Channel einfach bisschen vorsichtiger sein.

Fedora Linux contains software distributed under a free and open-source license and aims to be on the leading edge of such technologies. Fedora has a reputation for focusing on innovation, integrating new technologies early on and working closely with upstream Linux communities

Von Distrowatch: https://distrowatch.com/table.php?distribution=fedora

Wenn man nen möglichst bugfreies Erlebnis haben möchte, sollte man ggf. nicht auf Fedora setzen?

Kubuntu ist da einfach ausgereifter nur ist die Performance ist spürbar schlechter

(K)Ubuntu hat auch ne ganz andere Philosophie dahinter als es bei Fedora der Fall ist

 

[SpartanerTom]

Eventuell gibt es auch zunehmend mehr ungetestete Randprobleme seit SDDM als default durch Plasma Login Manager ersetzt wurde (wenn ich mich richtig erinnere kommt SDDM nur noch bei Bestandsystemen zum Einsatz). Sollte natürlich nicht sein, aber könnte es mir durchaus vorstellen.

 

[Alexander2]

Bei mir wird auch der Plasma-login genutzt. habe ich erst einige Zeit nach der Installation gemerkt.

 

[Habicht]

Naja, da ja der erste Benutzer funktioniert, kann die Ursache auch eine andere sein - war der zweite Benutzer eventuell als Standardbenutzer eingestellt?

Nebenbei, bei mir ist das aktuelle Update ohne Probleme durchgelaufen, ich hab aber keinen zweiten Benutzer aktiviert, kann somit das Problem nicht nachstellen.
Ich kann mir aber durchaus vorstellen, dass das Problem etwas mit der Rechtevergabe/Gruppenzugehörigkeit des zweiten Nutzers zu tun hat.

 

[MGFirewater]

Nein rechte wurden bei Einrichtung per Installationsroutine sauber erstellt. Liefen ja auch schon mehr als ein Jahr. Hatte Mal eine selinux Problem in der Zeit. Getraff damals aber beide user (admin und Kind) glaube aber kaum das die grub Reparatur das dann "zerstör"t hat.

Habe mit chatgpt etliche log Auswertungen gemacht weil das immer der erste Gedanke ist.
Aber nachdem die rechte Passwörter und eben auch timekpr ausgeschlossen werden kann bin ich mittels KI tiefer in die Analyse gegangen und das Ergebnis wollte ich euch zeigen.

@Alexander2
Wie kann ich das herausbekommen?

@tomgit
Das weiß ich. Deswegen habe ich als win10 nicht mehr supported werden sollte frühzeitig beide Distributionen getestet.
Laptop der Tochter hat kubuntu 26.04lts
Laptop vom Sohn Fedora 44
beides sind alte HP pro books 470 g3 bzw g4

Generell finde ich Fedora besser. Nur diese Probleme sind halt nervig. Auch dass SNAP discover crasht.

Ergänzung (Sonntag um 09:05)

@SpartanerTom

Nachtrag: Plasma Login Manager als möglicher Zusammenhang?​

Fedora 44 führt den neuen Plasma Login Manager (PLM) ein, der langfristig SDDM ersetzen soll.

Deshalb kam die interessante Frage auf, ob mein System beim Update vielleicht bereits automatisch von SDDM auf PLM umgestellt wurde und der Fehler daher stammen könnte.

Das lässt sich für meinen Fall ziemlich klar ausschließen.

• Bei bestehenden Fedora-Systemen bleibt SDDM erhalten; PLM wird nicht automatisch als Display Manager aktiviert.
• In der großen Update-Transaktion vom 22.08. wurde bei mir plasma-login-manager nicht installiert.
• Während des Fehlers liefen eindeutig die SDDM-Komponenten:

sddm
sddm-helper
sddm-greeter-qt6

Der Fehler entstand also nicht dadurch, dass Fedora SDDM durch den Plasma Login Manager ersetzt hätte.

Warum der Plasma Login Manager trotzdem interessant ist​

PLM ist eng mit dem bisherigen SDDM/Breeze-Login-Stack verwandt. Gleichzeitig wurde bei dem problematischen Update ein großer Teil des KDE-Unterbaus verändert.

Unter anderem:

Komponente	Vorher	Nachher
KDE Frameworks	6.28	6.29
KWin	6.7.4-1	6.7.4-2
Mesa	26.1.6	26.1.7

Wichtig dabei:

• plasma-workspace wurde in dieser Update-Transaktion offenbar nicht aktualisiert.
• plasma-desktop wurde ebenfalls nicht aktualisiert.
• sddm-breeze wurde ebenfalls nicht aktualisiert.
• Damit wurde auch die auffällige UserList.qml offenbar nicht durch dieses Update ersetzt.

Trotzdem trat unmittelbar danach im Breeze-Greeter immer wieder folgender Fehler auf:

qrc:/qt/qml/org/kde/breeze/components/UserList.qml:32:
TypeError: Cannot read property 'userName' of null

Das Interessante daran:

Obwohl im grafischen Login der zweite Benutzer ausgewählt wurde, gingen die SDDM/PAM-Authentifizierungsversuche weiterhin an den ersten Benutzer.

Vereinfacht sah das Verhalten so aus:

Benutzer 2 im Breeze-Greeter ausgewählt
↓
UserList.qml bekommt offenbar kein gültiges Benutzerobjekt
↓
userName = null
↓
SDDM erhält Benutzer 2 nicht korrekt
↓
PAM authentifiziert weiterhin Benutzer 1

Für den zweiten Benutzer tauchte im untersuchten Zeitraum überhaupt kein entsprechender grafischer sddm:auth-Versuch auf.

Was ist davon belegt und was ist nur eine Hypothese?​

Beobachtung	Status
SDDM war weiterhin der aktive Login Manager	Belegt
Plasma Login Manager hatte SDDM nicht ersetzt	Belegt
UserList.qml meldete wiederholt "userName of null"	Belegt
Beim grafischen Versuch mit Benutzer 2 wurde von PAM weiterhin Benutzer 1 authentifiziert	Belegt
Benutzer 2 war als Linux-Account korrekt vorhanden und per Terminal nutzbar	Belegt
Der Fehler trat erst nach dem regulären Fedora-Update auf	Belegt
Eine Änderung im KF6/QML-Unterbau hat den Fehler ausgelöst	Sehr plausible Hypothese, aber nicht bewiesen
Umbauten rund um Plasma Login Manager sind indirekt dafür verantwortlich	Möglich, aber bisher nicht bewiesen

Meine aktuelle Einschätzung​

Ich glaube daher nicht, dass der neue Plasma Login Manager selbst mein Problem verursacht hat – er lief auf dem Rechner überhaupt nicht.

Interessant ist vielmehr, dass in diesem Bereich aktuell viel umgebaut wird und der weiterhin aktive SDDM-Breeze-Greeter auf Komponenten aus dem Plasma-/KDE-QML-Unterbau angewiesen ist.

Eine mögliche Kette wäre daher:

Änderungen im Plasma/KDE/QML-Unterbau
↓
alter SDDM + Breeze verwendet diese Komponenten weiterhin
↓
UserList.qml bekommt ein ungültiges/null Benutzerobjekt
↓
ausgewählter Benutzer wird nicht korrekt an SDDM übergeben

Das ist ausdrücklich noch eine Hypothese.

Gesichert ist dagegen, dass SDDM weiterhin lief, der Breeze-User-Selector einen Null-Fehler produzierte und anschließend bei PAM nicht der im Greeter ausgewählte Benutzer ankam.

Gerade dieser Zusammenhang dürfte für die eigentliche Fehlersuche interessanter sein als die Frage, ob PLM bereits SDDM ersetzt hatte.

 

[Alexander2]

Ich habs gemerkt, als ich mit systemctl den sddm neustarten wollte, aber die Einheit gabs garnicht.

Nach etwas suchen habe ich dann herausgefunden, das es jetzt das plasma-login ist.
(per
systemctl list-unit-files
und dann suche per /
und "plasma" eingeben ohne Anführungszeichen.
Bei mir findet er dann entsprechend auch den neuen Dienst.

- es gibt auch durchaus Grafische Tools so etwas nachzuschlagen/einzustellen nur ist sowas normalerweise ja auch nicht isntalliert. Bevor jetzt wieder wer kommt terminal und so )

Ergänzung (Sonntag um 09:06)

Auch dass SNAP discover crasht.

Das kenne ich auch, und ist soweit ich das nachgeschlagen habe nen KDE Problem, das dürfte man überall antreffen.

 

[MGFirewater]

Nein in kubuntu funktioniert discover, weil das canonical sauber implementiert hat, bei Fedora ist flatpak der Standard und soweit ich weiß ist snap da ein Zusatz Community Plugin.

Ich werde Testweise auf PLM wechseln, aber ssdm noch nicht löschen.

 

[Alexander2]

Patches der Distro sind vorstellbar, vorallem wenn ja unter dem Dach der Snap macher.

Blöd nur, wenn der Patch noch nicht zu KDE weitergereicht wurde. denn da ist das Tatsächlich ein Bug. (gewesen zumindest als ich das explizit nachgeschlagen hatte)

 

[MGFirewater]

Off topic: ich habe jetzt den snap Aktualisierungsdienst im Hintergrund laufen, aber discover läuft unter Fedora jetzt ohne SNAP, damit die OS Updates sauber erkannt werden können.

Wusste nicht dass das geht scheint aber zu funktionieren.

Mir geht's hauptsächlich darum dass SNAP automatisch dopamine aktualisiert, da es das nicht als flatpak gibt und der Entwickler zurzeit viele neue Funktionen und Updates in den Player integriert und der einfach für alle OS systeme (Windows, Linux, MacOS)verfügbar ist, weshalb ich ihn überall verwende (nur auf dem Handy nutze ich bubblepnp)

 

[Habicht]

Offtopic:
falls du einen Player suchst, der für alle Systeme verfügbar ist, dann schau dir mal den Strawberry-Player an - damit musst du dir das System dann auch nicht mit irgend welchem "Schnaps-Gedöns" zumüllen.

 

[MGFirewater]

Strawberry hatte ich auch getestet aber dopamine ist viel besser die Kids fanden ihn auch unübersichtlich.

 

[Habicht]

Ich würde mir trotzdem nicht das System mit Snaps zumüllen, zumal es Dopamin ja auch als .deb und auch als .rpm gibt.

 

[Garmor]

Bei mir wird auch der Plasma-login genutzt. habe ich erst einige Zeit nach der Installation gemerkt.

Das ist ja der große Unterschied zwischen den Atomics und dem regulären Fedora: bei den Atomics werden regelmäßig Systemkomponenten ausgetauscht, weil der Systemzustand einheitlich gehalten wird, während man beim normalen Fedora auf allen seinen Altlasten sitzenbleibt. 😅

Auch ein interessanter Unterschied zwischen den Gnome- und KDE-Varianten: Autoupdates unter Discover laufen mehrfach täglich. Autoupdates unter Gnome Software nur bei kritischen Updates und ansonsten alle zwei Wochen (I shit you not).

 

[SpartanerTom]

@MGFirewater Schönes "post-mortem".

Habe eben mein bestehendes Fedora KDE (Bestandsinstallation seit 41) geupdated und es lief einwandfrei durch. Allerdings auch nur mit einem Benutzeraccount.

Habe danach mal spaßeshalber auf den Plasma-Login-Manager gewechselt und das scheint auch reibungslos funktioniert zu haben (man musste lediglich per CLI rebooten, da nach deinstallation von SDDM in der laufenden Session das Session Managment via GUI nicht mehr ging).

@Garmor
Das Intervall kann man bei Discover konfigurieren (es sei denn ich habe etwas falsch verstanden).

Wobei ich in der Regel alle Updates per Terminal mache. Ich mag Discover nicht besonders für Maintenance.

 

[Alexander2]

Genau, das ist einstellbar, Wöchentlich reicht mir vollkommen.