Theoretisch sollte es egal sein, welcher Interrupt von welchem
Gerät verwendet wird, solange nicht zwei Geräte so
konfiguriert sind, daß sie die gleichen verwenden. In der Datei
/etc/pcmcia/config.opts
können bestimmte Interrupts, die
bei nicht-PCMCIA Geräten Verwendung finden, ausgeschlossen
werden.
Ähnlich können keine bestimmten I/O Adressen für den
Gebrauch mit PCMCIA Karten angegeben werden. Die Datei
/etc/pcmcia/config.opts
erlaubt einem, einen Bereich von
verfügbaren Adressen für den Gebrauch aller PCMCIA
Geräte anzugeben oder 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 einem Grundmodul (i82365
oder
tcic
) für die Überwachung der Slots bereits
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 eine 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 einer Interruptzeile: Bit 0 ist irq
0, Bit 1 irq 1 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
erreicht man durch setzen lediglich eines Bits. 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 leichte 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 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 gestartet werden:
cardctl scheme
Ein root Dateisystem auf einem PCMCIA Gerät zu haben ist
trickreich, da PCMCIA Systeme nicht dazu vorgesehen sind in den Kernel
eingebunden zu werden. Die Kernkomponenten, die ladbaren Kernelmodule
und der cardmgr
Dämon, hängen von dem aktuell
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 anzubinden. Das
kurzfristige 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 unbeabsichtigter Nebeneffekt zur Unterstützung der
Installation von einem PCMCSI SCSI CDROM 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ärere Installation eines minimalen Linux auf einem
nicht-PCMCIA Laufwerk, Erzeugung eines initrd
Startprogramms
und dann 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.
pcinitrd
Das Skript pcinitrd
erzeugt ein initrd
Grundstartprogramm zum booten mit einem PCMCIA root
Dateisystem. Dies enthält eine minmale Verzeichnishierarchie, ein
paar Gerätedateien, einige ausführbare Programme, shared
libraries 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 man page von pcinitrd für weitere Informationen
gelesen werden.
initrd
BootdisketteNach der Erstellung durch pcinitrd
kann durch kopieren des
Kernels, dem gepackten initrd
Startprogramm und einiger
Hilfsdateien für lilo auf eine leere Floppy 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.
initrd
Startprogramm auf einemnicht-Linux LaufwerkEine häfige 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
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 Zielmaschiene gestartet wurde,
kann dann lilo
installiert werden um Linux direkt zu starten.
Als Beispiel sei /dev/hda1
die nicht-Linux Zielpartition und
/mnt
ein freies Verzeichnis zum Anschluß der Partition.
So muß als erstes 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ß der lilo
im Master
Boot Record (MBR) des angegebenen Gerätes liegen 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, daß auf /dev/hda1
liegt.
Um lilo
in diesem Fall zu installieren, sollte dies verwendet
werden:
lilo -C lilo.conf
Beachte, 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.