VDR auf dem Seagate FreeAgent DockStar unter Arch Linux ARM

Wurde Arch Linux ARM gebootet und Zugang per SSH gewährt, sind noch einige Konfigurationsdateien anzupassen, hier in Kürze einige zuerst von mir vorgenommenen Einstellungen. Die /etc/fstab wurde bereits im Rahmen der Vorkonfiguration Abschnitt 2.3 editiert. Bei älteren Installationen notwendige Schritte zur Umstellung auf systemd habe ich im Abschnitt 7 zusammengefasst.

Soll die oben erwähnte Tastenkombination Strg+Alt+Entf den DockStar nicht neu booten, sondern lediglich herunterfahren (entsprechend systemctl poweroff) verlinkt man einfach das zugehörige Target neu.

Je nach Alter des Installationsmediums wird man bei dem erste Update ggf. mit einer Vielzahl an notwendigen manuellen Eingriffen konfrontiert. Die Vorgehensweise ist normalerweise bei den Upstream News dokumentiert, Stichwort manual intervention required. Auch nachdem das System komplett eingerichtet ist, sollte man es regelmäßig sichern, aktualisieren und warten, diesbezüglich finden sich im Wiki eine Reihe von wichtigen Hinweisen.

4.1 Virtuelle Datenträger

Verzeichnisse, deren Inhalt nach einem Reboot ohnehin gelöscht bzw. neu erstellt wird, können zur Schonung des USB-Sticks in den RAM verlagert werden. Dazu wird üblicherweise das Dateisystem tmpfs eingesetzt, das unter Arch Linux für die Verzeichnisse /tmp und /run Verwendung findet. Die ehemaligen Verzeichnisse /var/run und /var/lock sind seit einiger Zeit Links auf /run respektive /run/lock und somit ebenfalls im RAM verortet.

Das Einbinden des temporären Verzeichnisses /tmp erfolgt über eine Systemd mount unit /usr/lib/systemd/system/tmp.mount. Ein Eintrag in /etc/fstab ist optional, etwa um die Maximalgröße (Voreinstellung: 50% des RAM) zu reduzieren. Auch für das Verzeichnis /var/log nutze ich tmpfs, was sich insbesondere bei Einsatz eines Syslog Daemons wie syslog-ng empfiehlt.

Auf aktuellen Systemen erfolgt die Verwaltung des Systemlogs durch systemd-journald, folglich gilt syslog-ng als obsolet und ist nicht mehr vorinstalliert. Bei älteren Installationen wird man den Dienst normalerweise deaktivieren wollen, um Redundanz zu vermeiden.

Einsehen lässt sich das Journal mit journalctl, gespeichert wird es per Voreinstellung unter /var/log/journal/. Zur Verlagerung in den RAM ist es nicht notwendig /var/log/ als tmpfs zu mounten, systemd-journald stellt dafür eigene Optionen bereit.

Das Journal wird nun unter /run/log/journal/ angelegt, auf /var/log/ schreiben nurmehr Applikationen, die ihre Meldungen direkt dort ablegen, wie z.B. pacman.

4.2 Externe Festplatte

4.2.1 Verzeichnisse einbinden

Die eingangs erwähnte USB-Festplatte ist bereits mit Ext4 formatiert¹² und bleibt permanent angeschlossen. Sie wird deshalb wie der USB-Stick fest über /etc/fstab eingebunden. Neben ihrer eigentlichen Aufgabe als primäres Aufnahmeverzeichnis für den VDR (Abschnitt 6.4) nutze ich die Festplatte zur Erweiterung des Speicherplatzes für das Betriebssystem. Dazu werden Verzeichnisse auf der Festplatte mit der mount-Option --bind zusätzlich an geeigneter Stelle im Verzeichnisbaum eingebunden. Damit dennoch ein längerer Standby möglich bleibt, berücksichtige ich nur Verzeichnisse, auf die selten zugegriffen wird: Der Paket-Cache, das ABS-Wurzelverzeichnis (Abschnitt 4.3) sowie das /srv Verzeichnis. Letzteres beherbergt z.B. von HTTP- und (T)FTP-Server bereitgestellte Inhalte.

Alternativ wären natürlich auch symbolische Links oder ein Anpassung der Pfade in /etc/pacman.conf und /etc/abs.conf möglich. Die Paketdatenbank /var/lib/pacman/sync verbleibt auf dem Stick, andernfalls würde jeder Aufruf von pacman die Festplatte aus dem Standby holen. Die angegebenen Verzeichnisse müssen, falls nicht bereits vorhanden, vor dem Mounten natürlich angelegt werden.

4.2.2 Standby Timeout einstellen

Die von mir verwendete Festplatte geht nach 30 Minuten ohne Zugriff automatisch in den Standby, andere mit hdparm -S eingestellte Werte blieben ohne Wirkung. Um einen früheren Timeout herbeizuführen, wird also ein Programm wie hd-idle benötigt. Bei der Konfiguration nutzt man vorzugsweise die ID der Festplatte.

Mit systemctl enable hd-idle.service fügt man das Programm den beim Booten automatisch gestarteten Diensten hinzu. Bedarfsweise gelingt mit hd-idle -t oder hdparm -y auch ein unmittelbarer Spindown.

4.3 Paketverwaltung

Mit der Paketverwaltung des Systems sollte man, wie bei jeder Linux-Distribution, vertraut sein. Bei Arch Linux ist auch das Erstellen von Software-Paketen relativ leicht. In den folgenden Abschnitten mache ich davon mehrfach gebrauch ohne auf das Vorgehen im Detail einzugehen, deshalb hier ein kurzer Überblick mit obligatorischen Links zum Wiki.

4.3.1 Repositories und Quellpakete

Quellpakete haben die Dateiendung .src.tar.gz, können aber auch ungepackt in einer Verzeichnistruktur vorliegen. Sie sind dann von Interesse, wenn Pakete aus dem archlinuxarm-Repository angepasst werden sollen oder dort nicht vorhanden sind. Quellpakete kann man von Hand erstellen - Prototypen von PKGBUILDs befinden sich nach Installation von abs unter /usr/share/pacman/ -, meist wird man aber auf vorhandene Pakete zurückgreifen:

Einige Pakete aus dem AUR sind bei ALARM als Binärpakete verfügbar, können also direkt mit pacman installiert werden. Die Quellen befinden sich zusätzlich im Git-Repository.

4.3.2 Quellpakete kompilieren

Als Git- und Paketbauverzeichnis bietet sich wiederum die Festplatte an. Vor dem Kompilieren der ABS- und AUR-Pakete ist zumindest das arch-Array im PKGBUILD zu editieren, man kann es aber auch einfach mit der makepkg-Option -A ignorieren. Mitunter sind jedoch weitere Anpassungen an die ARM-Architektur erforderlich.

Da keine Swap-Partition angelegt wurde, macht sich insbesondere im letzten Schritt des Paketbaus, dem Komprimieren des Paketes, mitunter der begrenzte RAM bemerkbar¹³:

Zumeist genügt es dann Programme mit erhöhtem Bedarf an RAM (wie z.B. vdradmind, Abschnitt 6.3.1) vorübergehend zu beenden. Anschließend kann die Zusammenstellung und Komprimierung des betroffenen Paketes mit makepkg -Rf erneut veranlasst werden. Eine zusätzliche Maßnahme wäre die Verwendung einer Kompressionsart, die weniger Arbeitsspeicher beansprucht:

Wer die Möglichkeit dazu besitzt, verlagert die Rechenlast per Cross-Compiling auf einen oder mehrere leistungsfähige i686/x86_64-Rechner im Netzwerk¹⁴. Hier ist zu beachten, dass distcc einige Dateien unter /tmp ablegt, die ursprüngliche Beschränkung auf 8 MB erwies sich in diesem Zusammenhang als zu knapp bemessen, vgl. Abschnitt 4.1. Alle hier genannten Pakete habe ich auf dem DockStar aber auch ohne Cross-Compiling erstellen können, problematisch war dies nur im laufenden Betrieb.

4.4 Komprimierter RAM

Die Fehlermeldung bei erschöpftem RAM ist selten so eindeutig wie im vorherigen Abschnitt, oft werden Programme, deren Bedarf an RAM nicht gestillt werden kann, einfach beendet. Die Ursache findet man dann mit dmesg, hier z.B. bei einer abgebrochenen Datensicherung mit rsync:

Zwar könnte man in dieser Situation vorübergehend ein swapfile, vorzugsweise auf der USB-Festplatte, einrichten. Alternativ - oder zusätzlich - gibt es aber auch die Möglichkeit, den verfügbaren RAM besser auszunutzen: Dazu wird mithilfe des Kernelmoduls zram eine virtuelle Swap-Partition /dev/zram0 angelegt und eingebunden. Die in diesen Swap ausgelagerten Daten werden komprimiert und im RAM gespeichert. Die Swap-Partition beansprucht dabei jederzeit nur die den komprimierten Daten entsprechende Menge das RAMs. Im Endeffekt werden also umso mehr Daten im RAM komprimiert, je höher der tatsächliche Bedarf an RAM ist. Der Preis dafür ist eine erhöhte CPU-Belastung.

Das Anlegen und Einbinden des virtuellen Swaps übernimmt das im AUR verfügbare Paket zramswap Pro CPU wird ein zram-Device erzeugt - beim DockStar also eines -, die zusammen maximal eine 20% des RAMs entsprechende Menge an unkomprimierten Daten aufnimmt. Dieser Wert lässt sich über eine zusätzliche Servicedatei beeinflussen:

Mit systemctl daemon-reload wird die Änderung übernommen, systemctl enable zramswap.service fügt zramswap den beim Booten automatisch gestarteten Diensten hinzu.

4.5 Ansteuerung der LEDs

Die Steuerung der LEDs über das /sys-Verzeichnis erfordert root-Rechte, soll möglichst aber auch anderen Nutzern offenstehen. Der direkte Einsatz von sudo ist in diesem Zusammenhang etwas umständlich. Ich habe deshalb ein einfaches C-Programm geschrieben, das sich auf herkömmliche Weise mit sudo ausführen lässt. Auch kann es einfach innerhalb eines Scriptes genutzt werden, das seinerseits mit sudo aufgerufen wurde (Abschnitt 6.4). Das Programm wird mit gcc, der im gleichnamigen Paket enthalten ist, kompiliert:

Es manipuliert jeweils nur eine der beiden LEDs und ermittelt diese anhand des Namens, unter dem das Programm aufgerufen wurde. Deshalb werden zwei Dateien erstellt, die auf denselben Inode zeigen (Hardlink):

Ohne Parameter werden verfügbare Zustände und aktueller Status angezeigt. Als erster Parameter kann der gewünschte Status angegeben werden. Der Status timer benötigt zusätzlich die Parameter delay_on und delay_off, hier ein Beispiel:

Um die LEDs beim Herunterfahren zum Erlischen zu bringen habe ich folgenden Service implementiert.

4.6 Kompilierung des Kernels

Zur Zeit gibt es für mich keine Veranlassung einen angepassten Kernel zu erstellen: Das Aufs-Dateisystem wurde unlängst in den ALARM-Kernel integriert und seit der Berücksichtigung einer größeren Anzahl von DVB-Treibern in Version 3.1.10-11 läuft auch mein DVB-Stick von Freecom out of the box. Anhand eines anderen Sticks beschreibe ich in Abschnitt 5, wie man auch ohne Kernelkompilation an die neuesten DVB-Treiber gelangt.

4.6.1 Konfiguration

Wer eine Anpassung der Kernelkonfiguration vornehmen will, kann sich an den Artikel Kernel Compilation im Wiki halten. Das zu modifizierende Kernelpaket befindet sich jedoch nicht im ABS, sondern im Git-Repository, siehe Abschnitt 4.3, nachfolgend das zuletzt von mir verwendete, überarbeitete Paket. Anders als im ALARM-Kernel werden Patches und Quelldateien für das Aufs-Dateisystem direkt aus dem Aufs-Git-Repository heruntergeladen.

Um die Kompilierzeit zu reduzieren, verwende ich im PKGBUILD das make-Target localmodconfig. Es deaktiviert in der Kernelkonfiguration sämtliche Module, die momentan nicht geladen sind. Als Basis dient die Konfiguration des laufenden Kernels aus /proc/config.gz. Man sollte also vor Aufruf von makepkg sämtliche Hardware, die man nutzen möchte, anschließen (ggf. nacheinander) und in Betrieb nehmen, sowie Programme und Daemons starten, die auf Kernelmodule angewiesen sind (z.B. der NFS Server). Im Anschluss werden neu hinzugekommene Kerneloptionen einzeln abgefragt. Man kann hier die Vorgaben zunächst bestätigen und hat im letzten, durch make menuconfig ausgelösten Schritt Gelegenheit in einer textbasierten Oberfläche die Konfigurationen zu überarbeiten. Hilfe bei der Auswahl benötigter Optionen bietet das Buch Linux Kernel in a Nutshell insbesondere Kapitel 7. Ein daraus abgeleitetes praktisches Beispiel folgt auch in Abschnitt 5.1.

4.6.2 Installation

Ist der Kernel konfiguriert, bestätigt man das Speichern der .config-Datei. Nach dem Kompilieren entstehen die Pakete linux-custom und linux-custom-headers. Sie lassen sich parallel zu linux und linux-headers installieren, das Kernelimage befindet sich unter /boot/uImage-custom. Um dieses Image zu booten, kann man behelfsweise /boot/uImage damit ersetzen:

Sollte nach einem Reboot der eigene Kernel nicht starten, stellt man das ursprüngliche Image wieder her (den Stick dazu an einen anderen PC anschließen) und kann so wieder den offiziellen Kernel nutzen. Ein unbeabsichtigtes Überschreiben von /boot/uImage durch ein Update - pacman geht ja davon aus, das diese Datei zum Paket linux gehört - lässt sich mit der Option NoUpgrade vermeiden, die neue Datei wird dann mit der Endung .pacnew versehen. Alternativ kann man natürlich auch die Kernelpakete vom Update ausschließen:

Ein Reboot ist normalerweise nur dann notwendig, wenn im Rahmen eines Updates ein neuer Kernel installiert wurde. ↩
Externe Festplatten sind ab Werk zumeist mit NTFS formatiert. Schreiboperationen unter Linux sind mit ntfs-3g zwar möglich, gehen aber mit außerordentlich hoher CPU-Last einher. Der Versuch auf einem Pogoplug E02 eine NTFS-Partition als VDR-Aufnahmeverzeichnis zu verwenden endete mit regelmäßigem Überlauf des Puffers und folglich unbrauchbaren Aufnahmen. Mit einer Ext4-Partition ist dagegen auch ein Abspielen von laufenden Aufnahmen völlig unproblematisch. ↩
Wird bereits der Kompiliervorgang mangels RAM unterbrochen, sollte man - nach etwaigen Maßnahmen den RAM betreffend (Abschnitt 4.4) - makepkg fortan mit der Option -e aufrufen. Andernfalls wird der Quellcode jedesmal erneut entpackt und somit bereits kompilierte Teile der Software gelöscht. Zuvor kann man auch einen etwaigen ./configure-Schritt im PKGBUILD vorübergehend auskommentieren. Patches dürfen nicht erneut angewendet werden, sind also - sofern sie nicht separat innerhalb der neuen prepare()-Funktion zu Anwendung kommen - auszukommentieren, sinnvollerweise ebenso alle weiteren Schritte, die ein Löschen bereits erstellter Binaries nach sich zöge, wie z.B. die standardmäßige Neuerstellung des build-Verzeichnisses bei Paketen, deren Quellen aus Versionskontrollsystemen geladen werden. Letzteres lässt sich durch die seit Version 4.1 von pacman mögliche Angabe der VCS-Quelle im source()-Array bewerkstelligen. ↩
In Version 3.1-9 wurde unter Arch Linux User=nobody im distccd.service eingefügt. Die Option --user wird dadurch ignoriert. Für Arch Linux x86_64 steht ein Quellpaket distccd-alarm zur Verfügung, das auf die vorkompilierten crosstool-ng toolchains zurückgreift. Es erstellt separate Pakete für ARMv5/6/7-Toolchains mit jeweils eigenen Konfigurations- und Servicedateien für distccd.
```
[user@linux ~]$ git clone git://github.com/WarheadsSE/PKGs
[user@linux ~]$ cd PKGs/distccd-alarm/
[user@linux ~]$ makepkg
[user@linux ~]$ sudo pacman -U distccd-alarm-armv5-4.9.2-1-x86_64.pkg.tar.xz
```
Nach Anpassen von /etc/conf.d/distccd-armv5 kann der distccd-armv5.service gestartet werden. ↩