Keine Hardware-Beschleunigung bei VMWare und openSUSE Linux

Beim Start meiner virtuellen Maschinen unter openSUSE 13.2 mit dem VMWare-Player 6.0.6 habe ich immer folgende Meldung bekommen:

Hardware graphics acceleration is not availabe.

As a result, this virtual machine may experience very low graphics performance. Follow the instructions provided by your graphics card vendor or Linux distribution in order to update your computer’s OpenGL drivers.

Mein Rechner hat eine integrierte Intel HD Graphics 3000 und läuft mit MESA 10.3.7. Aber nicht das Updaten der MESA Treiber löst das Problem, sondern ein Editieren der *.vmx Datei mit einem beliebigen Texteditor. Am Ende fügt man einfach folgendes hinzu:

mks.gl.allowBlacklistedDrivers = „TRUE“

[Quelle: http://mysteriouscable.blogspot.de/2014/07/as-result-this-virtual-machine-may.html]

Und schon ist die Meldung weg 🙂

Wake-On-Lan mit Opensuse 13.1

Ich habe seit kurzem ein Cubieboard2[1] zuhause, auf dem meine ownCloud läuft. Und da ich nun einen permanent laufenden Rechner habe, dachte ich mir, ich richte meinen großen PC so ein, dass ich den zur Not auch mal remote hochfahren kann. Um z.B. tagsüber von unterwegs schonmal einen größeren Download anzuschmeissen, damit der fertig ist, wenn ich nach Hause komme. Und weil ich doch ein bisschen rumprobieren musste, fasse ich hier einfach mal alles kurz zusammen.

Als erstes muss man die richtigen Einstellungen im BIOS treffen. Mein Mainboard ist ein ASUS P8H67-M LX/SI, wo man im erweiterten Modus erst das APM Menü öffnen muss.
APM Menü in den erweiterten BIOS Einstellungen

Und dort aktiviert man dann „Einschalten durch PCIE“.
Wake-On-Lan aktivieren (PCIE)

Danach kommt die Einrichtung des Betriebssystems an die Reihe. Bei mir läuft Opensuse 13.1. Im Netz habe ich zwar recht schnell die nötige Einstellung per ethtool gefunden, doch das alleine hat nicht geholfen, der Rechner liess sich nicht aufwecken. Etwas weitere Recherche lieferte dann noch den Hinweis, über das SysFS das Wakeup für das entsprechende Gerät grundsätzlich zu aktivieren. Demzufolge habe ich dann diese beiden Zeilen ans Ende der /etc/init.d/boot.local geschrieben:

ethtool -s enp5s0 wol g;
echo enabled > /sys/class/net/enp5s0/device/power/wakeup

Wobei „enp5s0“ der Name des Netzwerkinterfaces ist (sonst üblicherweise „eth0“). Das „g“ im „ethtool“ Kommando bedeutet übrigens, dass das Aufwecken über ein sog. Magic Paket passiert.

Auf meinem Cubieboard habe ich mir dann folgende ausführbare Datei als /usr/local/bin/wake-desktop angelegt (die MAC Adresse gibt’s via „ifconfig enp5s0“)

#!/bin/bash
if [ $EUID -gt 0 ]; then
exec sudo „$0“
fi
etherwake -D bc:ae:c5:e1:8a:d9

und meinen User in die /etc/sudoers eingetragen

brack    ALL=NOPASSWD: /usr/local/bin/wake-desktop

Und nun kann ich mich z.B. von meinem Fairphone aus auf das Cubieboard einloggen (ich nutze JuiceSSH) und den Rechner aufwecken.

PC aufwecken per JuiceSSH

Anmerkungen:
[1]: über die Einrichtung des Cubieboards und der ownCloud darauf will ich auch noch bloggen, das kommt aber erst später. An dieser Stelle nur kurz der Hinweis, dass ich dieses Debian Wheezy (7.5) Image installiert habe und die fertigen ownCloud Pakete vom Opensuse Build Service nutze

KDE Update auf 4.7 hat eine Stolperfalle

Heute habe ich auf meiner Opensuse 11.4 ein Update auf KDE 4.7 gemacht, nachdem ich die Ankündigung der Fertigstellung bei heise.de gelesen hatte.

Flugs das KDE:/Release:/47 Repository zu den Paketquellen hinzugefügt und ein Dist-Upgrade auf dieses gemacht:

zypper dup –from KDE

Dabei fragte das Tool an, was mit dem Paket „k3b-codecs“ passieren sollte, von dem es für das 4.7er KDE wohl noch keine Entsprechung in den Paketquellen gab. Ich habe die Variante gewählt, das veraltete k3b Paket aus 4.6 zu behalten.

Der Rest lief easy, einmal abmelden und neu anmelden und schon lief KDE 4.7.

ABER: der Kalender war leer. Das hat mich etwas geschockt. Komischerweise liess sich in dem leeren Kalender auch nichts neu anlegen.

Ursache war, dass der Standardkalender nicht mehr selektiert gewesen ist. So wie im Screenshot muss es aussehen, nach dem Update war der Haken einfach nur weg.

Standardkalender aktiv gesetzt

Letztlich also kein Drama. Aber im Netz finden sich andere Hilfesuchende, die deswegen wohl schon ein Downgrade auf die 4.6 gemacht haben.

Der ganze Stress wäre nicht nötig, wenn beim Upgrade einfach dieser kleine Haken erhalten bliebe…

Intel Sandy Bridge Grafikfehler bei openSUSE 11.4 mit KDE 4.6

Bei einer frischen Installation von openSUSE 11.4 hatte ich unter KDE 4.6 einige hässliche Grafikfehler. Die obersten Einträge in den Ausklappmenüs waren unleserlich.

Irgendwie fehlten mir die passenden Suchbegriffe, erst nach 2 Tagen Recherche fand ich den korrekten Hinweis auf http://lslezak.blogspot.com/2011/04/installing-latest-intel-graphics-driver.html.

Es reicht, von der Intel-Seite den Treiber 2.15.0 herunterzuladen, zu kompilieren und zu installieren. Danach einmal X neu starten und alles ist super.

Auf der Intel-Seite hatte ich zwar auch schon geguckt, aber dort sind jede Menge Komponenten angegeben ohne eine klare Anleitung was man davon wirklich braucht und wie man’s installiert. In der Tat wollte ich nicht einfach per Trial and Error rumprobieren und womöglich X komplett zerschießen. Aber es ist ja gar nicht nötig.

Update openSUSE 11.0 auf 11.1 im laufenden Betrieb

Ich war ja früher immer etwas neidisch auf die Debian-Benutzer, bei denen es immer hiess, dass man so schön per apt-get auf eine neue Version der Distribution upgraden kann.

Aber was habe ich da vor kurzem in der c’t gelesen? Ab der 11.1 beherrscht zypper auch den Upgrade auf eine höhere Version im laufenden Betrieb. Da genau der Sprung von 11.0 auf 11.1 im Heft beschrieben wurde, den ich auch hätte machen können auf meinem Desktop (und weil die Update-Installation per DVD auf meinem Laptop von einer 10.0 auf 11.1 auch schon sehr stressfrei gewesen ist), hab‘ ich es dann mal riskiert.

Und so ging’s:

  • Alle repo-Dateien in /etc/zypper/repos.d von 11.0 auf 11.1 abändern
  • zypper ref repo-oss
    Um die neueste Version von zypper aus den 11.1er Repositories installieren zu können
  • zypper in zypper libzypp
    zypper tatsächlich aktualisieren
  • zypper ref
    Nun auch die anderen Repositories reinziehen (das gab vorher Fehlermeldungen)
  • zypper dup
    Das eigentliche Upgrade anstoßen

Das war’s dann auch schon. Zwei Konflikte wurden angezeigt, die sich manuell durch die Option lösen liessen, MozillaFirefox-branding-openSUSE und OpenOffice_org-branding-openSUSE zu deinstallieren.

Nicht ganz 2 Stunden und knapp 2 GB an Downloads später war alles durch. Reboot und gut. Das neue System nimmt übrigens 700 MB mehr Platz in Anspruch.

Wer viele Repositories eingerichtet hat und nich alle per Hand anpasssen möchte, dem hilft evtl. folgender Hinweis: einfach in /etc/zypper/repos.d ausführen

perl -pi -e 's/11.0/11.1/g'

Wer sich für die Update-Installation auf meinem Laptop interessiert, der lese bitte meinen Upgrade-Bericht.

dbus Session Daemon wird nicht gestartet

Nachdem ich vor kurzem ein frisches OpenSUSE 11 installiert hatte, gab es Probleme mit dem Programm beagle-search. Es meckerte, dass der dbus Session Daemon nicht liefe.

Diverse Suchen mit diversen Suchbegriffen lieferten immer nur Webseiten, auf denen entweder die Grundlagen von dbus beschrieben wurden oder wo jemand Probleme hatte mit dbus Daemons, die sich nicht mehr beendeten.

Geholfen wurde mir dann hier http://www.linuxforen.de/forums/showthread.php?t=257479

Dabei habe ich ein interessantes Feature kennengelernt: dass man ausführbare Skripte in ~/.kde/env benutzen kann, um Session-weite Umgebungsvariablen zu setzen. Das Verzeichnis kann man einfach anlegen, wenn es noch nicht existiert.