Theoretisch sollte es egal sein, welcher Interrupt von welchem
Gerät verwendet wird, solange nicht zwei Geräte so
konfiguriert sind, daß sie den gleichen verwenden. In der Datei
/etc/pcmcia/config.opts können bestimmte Interrupts, die
bei nicht-PCMCIA-Geräten Verwendung finden, ausgeschlossen
werden.
Es ist nicht möglich, eine PCMCIA-Karte anzuweisen, eine bestimmte
I/O-Adresse zu verwenden. Vielmehr erlaubt die Datei
/etc/pcmcia/config.opts einem, einen Bereich von
verfügbaren Adressen für den Gebrauch durch PCMCIA-Geräte
anzugeben oder einen Bereich vom Gebrauch auszuschließen.
Nach der Modifizierung der Datei /etc/pcmcia/config.opts kann
cardmgr mit dem Befehl
kill -HUP
neu gestartet
werden.
Der Interrrupt, der verwendet wird, um den Kartenstatus zu
überwachen, wird von dem Grundmodul (i82365 oder
tcic) ausgewählt, bevor cardmgr die Datei
/etc/pcmcia/config durchforstet, so daß diese
Einstellungen durch diese Datei nicht beeinflußt werden.
Um diesen Interrupt zu setzen, muß die cs_irq= Option
verwendet werden, wenn der Slottreiber geladen wird. Dies wird durch
Setzen der Variable PCIC_OPTS= im Startskript
rc.pcmcia erreicht.
Alle darauf aufbauenden Kartentreiber haben einen Parameter, der
irq_mask= genannt wird und mit dem die Interrupts festgelegt
werden, die von dem Treiber verwendet werden können. Jedes Bit
von irq_mask entspricht einem Interrupt: Bit 0 ist IRQ0,
Bit 1 IRQ1 und so weiter. Eine Maske von 0x1200 würde den
Interrupts 9 und 12 entsprechen. Um einen Treiber derart
einzuschränken, daß dieser nur einen Interrupt verwendet,
darf lediglich ein Bit gesetzt werden. Diese Treiberoptionen
sollten in der Datei /etc/pcmcia/config angegeben werden. Zum
Beispiel
device "serial_cs"
module "serial_cs" opts "irq_mask=0x1100"
...
würde bedeuten, daß nur die Interrupts 8 und 12 verwendet
werden dürfen. Unabhängig von der Einstellung der Variablen
irq_mask wird Card Services niemals einen Interrupt
verwenden, der bereits von einem anderen Gerät benutzt oder durch
die Datei config ausgeschlossen wird.
Dies ist wirklich eine einfache Anwendung der Unterstützung von
PCMCIA-Schemata. Dazu verwendet man am besten zwei
Konfigurationsschemata, genannt Arbeit und Heim. Hier
ist ein Beispiel eines network.opts Skriptes mit
schemaspezifischen Einstellungen:
case "$ADDRESS" in
Arbeit,*,*,*)
# Definition der Netzwerkkarte im Arbeit Schema
...
;;
Heim,*,*,*|default,*,*,*)
# Definition der Netzwerkkarte im zu Hause Schema
...
;;
esac
Der erste Teil einer PCMCIA-Geräteadresse ist immer das Konfigurationsschema. In diesem Beispiel wird der zweite Fall sowohl für das Heim, als auch für das default Schema verwendet. Wenn also das Schema aus irgendeinem Grund nicht gesetzt ist, wird automatisch das Heim Schema verwendet.
Um jetzt zwischen diesen beiden Sätzen von Einstellungen zu wählen, kann man eines dieser Kommandos starten:
cardctl scheme home
oder
cardctl scheme work
Das Kommando cardctl fährt alle Karten herunter und
startet diese neu. Dieses Kommando kann sicher verwendet werden,
unabhängig davon, ob das PCMCIA-System geladen ist. Es kann aber
fehlschlagen, wenn zur gleichen Zeit andere Geräte verwendet
werden. Dies ist unabhängig davon, ob diese Geräte von der
Einstellung des aktuellen Schemas abhängen oder nicht.
Um das gerade eingestellte Schema herauszufinden, kann dieses Kommando verwendet werden:
cardctl scheme
Das Root-Dateisystem auf einem PCMCIA-Gerät zu haben, ist
trickreich, da das PCMCIA-System von Linux nicht dazu gedacht ist, in
den Kernel fest eingebunden zu werden. Die Kernkomponenten,
die ladbaren Kernelmodule und der cardmgr Daemon hängen von
einem bereits laufenden System ab. Die initrd Möglichkeit des Kernels
umgeht diese Voraussetzungen dadurch, daß Linux erlaubt wird,
vorübergehend ein RAM-Laufwerk als minimales Root-Dateisystem zu verwenden,
die Treiber zu laden und dann ein anderes Root-Dateisystem an dessen
Stelle zu mounten. Das temporäre Root-Dateisystem kann dazu verwendet werden,
PCMCIA zu konfigurieren und dann ein PCMCIA-Gerät als
Root-Dateisystem einzurichten.
Einige Linuxdistributionen erlauben eine direkte Installation auf
Geräten, die direkt an einem PCMCIA-SCSI-Controller hängen,
als unbeabsichtigten Nebeneffekt der Unterstützung der
Installation von einem PCMCIA-SCSI-CD-ROM-Laufwerk. Kein
Installationsprogramm unterstützt die Konfiguration von
initrd, um Linux mit einem PCMCIA-Root-Dateisystem zu
booten. Um so ein System einzurichten, benötigt man ein anderes
Linuxsystem, um ein initrd Startprogramm zu erzeugen. Wenn ein
anderes Linuxsystem nicht verügbar ist, kann eine andere Option
die temporäre Installation eines minimalen Linuxsystems auf einem
Nicht-PCMCIA-Laufwerk, die Erzeugung eines initrd Startprogramms
und dann die Neuinstallation auf einem PCMCIA-Laufwerk sein.
Das Linux
Bootdisk HOWTO enthält einige generelle
Hinweise zur Erstellung von Bootdisketten aber nichts spezielles
zu initrd. Die Hauptdokumentation zu initrd ist im
Quellcode aktueller Kernelversionen in der Datei
linux/Documentation/initrd.txt enthalten. Bevor man
anfängt, sollte man diese Dokumentation lesen. Eine Vertrautheit
mit LILO ist ebenfalls hilfreich. Die Verwendung von
initrd erfordert, daß der Kernel mit den aktivierten
Optionen CONFIG_BLK_DEV_RAM und CONFIG_BLK_DEV_INITRD
übersetzt wurde.
Das Skript pcinitrd erzeugt ein initrd
Grundstartprogramm zum Booten mit einem PCMCIA-Root-Dateisystem.
Dies enthält eine minimale Verzeichnishierarchie, ein
paar Gerätedateien, einige ausführbare Programme, Bibliotheken
und einen Satz von PCMCIA-Treibermodulen. Wenn
pcinitrd aufgerufen wird, müssen die Treibermodule
angegeben werden, die verwendet werden sollen. Die
Kern-PCMCIA-Komponenten, pcmcia_core und ds, sind
automatisch enthalten.
Als ein Beispiel für den Fall, daß das Notebook einen
i82365-kompatiblen PCMCIA-Controller besitzt und Linux mit
dem Root-Dateisystem auf einer Festplatte installiert werden
soll, die an einem Adaptec SlimSCSI Controller angeschlossen
ist, würde man folgenden Befehl verwenden:
pcinitrd -v initrd pcmcia/i82365.o pcmcia/aha152x_cs.o
Um die Startsequenz von initrd anzupassen, kann das
Dateisystem mittels des loopback Gerätes eingefügt
werden:
mount -o loop -t ext2 initrd /mnt
Danach sollte das Skript linuxrc editiert werden. Die
PCMCIA-Konfigurationsdateien werden hierauf im Verzeichnis /etc
installiert und können ebenfalls angepaßt werden. Dazu
sollte die Manual Page von pcinitrd für weitere Informationen
gelesen werden.
Nach der Erstellung durch pcinitrd kann durch Kopieren des
Kernels, des gepackten initrd Startprogramms und einiger
Hilfsdateien für LILO auf eine leere Diskette eine
Bootdiskette erstellt werden. Im folgenden Beispiel nehmen wir an,
daß das benötigte PCMCIA-Root-Dateisystem auf
/dev/sda1 liegen soll:
mke2fs /dev/fd0
mount /dev/fd0 /mnt
mkdir /mnt/etc /mnt/boot /mnt/dev
cp -a /dev/fd0 /dev/sda1 /mnt/dev
cp [kernel-image] /mnt/vmlinuz
gzip < [initrd-image] > /mnt/initrd
Erzeuge dann /mnt/etc/lilo.conf mit diesem Inhalt:
boot=/dev/fd0
compact
image=/vmlinuz
label=linux
initrd=/initrd
read-only
root=/dev/sda1
Zum Schluß muß lilo aufgerufen werden:
/sbin/lilo -r /mnt
Wenn lilo mit der Option -r aufgerufen wird, so wird
es alle Aktionen relativ zu dem alternativ angegebenen
Root-Dateisystem durchführen. Der Grund für das Erzeugen der
Dateien unter /mnt/dev ist der, daß lilo nicht
in der Lage ist, die Dateien in /dev zu verwenden, wenn es in
diesem alternativen root Modus läuft.
Eine häufige Verwendung der initrd Möglichkeit ist
der Gebrauch auf Systemen, wo die eingebaute Festplatte einem anderen
Betriebssystem gewidmet ist. Der Linux-Kernel und das initrd
Startprogramm können auf einer Nicht-Linux-Partition
untergebracht werden und LILO oder LOADLIN
können so konfiguriert werden, daß sie Linux von dort
starten können.
Ausgehend von der Annahme, daß der Kernel für das
entsprechende Root-Laufwerk konfiguriert wurde und das
initrd Startprogramm auf einem anderen System erstellt wurde,
ist der einfachste Weg, Linux mit LOADLIN zu starten:
LOADLIN <kernel> initrd=<initrd-image>
Wenn Linux erst einmal auf der Zielmaschine gestartet wurde,
dann kann LILO installiert werden, um Linux direkt zu starten.
Als Beispiel sei /dev/hda1 die Nicht-Linux-Zielpartition und
/mnt ein freies Verzeichnis zum Mounten der Partition.
Als erstes muß ein Unterverzeichnis für Linux auf dieser
Partition geschaffen werden:
mount /dev/hda1 /mnt
mkdir /mnt/linux
cp [kernel-image] /mnt/linux/vmlinuz
cp [initrd-image] /mnt/linux/initrd
Wenn in diesem Beispiel /dev/sda1, ein SCSI-Laufwerk, auf welches
über einen PCMCIA-Controller zugegriffen wird, die
Root-Partition von Linux enthalten soll, so muß zur Installation von
LILO eine Datei lilo.conf mit folgendem Inhalt
erstellt werden:
boot=/dev/hda
map=/mnt/linux/map
compact
image=/mnt/linux/vmlinuz
label=linux
root=/dev/sda1
initrd=/mnt/linux/initrd
read-only
other=/dev/hda1
table=/dev/hda
label=windows
Die boot= Zeile besagt, daß LILO im Master
Boot Record (MBR) des angegebenen Gerätes installiert werden soll. Die
root= Zeile kennzeichnet das gewünschte
Root-Dateisystem, welches später für den Gebrauch des
initrd Startprogramms verwendet werden soll, und kann
überflüssig sein, wenn der Kernel schon entsprechend
konfiguriert worden ist. Der other= Abschnitt beschreibt das
andere Betriebssystem, das auf /dev/hda1 liegt.
Um LILO in diesem Fall zu installieren, sollte dies verwendet werden:
lilo -C lilo.conf
Beachten Sie, daß in diesem Fall die Datei lilo.conf
absolute Pfadnamen verwendet, die /mnt enthalten. David tat
dies in diesem Beispiel, da das Zieldateisystem eventuell die
Einrichtung von Linux Gerätedateien für die boot=
und root= Optionen nicht unterstützt.