Lenovo Thinkpad Yoga: Touchscreen beim Schließen des Deckels deaktivieren

Wenn der Deckel des Lenovo Thinkpad Yoga geschlossen wird (und nicht in den Energiesparmodus wechselt), dann sorgt der Touchscreen für unerwünschte Eingaben auf dem Laptop.

Deshalb soll von nun an beim Schließen des Deckels der Touchscreen deaktiviert und beim Öffnen wieder aktiviert werden.

Der Dienst acpid sorgt dafür, dass Skripte in Abhängigkeit verschiedener Events ausgeführt werden können. Daher legen wir die Datei /etc/acpi/events/lid mit folgendem Inhalt an:

event=button/lid.*
action=/etc/acpi/yoga_lid.sh %e

Anschließend wird die Datei /etc/acpi/yoga_lid.sh angelegt:

#!/bin/bash

DEBUG_LOG=0
log=/home/stephan/yoga_lid.log

function debug() { ((DEBUG_LOG)) && echo "$*" >> $log; }

state=$(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}')

if [ $state == "open" ]; then
	debug "$(date +%Y-%M-%d_%H-%M-%S) Deckel offen - Touchscreen wird aktiviert"
	xinput --enable "ELAN Touchscreen"
	xinput --enable "Wacom ISDv4 EC Pen stylus"
	xinput --enable "Wacom ISDv4 EC Pen eraser"
else
	debug "$(date +%Y-%M-%d_%H-%M-%S) Deckel geschlossen - Touchscreen wird deaktiviert"
	xinput --disable "ELAN Touchscreen"
	xinput --disable "Wacom ISDv4 EC Pen stylus"
	xinput --disable "Wacom ISDv4 EC Pen eraser"
fi

und ausführbar gemacht mittels

chmod a+x /etc/acpi/yoga_lid.sh

Damit das Ganze auch wirklich ausgeführt wird, muss der acpid-Dienst neugestartet werden:

systemctl restart acpid.service

Verbindungsabbrüche bei Lenovo Thinkpad Yoga und OneLink Pro Dock

Mein Thinkpad Yoga hat im Zusammenspiel mit dem OneLink Pro Dock das Problem, dass der in der Dockingstation verbaute USB3-Hub öfters neu gestartet wird und somit etwa neben angeschlossenen USB-Sticks auch die am Dock vorhandene, per USB-zu-Ethernetadapter realisierte LAN-Schnittstelle die Verbindung verliert. Getestet hatte ich bereits zwei verschiedene Dockingstationen, um einen Hardwaredefekt auszuschließen. Außerdem hat mein parallel installiertes Windows 10 diese Probleme nicht.

Wie auch schon im Ubuntuusers-Forum dargestellt, bekomme ich in diesem Fall folgende Meldungen bei udevadm monitor:

KERNEL[620.462898] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1/queues/rx-0 (queues)
KERNEL[620.462987] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1/queues/tx-0 (queues)
KERNEL[620.463081] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1 (net)
UDEV  [620.465372] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1/queues/rx-0 (queues)
UDEV  [620.465449] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1/queues/tx-0 (queues)
UDEV  [620.469248] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1 (net)
KERNEL[620.488358] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0 (usb)
UDEV  [620.489213] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0 (usb)
KERNEL[620.508182] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3 (usb)
KERNEL[620.508368] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1:1.0 (usb)
KERNEL[620.509552] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1 (usb)
UDEV  [620.509591] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1:1.0 (usb)
KERNEL[620.509612] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0 (usb)
UDEV  [620.509658] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3 (usb)
UDEV  [620.510619] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1 (usb)
KERNEL[620.510669] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3 (usb)
UDEV  [620.510699] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0 (usb)
UDEV  [620.511233] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3 (usb)
KERNEL[620.996518] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3 (usb)
KERNEL[621.198346] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0 (usb)
KERNEL[621.920579] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1 (usb)
KERNEL[621.922551] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1:1.0 (usb)
UDEV  [622.010547] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3 (usb)
UDEV  [622.013885] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0 (usb)
KERNEL[622.314107] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3 (usb)
KERNEL[622.314926] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:2.0 (usb)
KERNEL[622.316478] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:2.0/net/eth0 (net)
KERNEL[622.316523] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:2.0/net/eth0/queues/rx-0 (queues)
KERNEL[622.316551] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:2.0/net/eth0/queues/tx-0 (queues)
KERNEL[622.316998] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:2.1 (usb)

Nach langem Suchen, Probieren und Testen mit verschiedenen Linux-Distributionen und Kernelversionen (getestet mit Ubuntu 14.04 LTS, Kubuntu 15.04, SystemRescueCd, GParted Live CD jeweils mit den Standard-Kerneln, sowie unter Kubuntu 15.04 zusätzlich mit den Kerneln 4.1 und 4.2), konnte ich das Problem lösen.

Ich kann es mir zwar nicht erklären, aber Abhilfe schafft es tatsächlich, die Energieverwaltung für die Soundkarte des Laptops zu aktivieren! Dies wird zwar zum generellen Energiesparen von powertop empfohlen, jedoch hätte ich dies nie im Zusammenhang mit der Dockingstation erwartet.

Die Einstellung lässt sich bspw. mittels

echo '1' > '/sys/module/snd_hda_intel/parameters/power_save';

in der Datei /etc/rc.local realisieren.

Eine etwas elegantere Variante wäre per UDEV-Regel. Dazu wird die Datei /etc/udev/rules.d/99-Yoga-Powermanagement.rules mit folgendem Inhalt angelegt:

SUBSYSTEM=="module", ACTION=="add", KERNEL=="snd_hda_intel", TEST=="parameters/power_save", ATTR{parameters/power_save}="1"

Die dritte und für Thinkpads meiner Meinung nach beste Variante ist die Benutzung des Tools tlp. Installationsanleitungen sind hier zu finden. Hier lassen sich viele Optionen zum Energiesparen relativ leicht einstellen.

Wichtig für die Aktivierung des Powermanagements der Audio-Hardware, insbesondere bei Betrieb am Netzstrom ist die Einstellung

SOUND_POWER_SAVE_ON_AC=1

in der Datei /etc/default/tlp.

Firefox: Sync – Fehler bei der Synchronisation: Unbekannter Fehler

Mein Firefox hat seit kurzem das Problem, dass das Synchronisieren der Lesezeichen usw. mit obiger Fehlermeldung abbricht.

Im Sync-Log unter about:sync-log steht irgendwo der Fehler NS_ERROR_MALFORMED_URI.

Dank dem Eintrag hier bin ich schließlich auf diese Erweiterung gestoßen: Places Maintenance. Damit konnte meine offensichtlich beschädigte Lesezeichen-Datenbank repariert werden. Und Firefox Sync klappt wieder!

Lenovo Wiederherstellungspartition und Grub: störenden Eintrag verhindern

Bei einem Lenovo-Laptop erzeugt Grub2 automatisch einen Eintrag für die Wiederherstellungspartition. Um diesen aus dem Grub-Menü fern zu halten, kann man das dafür zuständige Grub-Skript deaktivieren, indem die Ausführungsrechte entzogen werden (natürlich als root):

chmod a-x /etc/grub.d/30_uefi-firmware

Ein anschließendes

update-grub

sorgt dafür, dass das Grub-Menü neu erstellt wird.

darktable und lensfun: Objektivkorrekturen

Die Objektive unserer neuen Kamera, die Panasonic Lumix DMC-GX7, werden erst seit der Version 0.3.0 von Lensfun unterstützt (Objektivliste).
Ubuntu 14.10 ist allerdings noch bei der Version 0.2.8 im Paket liblensfun0.

Da ich auch kein passendes PPA gefunden habe, wird lensfun selbst kompiliert.

Als erstes den Quelltext runterladen und entpacken.
Danach dafür sorgen, dass es auch kompiliert werden kann

sudo apt-get build-dep liblensfun0

Jetzt sollte noch dafür gesorgt werden, dass liblensfun0 deinstalliert wird, damit es nachher keine Komplikationen mit der neuen Version gibt (in diesem Zusammenhang werden bei mir auch digikam und darktable deinstalliert, was erstmal ok ist)

apt-get remove liblensfun0
apt-get autoremove

Danach ins entpackte lensfun-Verzeichnis wechseln und folgende Befehle ausführen

mkdir cmake_build
cd cmake_build/
cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ../
make
sudo checkinstall -D --pkgname liblensfun0 --pkgversion 0.3.0-lokal

Danach kann man darktable und digikam wieder installieren

apt-get install darktable digikam

In den Objektivkorrekturen bei darktable steht nun für beiden Panasonic-Objektive die Objektivkorrektur bereit.

Kubuntu 14.10: Network-Manager startet nicht mehr automatisch

Nach dem Upgrade von Kubuntu 14.04 auf 14.10 funktionierte nach einem Neustart meine WLAN-Verbindung auf meinem Lenovo Thinkpad X220 nicht mehr.
Beim Booten kam die Meldung:

waiting for network configuration (kurz danach dann:)
waiting an additional 60 seconds for network configuration

Nach einiger Wartezeit startete KDE dann trotzdem, jedoch ohne eine Netzwerkverbindung aufzubauen.
Dann fiel mir auf, dass der Network-Manager nicht wie gewünscht automatisch gestartet ist.

Nach manuellen Starten des Network-Manager-Dienstes mittels

service network-manager start

funktionierten dann auch die Netzwerkverbindungen wieder.

Leider startete der Dienst beim Hochfahren nicht von alleine.

Eine Google-Suche brachte nur Hinweise darauf, dass die Datei /etc/network/interfaces evtl. falsche Einträge enthalte. Das tat sie bei mir nicht. Es standen lediglich die beiden Zeilen

auto lo
iface lo inet loopback

drin.

Ich habe dann festgestellt, dass lediglich das Upstart-Event „static-network-up“ aus irgendeinem Grund fehlte. Wenn ich nämlich im gestarteten System den Befehl

initctl emit static-network-up

aufrief, kam auch der Network-Manager hoch.

Nach einiger Zeit habe ich festgestellt, dass in der Datei /etc/init/networking.conf relativ weit am Anfang der Befehl „ifup -a“ aufgerufen wird, um die Netzwerkschnittstellen zu aktivieren.

Als ich ihn manuell ausführte, kam es bei mir allerdings zu einer Fehlermeldung, dass „bridge“ nicht aktiviert werden konnte (die genaue Meldung bekomme ich aus dem Gedächtnisprotokoll leider nicht mehr hin…).

Das Problem lag daran, dass im Ordner /etc/network/if-pre-up.d noch ein Symlink namens „bridge“ auf eine nicht mehr vorhandene Datei aus dem Paket „bridge-utils“ existierte, welches aber nicht (mehr?) installiert war.

Nach dem Löschen der fehlerhaften Verknüpfung klappt jetzt auch das Hochfahren des Rechners inklusive NetworkManager.

Man sollte also schauen, ob der Befehl

ifup -a

fehlerfrei durchläuft. Dann ist die Wahrscheinlichkeit hoch, dass auch das Upstart-Event „static-network-up“ emit-iert wird, woraufhin wiederum der NetworkManager automatisch startet.

PDF in Graustufen umwandeln

Folgender Befehl wandelt per GhostScript ein farbiges PDF in ein Graustufen-PDF um, um bspw. die Dateigröße etwas zu reduzieren:

gs -sOutputFile=output.pdf -sDEVICE=pdfwrite -sColorConversionStrategy=Gray -dProcessColorModel=/DeviceGray -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH input.pdf

StartSSL Zertifikate erneuern

Neues Certificate Signing Request erstellen (mit vorhandenem privaten Schlüssel)

openssl req -new -key ~/stephangsell.de.key -out ~/stephangsell.de.csr

Dann bei StartSSL den Inhalt der CSR-Datei hochladen und auf unterzeichneten Schlüssel warten.
Schlüsselinhalt in ~/stephangsell.de.crt speichern.

Folgende 3 Befehle sind nur beim ersten Mal notwendig, um eine gültige StartSSL-Zertifikatskette zu erzeugen

wget https://www.startssl.com/certs/ca.pem
wget https://www.startssl.com/certs/sub.class1.server.ca.pem
cat sub.class1.server.ca.pem ca.pem > startssl_alles.pem

UPDATE April 2016: Mittlerweile bekommt man bei StartSSL eine ZIP-Datei mit dem eigentlichen Zertifikat als .crt-Datei sowie einer Datei namens root_bundle.crt. Diese wird als ~/startssl_root_bundle.crt gespeichert.

Anschließend

cp ~/stephangsell.de.crt /etc/ssl/certs/ && cp ~/stephangsell.de.key /etc/ssl/private/
cp ~/startssl_root_bundle.crt /etc/ssl/pem/
cat ~/stephangsell.de.key ~/stephangsell.de.crt > /etc/ssl/pem/stephangsell.de.pem
cat /etc/ssl/pem/stephangsell.de.pem /etc/ssl/pem/startssl_root_bundle.crt > /etc/ssl/pem/stephangsell.de.startssl_alles.pem
systemctl restart apache2.service ; systemctl restart postfix.service ; systemctl restart dovecot.service 

owncloud + lighttpd: „413 – Request Entity Too Large“

Obiger Fehler führte dazu, dass in ownCloud keine größeren Dateien hochgeladen werden konnten.
Das Problem war leicht zu beheben, da nur der entsprechende Ordner fehlte, in dem lighttpd seine hochzuladenden Dateien zwischenspeichert.

Er wird so angelegt und anschließend schreibbar für den Benutzer www-data gemacht:

mkdir -p /var/cache/lighttpd/uploads
chown www-data:www-data /var/cache/lighttpd/uploads