MameCab/Betriebssystem

Aus LaborWiki
Version vom 8. September 2009, 04:20 Uhr von Tunix (Diskussion | Beiträge) (angefangene Dokumentation der Debian-Installation des Cabinets)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

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.

GRUB: Änderungen in der menu.lst

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.