Folgendes Problem belastet mich schon länger:
Aus KDE 4 (openSUSE 11.4) kann ich nicht in den Ruhezustand oder den Tiefschlaf wechseln.
Die Schaltflächen aus dem K-Menü unter dem Reiter “verlassen” funktionieren nicht.
Auch die Buttons des Miniprogramms “Bildschirmsperre/Abmeldung” arbeiten nicht richtig.
Aus Gnome kann ich den PC ebenfalls nicht herunterfahren, ich lande immer nur im Anmeldemanager aber der Rechner fährt nie standardmäßig runter.
Wie kann ich das beheben?
Ein großes Dankeschön an alle Helfer!!!
Neben meinem gibt es in den Linux-Foren unzählige Threads zu diesem Thema. Letztlich liegt es - soweit ich informiert bin - am Zusammenspiel des Betriebssystems und der Hardware – sprich: Wenn die Hardware-Hersteller (egal ob für Linux, Windows oder sonst was) ordentliche Treiber bereitstellen würden, liefe die ganze Sache erheblich problemloser. Bei Linux muss man halt mit der Art des Kernel Glück haben. Manchmal findet sich im Internet eine Seite, auf der Du überprüfen kannst, wie sich ein bestimmtes Linux mit Deinem Rechner verträgt, z.B. LinLap.com [LinLap - Linux Laptop Wiki]
Ab und zu halte ich Ausschau nach Lösungen für meinen Laptop. Vielleicht gibt es ja einen Konfigurationstrick - aber von dem habe ich noch nichts mitgekriegt, vor allem in keiner Form, die für Laien verständlich ist.
Meine Lösung bisher: Ich habe in den Systemeinstellungen alle ‘automatischen’ Stand-bys etc. auf “Bildschirm sperren” gestellt. Das spart wenigstens den Strom für die Anzeige.
Antworten von seiten der Profis sind auch mir herzlich willkommen!!!
Das ändert natürlich nichts daran, dass openSuSE ein geniales OS ist :good: Grüße in alle Richtungen!
Komisch, unter Gnome funktionieren Ruhezustand und Tiefschlaf einwandfrei.
Ich hab das Gefühl, dass es an einer Berechtigung im Policykit liegen könnte,
kann diese unter KDE allerdings nicht ändern (bei Gnome klappt das).
Nach jeder Modifizierung einer Aktionsregel springt alles in seinen ursprünglichen Zustand zurück.
In Gnome hab ich aber wie gesagt das Problem, dass ich aus dem angemeldeten Zustand den Rechner nicht ohne Umweg herunterfahren kann.
Sicher ist die Lösung simpel, doch ohne interne Erfahrung in diesem Bereich ist das Finden einer Lösung schwer.
Keiner da, der mal konstruktive Vorschläge hat! (nicht für ungut Jackson)
Es würde mich freue,n wenn die hochgelobte Community bei Problemen behilflich ist anstatt sie zu ignorieren.
Jedenfalls kann ich mir nicht vorstellen, dass es sich bei meinem Problem um ein schwerwiegendes handelt. Ich bin davon überzeugt, das man mit einer kleinen Änderung einer Konfigurationsdatei oder eines Befehls eine Lösung herbeiführen kann.
Ich glaube nicht, dass es man so ein Problem damit herunterspielen kann das die Hersteller keine Treiber bereitstellen.
Für mich leider ein großer Kritikpunkt an SUSE. Viele kleine Probleme summieren sich auf ein großes Ganze.
Ein direktes Herunterfahren aus GNOME (statt aus KDE - dann aber dort dann nicht mehr;) ) kannst Du voraussichtlich erreichen, wenn Du den in Deinen Einstellungen für die System-Konfiguration (am einfachsten mit dem /ect/sysconfig Editor)
bei Display Manager auf gdm
(für GNOME Display Manager) und
bei Window Manager > DEFAULT_WM (Standard Fenster Verwalter) auf gnome
umstellst.
Das mit dem Suspend to Disk und Suspend to RAM ist oft ein Problem bei Laptops.
Ehrlich gesagt bleibt (sofern ambitioniertes Kaputt-Konfigurieren einigermaßen ausgeschlossen werden kann) dem Linux-Fan meiner Meinung nur:
Einen sehr erfahrenen Linuxer direkt vor das Gerät setzen (Linux User Group?)
Beim Kauf gleich ein auf Linux ausgelegtes Gerät kaufen oder mit einer Live CD testen, ob die entsprechende Linux Distribution/Linux basierte Systeme überhaupt funktionieren (einschließlich S2R, S2D).
Schon in der Testphase (Milestones usw.) einer Distributions-Version sein Schätzchen mit Linux in Kontakt bringen und den Entwicklern freundliche sowie möglichst exakte Fehlerberichte liefern…
Aber vielleicht findet sich noch ein besonders kluger Mensch hier im Forum?
Ich kann aus GNOME jetz nun supspend to disk und ram ausführen sowie den PC ohne Anmeldemanager herunterfahren (beim letzten wird dieser jedoch kurzzeitig angezeigt).
Habe jetzt allerdings eine schwerwiegendes Sicherheitsproblem:
Wenn ich aus suspend to disk bzw ram hochfahren lande ich sofort auf der Arbeitsfläche. Die Bildschirmsperre ist verschwunden.
In meiner Gnomekonfiguration sind folgende Schlüssel dazu gesetzt:
Den entsprechenden Schlüssel habe ich jetzt nicht so schnell gefunden.
Aber versuch mal:
Kontrollzentrum : Darstellung > Bildschirmschoner/Einstellungen des Bildschirmschoners > Bildschirm sperren, wenn der Bildschirmschoner aktiv ist.
Das Entfernen des Hakens hat bei mir eben dazu geführt, dass keine Passwortabfrage beim Aufwachen aus dem
Speichern in den Arbeitsspeicher/s2ram/Bereitschaftsbetrieb/
Standby-Modus/ACPI-S3
mehr durchgeführt wird -> hoffentlich hat das Gegenteil bei Dir auch den gegenteiligen Effekt (auch wenn das nicht logisch zwingend ist ).
… dieses schwerwiegende Sicherheitsproblem …
Und auf diese Passwortabfrage würde ich mich nur einsetzen, wenn man mal kurz den Rechner aus dem Auge lässt und neugierigen Unbedarften ein kleines Hindernis setzen will - wenn z. B. wenn man in einer öffentlichen Bibliothek den Rechner angeschlossen hat und kurz weitere Bücher holt.
Mit Hilfe einer Live CD oder ähnlichem dürfte meines Amateur-Wissens nach sowieso jeder in unter 5 Minuten an Deine Daten kommen können, wenn er einigermaßen unbeobachteten körperlichen Zugriff auf Deinen Rechner hat.
Da bräuchte es sonst wohl Verschlüsselung (der Datenpartition oder gar des ganzuen Systems - root-Verschlüsselung) und ich weiß nicht, ob diese nicht aufgehoben ist/leicht aushebelbar ist, wenn der Rechner im s2ram oder s2disk ist…???:\
zusätzlich dazu habe ich unter Kontrollzentrum>Bildschirmschoner “Bildschirm sperren, wenn der Bildschirmschoner aktiv ist” gesetzt.
Werde in den nächsten Tagen mal schauen, ob die Sperre in allen Szenarien nun zuverlässig arbeitet.
Mich würde zusätzlich interessieren, ob es Möglichkeiten gibt aus einem gesperrtem System Speicherfelder aus dem Ram auszulesen.
Der Sperre als solches traue ich nämlich keinen effektiven Schutz zu. Wäre gut wenn jemand was dazu zu sagen hätte.
Wenn eine Encryption des Rootverzeichnis (auch Swap) auf dem System vorhanden ist, dann werden meines Wissens nach die temporären Daten bei suspend2disk mit verschlüsselt. Bei suspend2ram kann das nicht funktionieren, weil die benötigten Dateien nicht auf einem Verschlüsselten Festplattenlayer, sondern im Arbeitsspeicher liegen. Und wie man Echtzeitverschlüsselung des Arbeitsspeicher unter Linux implementiert, (wenn das überhaupt möglich ist) kann ich spontan nicht sagen.
Nach jeweils einem Neustart ist der Haken unter Kontrollzentrum>Bildschirmschoner “Bildschirm sperren, wenn der Bildschirmschoner aktiv ist” verschwunden und das System hat plötzlich keine Bildschirmsperre mehr!
).