MameCab/Betriebssystem
WORK IN PROGRESS!
Betriebsystem des Mame-Cabinets
Als zugrundeliegendes Betriebssystem für das Mame-Cabinet wurde Debian "Lenny" 5.0 ausgewählt, dessen Konfiguration nur geringfügig vom Standard abweicht.
Bootphase
Hintergrund
Das Mame-Cabinet hat den Nachteil, dass es am Gerät selbst keine Möglichkeit gibt, ein sauberes Herunterfahren zu veranlassen. Das hat zur Folge, dass die Benutzer das System einfach hart abschalten, wodurch das Dateisystem regelmäßig in Mitleidenschaft gezogen wird. 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 auch bei USB-Sticks für einen höheren Verschleiß.
Um dieses Problem abzumildern bedient man sich eines Tricks: 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 geprochen schimmert das Nur-Lese-Dateisystem durch das tmpfs durch, wobei im tmpfs getätigte Änderungen die betreffenden Teile im Nur-Lese-Systems überdecken. Dadurch, dass auf der tatsächlichen Betriebssystem-Installation keinen Schreibzuzugriffe stattfinden, trägt diese durch hartes Abschalten keine Schäden mehr davon. Diesen Vorteil erkauft man sich allerdings mit dem Verlust der Fähigkeit, Änderungen wie Spielstände oder Highscores dauerhaft abspeichern zu können. Letztere gehen mit dem Abschalten einfach verloren.
Technisch gesehen wird dies mit aufs realisiert. aufs ermöglicht das Mischen mehrerer Dateisyteme (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, muss beim Boot-Vorgang bereits recht früh durch Skripte in der initialen RAM-Disk eingegriffen werden, bevor das System durch den Init-Prozess vollständig gestartet wird.
Durchführung
USB-Stick
Für den USB-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 x Mounts bzw. alle y Tage eine Dateisystemprüfung angestoßen wird. Im weiteren wird davon ausgegangen, dass sich auf dem USB-Stick bereits eine funktionierende bootfähige Debian-Installation befindet. Sollte es beim Booten vom USB-Stick Probleme mit dessen Erkennung durch den Kernel geben, kann es helfen, in Grub den Kernelparameter "rootdelay=3" mit 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-Dateisytems 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 bereits in der inititalen RAM-Disk die nötigen Kernelmodule für USB-Massenspeicher und die verwendeten Dateisysteme 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
}
Dieses Skript ist so gestaltet, dass es bei der Angabe des Kernelparameters "nakka" das Root-Dateisystem auf klassische Weise beschreibbar mountet, was im Falle eines Falles auch persistente Änderungen am Dateisystem ermöglicht. 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 die neue RAM-Disk.
Der USB-Controller vom Mainboard reagiert bei einer Reinitialiserung durch den Linux-Kernel etwas träge, wodurch beim Booten ein Kernel-Panic verursacht werden kann, weil der Kernel bereits nach dem Root-Dateisystem sucht, obwohl der USB-Stick noch nicht ansprechbar ist. Das Debian-Initramfs-Framework stellt für diesen Fall den Kernelparameter rootdelay=x zur verfügung, wobei x die Anzahl der Sekunden darstellt, die die Skripte der initialen RAM-Disk abwarten, bevor sie das Root-Dateisystem mounten. In unserem Fall hast sich ein Wert von drei Sekunden als ausreichend erwiesen.
Damit diese Änderung auch dauerhaft gespeichert wird, bedarf 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.