Hallo,
ich habe mir vorgenommen Arch Linux auf einer MikroSD-Karte zu
installieren (+GUI). Konkret MikroSD -> SD-Adapter -> SD-Slot im Laptop
(ist praktischer hier als USB da die Karte nicht heraussteht), aber die
Vorgehensweise sollte eigentlich dieselbe wie mit einem USB-Stick sein.
Nun ist meine Frage, wie man Linux* dazu bringt, (so gut wie) keine
Daten mehr auf die MikroSD-Karte zu schreiben, sondern lediglich zu
lesen (und natürlich trotzdem erfolgreich zu booten).
Angenommen ich würde die den Schieber an dem SD-Adapter auf
schreibgeschützt stellen, würde das funktionieren oder Linux* gar nicht
erst starten? Welche Modifikationen müssen vorgenommen werden (ich habe
da etwas von "fstab" gehört, hat das etwas damit zu tun?!), um die
komplette Installation in ein Live-OS zu verwandeln?
Das Ziel ist, Arch Linux einmal zu installieren, einzurichten und dann
so zu lassen, ohne durch unnötiges Schreiben die Lebensdauer der
MikroSD-Karte einzuschränken.
Updates werden nicht benötigt, da dieses Arch nach der einmaligen
Installation & Einrichtung der Programme nur noch offline genutzt wird.
*Linux bezeichnet hier nicht nur den Kernel sondern auch
Linux-Kernel-basierte Betriebssysteme wie Arch Linux. Die Free Software
Foundation möchte zwar, dass jedes Linux-Kernel-basierte OS das auch
ehemalige GNU-Software nutzt GNU/Linux genannt wird (also hier Arch
GNU/Linux), aber ich schreibe es hier wie viele andere kurz.
Die Datei /etc/fstab definiert nur welche Partitionen beim Systemstart
gemountet werden. Zwar ist es möglich eine Partition nur lesend
einzuhängen, aber dann funktioniert das System nicht. Das Stichwort für
dein Vorhaben lautet Initramfs https://de.m.wikipedia.org/wiki/Initramfs
Aber das dürfte ein Steiniger Weg werden.
Live OS ist dafür wahrscheinlich der falsche Begriff. Suche mal nach
mount read only, read only root, ...
Theoretisch sollte das per fstab gehen, praktisch weiß ich nicht ob z.B.
Swap noch Anpassungen braucht.
Beim Raspberry Pi wird das gerne gemacht, damit der bei Stromausfall
nicht das Dateisystem zerlegt. Da gibt es einige Anleitungen.
P.S. der Schreibschutz Schalter ist nur eine Plastiknase die vom
Kartenleser ausgewertet werden kann. Das Linux damit beim booten korrekt
umgeht glaub ich weniger
Linux-using BSD enthusiast due to incompability schrieb im Beitrag
#5870484:
> Nun ist meine Frage, wie man Linux* dazu bringt, (so gut wie) keine> Daten mehr auf die MikroSD-Karte zu schreiben, sondern lediglich zu> lesen (und natürlich trotzdem erfolgreich zu booten).
Am einfachsten, indem du ein ISO-Image einer bestehenden
Live-Distribution auf deine Karte kopierst.
> Angenommen ich würde die den Schieber an dem SD-Adapter auf> schreibgeschützt stellen, würde das funktionieren oder Linux* gar nicht> erst starten? Welche Modifikationen müssen vorgenommen werden (ich habe> da etwas von "fstab" gehört, hat das etwas damit zu tun?!), um die> komplette Installation in ein Live-OS zu verwandeln?
Die fstab ist ein kleiner Bestandteil. Im Wesentlichen muss man für alle
Stellen, an denen das System schreibt, entweder die Funktion ausschalten
oder in eine Ramdisk schreiben lassen.
Siehe z.B. https://wiki.debian.org/ReadonlyRoot> *Linux bezeichnet hier nicht nur den Kernel sondern auch> Linux-Kernel-basierte Betriebssysteme wie Arch Linux. Die Free Software> Foundation möchte zwar, dass jedes Linux-Kernel-basierte OS das auch> ehemalige GNU-Software nutzt GNU/Linux genannt wird (also hier Arch> GNU/Linux), aber ich schreibe es hier wie viele andere kurz.
Ist eigentlich auch Blödsinn. Das ganze besteht ja nicht nur aus dem
Kernel und den GNU-Komponenten. Man müsste dann konsequenterweise
GNU/Linux/Xorg/KDE/Firefox/… mit einem Rattenschwanz von 500 Namen
hinschreiben.
Andre schrieb:> P.S. der Schreibschutz Schalter ist nur eine Plastiknase die vom> Kartenleser ausgewertet werden kann. Das Linux damit beim booten korrekt> umgeht glaub ich weniger
Warum sollte es das nicht tun?
Linux-using BSD enthusiast due to incompability schrieb im Beitrag
#5870484:
> Nun ist meine Frage, wie man Linux* dazu bringt, (so> gut wie) keine Daten mehr auf die MikroSD-Karte zu> schreiben, sondern lediglich zu lesen (und natürlich> trotzdem erfolgreich zu booten).
Ein Kochrezept kann ich nicht liefern, aber einen Hinweis:
Der "Filesystem Hierarchy Standard" (--> Google) definiert
für eine große Anzahl von Dateien und Verzeichnissen, ob
und für wen Schreibrecht gegeben sein muss. Den würde ich
durcharbeiten; das gibt Dir schon mal einen guten Überblick.
> Angenommen ich würde die den Schieber an dem SD-Adapter> auf schreibgeschützt stellen, würde das funktionieren> oder Linux* gar nicht erst starten?
Ich schätze, es startet, gibt aber Unmassen Fehlermeldungen,
weil z.B. das Logging nicht funktioniert.
In der Guten, Alten Zeit (tm) [also vor systemd] war es
so, dass die allerwenigsten Systemdienste Schreibzugriff
auf irgendwelche Systemdateien benötigt haben. Es war
durchaus sinnvoll und vorgesehen, die root-Partition
read-only zu mounten.
/var/log muss natürlich schreibbar sein, wenn man Logging
haben will; /home gleichfalls, wenn der Nutzer Daten speichern
können soll.
> Welche Modifikationen müssen vorgenommen werden (ich habe> da etwas von "fstab" gehört, hat das etwas damit zu tun?!),
Ja.
In /etc/fstab wird festgelegt, welche Partition mit welchen
Rechten wo im Verzeichnisbaum gemountet sein soll.
Linux-using BSD enthusiast due to incompability schrieb im Beitrag
#5870484:
> Nun ist meine Frage, wie man Linux* dazu bringt, (so gut wie) keine> Daten mehr auf die MikroSD-Karte zu schreiben, sondern lediglich zu> lesen (und natürlich trotzdem erfolgreich zu booten).Rolf M. schrieb:> Am einfachsten, indem du ein ISO-Image einer bestehenden> Live-Distribution auf deine Karte kopierst.
Wenn man es so macht, werden keine Daten auf der Karte verändert.
Es läuft ja nicht direkt von der Karte.
Es werden Programmteile in den RAM kopiert und dort ausgeführt.
Bei manchen Disributionen kann man die CD entnehmen und es läuft
komplett im RAM.
> Bei manchen Disributionen kann man die CD entnehmen und es läuft> komplett im RAM.
Ja, keine grosse Kunst wenn man die komplette CD vorher in
den Hauptspeicher kopiert.
> In der Guten, Alten Zeit (tm) [also vor systemd] war es> so, dass die allerwenigsten Systemdienste Schreibzugriff> auf irgendwelche Systemdateien benötigt haben. Es war> durchaus sinnvoll und vorgesehen, die root-Partition> read-only zu mounten.
Ja, frueher konnte man mit normalen Filesystemen ext2/3/4,
ein paar symbolischen Links und einigen Startscripten ein Livelinux
bauen.
Die Idioten machen alles kaputt.
michael_ schrieb:> Wenn man es so macht, werden keine Daten auf der Karte verändert.> Es läuft ja nicht direkt von der Karte.> Es werden Programmteile in den RAM kopiert und dort ausgeführt.
Kommt auf die Distro an. Manche verwenden auch ein Overlay-Filesystem
wie AUFS. Damit landen nur die Änderungen in einer Ramdisk.
Andre schrieb:> Live OS ist dafür wahrscheinlich der falsche Begriff. Suche mal nach> mount read only, read only root, ...
+1
> Theoretisch sollte das per fstab gehen, praktisch weiß ich nicht ob z.B.> Swap noch Anpassungen braucht.
Swap muss natürlich komplett abgeschaltet werden -- es sei denn...
Wenn es noch Platz auf der Laptop-Festplatte gibt, könntest du da eine
Partition für das /var vom Arch einrichten und unter /var ein swapfile
benutzen. Das geht praktisch genauso gut wie eine swap-Partition.
Hauptsächlich braucht man das, weil viele Leute glauben, dass man das
braucht. Linux läuft auch ohne swap.
Mit Debian habe ich einige Installationen ganz normal ohne Tricks wie
auf eine Festplatte gemacht und alles eingerichtet. Dann in der fstab
/var/log als tmpfs und den Rest als "ro" eingetragen und abgewartet, was
alles nicht mehr funktioniert.
Es waren immer nur einzelne Dateien bzw. Programme oder sogar nur ganz
bestimmte Funktionen. Zum Beispiel will sich der ntpd die Drift der
Systemuhr merken. Das geht nicht mehr, also dauert es nach dem Booten
länger, bis die maximale Stabilität erreicht wird. Na und?
Also, auf geht's, Versuch macht kluch!
Okay, so viele Antworten hatte ich heute nicht mehr erwartet ?
Ich lese mir morgen alles nochmal genauer durch und stelle dann
entsprechende Rückfragen ;)
Danke schonmal für die Hilfe
DPO schrieb:> Die Datei /etc/fstab definiert nur welche Partitionen beim Systemstart> gemountet werden. Zwar ist es möglich eine Partition nur lesend> einzuhängen, aber dann funktioniert das System nicht.> Das Stichwort für> dein Vorhaben lautet Initramfs https://de.m.wikipedia.org/wiki/Initramfs
Nö, das ist dafür eigentlich nicht gedacht. Eher ein Overlay-FS. So, wie
es z.B. bei Puppy-Linux standardmäßig genutzt wird.
> Aber das dürfte ein Steiniger Weg werden.
Soo schlimm ist es auch wieder nicht. Aber klar, man muss schon etwas
lesen. So lange es nicht erforderlich ist, dass das Overlay am Ende dann
doch irgendwie persistent werden muss, ist der Mehraufwand gegenüber
einer normalen Installation aber wirklich sehr überschaubar.
Zumindest auf nicht-systemd systemen ist das sehr einfach. In der fstab
alles auf RO setzen. Dann einfach tmp und run und eventuell noch ein
zwei dinge in /var auf mit der fstab als tmpfs mounten. Darin kann man
auch home als aufs/overlayfs mounten, das neue Daten in ein tmpfs
schreibt, oder sogar einfach das Benutzerverzeichnis als tmpfs mounten.
Pulseaudio zickt in der regel rum, aber das kann man auch einfach
deinstallieren und durch apulse ersetzen. Ich hab so mal ein PXE/NFS
basiertes Netzwerkbootsystem bei mir eingerichtet, das NFS und die
Clients sind readonly, aber auf meinem Server kann ich in nem Container
neues zeug installieren, was dann sofort auf allen PCs nutzbar ist, weil
auf dem NFS Root. https://dpa.li/pxeboot.mp4
Holger schrieb:> Ich hätte auch noch ein paar Antworten für Dich.>> Vielleicht komme ich Übermorgen dazu, sie Dir zu posten?
Klar, gerne, wieso nicht?
DPA schrieb:> Zumindest auf nicht-systemd systemen ist das sehr einfach
Danke für die Infos, nur eine Sache verstehe ich nicht ganz. Ich habe
von Kritikern gehört, dass systemd mysteriöse DNS-Anfragen an Google
senden soll, aber ansonsten soll es einiges vereinfachen.. Stimmt das
nicht? Bzw. was muss man mit systemd anders machen als ohne?!
Linux-using BSD enthusiast due to incompability schrieb im Beitrag
#5870484:
> Das Ziel ist, Arch Linux einmal zu installieren, einzurichten und dann> so zu lassen, ohne durch unnötiges Schreiben die Lebensdauer der> MikroSD-Karte einzuschränken.
Ich glaube du überschätzt die Anzahl an Schreibzugriffen, die so ein
Linux macht, im Verhältnis zur Lebensdauer (TBW) einer SD-Karte.
Mein Arbeits-Notebook früher hatte ein Zwangs-Windows, was ich nicht
verändern sollte, konnte aber von SD-Karte booten.
=> LUbuntu auf ein 32GB-Kärtchen installiert, lief über viele Jahre
problemlos.
Sogar mit SWAP-Partition auf SD und über mehrere Release-Upgrades
hinweg.
Und auch mit regelmäßiger Installation von Sicherheitsupdates,
user-homedir auch auf SD.
War zwar beim booten und jeweils ersten Programmstart deutlich
langsamer, als man das heute als SSD-Verwöhnter erwartet, aber ich
konnte damit über viele Jahre hinweg arbeiten.
Ohne Probleme mit der SD-Karten-Lebensdauer zu haben (regelmäßige
Backups gabs natürlich).
Hatte nur kleine Änderungen gegenüber der Default-Config von Ubuntu,
erinner mich an:
--> Swap auf ZRAM mit höherer Prio als Swap auf SD
--> "laptop mode utils"
--> aggressiver disk (write) cache über sysctl.conf, "vm.dirty_*..."
Sollte mit Arch genauso möglich sein.
Irgendwo hab ich die alte SD-Karte noch rumfliegen, evtl. sogar
ungelöscht...
falls Interesse besteht kann ich die mal hersuchen und auslesen, was da
tatsächlich geschrieben wurde (/sys/fs/ext4/*/lifetime_write_kbytes),
vielleicht hatte ich auch einfach nur großes Glück mit meiner Karte.
Ist alles ne Frage des RAMs der dir zur Verfügung steht wenn wenig RAM
da ist braucht es ne SWAP Partition, Komprimierten RAM ..., und dann ist
die Frage was du genau machen möchtest.
Würde mich da auch ehr "Lenovo X201" an schlissen mit recht einfachen
Tricks kann man die Schreibzugriffe minimieren, und dann ist ein
ziemlich wichtiges Kriterium wie gut die SD-Karte ist.
Meine Samsung EVO 32GB hat ohne Optimierungen 5 Jahre Gentoo überlebt,
mit Compilieren und co. vernümftige Große Karten (um so mehr Speicher um
so länger halten die) können schon einiges ab.
Da helfen auch kleinere Optimierungen wenn man mag wie grösserer Schreib
puffer ..., Priorität des Swaps verringern...
Da kann man sich gut im RPI bereich mal umschauen, da findet man die
gängigen Optimierungen.
Linux-using BSD enthusiast due to incompability schrieb im Beitrag
#5872748:
> DPA schrieb:>> Zumindest auf nicht-systemd systemen ist das sehr einfach>> Danke für die Infos, nur eine Sache verstehe ich nicht ganz. Ich habe> von Kritikern gehört, dass systemd mysteriöse DNS-Anfragen an Google> senden soll, aber ansonsten soll es einiges vereinfachen.. Stimmt das> nicht?
Lies nicht zuviel da hinein. Ich will damit nur sagen, dass ich keine
Systemd Systeme verwende, und deshalb nicht weis, ob bei Systemd noch
zusätzliche Verzeichnisse readonly gemountet werden müssem, ob das
anders zu bewerkstelligen ist (mount units?), und ob noch sonstige
Einstellungen nötig sind. Systemd ist ein sehr Komplexes System mit
vielen Subsystemen, die auch Dateien an verschiedensten stellen
generiert, es kann sein, dass dort die üblichen Verzeichnisse reichen,
ich kann aber nicht einfach so sagen, was dort alles tatsächlich nötig
ist. Ich halte systemd auch nicht für einfacher zu verwenden als andere
Systeme. Das was vorgesehen ist, vielleicht. Aber was nicht explizit
vorgesehen ist... Die DNS Geschichte die du erwähnst, dort geht es um
hartcoded DNS defaults, man könne es ja neu kompilieren wenn man
wirklich keine default DNS wolle. (Oder meintest du eher das DNS/VPN
Problem?)
Andere init Systeme sind viel einfacher aufgebaut. Unter anderem sind es
in der regel dann auch tatsächlich init Systeme, manchmal noch mit
Supervisorfunktion. Die sind aber alle definitiv mit /tmp /run /var/tmp
/var/run als tmpfs zufrieden (2 davon sind oft sowieso symlinks). Einige
kommen sogar mit noch weniger klar.
Andere Userspaceprogramme/Daemons brauchen manchmal noch schreibbares
/home und ein zwei schreibbare Orte in /var. Die meistens kommen
komplett RO aber auch ganz gut zurecht.
K. J. schrieb:> Ist alles ne Frage des RAMs der dir zur Verfügung steht
16GB
DPA schrieb:> (Oder meintest du eher das DNS/VPN Problem?
ersteres war gemeint
Lenovo X201 schrieb:> Ich glaube du überschätzt die Anzahl an Schreibzugriffen, die so ein> Linux macht, im Verhältnis zur Lebensdauer (TBW) einer SD-Karte.
Das kann gut sein. Ich kann es ja mal über ein paar Jahre austesten.
Lenovo X201 schrieb:> falls Interesse besteht kann ich die mal hersuchen und auslesen, was da> tatsächlich geschrieben wurde
Karte gefunden :)
1
cat /sys/fs/ext4/sdg1/lifetime_write_kbytes
2
185012849
3
4
tune2fs -l /dev/sdg2
5
...
6
Filesystem created: Mon Jan 26 11:10:46 2015
7
...
8
Lifetime writes: 176 GB
9
...
also 176GB geschrieben, wären bei optimaler Verteilung < 6 Erase-Zyklen
für jeden Flash-Block, real natürlich viel mehr.
Wieviel über die Zeit in die Swap-Partition geschrieben wurde, kann man
m.W. nicht auslesen, denke aber nicht, dass das relevant viel war.
Sagt natürlich nix darüber aus wie das bei deiner Workload laufen würde
=> installieren, nach Installation und nach einer Woche Nutzung mal die
"Lifetime writes" checken für eine grobe Abschätzung.
Lenovo X201 schrieb:> Wieviel über die Zeit in die Swap-Partition geschrieben wurde, kann man> m.W. nicht auslesen, denke aber nicht, dass das relevant viel war.
Auf einer normalen Installation werden nur einmal pro Systemstart wenige
MB swap geschrieben, weil genug RAM installiert ist...
Wer swap auf SD-Karten benutzt, frisst auch kleine Kinder ;)
Bauform B. schrieb:> Lenovo X201 schrieb:>> Wieviel über die Zeit in die Swap-Partition geschrieben wurde, kann man>> m.W. nicht auslesen, denke aber nicht, dass das relevant viel war.>> Auf einer normalen Installation werden nur einmal pro Systemstart wenige> MB swap geschrieben, weil genug RAM installiert ist...
Auf einer normalen Installation wird - solange man keinen
Speicherfresser laufen lässt - gar kein Swap geschrieben. Das ist nur
bei Windows so, dass es unabhängig von der Speichergröße und auch ohne
dass man irgendein Programm startet, grundsätzlich immer irgendwas
auslagert.
Ich meinte diese 724K, sowas habe ich schon öfter gesehen. Aber jetzt,
wo du es sagst: Die gehören vermutlich zu Prozessen wie cron oder udevd
und wurden nicht beim Start, sondern irgendwann ausgelagert, als ich
versehentlich einen 2. Tab im firefox aufgemacht hab ;)
Wie weiter oben geschrieben: da lief noch Swap-auf-ZRAM mit höherer Prio
als auf die SD-Partition.
d.h. Wenn der Speicher knapp geworden ist, hat er erstmal die CPUs mit
Komprimierung/Dekomprimierung belastet, bevor überhaupt ein Byte auf die
SD "geschwappt" ist.
anderes system:
