Ubuntu 16.04/18.04 wacht aus dem Standby mit einem schwarzen Bildschirm auf

Das nervt mich schon seit mehr als zwei Jahren: Ubuntu wird in den Suspend gefahren und fährt in einen schwarzen Zustand, den man wahlweise mit einem harten Reboot oder einem Weich SysRQ-Befehl beendet. Das ganze betrifft mich in erster Linie, weil ich die proprietären nVidia-Treiber nutze, allerdings gibt es auch eine Reihe anderer nutzer, die vor einem vergleichbaren Problem stehen.

In folgendem nVidia-Forenbeitrag gibt es dazu dieses nützliche Statement:

Schritt 1:

[Disable hibernate by default in upower]
Identity=unix-user:*
Action=org.freedesktop.upower.hibernate
ResultActive=yes

[Disable hibernate by default in logind]
Identity=unix-user:*
Action=org.freedesktop.login1.hibernate;org.freedesktop.login1.handle-hibernate-key;org.freedesktop.login1;org.freedesktop.login1.hibernate-multiple-sessions;org.freedesktop.login1.hibernate-ignore-inhibit
ResultActive=yes

Schritt 2:
GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash nvidia-drm.modeset=1 vga=0 rdblacklist=nouveau nouveau.modeset=0″

Schritt 3:
sudo gedit /etc/initramfs-tools/modules and add the following modules
nvidia
nvidia_modeset
nvidia_uvm
nvidia_drm

Schritt 4:
update-initramfs -u

Schritt 5:
Neustarten

Anschließend habe ich noch via „sudo apt install laptop-mode-tools“ das Powermanagementpaket für portable Geräte nachinstalliert, neu gestartet und der Standby funktioniert wieder sauber und anständig. Endlich!

Linux, Intel CPU, Notebook, Laptop, Ultrabook und laute CPU nach dem Aufwachen?

Manchmal gönnt man sich etwas. Nachdem ich zehn Jahre lang meinen eeePC 901 als digitale Schreibmaschine für die Uni eingesetzt habe, war es leistungstechnisch höchste Eisenbahn, aufzurüsten. Das habe ich getan mit einem hübschen Gebrauchtgerät von notebooksbilliger.de: Ein Toshiba Protégé Z30A aus dem Jahr 2014 mit Intel core i5-4310U (vPro), 8 GB Ram, 128 GB SSD auf 13,3 Zoll. Schönes, neues Schreibmaschinchen.

Doch was ist das? Nachdem ich Kubuntu 17.10 aufgespielt und eingerichtet habe und nahezu alles funktioniert (Keyboardhotkeys sind etwas gemein und auch das Einrichten des Touchpads erfordert Geduld) ist mir aufgefallen, dass manchmal, nach dem Aufwachen aus dem Standby (resume from suspend to ram, S3) der Lüfter (mein gröter Fan) auf Höchsttouren lief. Ein Heruntertakten der Geschwindigkeit hat nicht eingesetzt. Einfachste Lösung: Schlafen legen, wieder wecken und gut. Aber warum?

Das ganze geht wohl auf einen Kernel Bug aus dem Jahre 2013 zurück, der zwischenzeitlich angeblich gelöst war, dann wieder nicht … und letztlich alle Linux-Derivate betreffen kann. Gelöst werden kann das ganze wiederum über ein praktisches Skript von franz-knipp, welches derart aussehen muss und von hier stammt:

#!/bin/sh
#
# Reset fan speeds after resume, otherwise they blow at maximum speed
#
# Used as work-around for ACPI kernel bug 58301
# https://bugzilla.kernel.org/show_bug.cgi?id=58301
#
# The idea for this fix was taken from
# http://ubuntuforums.org/showthread.php?t=1761370
#
# Author: franz@qnipp.com
#
# To be saved as /etc/pm/sleep.d/11_fan_3.11.0

case „$1“ in
thaw|resume)
for i in /sys/class/thermal/cooling_device* ; do
type=`cat $i/type`
if [ „$type“ = „Fan“ ] ; then
echo 0 > $i/cur_state
fi
done
;;
esac

Das ganze als root (also bspw. aus dem Terminal als „sudo nano /etc/pm/sleep.d/11_fan_3.11.0„) unter /etc/pm/sleep.d/11_fan_3.11.0 anlegen, speichern und beim nächsten Suspend wird es aufgeführt. Simple Lösung für ein nerviges Problem, sehr schön und danke Franz! 😉

Telekom WLan To Go bzw. Hotspot (Hotspot_FON) verstärken?

Seit Monaten sitze ich an dem Problem, wie ich einen Telekom Hotspot mittels eines Repeaters so verstärken kann, dass zumindest ein Client dahinter ins Internet kann. Einschlägige Foren der Telekom-Community (Telekom hilft) beschwören stets, dass dies nicht ginge. Andere Aussagen bezüglich exotischer Hardware in diversen Foren wiederum bestätigen, dass es doch irgendwie geht. Doch keiner schreibt genau, wie. Außerdem möchte ich doch vorhandene Hardware nutzen, weshalb ich das ganze in dd-wrt nachgebaut habe. Und das mit Erfolg!

Ich habe mich zunächst an dieser Anleitung orientiert und alle Schritte befolgt, die notwendig waren. Das wichtigste ist dabei die IP-Konfiguration:

Router IP: 172.17.2.2
Subnet: 255.255.255.0
DNS: 172.17.2.1
Gateway: 172.17.2.1

Das Netzwerk ist bridged, das WLan heißt Telekom_Fon und das gebridgede Netzwerk kann einen ganz eigenen Namen tragen. Einen DHCPD-Service braucht es gar nicht, wichtig ist lediglich, dass die Firewall aus ist. Auch mit VLAN-Tagging muss ich mich nicht beschäftigen, alles sollte bereits richtig konfiguriert sein.

Doch ein Problem bleibt bestehen: Zwar bekomme ich schon korrekterweise vom Telekom-Hotspot eine dynamische IP zugewiesen, doch sehe ich die Vorschaltseite mit den Zugangsdaten nicht. Warum aber?
Dies liegt am Umstand, dass der Hotspot die erste Mac-Adresse, die er sieht, mit dieser Seite behelligt. Hat nun der Repeater eine andere Mac als mein Client, so geht letzterer leer aus und kann schlicht nicht ins Internet – mein Repeater kann ja nicht antworten. Entsprechend reicht es, das Mac-Adress-Cloning einzuschalten und die Mac-Adresse des Clients zu übertragen. Et voilà – der Hotspot ist repeatet und sollte mittels Richtfunkantenne die entlegegensten Winkel mit Internet versorgen.

WiimoteWhiteboard unter Linux zum Laufen bekommen

Es ist ein tatsächlich seltenes Thema, aber doch nicht gänzlich unbekannt: Interaktive Whiteboards selbst bauen mit vorhandenen Bildschirmen/Projektoren und günstigen Eingabemöglichkeiten. Fertige, marktorientierte Lösungen schlagen mit mindestens 1500,-€ zu Buche, und das ist eindeutig zu fett. Warum also nicht mal DIY?

Einschlägige, preiswerteste Lösungen funktionieren mit einer Wiimote (dem Nintendo Wii/Wii U Controller), einem Infrarotstift und spezieller Software. Doch soll diese ja, obgleich des recht betagten Alters (latest release 2010), auch noch unter aktuellen Linux-Distributionen laufen. Nur wie?

  1. Linux-Voraussetzungen beachten und die JAR-Datei patchen, wie hier beschrieben. (Letztlich nur ein zip WiimoteWhiteboard.jar libbuecove*.jar zum hineinzippen in die ursprüngliche Java-Datei)
  2. libbluetooth-dev installieren, wie hier beschrieben. (Um BlueCove im BlueZ-Stack zu verankern)

Et voilá – läuft, sitzt, wackelt und hat Luft. Zumindest auf dem von mir getesteten Asus eeePC 901.

Privacy Policy Settings

Datenschutz DSGVO
Klick