MameCab/Betriebssystem

WORK IN PROGRESS!

Betriebssystem des Mame-Cabinets

Als Betriebssystem fürs Mame-Cabinet kommt ein leicht abgespecktes Debian "Lenny" 5.0 zum Einsatz, dessen Konfiguration an die Anforderungen eines Stand-Alone-Spieleautomaten angepasst wurde:

• vom Einschalten bis zur Präsentation der Spieleauswahl sollte keine Nutzerinteraktion nötig sein
• robustes System für möglichst wartungsfreien Dauerbetrieb
• keine persistenten Änderungen im Standardbetrieb, so dass nach einem Neustart die Ausgangskonfiguration wieder hergestellt wird
• dennoch anfallende Wartungsarbeiten (Updates) sollten nach wie vor nativ über die Distributions-Toolchain möglich sein

Das Root-Dateisystem

Problemstellung

Das Mame-Cabinet hat den Nachteil, dass es am Gerät selbst keine Möglichkeit gibt, es sauber herunterzufahren. Das hat zur Folge, dass die Benutzer das System einfach hart abschalten, wodurch das Dateisystem in Mitleidenschaft gezogen werden kann. Bei der ursprünglichen Gentoo-Installation führte dies nach und nach zu Folgeschäden, die einen störungsfreien Betrieb auf Dauer unmöglich machten.

Zusätzlich bestand der Wunsch, das System nicht mehr von der betagten 8GB-Festplatte zu booten, sondern stattdessen einen USB-Stick zu verwenden. Dies spart einerseits eine potenzielle mechanische Fehlerquelle ein und vereinfacht andererseits die Erweiterung des Systems, da der USB-Stick schnell an einen anderen Rechner gesteckt und modifiziert werden kann. Häufige Schreibzugriffe sorgen allerdings bei USB-Sticks für einen höheren Verschleiß.

Für diese Probleme verwenden wir folgende Lösung: Das Dateisystem, dass das Betriebssystem beinhaltet, wird beim Booten im Nur-Lese-Modus eingehängt. Anschließend wird ein im RAM liegendes tmpfs transparent darüber gelegt, so dass alle Schreibzugriffe im Hauptspeicher stattfinden. Bildlich gesprochen schimmert das Nur-Lese-Dateisystem durch das tmpfs hindurch, wobei im tmpfs getätigte Änderungen die betreffenden Teile im Nur-Lese-System überdecken. Dadurch, dass auf der tatsächlichen Betriebssystem-Installation keine Schreibzugriffe stattfinden, trägt diese beim Abschalten keine Schäden mehr davon und der USB-Stick nutzt sich nicht schneller als nötig ab.

Diese Vorteile erkaufen wir uns allerdings mit dem Verlust der Fähigkeit, Änderungen wie Spielstände oder Highscores dauerhaft zu speichern. Letztere gehen mit dem Abschalten einfach verloren. Auf der anderen Seite ist so sichergestellt, dass nach dem Neustart immer eine vorher festgelegte, funktionierende Konfiguration vorliegt.

Für den Fall, dass tatsächlich mal persistente Änderungen vorgenommen werden müssen, sollte durch die Angabe des Kernel-Parameters nakka ein Booten mit klassischem Schreibzugriff möglich sein

Technisch gesehen wird dies mit aufs realisiert. aufs ermöglicht das Mischen mehrerer Dateisysteme (in unserem Fall das nur lesbare Root-Dateisystem und das im RAM liegende tmpfs) zu einem neuen virtuellen Dateisystem. Um ein solches virtuelles Dateisystem als Root-Dateisystem verwenden zu können, müssen bereits durch Skripte in der initialen RAM-Disk ensprechende Vorkehrungen getroffen werden, bevor das System durch den Init-Prozess vollständig gestartet wird. Dieses Skript sollte ebenfalls den eben genannten Kernelparameter auswerten können.

Durchführung

USB-Stick

Im weiteren gehen wir davon aus, dass sich auf dem USB-Stick bereits eine funktionierende bootfähige Debian-Installation befindet. Für den Stick bietet sich das ext2-Dateisystem an, da es kein für unseren Fall nutzloses Journal anlegt. Außerdem sollte mittels tune2fs dafür gesorgt werden, dass nicht alle paar Mount-Vorgänge bzw. alle paar Tage eine Dateisystemprüfung angestoßen wird. Sollte es beim Booten vom USB-Stick Probleme mit dessen Erkennung durch den Kernel geben, kann es helfen, in Grub zusätzlich den Kernelparameter "rootdelay=3" anzugeben. Dazu später mehr.

Initiale RAM-Disk

Im ersten Schritt muss in Debian die Unterstützung für aufs nachinstalliert werden. Dies geschieht über die Installation der Pakete aufs-tools und aufs-modules-2.6-686 (bzw. das zum verwendeten Kernel passende Paket). Anschließend muss das Image für die initiale RAM-Disk angepasst werden, so dass es sowohl die Kernelmodule für aufs als auch ein Skript zur Bereitstellung unseres virtuellen Root-Dateisystems enthält. Zunächst modifizieren wir die Datei /etc/initramfs-tools/modules, so dass sie folgendes enthält:

# Module fuer USB-Storage
sd_mod
scsi_mod
ohci
uhci_hcd
ehci_hcd
usb-storage

# Module fuer die Dateisysteme
ext2
tmpfs
aufs

Dies stellt sicher, dass die nötigen Kernelmodule für USB-Massenspeicher und die verwendeten Dateisysteme bereits in der inititalen RAM-Disk bereitstehen.

In der Datei /etc/initramfs-tools/scripts/aufs legen wir das Skript zum Erstellen des eingangs erwähnten virtuellen Dateisystems an:

get_fstype()
{
        echo "aufs"
        return 0
}

root_missing()
{
        return 0
}

mountroot()
{
        modprobe ext2
        modprobe aufs
        modprobe tmpfs
        mkdir -p /rwstore
        mkdir -p /rostore
        mount -w -t tmpfs none /rwstore
        mount -r -t ext2 /dev/sda1 /rostore
        CMDLINE=$(cat /proc/cmdline | grep nakka)
        if [[ x$CMDLINE == x ]];then
                mount -w -t aufs -o br=/rwstore/:/rostore/=ro aufs ${rootmnt}
        else
                mount -o remount,rw /rostore
                mount --bind /rostore ${rootmnt}
        fi 
}

In der Datei /etc/initramfs-tools/initramfs.conf muss noch der Eintrag BOOT=local in BOOT=aufs geändert werden, damit das Skript tatsächlich eingebunden wird. Der Befehl update-initramfs -u -k all erzeugt schließlich das Image für die neue RAM-Disk.

GRUB: Änderungen in der menu.lst

Der USB-Controller des SiS-basierten Mainboards reagiert bei der Reinitialisierung durch den Linux-Kernel etwas träge. Dies verursacht beim Booten einen Kernel-Panic, da der Kernel bereits nach dem Root-Dateisystem sucht, bevor der USB-Stick wieder ansprechbar ist. Das Debian-Initramfs-Framework stellt für diesen Fall den Kernelparameter rootdelay=x zur verfügung, wobei x die Anzahl der Sekunden ist, die das Skript in der initialen RAM-Disk abwartet, bevor es das Root-Dateisystem einhängt. In unserem Fall ist ein Wert von drei Sekunden ausreichend.

Damit diese Änderung auch dauerhaft gespeichert wird, bedarf noch es einer Änderung an der Datei /boot/grub/menu.lst. Dort muss die Zeile

# defoptions=quiet

in

# defoptions=quiet rootdelay=3

geändert werden. Ein anschließendes update-grub vervollständigt die Konfiguration.