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! 😉

Leere Startseite nach Owncloud Upgrade auf Version 8

Index.php und index.html sind leer. Wirklich leer. Tatsächlich ohne Inhalt, 0 KB. Das ganze nach einem Upgrade von Version 7.0.4 auf 8.0.2. Nicht-PHP-Dateien wie COPYING-APL werden vom Apache ordentlich durchgegeben, sodass es zunächst nach einer per directory Misskonfiguration aussieht. Aber auch das kann nicht der Grund sein, es hat sich ja nichts geändert. Also in die .htaccess reingeschaut – sieht alles gut aus. Wie in Gottes Namen kann das also sein.

Und hier liest es sich dann. Eine Regression einer Abhängigkeit, welche für Core nicht mehr wichtig ist aber von essentiellen Apps wie Calendar und Contacts genutzt wurde, ist entfernt worden. Entsprechend ist es auch nötig, dass die Apps, die darauf zugreifen, zunächst aus dem apps Verzeichnis entfernt werden. Warum das der Owncloud Updater nicht selbst macht bzw. ein Update fährt erschließt sich mir nicht. Ebenfalls ist die Informationspolitik phänomenal schlecht. Zudem ist es strukturell ein Witz, dass Apps die gesamte Installation im Frontend abschießen.

Sei’s drum, nun geht es wieder zufriedenstellend. Übrigens lief Owncloud die ganze Zeit durch, denn Zugriff via remote.php wurde gegeben, was man an Synchronisierungen via Owncloud-App (Android, Linux) sehen konnte.