06/2017

Know-how

Kernel- und Treiberprogrammierung mit dem Linux-Kernel – Folge 92

Kern-Technik
Kern-Technik

74
www.linux-magazin.de

Viele Schreibzugriffe und hartes Stromabschalten mögen Flashspeicher gar nicht gerne. Wer der SD-Karte sei-
nes Raspberry Pi ein langes Leben schenken und Anwendungen und Anwender trotzdem nicht reglementieren
will, garniert sein Himbeertörtchen mit einem Overlay-Filesystem. Hier die Backanleitung. Eva-Katharina Kunst, Jürgen Quade

über den PC einfach land und mit den Applikationen treten

auf die SD-Karte zu Schreibzugriffe auf – und das nur, wenn
transferieren, und das es explizit passieren muss. Beispielsweise
im Vergleich zur Fest- legen Unix-Systeme für jede Datei drei
platte reduzierte Spei- Zeitstempel ab: den Erzeugungszeitpunkt
chervolumen erweist (Creation), den Zeitpunkt der letzten Än-
sich für kaum einen derung (Modification) und den des letz-

92
Einsatzzweck als zu ten Zugriffs (Access).
gering. Jedes Lesen einer Datei löst daher einen
Wer aber länger und Schreibzugriff auf den zugehörigen Zeit-
häufiger mit einem stempel aus – eigentlich, denn die Linux-
Raspberry Pi arbei- Entwickler haben diese Abhängigkeit vor
tet, diesen vielleicht einigen Jahren zurückgefahren und aktu-
sogar im 24/​ 7-Be- alisieren standardmäßig den Zugriffszeit-
trieb nutzt, bekommt stempel nur beim allerersten lesenden Zu-
eine eingeschränkte griff. Das Verhalten bekommt der Kernel
Zuverlässigkeit des beim Mounten eingeimpft (Tabelle 1).
Speichermediums zu
© psdesign1, Fotolia

spüren. Robuste Systeme

Die klassische Festplatte ist ein Auslauf-
modell, kein Zweifel. Noch punktet sie
mit ihrem Preis und üppigem Speichervo-
lumen, doch den ungleich besseren Zu-
griffszeiten der Flashspeicher hat die
Festplatte nichts entgegenzusetzen.
Hinzu kommt die mechanische Anfällig-
keit ihrer bewegten Teile. Smartphones,
Tablets oder die Gruppe der Microcompu-
ter à la Raspberry Pi setzen schon jetzt
rein auf Flash, Letzterer in Form von
leicht handhabbaren SD-Karten. Das Be-
triebssystem für den Minicomputer ist
Flashspeicher kämp-
fen auch 2017 mit
einer limitierten Zahl
von Schreibzyklen. Linux reagiert auf
diese Problematik mit Flash-optimierten
Spezial-Dateisystemen, zum Beispiel
F2fs. Damit lässt sich tatsächlich bei
SSDs eine hohe Zuverlässigkeit errei-
chen. Mit den (billigen) SD-Karten, auf
denen klassisch die alten Dateisysteme
(Ex)-FAT und Ext 4 liegen, ist das nicht
so. Da gibt es keinen besseren Schutz, als
Schreibzugriffe komplett zu meiden oder
wenigstens zu minimieren.
Für Linux ist das prinzipiell kein Prob-
lem. Der Kernel selbst muss zunächst nur
lesen. Erst in Kombination mit dem User-
Für Systeme, die weitgehend unbeauf-
sichtigt laufen, reicht das Reduzieren
von Schreibzugriffen jedoch nicht aus.
Wer sein Internet-of-Things- oder Indus-
trie-4.0-Gerät schützen will – der Fach-
mann spricht von Ruggedizing –, hängt
die Dateisysteme nur lesend ein [1]. Al-
lerdings mucken einige nun schreibge-
hemmte Applikationen auf und verwei-
gern den Betrieb.
Auch der Ansatzpunkt, die SD-Karte zu
partitionieren und die kritische Boot- und
Rootpartition nur lesend, eine unkritische
Homepartition für die Applikationen zu-
sätzlich schreibend einzuhängen, führt
nicht zum Ziel. Hier funkt die Hardware

Die Autoren Tabelle 1: Einfluss des Mount-Kommandos auf den Zugriffszeitstempel

Eva-Katharina Kunst ist seit den Anfängen von Mount-Option Verhalten
Linux Fan von Open Source. Jürgen Quade ist
»relatime« Das erste Lesen nach einem Write aktualisiert den Zeitstempel.
Professor an der Hochschule Niederrhein. Ihr
»noatime« Der Zeitstempel wird nie aktualisiert.
gemeinsames Buch „Linux-Treiber entwickeln“
»atime« Bei jedem Lesen wird der Zeitstempel aktualisiert.
ist Ende 2015 in vierter Auflage erschienen.

des Flashspeichers quer: Das so genannte
Wear Leveling macht nämlich nicht vor
Partitionsgrenzen halt und tauscht Sek-
toren zwischen den Partitionen, um eine
gleichmäßige Verteilung der Schreibzu-
griffe zu erreichen.
Für ein zuverlässiges System geht also
kein Weg an einem rein lesenden Zugriff
vorbei. Folglich sind die Schreibzugriffe
umzulenken, beispielsweise auf einen
zweiten Flashspeicher (USB-Stick) oder
eben – falls ausreichend vorhanden – auf
den Hauptspeicher. Für Letzteres bietet
der Linux-Kernel gleich zwei Techniken:
Erstens das Initram-FS [2] und zweitens
das in der letzten Kern-Technik vorge-
stellte Overlay-Filesystem [3].
Filesysteme im RAM
Der Initram-FS-Ansatz benötigt den
Flashspeicher nur während des Boot-
prozesses, um den Kernel und ein Root-
Filesystem in den Speicher zu schubsen
(Abbildung 1). Das Root-Filesystem ist
als Initram-FS ausgeprägt, das sämtliche
Dateien und Verzeichnisse im Hauptspei-
cher abbildet. Ein klassisches Dateisys-
tem wie Ext 4 gibt es nicht mehr, der
Kernel greift ohne Umwege besonders
effizient auf die Daten zu.
Der einzige Nachteil besteht im limitier-
ten Platzangebot des Hauptspeichers.
Systeme mit komplexen grafischen Ober-
flächen oder umfangreichen Datenban-
ken sind so nicht realisierbar. Wer jedoch
sein System selber baut, etwa mit Hilfe
von Buildroot [4], schafft zudem noch
den Raum, um einen einfach handhabba-
ren Update-Mechanismus zu etablieren.
Allerdings gehen bei Stromausfall neue
Daten verloren und solche, die sich zwi-
schenzeitlich geändert haben.
Für komplexere Systeme ist der Hybrid-
Ansatz geeignet. Dann liegen die Daten
wie bisher auf dem Flashspeicher, schrei-
bende Zugriffe fängt aber ein Overlay-
Filesystem ab, die geänderten Daten lan-
den entweder auf einem Filesystem im
Hauptspeicher (Abbildung 2) oder auf
einem USB-Stick (Abbildung 3).
Wer im Internet nach Anleitungen zur
Realisierung sucht, wird zwar schnell
fündig (zum Beispiel [5]), ist bei der
Umsetzung aber selten erfolgreich [6].
Die saubere Integration in den Bootpro-
zess ist nicht trivial. So ist vor dem ers-
Root-Filesystem im Hauptspeicher
»/boot«
RAM
SD-Karte »/boot«
Abbildung 1: Schlanke Selbstbau-Linuxe können beim Hochfahren ihr Root-Filesystem komplett in den Haupt-
speicher kopieren.
ten schreibenden Zugriff für das Mission-
critical-Rootverzeichnis auf die SD-Karte
ein Overlay nötig. Eine funktionierende
Lösung in Form eines Skripts stammt
ursprünglich aus den Entwicklerhänden
von Axel Heider und ist unter [7] zu
finden, die Installation beschreibt der
Kasten „Overlay auf dem Raspberry Pi
einrichten“ detailliert.
Booten im Hauptspeicher
Um das Overlay vor dem ersten schrei-
benden Zugriff aufzusetzen, kommt das
bereits erwähnte Initram-FS als Sprung-
brett zu Ehren. Das für den Raspberry
Pi noch zu generierende Initram-FS legt
der Raspberry-Besitzer – wie den Kernel
auch – auf der Bootpartition der SD-Karte
ab, und der Bootvorgang wird ihn vom
Bootloader in den Hauptspeicher trans-
ferieren.
Der Kernel startet aus dem im Hauptspei-
cher liegenden Initram-FS das Programm
»init«. Dies lädt normalerweise die wich-
tigsten Treiber, schaltet auf das auf der
Festplatte beziehungsweise auf der SD-
Karte liegende Orginal-Root-Filesystem
um und mutiert schließlich zum dort
abgelegten (Standard-)Init.
Drei Root-Filesysteme
Für ein robustes (ruggedized) System
klinkt sich das vorgestellte Setup in den
ersten Initprozess ein, und zwar nach-
dem Init – wie es seine Art ist – das Root-
Filesystem ohnehin erst einmal read-only
eingehängt hat. Init startet danach das
Skript »root‑ro«, welches nach Auswer-
tung der Bootparameter das Overlay-
Filesystem etabliert. Da das Skript mit
06/2017
Know-how
Kern-Technik
»/«
»/« Initram-FS
75
www.linux-magazin.de
»/«
290 Zeilen fürs Abdrucken zu groß ist,
reflektiert Listing 1 nur die entscheiden-
den (Mount)-Kommandos zum Anlegen
des Overlay.
Zum besseren Verständnis des kompli-
zierten Vorgangs sollte man wissen, dass
drei (Root-)Dateisysteme beteiltigt sind:
Als erstes das zum Bootzeitpunkt aktive
Root-Filesystem des initialen RAM-File-
systems, als zweites das Root-Filesystem
auf der SD-Karte, auf das nur lesende Zu-
griffe erlaubt sein sollen, und als drittes
das Overlay-Filesystem, das aus Sicht des
laufenden Betriebssystems das eigentli-
che Root-Filesystem werden wird.
Das Skript »root‑ro« erzeugt dazu nach
Auswertung der Bootparameter im (noch
aktiven) Init-Filesystem ein Verzeichnis
als Mountpoint für das Filesystem auf
der SD-Karte (»/mnt/root‑ro/«) und ein
Verzeichnis als Mountpoint für das neue
Overlay-Filesystem (»/mnt/root‑rw/«).
Da das Initsystem die SD-Karte bereits
mit lesendem Zugriff eingehängt hat, ver-
schiebt das Kommando
mount ‑o move /root /mnt/root‑ro
Overlay-FS im RAM
»/«
RAM »/« Overlay
SD-Karte »/«
Abbildung 2: Wer ein System mit Speicher-genügsa-
men Applikationen betreibt, fährt oft gut mit einem
Overlay im RAM.
 06/2017
Know-how

den Mountpoint der SD-Karte auf das Overlay auf USB-Stick

neu kreierte Verzeichnis »/mnt/root‑ro/«
Kern-Technik

(Listing 1). Dieses Verschieben macht »/«

den Weg frei, um das Overlay auf das
von Init verwendete Verzeichnis »/root/«
für die SD-Karte umzuhängen. Ab diesem USB-Stick »/« Overlay
Zeitpunkt würden schreibende Zugriffe
76 auf das Root-Filesystem bereits im Haupt-
www.linux-magazin.de

speicher landen (Abbildung 4).

RAM »/boot« »/« Initram-FS

Trick mit der Fstab

Problematisch ist allerdings, dass Init
nach getaner Arbeit in der ersten Stufe
das Init-Filesystem wieder freigibt und als
neues Root-Filesystem das Verzeichnis
»/root/« verwendet. Bei der Freigabe fal-
len damit aber auch die von »root‑ro«
dort angelegten Verzeichnisse »/mnt/
root‑ro/« und »/mnt/root‑rw/« weg. Da-
her muss das Skript sie vorher noch nach
»/root/« verschieben, also in das neue
Temp-Filesystem (siehe Kasten „Tempo-
räres Filesystem“).
Jetzt gilt es, den weiteren Bootverlauf
anzupassen, denn Linux wird gemäß
»/etc/fstab« – die steuert beim Bootpro-
zess das Einhängen der Dateisysteme –
die Rootpartition von der SD-Karte lesend
SD-Karte »/boot«
Abbildung 3: Für komplexe Systeme, auch für Raspbian, eignet sich der Ansatz, das Overlay auf einem
USB-Stick abzulegen.
und schreibend mounten. Der Trick, um
das zu verhindern: Im Overlay schreibt
das Skript die Fstab neu und modelt bei
der Kopie den Eintrag für die Rootparti-
tion (»/dev/mmcblk0p2«) auf read-only
um (Abbildung 5).
Jetzt funktioniert’s
Mit diesen Änderungen ist die eigentli-
che Arbeit erledigt und das System kann
»/«
normal hochfahren. Dazu gehört, dass
das vom Initram-FS vorbereitete Root-
verzeichnis »/root/« per Kommando
»switch_root« zum neuen, letztgültigen
Wurzelverzeichnis (»/«) wird und dass
Linux dank modifizierter Fstab das Root-
Filesystem der SD-Karte auch nur read-
only einhängt (beziehungsweise es ein-
gehängt bleibt).
Das vorgestellte Setup mountet die
Bootpartition »/dev/mmcblk0p1« (auf

Listing 1: »
 root‑ro« (modifizierter Overlay auf dem Raspberry Pi einrichten
Auszug)
Falls noch nicht geschehen, installiert der cd /etc/initramfs‑tools/scripts/U
[...]
01  Raspi-Besitzer Raspbian (in der Version »2017 init‑bottom
02 ROOT_RO=/mnt/root‑ro ‑03‑02‑raspbian‑jessie«) auf eine SD-Karte. wget https://gist.github.com/niun/U

03 ROOT_RW=/mnt/root‑rw Außerdem richtet er das System ein, indem er 34c945d70753fc9e2cc7/raw/3d60338cd8d8U

04 ROOT_RW_UPPER=${ROOT_RW}/upper n das Passwort mit dem Kommando »passwd« daf740692f426a5a1ec17839d613/root‑ro

05 ROOT_RW_WORK=${ROOT_RW}/work
für den Default-User »pi« ändert, chmod +x root‑ro
n den SSH-Server per »raspi‑config« akti-
06 rootmnt=/root
viert, Danach geht es weiter mit dem Generieren
[...]
07  des Initram-FS:
n die Systemsoftware aktualisiert: »apt‑get
08 
mount ‑t tmpfs tmpfs‑root ${ROOT_RW}
update; apt‑get dist‑upgrade« und update‑initramfs ‑c ‑k $(uname ‑r)
[...]
09 
n eventuell einen neuen User anlegt und mit
10 
# root is mounted on ${rootmnt}, move it to Admin-Rechten ausstattet (»adduser login- Das Initram-FS ist damit zwar gebaut, liegt
${ROOT_RO}. name; adduser loginname sudo«). aber noch im Bootverzeichnis »/boot/« unter
11 
mount ‑o move ${rootmnt} ${ROOT_RO} Nun loggt sich der Benutzer in das vorbereitete einem unhandlichen Namen. Der Aufruf
[...]
12  System ein und wird durch Eingabe von »sudo mv initrd.img‑$(uname ‑r) initrd7.img
13 
# mount virtual fs ${rootmnt} with rw‑fs ${ROOT_RW} su« zum Superuser. Jetzt geht es ans Konfek-
tionieren des Initram-FS: benennt es daher um. Der letzte Schritt vor
on top or ro‑fs ${ROOT_RO}.
n Damit der Kernel das Modul »overlay« lädt, dem Reboot aktiviert das Initram-FS auf dem
14 
mount ‑t overlay ‑o \
trägt der Superuser den Modulnamen in die Raspberry Pi, indem
15  lowerdir=${ROOT_RO},upperdir=
Datei »/etc/initramfs‑tools/modules« ein: cd /boot
${ROOT_RW_UPPER},workdir=${ROOT_RW_WORK} \
echo "overlay" >> /etc/U echo "initramfs initrd7.img" >>config.txt
16  overlay ${rootmnt}
initramfs‑tools/modules
[...]
17  den Bootloader anpasst. Achtung: Diese Konfi-
18 
# move mount from ${ROOT_RO} to ${rootmnt}${ROOT_RO} n Für die eigentliche Aktivierung des Overlay gurationsoption verlangt kein Gleichheitszei-
19 
mount ‑o move ${ROOT_RO} ${rootmnt}${ROOT_RO} muss er das Skript »root‑ro« an der richti- chen zwischen Optionsname und Wert.
gen Stelle in das Initram-FS aufnehmen und Fertig! Mit dem nächsten Reboot ist der Zugriff
20 
# move mount from ${ROOT_RW} to ${rootmnt}${ROOT_RW}
ausführbar machen: auf die SD-Karte nur noch lesend möglich.
21 
mount ‑o move ${ROOT_RW} ${rootmnt}${ROOT_RW}

»/boot/«) übrigens lesend und schrei-
bend. Das ist zunächst unkritisch, da auf
diese Partion im laufenden Betrieb keine
Schreibzugriffe stattfinden. Andererseits
müssen für den rein lesenden Zugriff
in der orginalen Fstab nur die Mount­
optionen »defaults« durch »ro,noatime«
getauscht werden.
Nach dem Reboot zeigt der Mountbe-
fehl in Abbildung 6 den Erfolg an: Die
Rootpartiton ist nur lesend (»ro«) im Ver-
zeichnis »/mnt/root‑ro/« eingehängt, das
Root-Filesystems selbst als Overlay mit
Schreibrechten.
Über den Pfad »/mnt/root‑ro/« gelingt es
übrigens, jederzeit auf die Orginaldateien
lesend zuzugreifen (wie in Abbildung 5),
die nachträglichen Änderungen sind un-
ter »/mnt/root‑rw/« zu finden. So listet
»ls ‑R /mnt/root‑rw/upper« rekursiv die
dort abgelegten Dateien auf. Mittels »du
‑sh /mnt/root‑rw« lässt sich feststellen,
wie viel Hauptspeicher das Overlay-File-
system belegt.
Dies sind nach dem Booten gut 100
MByte von den rund 450 zur Verfügung
stehenden. Denn Linux reserviert beim
Anlegen eines Temp-Filesystems rund die
Hälfte des vorhandenen Hauptspeichers.
Da der Raspberry Pi 3 etwa 1 GByte
RAM hat, sind das 463 MByte. Wer mehr
braucht, ergänzt in dem Skript »root‑ro«
die Zeile 166 um »‑o size=550M«, wobei
»550M« für 550 MByte steht und durch
die benötigte Größe zu ersetzen ist. Im
Ganzen sieht die Zeile dann so aus:
mount ‑t tmpfs ‑o size=550M \
tmpfs‑root ${ROOT_RW}
Aber Vorsicht: Mehr Speicher für das
Overlay-Filesystem bedeutet zugleich
weniger Speicher für die Anwendungen.
Wer also mit größeren Datenbanken han-
tiert oder mit anderen Applikationen, die
viele Daten schreiben, muss nach Alter-
nativen suchen. So könnte er die Daten
auf ein Netzwerklaufwerk oder einen
USB-Stick transferieren. Letzterer eignet
sich freilich auch als Lagerstätte für ein
Overlay-Filesystem (Abbildung 3).
Häufige Schreibvorgänge
ausdünnen
Da der Raspberry Pi jetzt ruggedized ist,
sollte dessen Besitzer ihn noch für den
Langzeitbetrieb sichern. So schreibt der
Ergibt virtuell:
Merged »etc/fstab« »etc/password« »home/pi/foo.c/« »...«
»/«
Im RAM: Upper
»/mnt/root-rw/« »etc/fstab«
Auf SD-Karte:
»etc/fstab« »etc/password«
Lower
»/mnt/root-ro/«
Abbildung 4: Die SD-Karte ist die untere, ein Temp-Filesystem die obere Schicht des Overlay-Filesystems.
Logdaemon »rsyslogd« im Moment noch
regelmäßig Logdateien unter »/var/log/«.
Diese lassen sich beispielsweise per »log­
rotate« in Schranken halten. Alternativ
de­installiert der Admin Rsyslogd per
»dpkg ‑‑purge rsyslog« und ersetzt ihn
durch die Busybox-Variante (Kommando
»apt‑get install busybox‑syslogd«). Diese
behält die Lognachrichten im RAM und
stellt mit »logread« ein passendes Werk-
zeug zum Log-Lesen bereit.
Ein absolutes No-Go für das Ruggedized
System ist Swapping. Beim Raspberry Pi
ist der Auslagerungsmechanismus nor-
malerweise auch abgeschaltet. Wer si-
chergehen will, entfernt ihn per »apt‑get
purge dphys‑swapfile« komplett.
Wer mag, gibt alternativ dem Kernel Pa-
rameter mit auf den Weg, die der beim
Booten auswertet. Die Parameter gehören
in der Datei »/boot/cmdline«. Ein dort
eingetragenes »noswap« setzt Swapping
ebenfalls außer Gefecht. Ebenfalls hilf-
reich: »fastboot« überspringt den Filesys-
temcheck, der in einem reinen Lesebe-
Abbildung 5: Während des Bootens wird die originale Fstab (oben) modifiziert (unten).
06/2017
Know-how
writable
Kern-Technik
writable
»home/pi/foo.c/«
read-only
»...« 77
www.linux-magazin.de
trieb keinen Sinn ergibt. Die Option »ro«
schließlich sorgt ebenfalls dafür, dass der
Kernel nur read-only mountet.
Updates würden ins Leere
laufen
Wichtig: Mit dem Overlay finden alle Än-
derungen im Filesystem im RAM statt.
Mit dem nächsten Bootvorgang gehen
diese verloren. Sollen Wartungs- bezie-
hungsweise Konfigurationsarbeiten län-
gerfristig Wirkung entfalten, muss der
Besitzer sein System erst ohne Overlay-
Mechanismus booten. Dazu kommen-
tiert er in der Datei »/boot/config.txt«
nur die letzte Zeile (»initramfs initrd7.
img«) durch Einfügen eines Hashtag »#«
am Zeilenanfang aus. Das sonst so es-
senzielle Herunterfahren von Linux darf
man sich übrigens im gerade noch akti-
ven robusten Modus sparen und schadlos
einfach den Strom abschalten.
Mit dem nächsten Reboot kehrt nun das
normale, mit Schreibrechten auf die SD-
 06/2017
Know-how
Kern-Technik
78
www.linux-magazin.de
Abbildung 6: Erfolg! Das Root-Filesystem ist als Overlay gemountet.
Karte versehene System zurück. Aktuali-
sierungen, beispielsweise mittels »apt‑get
dist‑upgrade«, sind in diesem Zustand
persistent. Sind alle Arbeiten erledigt,
entfernt der Sysadmin in der letzten Zeile
Temporäres Filesystem
Linux hat mit Kernel 2.4 die klassische RAM-
Disk durch das temporäre Filesystem Tmp-FS
ersetzt. Dies hält alle Daten im Hauptspei-
cher, auch im ausgelagerten. In Abgrenzung
zur RAM-Disk benötigt ein Tmp-FS keinen
Dateisystemtreiber, da es direkt auf die in-
ternen Schnittstellen für den Dateizugriff
aufsetzt. Damit arbeitet es effizienter.
Linux nutzt das Tmp-FS in diversen Varian-
ten extensiv (Abbildung 6). Als Initram-FS
beispielsweise beherbergt es ein rudimentä-
res Userland. Dort liegen insbesondere Pro-
gramme zur Systemkonfiguration und zum
Laden von Treibern.
Ubuntu setzt es als so genanntes Early User-
land ein, um den Kernel ohne Treiber – die
befinden sich nämlich dann im Initram-FS –
auszuliefern. Nach dem Laden der Treiber
wechselt Ubuntu auf die eigentliche Root-
partition über und löscht das Early Userland
wieder aus dem Hauptspeicher.
Dadurch verbleiben keine überflüssigen
Treiber oder Konfigurationen im RAM. Für
den User ist der Vorgang unsichtbar. Gibt es
aktualisierte oder zusätzliche Treiber, muss
Ubuntu im Übrigen nur das Initram-FS neu
installieren, nicht den Kernel selbst.
von »/boot/config.txt« den Hashtag am
Zeilenanfang wieder. Diesmal muss er
das System sauber herunterfahren, und
die SD-Karte arbeitet mit dem nächsten
Start wieder im Schongang.
Wegen kleiner Änderungen, die zum
Beispiel ein Backup bewirkt, das System
rebooten zu müssen, erscheint nicht son-
derlich elegant. Und tatsächlich lässt sich
das System auch live in den SD-Karten-
Schreibmodus setzen. Dafür hängt Root
das read-only eingehängte Filesystem
neu mit Schreibrechten (read-write) ein:
sudo mount ‑o remount,rw /mnt/root‑ro
Das Backup selbst kann Rsync erledigen.
Einige Dateien und Ordner, zum Beispiel
»/etc/fstab«, »/var/«, »/tmp/«, sollte ein
Restore besser aussparen. Ein
sudo mount ‑o remount,ro /mnt/root‑ro
nach dem Schreibvorgang macht alles
wieder rückgängig.
Hart abschalten ohne Reue
So oder so: Bevor er sein haltbar gemach-
tes Himbeertörtchen in den Dauerbetrieb
überführen kann, hat der Besitzer die
Speicherauslastung über einen längeren
Zeitraum zu beobachen und eventuelle
Speicherfresser zu identifizieren und zu
beseitigen. Bleibt der Memory-Footprint
aber konstant, spricht nichts mehr gegen
den Einsatz als eingebettetes Ruggedized
System. Und damit etwas sonst Verbote-
nes ungestraft tun zu dürfen – zack: Ste-
cker raus! – ist für den Raspberry-Pi-Fan
das Sahnehäubchen. (jk) n
Infos
[1] Michael Kofler, „Raspbian-Lite für den
read­only Betrieb konfigurieren“:
[https://​­kofler.​­info/​
­raspbian‑lite‑fuer‑den‑read‑only‑betrieb/]
[2] Quade, Kunst, „Kern-Technik“, Folge 39
(über Initram-FS): Linux-Magazin 05/​08,
S. 98
[3] Quade, Kunst, „Kern-Technik“, Folge 91
(über Overlay-Filesysteme): Linux-Magazin
04/​17, S. 78
[4] Quade, „Embedded Linux lernen mit dem
Raspberry Pi“: Dpunkt-Verlag, 1. Auflage,
2014
[5] „Raspbian with Read-only Root“:
[https://​­www.​­raspberrypi.​­org/​­forums/​
­viewtopic.​­php?​­f=63&​­t=161416]
[6] „Raspberry Pi Forum“:
[https://​­www.​­raspberKastenrypi.​­org/​
­forums/​­viewtopic.​­php?​­f=63&​­t=145084]
[7] Axel Heider, „Read-only Root-FS with over-
layfs for Raspian“: [https://​­gist.​­github.​
­com/​­niun/​­34c945d70753fc9e2cc7]