Nach einer Systemaktualisierung des Raspberry Pi Streamingclients mittels

[root@alarmpi ~]# pacman -Syu

sah im ersten Moment alles gut aus: das Update lief durch, “systemctl –failed” offenbarte keine neuen Baustellen und auch der zwischenzeitlich abtürzende gmrender-resurrect lief wieder wie geplant.

Ein Problem zeigte sich allerdings beim Abspielen des ersten Audio-Tracks: die Lautsprecher blieben stumm und “aplay -l” lieferte mit

[root@alarmpi ~]# aplay -l
aplay: device_list:268: no soundcards found...

den Hinweis, daß irgendetwas mit dem Treibern für den HiFiBerry nicht in Ordnung war.

Der entscheidende Tip kam vom HiFiBerry-Support innerhalb weniger Minuten in Form des “Configuring Linux 3.18.x-Guide”:

In January 2015, the Raspberry Pi kernel developers have decided to start using Linux 3.18.x. With this version a new way to load device drivers have been introduced to the Raspberry Pi environment. It is called device tree overlay. This brings big changes to the way how to configure the necessary drivers for the HiFiBerry boards.

Nach Einfügen der Zeile “dtoverlay=hifiberry-dac” in die Datei “/boot/config.txt” wurde der HiFIBerry wieder erkannt und die Soundausgabe funktionierte wieder.

Keine Ahnung, wie oft ich im Laufe der Jahre dem Windows 7-Assistenten zum Ermitteln der Probleme des Audiodienstes zugesehen habe …

… jedenfalls ist mir bis gestern noch nie aufgefallen, daß in der Titelzeile “Wiedergeben von Audiodataeien” steht.

So lobenswert die Stabilität von Debian im Serverbetrieb ist, für “das kleine Experiment zwischendurch” sind manche Programme in den offiziellen Repositories dann doch zu angestaubt. Als Alternative bietet es sich an, eine Sandbox auf Basis einer Rolling Release-Distribution zu installieren, die deutlich näher am Puls der Zeit ist, dafür aber vielleicht in Einzelfällen nicht ganz so fehlerfrei und stabil läuft.

Wer unter Windows 7 sowieso den virtuellen XP-Modus installiert hat, kann dafür die in diesem Fall bereits installierte Virtualisierungsumgebung verwenden.

Nach dem Download der offiziellen Installations-ISO wird eine neue virtuelle Maschine angelegt und die ISO als virtuelles CD/DVD-Laufwerk eingebunden. Als Basisdaten für die hier beschriebene Maschine wurde ein Hauptspeicher mit einer Größe von 768MB sowie eine dynamisch wachsende Festplatte mit einer Größe von 16GB gewählt.

Als Leitfaden für diesen Beitrag diente der “Beginner’s Guide” aus dem Arch Linux-Wiki, der auf die relevanten Stellen gekürzt bzw. um einige Informationen ergänzt wurde.

Weiterlesen

Auch wenn glücklicherweise nicht mehr in jedem zweiten “Ich optimiere mir mein Windows kaputt”-Beitrag zu Experimenten mit der MTU-Einstellung geraten wird, kann es trotzdem sein, daß je nach Netzwerkkonfiguration eine Änderung des aktuellen Werts notwendig ist. Wenn auch etwas “versteckt”, so kann dies problemlos mit Windows-Bordmitteln bewerkstelligt werden:

Im ersten Schritt muß die Netzwerkschnittstelle ermittelt werden, für welche die Einstellungen modifiziert werden sollen, was - genauso wie die spätere Änderung - mit dem Kommandozeilenprogramm “netsh” möglich ist.

C:\>netsh interface ipv4 show interfaces

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          50  4294967295  connected     Loopback Pseudo-Interface 1
 12          10        1500  connected     LAN-Verbindung

Die wichtigen Informationen finden sich in den Spalten “MTU” sowie “Name”, in denen zum einen die aktuelle Einstellung und zum anderen der Name der zu ändernden Verbindung ausgegeben wird.

Die Änderung erfolgt durch einen weiteren Aufruf von “netsh”, wobei darauf zu achten ist, daß dieser als Administrator ausgeführt wird.

C:\>netsh interface ipv4 set interface "LAN-Verbindung" mtu=1500 store=active

Der Text “LAN-Verbindung” muß ggf. durch den im ersten Schritt ermittelten Schnittstellennamen ersetzt werden, der Wert “1500” durch den neuen Schnittstellenwert und über den Parameter “store” lässt sich steuern, ob die neue Einstellung nur bis zum nächsten Systemstart (“active”) oder darüber hinaus (“passive”) behalten wird.

Debian gehört nicht zu den standardmäßig unterstützten Plattformen für den Betrieb des vSphere SDK for Perl. Damit es trotzdem läuft, sind ein paar kleine Anpassungen nötig:

Als erstes sollte die im Paket enthaltene und zur Installation verwendete Datei “vmware-install.pl” modifiziert werden, welche im Zuge der Installation das verwendete Betriebssystem ermittelt und somit auch die zu verwendenden Systemwerkzeuge festlegt.

Nach einem

vi vmware-install.pl

reicht es, nach dem String “ubuntu” zu suchen und dessen zweites Vorkommen durch “debian” zu ersetzen.

Anschließend müssen noch die fehlenden Pakete

Archive::Zip 1.28 or newer
Crypt::SSLeay 0.55 or newer
Class::MethodMaker 2.10 or newer
HTML::Parser 3.60 or newer
Data::Dump 1.15 or newer
SOAP::Lite 0.710.08 or newer
URI 1.37 or newer
XML::SAX 0.16 or newer
XML::NamespaceSupport 1.09 or newer
XML::LibXML::Common 0.13 or newer
XML::LibXML 1.63 or newer
LWP 5.805 or newer
LWP::Protocol::https 5.805 or newer

nachinstalliert werden, damit die benötigten Abhängigkeiten erfüllt sind, was ein

apt-get install libssl-dev libarchive-zip-perl libcrypt-ssleay-perl libclass-methodmaker-perl libhtml-parser-perl libdata-dump-perl libsoap-lite-perl libxml-sax-perl libxml-libxml-perl libtime-duration-parse-perl

erledigt. Debian konform sollten die ausführbaren Dateien im letzten Schritt statt nach “/usr/bin” in das Verzeichnis “/opt/bin” kopiert werden.