Resilient Raspberry Pi OS - der "unkaputtbare" Raspi #raspberrypi #x2go #kielux2026 #kielux

(Das ist mein Videobeitrag zum Kielux 2026 - aber mit etwas nachgebessertem Ton.) Hier geht es um diverse Hard- und Software-Tricks, wie man ein Raspberry Pi OS so installiert, dass es nahezu "unkaputtbar" ist. Dazu gibt es fertige Installationsskripte für Beispielanwendungen. Einige der Tricks sind gar nicht so neu - aber gefühlt vor über 20 Jahren wieder in Vergessenheit geraten. Wir beginnen mit der Auswahl eines geeigneten Speichermediums (Spoiler: keine MicroSD-Karten), hangeln uns durch den offiziellen Installer der Raspberry Pi Foundation, und biegen dann mit unserem Installationsskript noch vor dem ersten Start das erstellte Image nach unseren Vorstellungen um. Dabei nutzen wir Konzepte, die zum Teil noch aus alten, zu OS/2-Zeiten von IBM verfassten Redbooks stammen, aber auch heute auf dem Raspberry Pi noch (oder wieder) von Nutzen sind. Am Schluss hat man dann zum Beispiel einen kleinen Port-9100-Printserver, mit dem man seinen billigen USB-only-Drucker plötzlich netzwerkfähig machen kann, oder ein mailcow-, paperless-ngx-, oder eurooffice-Demo-Setup (die letztgenannten drei sogar mit Docker), oder die Entwicklungsbasis für Grannophone-Images, oder einen X2Go-Server oder -ThinClient, oder einen WLAN-Accesspoint (oder umgekehrt, einen WLAN-zu-LAN-Adapter für Geräte, die zwingend ein LAN-Kabel als Uplink erwarten) oder einfach nur eine Minimalinstallation, bei der die Eingabe von "sl" dazu führt, dass eine Dampflok als ASCII-Animation über die Konsole huscht, und die man als Basis für eigene Erweiterungen nutzen kann. Allen diesen Installationsvarianten ist gemein, dass sie einen ungeplanten Stromausfall zumindest soweit problemlos überleben, dass das Betriebssystem danach wieder startet und über SSH erreichbar ist (Services, die lokal Daten speichern müssen, wie z.B. Mailcow, brauchen ggf. manuelle Nacharbeit). Genauso hat man zu jedem eingespielten Update, wenn man sich an unsere Anleitung hält, immer eine automatisiert (z.B. per watchdog oder Startup-Skript) bzw. aus der Ferne auslösbare Fallback-Möglichkeit auf den vorherigen Stand. Der finale Clou: Hat man sich sowohl Produktionsumgebung als auch Fallback zerschossen, kommt man mit einem Hardwareschalter beim nächsten Neustart in eine Rettungsumgebung.