Suse verteilte auf der Susecon den Raspberry Pi 3 mit Suse-Logo und SLES © Computec Media GmbH

Das Chamäleon wagt den Sprung auf den Raspberry Pi: Mit SLES 12 Service Pack 2 und Open Suse Leap 42.2 offerieren die Nürnberger zwei Systeme für den 64-Bit-Modus der ARM-CPU.

In atemberaubendem Tempo eroberte der Raspberry Pi die Herzen. Im Raspberry Pi 3 kommt erstmals eine 64-Bit-CPU zum Einsatz, was einige neue Optionen eröffnet. Dazu zählt die quasi-native Unterstützung der Architektur durch den Linux-Vanilla-Kernel [1].

Vorbereitungen

Der Linux-Distributor Suse aus Nürnberg veröffentlichte im Rahmen der Hauskonferenz Susecon Ende 2016 sein aktuelles Server-Produkt SLES 12SP2 [2] für den Raspberry Pi 3 (Abbildung 1). Später folgte von der Open-Suse-Gemeinde das Heimanwender-Pendant [3] Leap 42.2 [4], das die Quellen von Suse Linux Enterprise (SLE) verwendet.

Open Suse Leap steht in verschiedenen Versionen auf den Servern des Projekts zum Herunterladen bereit [5]. Die Abbilder unterscheiden sich hinsichtlich des Paketumfangs und der Windowmanager. Minimalisten sei die Je-OS-Variante (Just enough Operating System) empfohlen. Wer es lieber grafisch mag, wählt zwischen dem Klassiker X, XFCE, LXQt oder Enlightenment E20.

Im Falle von SLES bedarf es eines Accounts im Suse Customer Center [6]. Damit ermöglicht Suse Zugriff auf die Software (Abbildung 2) und Updates für ein Jahr. Den dafür nötigen Code gibt es beim Herunterladen der Distribution. Danach landet das rund 1 GByte große Abbild auf dem heimischen Datenträger. Nach dem Entpacken folgt das Prozedere, es auf eine mindestens 8 GByte große Micro-SD-Karte zu kopieren.

Abbildung 2: Um SLES für den Raspi herunterzuladen, ist ein Account beim Suse Customer Center nötig.

In den Tests gab es Probleme mit einer per USB-Bluetooth-Adapter angeschlossenen Tastatur. Im Bootmenü funktionierte sie noch, bei aktiviertem Kernel nicht mehr. Ein Recherche im Suse-Forum für den Raspberry Pi führte schließlich zur Erklärung für das Tastaturproblem. Grund ist ein fehlender Kerneltreiber für die verwendete Tastatur. Damit die K400r von Logitech funktioniert, ist das Modul »hid_logitech_hidpp« nötig. Dies fehlt aber sowohl dem Install-Kernel als auch bei den ersten Updates (4.4.21-90). Anfang Februar gibt es bereits die Version 4.4.38-93 und diese enthält das notwendige Modul.

Ist der Kernel installiert und aktiviert, funktioniert auch die Tastatur wie erwartet. Das hilft natürlich nicht bei der Installation. Prinzipiell müsste der den Install-Kernel austauschen oder das passende Modul unterjubeln. Beides ist machbar, aber nicht unbedingt trivial. Die temporäre Verwendung einer USB-Tastatur, die anstandslos funktioniert, ist der deutlich einfachere Weg.

Die weitere Installation ging frei von Überraschungen über die Bühne. Dass es während der Installation immer wieder kleine Ruckler gab, lässt sich verzeihen, wenn man bedenkt, dass eine ausgewachsene Serverdistribution auf dem ARM-Zwerg läuft. Sowohl die Installation als auch die spätere Bedienung lassen sich aber als flüssig bezeichnen. Auch die Konfiguration des integrierten WLAN-Adapters funktionierte auf Anhieb.

Raspi-SLES im Detail

Im Betrieb verhält sich SLES auf dem Raspberry nicht anders als auf x86-Maschinen [7]. Nach dem Registrieren lassen sich Aktualisierungen für 365 Tage automatisch oder manuell herunterladen und installieren (Abbildung 3).

Abbildung 3: Ein im SCC registriertes Raspi-SLES-System bekommt Software-Aktualisierungen frei Haus.

Im Gegensatz zur offiziellen Distribution Raspian startet Suse den Linux-Kernel nicht direkt. Wie aus der x86-Welt bekannt, kommt Grub in der UEFI-Variante zum Einsatz, beim Hochfahren erscheint sogar die Meldung »Secure Boot is enabled«. Verschiedene Tests zur Laufzeit des Systems bekräftigen diese Aussage dann aber nicht: Weder die benötigten EFI-Dateien noch die Kernel weisen die obligatorischen Signaturen auf.

Wer auf Secure Boot gehofft hat, sollte also nicht mit dem Raspberry Pi rechnen. Dort funktioniert Secure Boot einfach nicht. Der Raspberry ist in diesem Fall als eine preiswerte Umgebung zum tatsächlichen Testen von Hardware-nahen Funktionen zu verstehen, die nicht mehr kostet als ein gutes Mittagessen.

Bootprozesse

Das Initiieren der UEFI-Umgebung übernimmt der Universal Boot Loader (U-Boot, [8]). Laut Aussagen von Suse-Entwicklern war es ein gehöriges Stück Arbeit, diese Kombination [9] zum Laufen zu bekommen. Doch der Aufwand der Entwickler hat sich gelohnt. Denn alles, was ab dem Bootloader Grub möglich ist, kann nun ebenfalls funktionieren – wenn es denn komplett auf Software beruht. Das gilt auch für den GNU-Bootloader selbst. Wenn Grub etwas starten kann und das prinzipiell für ARM verfügbar ist, dann sollte es auch auf dem Pi funktionieren. Die offensichtliche Einschränkung ist in diesem Fall, dass die Funktionalität für SLES und Open Suse überhaupt verfügbar ist.

Die Früchte dieser Leistung bilden das Fundament für eine weitere Besonderheit von Suse im Vergleich zu einigen anderen Raspberry-Distributionen: den Betriebssystemkern. SLES verwendet den Vanilla-Kernel. Das bedeutet, dass die Pflege eines Raspi-spezifischen Kernels komplett entfällt. Die daraus erwachsenden Vorteile liegen auf der Hand: Alle Prozesse, Methoden und Techniken für die Pflege, Wartung, Bereitstellung und das Testen von Enterprise-Kernen aus dem Hause Suse lassen sich 1:1 verwenden. Auf der Schattenseite findet man höchstens die limitierte Unterstützung von proprietären Protokollen oder Technologie-Implementierungen.

Der Rest der SLES-Geschichte auf dem ARM-Zwerg ist schnell erzählt. Als Dateisystem kommt der SLES-Standard Btr-FS zum Einsatz. Um die Leistung zu steigern, aktiviert Suse hier die Funktion »Kompression« (siehe Listing 1).

01 # mount |grep mmc
02 /dev/mmcblk0p3 on / type btrfs (rw,noatime,compress=lzo,ssd,space_cache,subvolid=257,subvol=/@)
03 /dev/mmcblk0p2 on /boot type ext3 (rw,relatime,data=ordered)
04 /dev/mmcblk0p1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

Anspruchsdenken

Die Tatsache, dass es ein Enterprise-Linux für den ARM-Zwerg gibt, kann zu falschen Erwartungen führen. Da wären Fragen wie: Funktioniert WoL (Wake on LAN) oder wie sieht es mit Suspend to RAM (S2R) aus. An dieser Stelle lohnt es, die ursprünglichen Anwendungsfälle noch einmal genau zu betrachten. Bei beiden ist das Sparen von Strom einer, wenn nicht der hauptsächliche Grund. Dies trifft für die “kräftigen” Computer im Rechenzentrum genauso zu wie für die leistungsfähigen Desktop-PCs im heimische Bereich.

Der geringe Energieverbrauch ist aber eines der bemerkenswerten Merkmale des Raspberry Pi. Damit stellt sich die Frage, ob WoL oder S2R hier Sinn ergeben. Die Hardware des Raspi hilft bei den Antworten. Die Netzwerkschnittstelle unterstützt kein Aufwachen übers Netzwerk, sie ist über den USB-Bus angebunden. Wenn der Pi aus ist, dann ist er aus. Die Netzwerk-Schnittstelle erhält keine Spannung, die ein Aufwachen über WoL ermöglichen würde.

Analoges gilt für die Stromsparmodi, die typischerweise unter dem Titel Powermanagement zusammengefasst sind. Berichte im Internet und die eigenen Larbortests lassen in dieser Hinsicht auf eine aussichtslose Mission schließen. Der ARM-Rechner verbraucht allerdings im Betrieb auch oft weniger Strom als so mancher hochgezüchtete Computer im Spar-Modus.

Open Suse auf dem Raspi 3

Obwohl SLES und Open Suse Leap auf dem gleichen Quelltext basieren, gibt es Unterschiede, nicht nur in den vorkonfektionierten Abbildern. Für einen korrekten Vergleich müsste es eine Leap-Version mit Ice-WM geben, der voreingestellten Variante für das SLES-ARM-Linux.

Auch auf der Kernel-Ebene finden sich Differenzierungen. SLES verwendet seit Anfang 2017 Kernel 4.4.21-90, Leap die Version 4.4.36-8. Beim Root-Dateisystem setzt der Community-Ableger auf Ext 4. Alle Funktionen, die auf der Snapshot-Funktion von Btr-FS beruhen, entfallen damit mehr oder weniger. Das verwundert, weil Ext 2, 3 und 4 im Suse-Lager nie viele Freunde fand. Selbst Red Hat, langjähriger Förderer der Ext-Dateisysteme, bevorzugt XFS.

Die Installation gestaltet sich bei Leap unspektakulärer. Schon das Beziehen der Software gelingt ohne Anmeldung und Aktivierung. Open Suse kategorisiert die Distribution als Appliance. Das Bestücken der Micro-SD-Karte erfolgt über das Kommando aus Listing 2.

01 # dd if=Image of=/dev/SD-Card bs=4M iflag=fullblock oflag=direct

Beim ersten Booten nimmt das System einige Änderungen vor, etwa das Anpassen der Partitionstabelle und das Aktualisieren des Linker-Cache. Ohne Benutzereingaben ist das System kurze Zeit später gebrauchsfertig. Für den Nutzer »root« lautet das eingestellte Passwort »linux«.

Fazit

Generell fühlt sich Leap im Betrieb etwas flüssiger an als SLES. Ein objektiver Vergleich fällt aber schwer: Dafür müsste man Kernel, Software-Paketumfang und auch die Fundamente beider Linux-Varianten entsprechend anpassen.

SLES auf dem Raspberry Pi dient primär der Förderung des Know-how und zu Testzwecken rund um das Enterpise Linux von Suse. Die Einstiegshürden dafür sind relativ niedrig. Der Interessent hat mit zwölf Monaten genügend Zeit, um zu testen, und bekommt Updates. Die Verwendung dedizierter Hardware schafft ideale Voraussetzungen für das Nichtbeinflussen der restlichen IT. Und es gibt ausreichend viele Verwendungsmöglichkeiten für den Raspi, wenn der SLES-Test einmal beendet ist.

Mit beiden beschriebenen Systemen lässt sich gut auf dem Raspberry Pi 3 arbeiten. Die Inbetriebnahme gestaltet sich bei Opens Suse Leap etwas schneller und einfacher, sowohl im Hinblick auf die Beschaffung der Software als auch auf deren Installation. Zudem ist die Zukunft von SLES auf dem Raspberry Pi derzeit noch ungewiss.