Linux T495 schläft nach Login ein

[der_ingo]

Moin,

ich betreibe seit längerem als privates Haupt-Gerät ein T495 (20NJ0006US) an einem 40B0 Dock, an dem u.a. ein Dell 2713HM Bildschirm hängt neben Tastatur, Maus und USB-SPDIF. Bisher mit Windows 11 und dort problemlos.
Nun ist das Gerät auch auf Linux umgestellt worden. Verwendet wird ein Fedora 42 KDE auf aktuellem Stand.
Damit taucht ein seltsamer Effekt auf: das Gerät ist zugeklappt, wird via Dock angeschaltet und fährt hoch. Bild kommt auf dem externen Bildschirm, Login-Fenster taucht auch auf. Sobald ich mich angemeldet habe, geht das System aber sofort in den Standby. Ich kann es dann per Tastendruck wieder aufwecken und weiterarbeiten.

Offenbar erkennt das System den geschlossenen Deckel und meint, es müsse dann in den Standby wechseln. Was natürlich bei einem externen Display samt externer Tastatur und Maus irgendwie sinnlos ist. In den Energieeinstellungen von KDE ist folgendes eingestellt:




Im Netz finden sich Hinweise auf systemd-logind und dass man dort einen Parameter setzen solle. Die entsprechende logind.conf gibt es hier allerdings nicht. Verwendet Fedora 42 KDE überhaupt diesen logind?

1840021 – PM suspend entry (deep) after starting

bugzilla.redhat.com

Hat da jemand noch Ideen?

Grüße, Ingo

 

[fakiauso]

Vermutlich meinst Du diesen Hinweis:

1840021 – PM suspend entry (deep) after starting

bugzilla.redhat.com

Falls es diese Datei nicht gibt, kannst Du diese mittels root-Rechten anlegen, entweder im Terminal oder in einem Dateimanager.

Dann fügst Du mittels C&P die Zeile ein

HandleLidSwitchExternalPower=ignore

Danach neustarten und es sollte laufen, weil dann der geschlossene Deckel ignoriert wird.

Du kannst im Terminal auch mit normalen Rechten in das Verzeichnis wechseln:

cd /etc/system.d

Die Datei abfragen kannst Du im Verzeichnis mit:

ls -l | grep logind.conf

Wenn sie nicht existiert, lege sie im Verzeichnis an mit:

sudo touch logind.conf

Bearbeiten kannst Du sie dann mit dem kleinen Editor nano:

sudo nano logind.conf

Oder eben per Klickibunti...

 

[think_pad]

Wäre es nicht einfach schlauer, den Schalter "Beim Schließen des Laptopdeckels" auf "Do nothing" zu setzen,
und den Sleep-Modus später per Keyboard auzuloesen?

 

[Mornsgrans]

Stört dann aber bei ungedockter Nutzung.

 

[der_ingo]

Falls es diese Datei nicht gibt, kannst Du diese mittels root-Rechten anlegen, entweder im Terminal oder in einem Dateimanager.

Okay. Ich war davon ausgegangen, dass bei Verwendung dieses logind die Config-Datei schon existiert.
Hab sie mal angelegt und werde testen, ob das einen Unterschied macht.

Beitrag automatisch zusammengeführt: 30 Mai 2025

So, das hat leider keinen Unterschied gemacht.
Das Gerät schläft weiterhin direkt nach dem Login ein. Es wacht auch daraus nicht sauber auf, d.h. meist kommt hinterher ein Bild, aber alle USB-Geräte funktionieren nicht mehr.

Ich habe zeitweise zum Testen ein L14 Gen 1 Intel am selben Dock, selbes OS auf selbem Patch-Stand. Das zeigt dieses Verhalten mit dem Einschlafen nach Login nicht. Es bringt nur hin und wieder mal beim Starten kein Bild auf dem externen Bildschirm. Ein Neustart hilft da.

Mit dem T495 unter Windows 11 kenne ich solche Zicken überhaupt nicht mehr. Das ist jedes Mal sauber gestartet und hat USB und externes Display sauber angesprochen. Von einem Hardwareproblem würde ich also nicht ausgehen.

Noch irgendwas, was ich testen könnte?

 

[fakiauso]

Noch irgendwas, was ich testen könnte?

Das ist auch kein Hardwareproblem, sondern hat m.E. etwas mit der AMD-Unterstützung zu tun. T495 und Linux ist anscheinend so ein Lottospiel mit der Energiesparunterstützung.

Gefunden habe ich in loser Folge schon etwas, aber das ist auch viel "alter Kram", der mit aktuellem Kernel gar nicht mehr auftreten sollte.

User:JL55HW/T495 - ArchWiki

Lenovo ThinkPad T495 - ArchWiki

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Drittanbieter-Cookies akzeptieren

Backlight - ArchWiki

Am wahrscheinlichsten wäre für mich die Chose mit IOMMU und dem USB-Suspend.

Als "nutzerfreundlichste" Methode fiele mir ein, dass Du ggf. einen älteren Kernel bootest, wenn Dir dieser in der grub-Auswahl angeboten wird, oder eine andere Distri vom Stick auf dieses Verhalten prüfst. An sich hat Fedora42 ja einen 6.14 dabei, der aktuell genug sein sollte.

TLP und brightnessctl kann noch installiert werden:

No way to control screen brightness

For the last days I have been unable to control the screen/display brightness on my laptop lenovo ThinkPad. Not with any control, and neither with the function keys (F5/6). So the screen is barely readable. I am pretty sure about the problem being related with fedora, since it is a dual-boot...

forums.fedoraforum.org

Klappt das Umschalten als Würgaround auf ein Terminal mit Strg+Alt+F1 und zurück mit Strg+Alt+F5?

Vielleicht stellst Du mit den Logs auch die Frage parallel im Fedora-Forum, falls wir hier nicht weiter kommen..

 

[der_ingo]

Hm... klingt ja nicht so begeisternd. Tatsächlich klappt mit der Helligkeit am internen Display alles und auch die Standby-Modi klappen sauber, wenn das Gerät einzeln läuft. Es wird aber halt hier zu 2/3 am Dock betrieben.

Ich denke, dann bleibt das L14 Gen 1 erst einmal das Haupt-Linux-Gerät und das T495 bleibt bei Windows 11.

Nächstes Jahr kann ich hoffentlich von der Firma ein P14s Gen 2a übernehmen, dann starte ich noch einen Versuch.
Danke auf jeden Fall für die Recherchen.

 

[fakiauso]

Es wird aber halt hier zu 2/3 am Dock betrieben.

Wäre wirklich so just for fun noch eine andere Distri einen Versuch wert. Bist Du auf Fedora und KDE angewiesen oder wäre da ein Debian- oder Arch-basiertes OS mit Gnome/Cinnamon auch möglich?

Endeavour-OS hat auch einen "schönen" KDE.

 

[der_ingo]

Zum Test könnte ich auch mal was anderes installieren, aber jetzt ist gerade Windows 11 wieder drauf.

Mit Gnome komme ich nicht wirklich klar, aber zum Test wäre das natürlich auch mal eine Möglichkeit. Ich denke aber, dass weniger die Desktopumgebung da das Problem sein dürfte.

Arch habe ich auf einem älteren Dell zum Testen. Wäre auch noch mal einen Versuch wert. Ich hatte Fedora bisher gerne verwendet, weil relativ aktuell und trotzdem für mich vergleichsweise stabil.

 

[fakiauso]

Endeauvour ist ja Arch-basiert und kann auch im Livesystem mit proprietären Treibern und Sprachauswahl betrieben werden. Da kannst Du ergo einen Trockentest machen ohne Installation.

Jetzt mache ich mal ein Mittagsschläfchen, damit ich meine gemütlichen 12 Stunden Nachtschicht überlebe;-)

 

[Ambrosius]

Endeavour-OS hat auch einen "schönen" KDE

Ja definitiv, eins der besseren OS themed KDE Editionen, wobei ich find dass deren frühere XFCE Implementation auch sehr schick aussah.

Was das Thema T495 und Linuxkomp. angeht, ist das speziell auf die AMD CPU Architektur der 3000er Serie zurückzuführen oder was anderes? Ich bin bislang immer davon ausgegangen dass ZEN2 relatov ausgereift ist.

 

[Ravensberger]

Fedora ist doch Wayland pur und stolz darauf, den X-Server jetzt herauszuwerfen. Immer das neueste ist aber durchaus auch einmal experimentell. Mit dem X-Server hatte ich auch auf meinem AMD- Gerät nie Probleme, mit Wayland dagegen einige beim Anmelden, auch wenn bei mir "nur" die Sitzung nicht startete, wenn man sich zwischenzeitig noch einmal abgemeldet hatte.

Ich würde auf eine stabile Distribution mit dem Gerät gehen.

 

[fakiauso]

Arch habe ich auf einem älteren Dell zum Testen. Wäre auch noch mal einen Versuch wert. Ich hatte Fedora bisher gerne verwendet, weil relativ aktuell und trotzdem für mich vergleichsweise stabil.

Falls Du TLP mit installiert hast, kannst Du auch die Ausgabe posten von:

sudo tlp-stat

Vielleicht kann linrunner etwas damit anfangen.

 

[perplex]

Thinkpads T60 2007-CTO, T61 6463-B45, 6463-AP1 und 7661-CTO, Mini Dock 2504
Mint 22.1, Cinnamon 6.4.8, Kernel 6.8.0-51,57,58,59,60

Habe ein ähnliches Problem mit Mint 22.1 Cinnamon und vermutete einen Bug. Bin jetzt verwirrt, so etwas auch über Fedora KDE zu lesen und laut Link im Startbeitrag bereits 2020. Hier die Details des Phänomens bei mir:

Nach Installation von Mint 22.1 Cinnamon auf mehreren Thinkpads T60 und T61 gehen die Rechner oft unerwünscht nach der Anmeldung in Bereitschaft, anscheinend wegen inkonsistenter Beachtung des Deckelschalters.

Dieses Verhalten ist vom früheren Betrieb unter Mint 18.3 und 20.1 und aktuell weiterhin unter Windows 7 unbekannt. Bei Nutzung von Mint 22.1 als Live-System wurde es dagegen auch einmal beobachtet. Eingabetreiber ist libinput, war es aber wohl auch zuvor.

Alle Rechner gehen bei Betrieb in der Docking-Station mit geschlossenem Deckel und angeschlossenem externen Bildschirm nach der Anmeldung mit oder ohne Paßwort oft, aber nicht immer, in Bereitschaft. Dies gilt sowohl nach Hochfahren als auch nach einer Abmeldung. Besonders auf dem T60 kann der Übergang in Bereitschaft dabei so lange verzögert sein, daß für einige Sekunden bereits der Desktop sichtbar ist. Im Systemprotokoll gehen dem Übergang von Fall zu Fall unterschiedliche Meldungen voraus.

Das Verhalten gilt sowohl für die Wahl von „Bereitschaft“ als auch für die Wahl von „Nichts tun“ „Wenn der Deckel geschlossen ist“ in den Einstellungen der Energieverwaltung und unabhängig davon, ob dabei „Aktion nach Schließen des Deckels auch bei angeschlossenen externen Bildschirm durchführen“ aktiviert ist oder nicht. Die manuelle Eintragung „HandleLidSwitch=ignore“ in /etc/systemd/logind.conf als Behelf verhindert diesen Übergang in Bereitschaft, Aktivierung der dort angebotenen Eintragung „HandleLidSwitchDocked=ignore“ dagegen nicht.

Wenn der Deckel bei der Anmeldung geöffnet ist, gibt es - wie es sein soll - diesen Übergang in Bereitschaft nicht, unabhängig davon, ob der Rechner in der Docking-Station oder außerhalb betrieben wird, und unabhängig davon, ob ein externer Bildschirm angeschlossen ist oder nicht. Die Rechner gehen aber (nicht ausreichend getestet, ob immer) in Bereitschaft, wenn ihr Deckel unmittelbar nach der Anmeldung geschlossen wird.

Die Rechner lassen sich durch Drücken der Einschalttaste oder ausreichendes Anheben des Deckels aus der Bereitschaft aufwecken; aufgrund der entsprechenden Einstellung für den Bildschirmschoner (Rechner sofort sperren, wenn er in den Ruhezustand geht) wird dann ggf. erneut das Paßwort abgefragt. Im laufenden Betrieb gibt es den unerwünschten Übergang in Bereitschaft nicht.

Sieht so aus, als wirkten in der Phase nach dem Login die Einstellungen der Energieverwaltung nur manchmal. Sind da parallel laufende Prozesse nicht richtig synchronisiert?

Im Forum linuxmintusers.de wurde von einem gleichartigen Problem mit Mint 22.1 Cinnamon auf einem nicht näher spezifizierten Thinkpad in einer Docking-Station berichtet, dort leider versandet. Ein eigener Beitrag dort führte zu obigem Behelf, aber keiner Klärung der Ursache.

 

[perplex]

Nach den letzten Aktualisierungen meiner Installation von Mint 22.1 scheint sich das Problem erledigt zu haben. Jedenfalls habe ich auf zwei Rechnern bei etlichen Anmeldungen keinen Übergang in Bereitschaft mehr erlebt, auf dem täglich benutzten auch nicht mehr, nachdem ich dort die als Behelf vorgenommene Modifikation der /etc/systemd/logind.conf wieder rückgängig gemacht hatte. Ich hoffe also mal. Bei anderen Betroffenen ebenso?

Da die Aktualisierungen eine Vielzahl von Komponenten betrafen und die Ursache der Problems offen blieb, bleibt der genaue Fehler ungeklärt.