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?
:
Bearbeitet durch User
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.
Custom Arch Linux live USB https://gist.github.com/satreix/c01fd1cb5168e539404b --- ansonsten z.B. 'Linux Live Kit' http://www.linux-live.org/ diente bspw. slax in versch. Versionen
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
Ich hätte auch noch ein paar Antworten für Dich. Vielleicht komme ich Übermorgen dazu, sie Dir zu posten?
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.
1 | kuemmel:~$ free -h |
2 | total used free shared buff/cache available |
3 | Mem: 3.6G 68M 721M 277M 2.8G 2.9G |
4 | Swap: 7.4G 724K 7.4G |
5 | kuemmel:~$ uptime |
6 | 11:13:37 up 59 days, 2:52, 1 user, load average: 0.00, 0.00, 0.00 |
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:
1 | # cat /proc/swaps |
2 | Filename Type Size Used Priority |
3 | /dev/dm-0 partition 2103964 0 2 |
4 | /dev/dm-1 partition 2103964 0 2 |
5 | /dev/dm-3 partition 2096636 0 2 |
6 | /dev/dm-2 partition 2096636 0 2 |
7 | /dev/zram0 partition 1017764 66608 75 |
8 | /dev/zram1 partition 1017764 66988 75 |
9 | /dev/zram2 partition 1017764 67088 75 |
10 | /dev/zram3 partition 1017764 66836 75 |
11 | |
12 | # free -wh |
13 | Gesamt belegt frei gemeins. Puffer Cache verfügbar |
14 | Speicher: 15Gi 6,8Gi 1,0Gi 731Mi 9,0Mi 7,7Gi 7,7Gi |
15 | Auslagerungsspeicher: 11Gi 261Mi 11Gi |
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.