Linux, Ruhezustand und SSD: Vier Jahre voller Hürden

Vier Jahre GNU/Linux auf einem Mini-PC: Windows-Ruhezustand unmöglich, 40.600 GiB SSD-Schreiblast und die Rückkehr zu Xorg nach Wayland-Problemen.

Deutsch · Ursprüngliche Diskussion auf Spanisch · Veröffentlicht

Linux, Ruhezustand und SSD: Vier Jahre voller Hürden
Vier Jahre GNU/Linux: Vom Dual-Boot zum überlasteten SSD

Können Windows und Linux gleichzeitig auf demselben Rechner ruhen? Auf dem Papier ja. Bei einem Shuttle Slim Mini-PC von 2015 — Zweikern-Celeron mit 1,5 GHz, 16 GB RAM und SSD — lautete die Antwort monatelang nein. Dies ist der erste Halt einer vierjährigen GNU/Linux-Erfahrung, die vom unmöglichen Ruhezustand über den SSD-Verschleiß bis hin zum Austausch eines Videokabels reichte.

Der Ausgangspunkt: Installation von Ubuntu 22.04.1 neben Windows 10 22H2 im Dual-Boot mit GRUB. Ubuntu wechselt problemlos in den Ruhezustand, sobald der Offset in der GRUB-Datei berechnet wurde. Windows nicht. Beim Ausführen von shutdown -h antwortet das System knapp mit „Das angegebene Datei konnte nicht gefunden werden (2)“.

Warum hiberniert Windows nicht bei installiertem Linux?

Die Datei hiberfil.sys existiert auf der Windows-Partition. Eine Anpassung an die RAM-Größe — sie belegte anfangs nur 40% davon — bringt nichts. Die wahrscheinliche Ursache: Die als aktiv markierte Partition enthält GRUB, was Windows nicht akzeptiert. Eine Änderung der aktiven Partition könnte zwar den Windows-Ruhezustand ermöglichen, würde aber Ubuntu den Start verwehren. Ein Teufelskreis.

Gängige Lösungswege wurden erfolglos getestet: Deaktivieren und Reaktivieren des Ruhezustands-Dienstes per Konsole mit powercfg.exe /hibernate off und on. Auch dies half nicht. Die 90 GB freien Speicherplatz auf der Partition und die 16 GB RAM schließen ein Platzproblem aus. Man scherzte sogar, Windows komplett zu löschen und es innerhalb von Linux zu virtualisieren.

Die SSD, die täglich 50 GB Schreiblast schluckt

Die Warnung kam später: 40.600 GiB geschrieben und steigend um 50 Gigabyte pro Tag, da der Rechner oft stundenlang läuft. Der Hersteller gibt die Lebensdauer der Scheibe mit 160.000 GiB an. Es bleibt Puffer, aber die Sorge ist berechtigt.

Ein Teil der Lösung liegt in TRIM. Distributionen mit systemd führen dies automatisch durch — einmal wöchentlich oder kontinuierlich mit der Option discard —, sodass eine manuelle Planung via cron ein Relikt vergangener Zeiten ist. Der andere, pragmatischere Weg: Nicht nur eine Festplatte nutzen. SSDs sterben ohne Vorwarnung, mechanische Laufwerke zeigen zumindest Symptome.

Swappiness, Swap und 25 GB für den Ruhezustand

Hier beginnt das Zahlenjonglieren. Mit vm.swappiness auf 60 (Standardwert) wird die Swap genutzt, wenn der RAM zu 40% gefüllt ist. Bei Wert 0 ignoriert das System die Swap vollständig, was zum Absturz von Anwendungen führt. Mit Wert 5 bewegt sich die Swap wieder, ohne dass Prozesse sterben.

Die Ausgabe von free -h beruhigt wenig: 15 GiB gesamt, 5,8 GiB belegt, 410 MiB frei und 9,3 GiB im Cache. Der Systemmonitor zeigt anderes — 13,5 GB, 81,4% — und wirkt glaubwürdiger für jemanden, der drei Browser, Messenger, Player und einen Client für verteiltes Rechnen gleichzeitig nutzt. Für den Ruhezustand wurden 25 GB Swap angelegt.

Wayland verschiebt Fenster und leert den RAM

Das moderne Anzeigeprotokoll bringt zwei Probleme. Erstens: Einige maximierten Fenster rutschen nach unten, wenn der Bildschirm ausgeschaltet und wieder aktiviert wird. Zweitens, schlimmer: Der Speicher wird langsam verbraucht, bis bei Überschreiten von 80% Anwendungen abstürzen. Das Ergebnis unter pipas: Rückkehr zu Xorg.

Und es gibt keine bequeme Alternative. Xorg ist stark gepatcht und kaum noch jemand will es verstehen. Proprietäre Treiber für Grafikkarten machen es ebenfalls nicht einfach.

Von zwei Windows zu zwei Linux: Ubuntu, Artix und Linux Mint

Der Dual-Boot endete in Trennung: Windows raus, dafür ein zweites Linux. Zuerst Artix, die Arch-Schwester ohne systemd, mit dinit-Start und KDE Plasma. Die Installation war vernünftig, abgesehen von einem PipeWire, das doppelt startete und den Ton lahmlegte. Dann kam Linux Mint, und dort stabilisierte sich alles: läuft hervorragend.

Der Vergleich zwischen Distros überrascht wenig. Der Speicherverbrauch ähnelt sich, wenn die Hintergrundprozesse gleich sind: Ein Bicho wie ClamAV frisst allein ein Gigabyte. Die echten Unterschiede liegen in der Community, nicht im Desktop.

Flatpak, AUR und die volle Festplatte

Um Microsoft Teams oder Mp3Gain zu installieren, ist Flatpak der kurze Weg. Das Problem: Die Pakete belegen enorm viel Speicher. Die Alternative bei Artix ist das AUR, wo beide als Binärdateien vorliegen und nicht kompiliert werden müssen. Die 100% CPU-Auslastung durch Renderer-Prozesse der Browser ist ein anderes Thema: Symptom für Software-Rendering.

Das Kabel, das HD-Fernsehen ruinierte

Eine gesammelte Anekdote: Das pixelige Bild der HD-Kanäle des digitalen terrestrischen Fernsehens (TDT), sowohl unter Windows als auch in fast allen Distributionen. Die Ursache lag nicht in der Software. Es war ein analoges VGA-Kabel. Nach dem Wechsel auf DVI-D verschwand das Problem.



Vier Jahre, mehrere Distributionen, ein für 70 Euro repariertes Mainboard und eine SSD, die noch lebt. Die Schlussfolgerung ist bescheiden, aber aufschlussreich: Fast keines der Probleme lag an Linux. Fast.

Auch verfügbar auf: English

Zusammenfassung einer Diskussion auf Burbuja.info - Foro de economía, actualidad y política., aus dem Spanischen übersetzt und vor der Veröffentlichung geprüft. Die ganze Diskussion lesen (215 Antworten).

Weitere Zusammenfassungen

Alle Zusammenfassungen auf Deutsch →

Volver