Category Archives: Linux

Mein Wechsel zu Arch Linux

Logo Arch Linux

Logo Arch Linux

Adieu Ubuntu – Welcome Arch Linux! Vor ein paar Tagen habe ich den Wechsel auf meinem Produktivsystem erfolgreich vollzogen und möchte gern meine Beweggründe und Erfahrungen mit Euch teilen.

Gründe für den Umstieg

Ich bin seit den 90ern treuer Linux-Fan (meine erste Distribution war SuSE 6.0) und nutze Ubuntu seit Erscheinen der Version 6.06 (Dapper) auf meinem Produktivsystemen, vorrangig als LTS (siehe auch mein früherer Post hierzu.) Auf meinen Servern kommt traditionell stets Debian zum Einsatz.

Bisher war ich mit Ubuntu stets sehr zufrieden, auch heute würde ich Ubuntu als Einsteigerfreundliche Distribution uneingeschränkt empfehlen. Ubuntu hat in den letzten Jahren sehr viel für die Linux-Community erreicht und eine Distribution geschaffen, welche einen problemlosen Umstieg von Windows auf Linux ermöglicht und sowohl Anfänger als auch Fortgeschrittene gleichermaßen zufriedenstellen kann.

In den vielen Jahren Ubuntu (meine zuletzt eingesetzte LTS-Version war 12.04) gab es allerdings einige Entwicklungen, die mich persönlich doch ein wenig störten. Canonical, die Firma hinter Ubuntu, löst sich vermehrt von Debian sowie Community-Standards und setzt in meinen Augen auf nicht immer nachvollziehbare Eigenentwicklungen, als heraus stechende Beispiele seien hier insbesondere der „Unity“-Desktop und die Entwicklung eines eigenen X-Servers „Mir“ als Ersatz für X.org genannt. Unity selbst finde ich persönlich gar nicht schlecht, es greift viele Konzepte auf, welche auch u.a. in OS X ihre Anwendung finden (beispielsweise das Globalmenue oder die Exposé-Funktion) und lässt sich intuitiv bedienen, wenn man sich einmal daran gewöhnt hat.

Was mich allerdings in den letzten Monaten vermehrt störte, war die mangelnde Aktualität der Softwarepakete – was beim Einsatz einer LTS-Version auch normal und durchaus erwünscht ist. Der Fokus liegt hierbei nun mal auf Stabilität: ein festgelegter Entwicklungsstand wird mit seinen Paketversionen zum Tag X eingefroren, als LTS-Fassung zur Verfügung gestellt (ggf. mit Anpassungen) und fortan nur noch mit Sicherheitsupdates versorgt. Neue Funktionen oder Verbesserungen fließen hierbei nicht ein. Ubuntu 12.04 enthielt beispielsweise Kernel 3.2, X.org 1.11.4 und Libre Office 3.5.2.

Hier gab es bereits die ersten Probleme. Der Kernel 3.2 bereitete auf meiner Hardwareplattform Schwierigkeiten (Soundchip & SSD-Controller wurden nicht erkannt), der enthaltene proprietäre NVIVIA-Treiber lag in einer veralteten Version vor und sorgte für diverse Grafikprobleme. Gut, dank des LTS Enablement Stacks ließ sich das Problem relativ schnell beheben, später fanden auch neuere NVIDIA-Treiber ihren Weg ins Repository, womit sich auch die Grafikprobleme lösten.

Doch was ist mit den Anwendungsprogrammen? Ich benötigte beispielsweise zur Erstellung meiner LaTeX-Dokumente eine halbwegs aktuelle TeX Live Distribution, doch in den Paketquellen ließ sich nur eine veraltete Fassung finden. Gleiches auch bei Libre Office – die Version 3.5 war mir für den täglichen Einsatz etwas zu angestaubt.

Kein Problem – für diesen Fall gibt es eine Vielzahl an Fremdquellen, sogenannte „Personal Package Archives“, kurz PPAs, welche die Installation neuerer Softwarepakete erlauben. Doch Fremdquellen haben den bitteren Beigeschmack, das sie die Stabilität eines LTS-Systems gefährden können und deshalb nicht ohne triftigen Grund verwendet werden sollten.

Doch am Ende kamen trotz sorgfältiger Auslese gut und gerne 10 Fremdquellen auf meinem System zum Einsatz, welche ein späteres Upgrade auf die nächste LTS-Version (spätestens 2017) aufgrund diverser Paketabhängigkeiten sehr wahrscheinlich unmöglich gemacht hätten. Doch das System lief trotz diesem Wildwuchs problemlos und hätte erst zum Supportende im Jahr 2017 ein Upgrade, respektive eine Neuinstallation verlangt.

Dann kam das neue LTS-Release 14.04 und bei mir die Überlegung zu einem Wechsel. Allerdings wusste ich bereits im Vorfeld, das ich auch mit 14.04 nicht an PPAs und einer Vielzahl manueller Nacharbeit vorbeikommen würde. Wollte ich das wirklich wieder? Dazu überzeugten mich die Neuerungen in 14.04 nicht sonderlich und würden den Aufwand einer Neuinstallation nicht rechtfertigen. Hier tat sich dann die Frage auf, ob Ubuntu für mich noch die richtige Distribution ist.

Entscheidungsfindung – Arch, Gentoo, Fedora, FreeBSD oder doch lieber Debian?

Doch wenn nicht mehr Ubuntu, welche Distribution dann? Fragen über Fragen – bei hunderten möglicher Distributionen fiel die Wahl nicht leicht. Nach dem Studium der meistgenutzten Distributionen und deren Philosophien blieben nach Abwägen der jeweiligen für mich relevanten Vor- und Nachteile Debian, Fedora, Gentoo und Arch übrig. Debian war für mich zunächst die erste Wahl (zumal ich es seit Jahren auf meinen Servern einsetze), gefolgt von Fedora, doch wollte ich diesmal möglichst aktuelle Softwarepakete auf meinem Produktivsystem. An diesem Punkt stellte sich für mich letztendlich die Frage, ob eine Snapshot-basierte Distribution mit festen Release-Zyklen die richtige Wahl für mich ist. Die Zweige Debian „testing oder „sid“ schieden aufgrund ihrer Nachteile für mich aus.

Das Konzept „Rolling Release“

Der Begriff „Rolling Release“ steht sinngemäß für „laufende Aktualisierung“. Ein Betriebssystem, welches das Konzept Rolling-Release anwendet, aktualisiert sämtliche Software-Pakete fortwährend. Betriebssystem und Anwendungsprogramme sind (je nach Distribution) somit stets auf dem aktuellen Stand der Entwicklung.

Dieses Konzept hat mich – zugegeben – recht neugierig gemacht. Stets ein aktuelles System samt Anwendungsprogrammen zu haben, ohne zu festen Zyklen den Aufwand einer Neuinstallation auf sich nehmen zu müssen, klingt zu schön um wahr zu sein. Hierzu kamen für mich zwei Distributionen in Frage, welche das Konzept des Rolling Release verfolgen: Gentoo und Arch.

Bei Gentoo, einer quellbasierten Distribution, dessen Pakete vor der Installation kompiliert werden müssen, schreckte mich allerdings der enorme Zeitaufwand des Kompilierens ab. Allein die Downtime und die Stromkosten, welche bei jedem mehrstündigen Libre Office Update durch das erneute Kompilieren aus dem Quelltext anfallen würde, stehen im keinen Verhältnis zum Nutzen. Also sollte es doch eine Distribution sein, welche Binärpakete anbietet, so fiel die Wahl auf Arch Linux.

Der Umstieg auf Arch Linux

Arch Linux verfolgt gegenüber Ubuntu einen anderen, minimalistischen Ansatz und eine etwas andere Philosophie. Es wurde als Basis-Betriebssystem für fortgeschrittene Anwender entwickelt und basiert auf den Grundsätzen:

  • Einfach halten, nicht überladen (KISS-Prinzip, „Keep it simple, stupid“)
  • Keine GUI-Werkzeuge zur Konfiguration verwenden, die die eigentlichen Vorgänge vor dem Benutzer verstecken

Der minimalistische Ansatz bietet die Möglichkeit, sich eine individuelle Systeminstallation ohne unnötigen Ballast zusammenzustellen. Ich war überzeugt, also war die Entscheidung gefallen.

Auf https://www.archlinux.de kann ein aktuelles Snapshot-Image zum Booten von CD oder USB-Stick bezogen werden. Der minimalistische Ansatz zeigte sich bereits nach dem ersten Start: Ich landete auf einem Bash-Prompt, von nun an war die Installation also meine Sache. Wer sich allerdings schon etwas mit Linux befasst hat und mit der Konsole ein wenig vertraut ist, sollte vor keine großen Schwierigkeiten stoßen, zumal das Wiki von archlinux.de eine sehr gute Anleitung bereitstellt, welche ich nur empfehlen kann: https://wiki.archlinux.de/title/Anleitung_für_Einsteiger.

Die Dokumentation der Wikis unter https://www.archlinux.org sowie https://www.archlinux.de ist wirklich hervorragend und bietet eine Vielzahl Hilfestellungen an, sollte man auf Probleme stoßen.

Die Installation und Konfiguration verlief nun Schritt für Schritt, binnen weniger Minuten war die Partitionierung und Formatierung der Festplatte sowie die Einrichtung des Bootloaders erledigt, ein paar Minuten später Netzwerk und Lokalisierung konfiguriert und die Grundinstallation samt X-Server und Gnome-Desktopumgebung erfolgt. Es macht wirklich Spaß zu sehen, wie das eigene System Stück für Stück entsteht, die Lernkurve ist hoch.

Anschließend erfolgte, wie bei jedem anderen Linux-System auch, die Installation von weiterer Paketen und Anwendungsprogrammen und abschließend die detaillierte Konfiguration. Übrigens: Wer wie ich apt als Paketmanager unter Debian/Ubuntu zu schätzen gelernt hat, wird das Arch-Pendant pacman lieben.

Hier seht Ihr das Ergebnis:

Screenshot Arch Linux

Screenshot Arch Linux


(Arch Linux 64-Bit unter Kernel 3.14.1 und Gnome 3.12.1)

Fazit

Ich bin wirklich begeistert. Was mich überrascht hat: Letztendlich benötigte ich für die Installation samt Konfiguration nicht länger, als ich bei Ubuntu benötigt hätte. Die meiste Zeit verschlingt meiner Ansicht nach grundsätzlich die individuelle Systemkonfiguration, egal ob diese unter Windows, Linux oder OS X erfolgt. Auf größere Probleme bin ich bisher nicht gestoßen, in Summe hat die Installation sogar Spaß gemacht.

Das finale System beinhaltet keinen unnötigen Ballast, da jegliche Software selbst ausgewählt und installiert wurde. Die Startzeit ab Auswahl im Grub-Bootmanager bis zum Loginprompt beträgt auf meinem System knappe 3 Sekunden, trotz identischer Zahl an Diensten deutlich schneller als unter Ubuntu. Meiner Einschätzung nach liegen die Gründe in der schlankeren Konfiguration sowie im Init-System systemd, welches Arch Linux verwendet.

Ansonsten wirkt Arch Linux unter Gnome 3 subjektiv betrachtet angenehm flott und „aus einem Guss“. Die aktuelle Software begeistert natürlich, eine Vielzahl Bugs, welche ich noch aus den älteren Softwareversionen unter Ubuntu 12.04 kannte, wurden in den neueren Fassungen behoben.

Die Aktualisierung des Systems wird innerhalb des Terminals mittels des Befehls pacman -Syu vorgenommen – einfach und effizient.

Natürlich darf man bei Rolling Releases nicht vergessen: Ein solches System benötigt Pflege. Die stetige Aktualität des Systems erfordert hin und wieder einen gewissen Wartungsaufwand bei Aktualisierungen – dies ist der Preis, den man dafür zahlt. Mir persönlich sind allerdings ein paar Minuten manuelle Konfiguration bei größeren Aktualisierungen lieber, als der immense Zeitaufwand einer vollständigen Neuinstallation. Allerdings sind die wenigen händischen Eingriffe, welche hin und wieder bei tiefgreifenden Veränderungen des Systems vorgenommen werden müssen, auf den jeweiligen Webseiten von Arch Linux sehr gut dokumentiert.

In Summe hat mich diese Distribution überzeugt – künftig werde ich also ein wenig mehr aus dem Blickwinkel von Arch Linux berichten.

Ubuntu-Distributionen und neue Kernel-Versionen

logo-ubuntu_su-orange-hex Die beliebte Linux-Distribution Ubuntu wird in zwei Varianten angeboten, einmal als Short Term Support (STS) und als Long Term Support (LTS). Neue Releases der STS erscheinen alle 6 Monate und werden ab Version 13.04 für 9 Monate unterstützt. LTS-Releases erscheinen alle 2 Jahre und werden ab Version 12.04 über einen Zeitraum von 5 Jahren unterstützt.

Die Qual der Wahl

Welche Variante man wählt, hängt von den eigenen individuellen Bedürfnissen ab:

  • STS-Versionen bieten aktuellere Softwarepakete und somit teils neue Funktionen gegenüber den LTS-Varianten, haben allerdings den Nachteil des relativ kurzen Supportzeitraums von 9 Monaten hinsichtlich Fehlerkorrekturen und Sicherheitsupdates. Somit eignen sie sich primär für den Einsatz auf Desktops und erfordern nach Ablauf des Supportzeitraums ein Upgrade auf die nächsthöhere Version oder (besser) eine Neuinstallation.
  • LTS-Versionen sind auf Stabilität und lange Supportzeiträume ausgelegt und eigenen sich sowohl für den Server- als auch Desktopbetrieb. Die Softwarepakete sind nicht so aktuell wie bei den STS-Versionen, dafür ist erst nach 5 Jahren ein Betriebssystem-Upgrade auf die nächste LTS-Version erforderlich. Wer aktuelle Softwareversionen (wie z.B. von LibreOffice) benötigt, kann diese recht einfach über Backports oder PPAs aktualisieren.

Ich persönlich bevorzuge generell LTS-Versionen, auch auf meiner Workstation. Hauptsächlich aufgrund des langen Supportzeitraums – eine Systemeinrichtung und Individualisierung kostet auch unter Linux etwas Zeit. Das ist etwas, was ich nicht alle 6-9 Monate machen möchte – dafür fehlen mir schlichtweg Zeit und Nerven. Dazu kommt, das ich die STS-Releases eher als „Beta“-Versionen der LTS-Fassungen sehe – manches STS-Release war nach meiner Erfahrung hin und wieder schlichtweg nicht so ausgereift, um es als zuverlässiges Arbeitssystem nutzen zu können.

Das heißt nicht, das STS-Versionen generell schlecht sind – wer Neuerungen ausprobieren möchte und dem es nichts ausmacht, alle 9 Monate eine größere Systemaktualisierung / Neuinstallation auf sich zu nehmen, der kann mit einer STS-Version durchaus glücklich werden. Weitere Infos zu den Unterschieden zwischen beiden Varianten findet man im Ubuntuusers-Wiki.

LTS – Kernel & X11

Wer sich für eine LTS-Version entschieden hat, nutzt in der Standardinstallation im Regelfall gegenüber den STS-Releases etwas ältere Kernel- und X-Server-Versionen, bei Ubuntu 12.04 „Precise Pangolin“ sind dies beispielsweise Kernel 3.2 und X-Server 1.11.4.

Dies kann über den sehr langen LTS-Unterstützungszeitraum von 5 Jahren durchaus problematisch sein – beispielsweise wenn man neue Hardware einsetzen möchte, die dem vorliegenden älteren Kernel noch nicht bekannt sein dürfte. Um den Hardwaresupport zu verbessern, werden mit den Point Releases seit 12.04.2 bei einer Neuinstallation zurückportierte neuere Versionen des Kernels und des X-Servers aus jüngeren Ubuntu-Versionen als Standard verwendet – allerdings nur bei einer Neuinstallation eines Point Releases. Bestehende LTS-Installationen werden nicht automatisch aktualisiert. Die Firma hinter Ubuntu, Canonical, definierte diese Aktualisierungsmethode als „LTS Enablement Stack-Support“.

Wenn die bestehende Installation incl. der verwendeten Hardware problemlos läuft und neu implementierte Funktionen innerhalb des Kernels nicht benötigt werden, ist ein Wechsel der Kernelversion normalerweise nicht erforderlich. Benötigt man hingegen neuere Versionen von Kernel, X-Server und MESA, lassen sich diese auch bei einer bestehenden LTS-Installation einfach nachinstallieren.

Welche Versionen dies sind, lässt sich anhand folgender Tabelle nachvollziehen:

Ubuntu-Version

Kernel

Xserver-Core

MESA

Backport aus STS-Version

12.04

3.2

1.11.4

8.0.4

12.04.2

3.5

1.13.0

9.0.3

Quantal (12.10)

12.04.3

3.8

1.13.3

9.1.7

Raring (13.04)

12.04.4

3.11

1.14.5

9.2.1

Saucy (13.10)

Um beispielsweise die LTS Enablement Stacks aus dem derzeit aktuellen Point Release 12.04.4 zu installieren, nutzt man folgende Zeile:

sudo apt-get install --install-recommends linux-generic-lts-saucy xserver-xorg-lts-saucy libgl1-mesa-glx-lts-saucy
sudo update-grub

Im Regelfall werden die benötigten Abhängigkeiten problemlos aufgelöst. Bei mir traten wider Erwarten ein paar Abhängigkeitsprobleme auf – ich vermute, das diese Tatsache aus einer vorhergehenden Aktualisierung resultierte. Ich konnte diese beheben, nachdem ich das Paket xserver-xorg-lts-quantal entfernt hatte:

sudo apt-get autoremove xserver-xorg-lts-quantal
sudo apt-get install --install-recommends linux-generic-lts-saucy xserver-xorg-lts-saucy libgl1-mesa-glx-lts-saucy
sudo update-grub

Wichtig:

Auch wenn es sich um stabile Point Releases handelt, rate ich dennoch zur Vorsicht und zu einem vorherigen Backup. Im schlimmsten Fall führt die Aktualisierung zu einem nicht mehr startenden System und den damit verbundenen händischen Korrekturen. Hier rate ich zunächst, das entsprechende Point Release mittels einem Live-Medium (DVD/USB-Stick) vorab auf Hardware-Inkompatibilitäten zu testen.

Sollte der neue Kernel nach der Aktualisierung des Hauptsystems zu Problemen führen (System startet nicht), kann im Grub-Bootmenü unter „Previous Linux versions“ der vorherige Kernel ausgewählt werden. In einem solchen Fall kann ein Kernel aus dem nächst niedrigeren Point Release installiert und getestet werden, beispielsweise Kernel 3.8 aus dem Point Release 12.04.3.

Sicherung der Partitionstabelle

partitionmanager

Backups – leidiges, aber essentiell wichtiges Thema. Schnell ist es passiert: Ein Datenträger ist plötzlich defekt, ein unvorsichtiger Löschvorgang, Datenverluste durch Systemfehler… die Liste der möglichen Szenarien ist lang. Also sichert man seine Dateien, Datenbanken, manche fertigen sogar Images ihrer kompletten Datenträger oder Partitionen an. Doch eine Kleinigkeit wird dabei oft vergessen: Die Partitionstabelle. Gerade dann, wenn man seine Datenträger in mehrere Partitionen aufgeteilt hat und/oder mehrere Betriebssysteme nutzt, wäre es im Schadensfall nicht verkehrt zu wissen, wie man seine Datenträger mal partitioniert hatte und die ursprüngliche Partitionierung einfach wiederherstellen könnte.

Einfach realisieren lässt sich dies unter Linux, hierzu lässt sich auch jedes Live-Medium verwenden.

Mittels fdisk -l lässt sich eine Übersicht der Datenträger und Partitionen erstellen:

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 Köpfe, 63 Sektoren/Spur, 14593 Zylinder, zusammen 234441648 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0xb95c5516

Gerät boot. Anfang Ende Blöcke Id System
/dev/sda1 * 2048 206847 102400 7 HPFS/NTFS/exFAT
/dev/sda2 206848 119539711 59666432 7 HPFS/NTFS/exFAT
/dev/sda3 119539712 132122623 6291456 82 Linux Swap / Solaris
/dev/sda4 132122624 234441647 51159512 83 Linux

Doch ist diese zur Wiederherstellung zwar hilfreich, aber nicht optimal. Mittels

sfdisk -d /dev/sda

lässt sich eine kompakte Übersicht der Start- und Endsektoren und des Partitionstyps erzeugen:

# partition table of /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 204800, Id= 7, bootable
/dev/sda2 : start= 206848, size=119332864, Id= 7
/dev/sda3 : start=119539712, size= 12582912, Id=82
/dev/sda4 : start=132122624, size=102319024, Id=83

Diese lässt sich zwecks Backup mittels

sfdisk -d /dev/sda > parttable_sda

in eine Datei schreiben und per

sfdisk /dev/sda < parttable_sda

sehr einfach wiederherstellen.

Solid-State-Drives & TRIM

drive-harddisk

Solid-State-Drives (SSDs) bieten viele Vorteile gegenüber konventionellen Festplatten: Niedrige Zugriffszeiten, hohe Datenübertragungsraten, mechanische Robustheit, keine Geräuschentwicklung und niedrigerer Stromverbrauch. Ich nutze seit zwei Jahren eine SSD als Systemlaufwerk, sowohl unter Windows 7 als auch Linux – die Geschwindigkeitsvorteile sind enorm.

Bei SSDs sind ein paar Besonderheiten zu beachten, wie z.B. das korrekte Alignment bei der Partitionserstellung, doch heute möchte ich auch das Kapitel TRIM näher eingehen.

Was ist TRIM?

Nach dem Löschen von Daten auf dem Speichermedium vermerkt das Betriebssystem im Regelfall nur innerhalb des Dateisystems, welche Datenbereiche für neue Daten genutzt werden können. Physikalisch bleiben die Daten erhalten und werden quasi nur zum Überschreiben freigegeben.

TRIM ein ATA-Befehl des Betriebssystems, welcher dem Laufwerk nach dem Löschen mitteilt, welche Datenbereiche nicht mehr verwendet werden. Für den Controller einer konventionellen Festplatte ist diese Information eher weniger wichtig, doch anders sieht es für den Controller eines SSD-Laufwerk aus. Denn ohne diese Information hält dieser die gespeicherten Blöcke weiter vor, anstelle sie als ungültig zu markieren. Die Folge sind Performanceverluste beim Schreibzugriff sowie höhere Abnutzung des SSD-Laufwerks. TRIM ist also für SSDs von essentieller Bedeutung.

Nun die gute Nachricht: Die meisten aktuellen Betriebsysteme unterstützen die TRIM-Funktion – ein manueller Eingriff ist im Regelfall nicht erforderlich.

TRIM unter Linux

Seit Kernel 2.6.33 unterstützt Linux die TRIM-Funktion. Allerdings werden zwei Möglichkeiten angeboten: Batched Discard (manuell auszuführen) oder Online Discard (automatisch durch den Kernel). Mehr hierzu unter SSD-TRIM – Wiki-Ubuntuusers.de. Welche Methode nun die bessere ist, darüber streiten sich die Gelehrten.

Batched Discard muss manuell von Zeit zu Zeit ausgeführt werden (auch automatisiert per Cronjob möglich) – die Laufzeit des Befehls ist abhängig von der gelöschten Datenmenge seit dem letzten Aufruf. Der Befehl hierzu lautet: sudo fstrim -v / ## oder sudo fstrim -v /home. Der Parameter -v gibt die Anzahl der getrimmten Bytes aus.

Online Discard wird per discard-Option in den Mountoptionen der fstab definiert, erfordert keine manuellen Eingriffe und sendet den TRIM-Befehl nach dem Löschen einer Datei – dies könnte u.U. die Performance bei Löschvorgängen reduzieren.

Ich persönlich nutze die Methode des Online Discards und habe bis heute keinerlei Probleme feststellen können. Für welche Methode man sich entscheidet, ist letztendlich Geschmackssache.

TRIM unter Linux testen

Ob TRIM wie gewünscht funktioniert, lässt sich unter Linux mit ein paar Befehlen recht einfach testen, hierzu empfehle ich folgenden Artikel bei Ubuntuusers – SSD-Trim testen.

(Zweiter) Monitor wird nicht erkannt

computer Diesmal wieder ein umfangreiches Tutorial 🙂

Auf meiner Workstation nutze ich eine NVIDIA GeForce GTX 470 mit zwei per DVI angeschlossenen Monitoren, einen 24″ Samsung als Primärbildschirm und einen alten 19″ HannsG HX191D als Sekundärbildschirm. Diese Kombination lief lange Zeit problemlos – bis vor ein paar Wochen.

Wie Sie sehen, sehen Sie nichts!

Auf meiner Dual-Boot-Installation führte ich unter Windows 7 ein Treiberupgrade der GeForce-Treiber auf die Version 334.89 durch. Nach einem Reboot wurde der sekundäre Monitor (HX191D) nicht mehr erkannt, kurz flackerte ein Bild auf, danach blieb das Device tot und wurde nicht mehr erkannt. Die anschließende Fehlersuche gestaltete sich als schwieriges Unterfangen, es ließen sich keinerlei Hinweise auf eine Fehlfunktion feststellen – Windows wollte den Monitor nur partout nicht mehr ansprechen. Irgendwann gab ich es auf und installierte wieder die vorherige Treiberversion.

Fehlersuche unter Linux

supertux

In der Hoffnung, einen Hinweis auf die Treiberproblematik zu finden, durchsuchte ich unter Linux die Logfiles:

sudo cat /var/log/Xorg.0.log

Hier fand sich etwas, was mich stutzig machte:

[ 1243.044] (WW) NVIDIA(GPU-0): Ignoring EDID checksum for display DFP-2. Note that an EDID
[ 1243.044] (WW) NVIDIA(GPU-0): with a bad checksum could indicate a corrupt EDID. A
[ 1243.044] (WW) NVIDIA(GPU-0): corrupt EDID may have mode timings beyond the capabilities
[ 1243.044] (WW) NVIDIA(GPU-0): of your display, and could damage your hardware. Please
[ 1243.044] (WW) NVIDIA(GPU-0): use with care.

DFP-2 bezeichnete den Monitor HX191D – eine defekte EDID-Prüfsumme?

Was ist die EDID?

media-flash

Bei der EDID (Extended Display Identification Data) handelt es sich um eine 128-Byte-Datenstruktur, welche innerhalb des Displays in einem PROM oder EEPROM abgelegt ist. Diese enthält Informationen über Hersteller, Fertigungsdatum, Dimensionen des Displays, Pixel Mapping Data etc. Die Daten werden über den I²C-Bus vom Monitor an die Grafikkarte übertragen, diese Kombination von EDID und I²C nennt sich DDC2 (Display Data Channel Version 2). Der Grafiktreiber interpretiert diese Daten, um passende Auflösungen und Frequenzen zu bestimmen, welche ansonsten manuell definiert werden müssten.

Auslesen und Überprüfen der EDID

utilities-log-viewer

Da der Treiber im Logfile eine defekte EDID-Prüfsumme beim HX191D ermittelt hatte, verstand ich auch die Problematik unter Windows. Der neue Treiber konnte die EDID-Werte des Monitors nicht sauber interpretieren und schaltete als Vorsichtsmaßnahme das Signal zu diesem Monitor ab. Um meine Theorie zu beweisen, ging es erst mal daran, die EDID auszulesen. Hierzu kann man die Pakete read-edid und edid-decode verwenden:

sudo apt-get install read-edid edid-decode

Mittels get-edid können die Werte ausgelesen werden, die Augabe lässt sich mittels get-edid > dateiname.bin auch in eine Datei schreiben. Über parse-edid oder edid-decode kann die EDID ausgewertet werden.

Also: sudo get-edid | parse-edid

Ich habe die Ausgabe auf die relevanten Einträge gekürzt:

Your EDID is probably invalid.
parse-edid: EDID checksum failed - data is corrupt. Continuing anyway.
parse-edid: first bytes don't match EDID version 1 header
parse-edid: do not trust output (if any).

Ein sudo get-edid | edid-decode ergab noch detailliertere Ausgaben:

get-edid: get-edid version 2.0.0

Performing real mode VBE call
Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
Function supported
Call successful

VBE version 300
VBE string at 0x11100 "NVIDIA"

VBE/DDC service about to be called
Report DDC capabilities

Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
Function supported
Call successful

Monitor and video card combination does not support DDC1 transfers
Monitor and video card combination supports DDC2 transfers
0 seconds per 128 byte EDID block transfer
Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called
Read EDID

Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
Function supported
Call failed

The EDID data should not be trusted as the VBE call failed
EDID claims 255 more blocks left
EDID blocks left is wrong.
Your EDID is probably invalid.

Extracted contents:
header: ff ff ff ff ff ff ff ff
serial number: ff ff ff ff ff ff ff ff ff ff
version: ff ff
basic params: ff ff ff ff ff
chroma info: ff ff ff ff ff ff ff ff ff ff
established: ff ff ff
standard: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
descriptor 1: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
descriptor 2: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
descriptor 3: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
descriptor 4: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
extensions: ff
checksum: ff

No header found
Manufacturer: ___ Model ffff Serial Number 4294967295
Made week 255 of model year 255
EDID version: 255.255
Digital display
Maximum image size: 255 cm x 255 cm
Gamma: 1.0
DPMS levels: Standby Suspend Off
Supported color formats: RGB 4:4:4, YCrCb 4:4:4, YCrCb 4:2:2
Default (sRGB) color space is primary color space
First detailed timing is preferred timing
Supports GTF timings within operating range
Established timings supported:
720x400@70Hz
720x400@88Hz
640x480@60Hz
640x480@67Hz
640x480@72Hz
640x480@75Hz
800x600@56Hz
800x600@60Hz
800x600@72Hz
800x600@75Hz
832x624@75Hz
1280x768@87Hz
1024x768@60Hz
1024x768@70Hz
1024x768@75Hz
1280x1024@75Hz
1152x870@75Hz
Standard timings supported:
2288x1372@123Hz
2288x1372@123Hz
2288x1372@123Hz
2288x1372@123Hz
2288x1372@123Hz
2288x1372@123Hz
2288x1372@123Hz
2288x1372@123Hz
Detailed mode: Clock 655.350 MHz, 4095 mm x 4095 mm
4095 5118 6141 8190 hborder 255
4095 4158 4221 8190 vborder 255
+hsync +vsync interlaced
Detailed mode: Clock 655.350 MHz, 4095 mm x 4095 mm
4095 5118 6141 8190 hborder 255
4095 4158 4221 8190 vborder 255
+hsync +vsync interlaced
Detailed mode: Clock 655.350 MHz, 4095 mm x 4095 mm
4095 5118 6141 8190 hborder 255
4095 4158 4221 8190 vborder 255
+hsync +vsync interlaced
Detailed mode: Clock 655.350 MHz, 4095 mm x 4095 mm
4095 5118 6141 8190 hborder 255
4095 4158 4221 8190 vborder 255
+hsync +vsync interlaced
Has 255 extension blocks
Checksum: 0xff (should be 0x7f)
EDID block does not conform at all!
Block has broken checksum
Manufacturer name field contains garbage

Wie die Ausgabe beschreibt, einhält die EDID meines HX191D „garbage“ – also Müll. Der Treiber kann die Ausgabe also nicht interpretieren – es bleibt dann nur, die Werte manuell zu vergeben (unter Windows via INF-Datei, unter Linux innerhalb der xorg.conf) oder den Monitor zu entsorgen, was aber auch nicht Sinn der Sache sein kann.

Lösung: Ersetzen der EDID-Informationen

Variante 1: Hardwareprogrammierung

media-flash

Man kann eine fehlerhafte EDID ersetzen, indem man die Binärinformationen eines fehlerfreien ROMs in das EEPROM des Monitors schreibt. Hierzu benötigt man neben einem passenden Binärfile auch entsprechende Spezialsoftware und ein programmierbares EEPROM im betroffenen Monitor. Besitzt der Monitor ein PROM, hat man Pech gehabt. Da ich nicht sagen kann, ob der HX191D ein EEPROM besitzt, ist eine Hardwareprogrammierung fraglich, zumal ich auch keine Software dazu nennen kann.

Variante 2: Treiber-/Softwarelösung (empfohlen)

preferences-other

Besitzt man eine passende EDID-Binärdatei (EDID-ROM), kann man dem Treiber vermitteln, das er diese Informationen anstelle der Hardwareinformationen verwenden soll. Diese Lösung ist praktikabel, ich gehe in den nächsten Absätzen darauf ein.

EDID beschaffen

Für beide Varianten benötigt man erst mal eine geeignete EDID-Binärdatei. Besitzt man zufälligerweise einen baugleichen Monitor ohne fehlerhafte EDID, kann man dessen Informationen unter Linux mittels get-edid > dateiname.bin in eine Datei schreiben. Unter Windows ist dies mit dem EDID Manager möglich. Ich war in der glücklichen Situation, das meine Frau ebenfalls einen HX191D als Zweitbildschirm nutzt und dessen EDID nicht fehlerhaft war – so konnte ich die Daten einfach auslesen und nutzen.

dialog-warning

Hat man diese Möglichkeit nicht, lässt sich mittels Software eine EDID erzeugen, z.B. mittels dem EDID Manager für Windows. Doch die Befüllung der Daten erfordert ein großes Maß an technischem Hintergrundwissen und die genauen technischen Daten des Monitors – fehlerhafte Werte können zur Zerstörung des Monitors führen! Für die Ermittlung der korrekten Werte helfen die technischen Daten des Monitors innerhalb der Betriebsanleitung und ggf. weitere Recherchen im Internet.

Eigene EDID verwenden – Vorgehensweise unter Linux

supertux

Liegen die EDID-Informationen nun in einer Binärdatei vor, speichert man diese idealerweise im Verzeichnis /etc/X11 und nimmt die EDID-Konfiguration innerhalb der xorg.conf vor. Der NVIDIA-Treiber besitzt dafür eine Option „CustomEDID“, welche wir nun in den Abschnitt „Device“ aufnehmen:


Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "GeForce GTX 470"
Option "CustomEDID" "DFP-2:/etc/X11/HX191D.bin"
Option "NoLogo" "True"
EndSection

Nach einem Neustart des X-Servers wird die neue Konfiguration übernommen.

Eigene EDID verwenden – Vorgehensweise unter Windows

winecfg

Die Konfiguration der Monitor wird innerhalb der Windows-Registry vorgenommen, hier benötigt man eine entsprechende INF-Datei, welche im Regelfall der Hersteller mitliefert. Sollte dies nicht der Fall sein, lässt sich mittels des Programms Monitor Asset Manager aus der vorliegenden EDID-Binärdatei eine passende INF-Datei erzeugen. Hierzu wird die EDID-Binärdatei geladen und mittels „Save INF“ als INF-Datei abgelegt.

Anschließend im Windows Geräte-Manager den entsprechenden Monitor-Eintrag doppelklicken, auf die Registerkarte „Treiber“ wechseln und die Schaltfläche „Treiber aktualisieren“ anklicken. Dann „Auf dem Computer nach Treibersoftware suchen“ und „Aus einer Liste von Gerätetreibern auf dem Computer auswählen“ und „Durchsuchen“ wählen. Nun wählt man die vorhandene INF-Datei aus, nach einem „Öffnen“, „Weiter“ und „Fertigstellen“ wird diese installiert und steht zur Verfügung. Weitere (Windows-spezifische) Informationen können unter Overriding Monitor EDIDs with an INF nachgelesen werden.

Ich hoffe, das dieses Tutorial bei auftretenden EDID-Problemen hilfreich sein wird.

Datum in Unixzeit konvertieren

Auf vielen Systemen spielt die sogenannte Unixzeit eine tragende Rolle, denn diese wird zur Verarbeitung von Zeitwerten innerhalb von Zeitstempeln des Dateisystems, Datenbanken und Server-Anwendungen wie z.B. PHP und MySQL verwendet.

Die „Unixzeit“ wurde 1969 als einfache Zeitdefinition für das Betriebssystem Unix entwickelt und als POSIX-Standard festgelegt. Seit Unix Version 6 bezeichnet die Unixzeit die Anzahl der vergangenen Sekunden seit dem 1. Januar 1970 00:00 Uhr UTC (Schaltsekunden werden nicht mitgezählt).

Diese Zeitdefinition bietet den Vorteil, das sie von Computersystemen als vorzeichenbehaftete Ganzzahl (Integer) einfach verarbeitet werden kann. Zeiträume lassen sich durch simple Addition oder Subtraktion leicht berechnen.

Mehr zum Thema: Wikipedia-Unixzeit

Unter den meisten Unix-basierten Systemen (wie auch Linux) lässt sich die Unixzeit mittels des Befehls date ausgeben und auch in das lokale Datumsformat konvertieren.

Aktuelle Unixzeit ausgeben

date +%s

Bestimmtes Datum/Uhrzeit in Unixzeit konvertieren

date -d "2014-02-24 13:00" +%s

Unixzeit in Datum/Uhrzeit konvertieren

date -u -d @UNIXZEIT

Beispiel:
date -u -d @1234567890
Fr 13. Feb 23:31:30 UTC 2009

dpkg: Pakete von der Aktualisierung ausschließen

Paketaktualisierungen in Debian-basierten Systemen wie z.B. Ubuntu sind im Regelfall problemlos und schnell erledigt. Meistens jedenfalls. Nicht jedoch, wenn bestimmte Paketupdates zu Problemen führen – dann wünscht man sich die Möglichkeit, bestimmte Pakete (erst mal) von der Aktualisierung auszuschließen.

Upgrade unerwünscht

Über die Kommandozeile lässt sich das Vorhaben problemlos in die Tat umsetzen:

Paket-Aktualisierung sperren

echo <Paket> hold | dpkg --set-selections

Sperre aufheben und Updates wieder freigeben

echo <Paket> install | dpkg --set-selections

Liste mit gesperrten Paketen anzeigen

dpkg --get-selections | grep hold

Hintergründe: Upgrades und ihre Tücken

Vor einiger Zeit wurde mir aus den offiziellen Quellen ein Upgrade des NVIDIA-Grafiktreibers vorgeschlagen; dieser brachte die neue Version 319.32 mit sich. Das Upgrade lief sauber durch, ein anschließender Neustart ergab plötzlich ein ein nicht mehr startendes System.

Fehlersuche

Im Failsave-Mode ergab ein Blick in /var/log/syslog folgendes:

NVRM: API mismatch: the client has the version 319.32, but
NVRM: this kernel module has the version 304.88. Please
NVRM: make sure that this kernel module and all NVIDIA driver
NVRM: components have the same version.

Eine weitere Analyse mittels

dkms status

ergab schließlich:

nvidia-304-updates, 304.88, 3.5.0-39-generic, x86_64: installed
nvidia-319-updates, 319.32, 3.5.0-39-generic, x86_64: installed

Was war passiert? Das alte Kernel-Modul Version 304 wurde beim Upgrade nicht entfernt und führte zu einem Versionskonflikt, wie man am Auszug aus /var/log/syslog ersehen kann. Bis ich allerdings auf diese Ursache kam, war bereits einige Zeit an Fehlersuche vergangen – an doppelte Module hatte ich zunächst nicht im Traum gedacht und zunächst nur im Xorg.log nachgeschaut, welches mir aber keinen Aufschluss auf die Ursache geben konnte.

Fehlerbehebung

Manuelle Deinstallation aller Komponenten des alten Treibers 304 mittels:

apt-get remove nvidia-304*

und ein anschließendes

update-grub

Nach einem Reboot lief anschließend alles wieder einwandfrei.

Weitere Probleme…

Eine ganze Weile später meldete sich die Paketaktualisierung mit einem weiteren Upgrade des NVIDIA-Grafiktreibers. Diesmal lief alles reibungslos, allerdings zeigten sich im laufenden Betrieb Probleme mit der Erkennung des zweiten Monitors resultierend aus (urplötzlich) fehlerhaften DDC/EDID-Werten. Sich häufende Bugreports zu dieser Treiberversion führten dann zu der Entscheidung, auf die vorherige Treiberversion zu wechseln und erst mal bei dieser zu bleiben.

Audioformat in Videodatei ändern

Basierend auf meinem letzten Blogeintrag DVD-Sammlung archivieren mit Handbrake noch eine kleine praktische Ergänzung.

Bei der Archivierung meiner DVDs in MP4-Container habe ich die originale Audiospur im Format „AC3 5.1“ beibehalten. Sollte man mit diesem Audioformat auf bestimmten Abspielgeräten (wie z.B. dem iPad) Probleme bekommen, ist keine erneute Konvertierung des gesamten Videos erforderlich. Ich habe dies so gelöst, das ich eine weitere Kopie der betreffenden Videos in einem separaten Ordner erzeugt und die Audiospur in das Format „AAC“ konvertiert habe.

Unter Linux mit installierten ffmpeg bzw. Libav sowie Codecs (siehe Artikel bei Ubuntuusers Libav, avconv und Codecs) ist diese Aufgabenstellung überhaupt kein Problem. Ein simpler Einzeiler konvertiert die Audiospuren aller Videodateien im aktuellen Verzeichnis und legt die neuen Videodateien in einem separaten (existierenden) Verzeichnis ab:

for f in *.*;do avconv -i "$f" -f mp4 -vcodec copy -acodec libvo_aacenc -ab 160k -ar 48000 -ac 2 /home/arndt/Video/AAC-Format/"${f%.*}".mp4;done

Suchen und Ersetzen in Dateien

Vor einiger Zeit musste ich bei der Überarbeitung einer Webpräsenz in sämtlichen PHP-Dateien eine bestimmte Zeichenkette durch eine andere ersetzen. Da es sich hierbei aber um eine recht große Zahl handelte, wäre eine manuelle Bearbeitung jeder Datei recht mühsam gewesen. Also was tun?

Hier hilft auf der Konsole der Befehl find in Kombination mit sed (stream editor) weiter:

find . -name "*.php"|xargs sed -i "s#TextAlt#TextNeu#g"

Somit wird diese Aufgabe zu einer Sache von Sekunden.

Vor der Anwendung möchte ich ergänzend empfehlen, für den Fall der Fälle eine Backup-Kopie der betreffenden Dateien anzulegen, da die bestehenden Dateien in jedem Falle überschrieben werden.

iPhone-Fotos nach dem Aufnahmedatum benennen

Und wieder etwas für die Freunde der Konsole 😉 Beim Sortieren meiner iPhone-Fotos suchte ich nach einer Möglichkeit, diese bequem anhand des Aufnahmedatums zu benennen und fand diese mit dem ExifTool.
Wie auch das iPhone, legt mittlerweile jede handelsübliche Digitalkamera zusätzliche Informationen wie Datum, Uhrzeit, Brennweite, Belichtungszeit, Blende, GPS-Koordinaten (wenn verfügbar), etc. in Form von Exif-Metadaten innerhalb der Bilddatei ab. Diese Metadaten können von Bildverarbeitungsprogrammen ausgelesen und weiterverarbeitet werden und eignen sich somit hervorragend für mein Vorhaben.

Beim ExifTool handelt es sich um ein Perl-Modul, welches ein zusätzliches Kommandozeilen-Werkzeug zum Lesen und Schreiben der Metainformationen beinhaltet. Hierzu muss das Paket libimage-exiftool-perl installiert werden; unter Debian-basierten Systemen (wie beispielsweise Ubuntu) geschieht dies mittels

apt-get install libimage-exiftool-perl

Zum Umbenennen aller Dateien im aktuellen Verzeichnis nach dem Aufnahmedatum (wofür ich hier den Wert „CreateDate“, also das Erzeugungsdatum verwende) kommt nun das ExifTool zur Anwendung:

exiftool -P '-FileName<CreateDate' -d %Y-%m-%d_%Hh%Mm%S.%%e ./*

Dieser benennt nun die Dateien nach folgendem Schema: 2013-12-09_16h31m15.JPG