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.