Meiner Erfahrung nach muss das Filesystem, mit Ausnahmen von Logs und anderen Kleinigkeiten selten verändert werden. Aus diesem Grund sehe ich mir an, wie man / read only behandelt.

Was sind Gründe um dies zu tun?

• LiveCDs
• Erhöhen der Systemsicherheit
• Schadensbegrenzung bei Crashes
• Root über NFS ‚verteilen‘

Es gibt sicher noch mehr Anwendungsbeispiele oder Ideen wo man es einsetzen kann. Um dies realisieren zu können müssen wir einen Devicemanager, in unserem Fall udev verwenden, da sonst kein nachträgliches Hinzufügen und Mounten von Wechselmedien wie USB Sticks mehr möglich ist.

Es gilt zu beachten dass /home, /tmp und /var Schreibzugriffe benötigen. Aus diesem Grund müssen sie, genauso wie unser Portage, sofern wir uns dazu entscheiden ihn zu verwenden, auf eigenen Partitionen liegen. So weit die Grundprobleme des Disklayouts. Widmen wir uns den unscheinbareren Dingen wie /etc/mtab welche uns den Nerv schlechthin kosteten:

Die Datei /etc/mtab beschreibt die aktuell gemounteten Dateisysteme, wobei sie bei jedem mounten bzw unmounten eines Dateisystems neu geschrieben wird. Die einfachste Methode besteht darin, die Datei durch einen Symlink nach /proc/mounts zu ersetzen. Die Informationen in der Datei sind zwar nicht so genau wie in der originalen mtab Datei, aber da mount selbst nicht direkt mit Symlinks zurechtkommt die einzige Methode um es ohne grobe Patches zu erledigen. Jeglich ein paar Änderungen in /etc/init.d/localmount sind wie folgt nötig:

– mount -at nocoda,nonfs,noproc,noncpfs,nosmbfs,noshm >/dev/null
+ mount -nat nocoda,nonfs,noproc,noncpfs,nosmbfs,noshm >/dev/null

– mount -t ${usbfs} none /proc/bus/usb &>/dev/null
+ mount -nt ${usbfs} none /proc/bus/usb &>/dev/null

Der letzte Streich ist die /etc/fstab, welche nun / nicht mehr read-write sondern read-only mounten muss:

– /dev/hda1 / ext2 noatime 0 1
+ /dev/hda1 / ext2 noatime,ro 0 1

Das sollte es gewesen sein. Um nun Konfigurationen upzudaten empfiehlt es sich, die entsprechenden Partitionen wieder mit Schreibzugriff zu mounten.

[Update:] Im vorhergehenden Eintrag betreffend Laden des Systems in den RAM habe ich die Verwendung von Ramdrives beschrieben – analog dazu könnte man die Verzeichnisse die Schreibzugriff benötigen behandeln. Die Grundidee dahinter ist, die Tarballs dann beim Herunterfahren zu exportieren um keine Daten zu verlieren…