Linux BootPrompt HOWTO Paul Gortmaker (Paul.Gortmaker@anu.edu.au) und Antje Faber (af@caldera.de) v1.13-3, 1. Februar 1998 Dies ist das BootPrompt HOWTO, welches eine Zusammenstellung aller möglichen Bootparameter enthält, die während des Bootvorgangs an den Linux-Kernel geschickt werden können. Hierbei sind alle Kernel- und Geräteparameter eingeschlossen. Es wird diskutiert, wie der Kernel Bootparameter sortiert und man erhält einen Überblick über die bekan­ nteste Software, die zum Booten von Linux-Kerneln verwendet wird. 1. Einführung Der Kernel verfügt über eine begrenzte Fähigkeit, während des Bootvorgangs Informationen in Form einer Kommandozeile anzunehmen, ähnlich einer Parameterliste, die man einem Programm übergeben würde. Dies dient im allgemeinen dazu, den Kernel mit Informationen über Hardwareparameter zu versorgen, die der Kernel alleine nicht bestimmen könnte oder die Werte zu vermeiden/übergehen, die der Kernel anderenfalls erkennen würde. Will man jedoch lediglich ein Kernelimage direkt auf Diskette kopieren (z.B. cp zImage /dev/fd0), dann erhält man nicht die Möglichkeit, einen Parameter für diesen Kernel festzulegen. Deshalb werden die meisten Linux-Anwender Software wie LILO oder loadlin verwenden, die diese Parameter an den Kernel weiterleitet und ihn anschließend bootet. Wichtiger Hinweis für die Verwendung von Modulen: Ein Kennzeichen von Bootprompt-Parametern ist die ausschließliche Anwendung auf Hardware- Treiber, die direkt in den Kernel einkompiliert sind. Sie haben keine Auswirkung auf Treiber, die als Module geladen werden. Die meisten Distributionen verwenden Module. Sollten Zweifel bestehen, sollte man man depmod und man modprobe zusammen mit /etc/conf.modules anschauen. Die derzeitige Ausgabe dieses Textes behandelt Kernel bis einschließlich Version 2.0.33. Es werden ebenfalls einige Eigenschaften dokumentiert, die ausschließlich bei den Entwicklerversionen des Kernels (bis Version 2.1.84) vorkommen. Man beachte, daß die speziellen Bootprompt-Parameter für Rechner, die keine i386 kompatible CPU enthalten (speziell Atari/Amiga), zur Zeit undokumentiert sind. 1.1. Ablehnungshinweise und Copyright Dieses Dokument ist kein Evangelium. Es bietet jedoch möglicherweise die aktuellste Information, die man finden kann. Jeder ist selbst dafür verantwortlich, was mit der eigenen Hardware geschieht. Falls die Hardware in Rauch und Flammen aufgeht, was eigentlich unmöglich ist, übernehme ich dafür keine Verantwortung. Falls Sie beabsichtigen, dieses Dokument in eine Veröffentlichung aufzunehmen, nehmen Sie bitte Kontakt mit mir auf. Ich werde dann mein Möglichstes tun, Ihnen die aktuellsten Informationen zur Verfügung zu stellen. In der Vergangenheit wurden längst überholte Versionen der Linux-HOWTO-Dokumente veröffentlicht, was den Entwicklern ständigen Kummer bereitete, da sie mit Fragen gequält wurden, die in den neueren Versionen bereits beantwortet waren. Dieses Dokument ist urheberrechtlich geschützt. Das Copyright für die englische BootPrompt HOWTO, auf der dieses Dokument basiert, liegt bei Paul Gortmaker. Das Copyright für die deutsche Version liegt bei Caldera GmbH (Antje Faber) und Marco Budde. Das Dokument darf gemäß der GNU General Public License verbreitet werden. Insbesondere bedeutet dies, daß der Text sowohl über elektronische wie auch physikalische Medien ohne die Zahlung von Lizenzgebühren verbreitet werden darf, solange dieser Copyright- Hinweis nicht entfernt wird. Eine kommerzielle Verbreitung ist erlaubt und ausdrücklich erwünscht. Bei einer Publikation in Papierform ist das Deutsche Linux HOWTO Projekt hierüber zu informieren. 1.2. Weitere Dokumentationen Die aktuellsten Dokumentationen werden immer die Kernel-Quelldateien selbst sein. Aber keine Angst, man benötigt keine Programmierkenntnisse zum Lesen der Anmerkungen in den Quelldateien. Will man zum Beispiel wissen, welche Parameter vom AHA1542 SCSI- Treiber erkannt werden, dann geht man ins Verzeichnis linux/drivers/scsi und wirft einen Blick auf die Datei aha1542.c. Dort findet man bereits in den ersten 100 Zeilen eine einfache Beschreibung (auf Englisch) der Bootparameter, die der 1542-Treiber erkennt. Die nächstbeste Informationsquelle sind die Dokumentationsdateien, die mit dem Kernel selbst ausgeliefert werden. Es gibt bereits einige davon und die meisten können im Verzeichnis linux/Documentation und seinen Unterverzeichnissen gefunden werden. Das Verzeichnis linux findet sich normalerweise unter /usr/src/. Es existieren einige README.foo-Dateien, die sich in dem jeweiligen Treiber-Verzeichnis befinden (z.B. linux/drivers/XXX/, wobei XXX scsi, char oder net ist). Hat man sich für bestimmte Bootparameter entschieden und will nun herausfinden, wie man die Information an den Kernel weitergibt, sollte man einen Blick auf die Dokumentation der Software, wie z.B. LILO oder loadlin werfen, die zum Booten des Kernels verwendet wird. Nachfolgend wird ein kurzer Überblick gegeben, der jedoch keinen Ersatz für die mit der Bootsoftware ausgelieferte Dokumentation darstellt. 1.3. Linux Newsgruppen Bei Fragen über die Weitergabe von Bootparametern an den Kernel sollte zuerst dieses Dokument gelesen werden. Falls dieses Dokument und die oben genannte Dokumentation die Fragen nicht klären können, dann kann man sich an die Linux-Newsgruppen wenden. Natürlich sollte man zuerst die älteren Artikel der Newsgruppe lesen, anstatt blindlings eine Frage zu stellen. Es ist nämlich gut möglich, daß dieselbe Frage bereits gestellt wurde oder möglicherweise sogar zu den Frequently Asked Questions (häufig gestellte Fragen) gehört. Ein schneller Blick auf die Linux-FAQs ist eine gute Idee. Die FAQ sollte man in der Nähe der Ursprungsseite dieses Dokuments finden. Allgemeine Fragen über die Systemkonfiguration sollte man an die Newsgruppe de.comp.os.unix.linux.misc richten. Wir bitten darum, sich an diese allgemeinen Richtlinien zu halten und vor allem eine Frage nicht gleichzeitig in mehreren Gruppen zu stellen. 2. Übersicht über die BootPrompt-Parameter In diesem Abschnitt werden einige Programme vorgestellt, die zur Weiterleitung von Kernel-Bootparametern zum Kernel selbst verwendet werden können. Es wird ebenfalls erklärt, wie die Parameter verarbeitet werden, welchen Beschränkungen sie unterliegen und wie sie zu jedem passenden Gerät, für das sie bestimmt sind, weitergeleitet werden. Man sollte unbedingt beachten, daß innerhalb eines Bootparameters keine Leerstellen verwendet werden sollten, nur zwischen getrennten Parametern. Mehrere Werte für einen Parameter müssen durch ein Komma getrennt werden und zwar wiederum ohne Leerstellen. Richtig wäre z.B. dieses Beispiel: ether=9,0x300,0xd0000,0xd4000,eth0 root=/dev/hda1 Nachfolgendes Beispiel ist hingegen falsch: ether = 9, 0x300, 0xd0000, 0xd4000, eth0 root = /dev/hda1 2.1. LILO (LInux LOader) LILO (LInux LOader) von Werner Almesberger ist das am häufigsten verwendete Programm zur Übergabe der Parameter. Das Programm hat die Fähigkeit, verschiedene Kernel bzw. Betriebssysteme zu booten. Die meisten Distributionen verwenden standardmäßig LILO, um Linux und z.B. auch Windows zu starten. LILO kann DOS, Windows, OS/2, Linux, FreeBSD, etc. ohne Schwierigkeiten booten und ist zudem äußerst flexibel. Nach dem Einschalten des Computers wird bei den meisten Installationen LILO gestartet. Drückt der Anwender nach der Meldung LILO die TAB- Taste, so gelangt er zum Prompt von LILO. Ansonsten wird nach eine festgelegten Zeit automatisch das Standardsystem gestartet. In der Regel wird hier durch die Eingabe eines label-Eintrages aus /etc/lilo.conf das zu startende Betriebssystem bzw. Linux Kernel ausgewählt. Typisch sind Labels wie linux, backup und msdos. Falls ein Bootparameter an den Kernel übergeben werden soll, kann man dies an dieser Stelle tun. Der Parameter wird einfach, durch ein Leerzeichen getrennt, an das Label angehängt. Folgendes Beispiel soll dies verdeutlichen: LILO: linux root=/dev/hda1 In der Regel möchte man natürlich nicht bei jedem Booten die Parameter per Hand eingeben müssen. Hier hilft die Option append=, die der Konfigurationsdatei von LILO hinzugefügt werden kann und deren Parameter dann automatisch an den Kernel übergeben werden. Man muß einfach nur etwas wie append = "foo=bar" in die Datei /etc/lilo.conf einfügen. Dieses kann entweder am Anfang der Datei eingefügt werden, so daß die Parameter für alle Abschnitte der Datei gültig sind, oder in den Abschnitt eines bestimmten Kernels, so daß nur diesem die Parameter übergeben werden. Eine ausführliche Beschreibung ist in der ausgezeichneten Dokumentation von LILO zu finden. 2.2. loadlin Ein anderer weitverbreiteter Linux-Loader ist loadlin. Dies ist ein DOS-Programm, das die Fähigkeit besitzt, einen Linux-Kernel vom DOS- Prompt aus zu starten, wobei Bootparameter übergeben werden können. Sehr nützlich ist die Möglichkeit, Linux von DOS aus zu starten, wenn man bestimmte Hardware besitzt, die von Linux erst dann unterstützt wird, wenn sie von dem der Hardware beiliegenden DOS-Treiber in einen bestimmten Zustand versetzt worden ist. Ein gutes Beispiel sind die Soundblaster-kompatiblen Soundkarten, welche den DOS-Treiber benötigen, um ein paar geheimnisvolle Register ziehen zu können, um die Karte in einen SB-kompatiblen Modus zu bringen. Das Booten von DOS mit dem zur Verfügung stehenden Treiber und das anschließende Laden von Linux mit loadlin vom DOS-Prompt aus verhindert das Zurückschalten der Karte in den vorherigen Zustand, was beim erneuten Booten der Fall wäre. So jedoch bleibt die Karte in einem SB-kompatiblen Modus und ist somit unter Linux verwendbar. Auch Plug&Play Hardware kann auf diese Art und Weise initialisiert werden. Es gibt auch noch andere Programme, die zum Booten von Linux verwendet werden können. Auf dem lokalen Linux-FTP-Server erhält man unter system/Linux-boot/ die komplette Liste aller verfügbaren Programme. 2.3. Das Hilfsprogramm »rdev« Es gibt einige Kernel-Bootparameter, deren Standardwerte an bestimmten Stellen im Kernel-Image selbst gespeichert sind. Es gibt ein Hilfsprogramm namens rdev, das auf den meisten Systemen installiert ist und das weiß, wo sich diese Werte befinden und wie sie geändert werden können. Dieses Hilfsprogramm kann auch Dinge ändern, die kein Kernel-Bootparameter-Äquivalent besitzen, wie z.B. der standardmäßig verwendete Grafik-Modus. Das Hilfsprogramm rdev ist gewöhnlich auch unter den Namen swapdev, ramsize, vidmode und rootflags aufrufbar. Diese Namen zeigen die fünf Änderungsmöglichkeiten durch rdev an: das Root-Device, das Swap- Device, die RAM-Disk-Parameter, der Standard-Grafik-Modus sowie die readonly/readwrite-Einstellung vom Root-Device. Weitere Informationen über rdev erhält man nach Eingabe von rdev -h oder durch die Lektüre der bereitgestellten Manpage (man rdev). 2.4. Sortierung der Parameter durch den Kernel Die meisten Bootparameter sind folgendermaßen strukturiert: name[=wert_1][,wert_2]...[,wert_11] name ist hierbei ein einzigartiges Schlüsselwort, das Aufschluß darüber gibt, für welchen Teil des Kernels die entsprechenden Werte bestimmt sind. Mehrere Bootparameter werden als Liste nach obigem Format an den Kernel übergeben, wobei die einzelnen Parameter durch Leerzeichen getrennt werden. Man beachte das tatsächliche Limit von 11 Parametern. Der bestehende Code kann nur 11 durch Kommas getrennte Parameter pro Schlüsselwort verarbeiten. In ungewöhnlich komplizierten Fällen kann man jedoch dasselbe Schlüsselwort mit 11 zusätzlichen Parametern erneut benutzen, vorausgesetzt, die Setup-Funktion unterstützt dies. Man beachte auch, daß der Kernel die Liste in maximal zehn Ganzzahlen-Parameter und eine anschließende Zeichenfolge unterteilt. Das heißt, man kann nicht wirklich 11 Ganzzahlen bereitstellen; dies ist höchstens durch Konvertierung des 11ten Parameters von einer Zeichenkette in eine Ganzzahl im Treiber selbst möglich. Die Sortierung findet hauptsächlich in linux/init/main.c statt. Zuerst überprüft der Kernel, ob der Parameter zu einem der speziellen Parameter wie root=, ro, rw oder debug gehört. Die Bedeutung dieser speziellen Parameter wird im weiteren Verlauf dieser Dokumentation beschrieben. Der Kernel durchsucht dann eine Liste von Setup-Funktionen, die im bootsetups-Array gespeichert ist, um zu sehen, ob ein Treiber oder ein Teil des Kernels für die entsprechende Zeichenkette, wie z.B. foo, eine Setup-Funktion setup_foo() registriert hat. Würde man dem Kernel die Zeile foo=3,4,5,6,bar übergeben, dann würde dieser den bootsetups- Array durchgehen, um herauszufinden, ob foo registriert ist. Falls dies der Fall wäre, würde der Kernel die Setup-Funktion, die mit foo verbunden ist, aufrufen und dieser die Ganzzahlen-Parameter 3, 4, 5 und 6 übergeben, wie sie auf der Kernel-Kommandozeile angegeben wurden. Außerdem würde er ebenfalls die Zeichenkette bar übergeben. 2.5. Umgebungsvariablen setzen Alles, was aussieht wie foo=bar und nicht als Setup-Funktion akzeptiert wird, wie oben beschrieben, wird dann als zu setzende Umgebungsvariable interpretiert. Ein Beispiel wäre die Verwendung von TERM=vt100 als Bootparameter. 2.6. Weitergabe von Parametern zum »init«-Programm Alle verbleibenden Parameter, die der Kernel nicht selbst verwendet und nicht als Umgebungsvariablen interpretiert, werden zum ersten Prozeß weitergeleitet. Dieser ist normalerweise das init-Programm. Meistens wird dem init-Programm per Bootparameter mitgeteilt, mit welchem Runlevel Linux gebootet werden soll. So kann init angewiesen werden, den Rechner im Ein-Benutzer-Modus zu booten und die üblichen Dämonen nicht zu starten. Um herauszufinden, welche Parameter von der auf Ihrem System installierten Version von init akzeptiert werden, lesen Sie bitte die entsprechende Manual Page. 3. Allgemeine, geräteunabhängige Bootparameter Hierbei handelt es sich um Bootparameter, die mit keinem speziellen Hardware-Treiber verknüpft sind. Statt dessen beeinflussen sie einige bestimmte intere Kernel-Parameter wie z.B. den Umgang mit dem Speicher, mit der RAM-Disk, dem Root-Dateisystem und anderen. 3.1. Root-Dateisystem Optionen Folgende Optionen beziehen sich alle auf das Vorgehen des Kernels bei der Auswahl und dem Umgang mit dem Root-Dateisystem. 3.1.1. Der Parameter »root=« Dieser Parameter teilt dem Kernel mit, welches Device beim Booten als Root-Dateisystem benutzt werden soll. Als Standardeinstellung benutzt der Kernel das Device, das auf dem System, auf dem der Kernel erzeugt wurde, das Root-Dateisystem enthielt. Wurde der fragliche Kernel z.B. auf einem System kompiliert, das /dev/hda1 als Root-Partition verwendete, dann geht der Kernel davon aus, daß sich das Root- Dateisystem auf /dev/hda1 befindet. Will man diesen Standardwert außer Kraft setzen und z.B. das zweite Diskettenlaufwerk als Root-Device verwenden, würde man root=/dev/fd1 wählen. Gültige Root-Devices sind: · /dev/hdaN bis /dev/hddN: Partition N auf der ST-506-kompatiblen (IDE) Festplatte a bis d · /dev/sdaN bis /dev/sdeN: Partition N auf der SCSI-kompatiblen Festplatte a bis e · /dev/xdaN bis /dev/xdbN: Partition N auf der XT-kompatiblen Festplatte a bis b · /dev/fdN: Diskettenlaufwerk mit der Nummer N. N=0 wäre das DOS- Laufwerk »A:« und N=1 wäre »B:«. · /dev/nfs: Dieses ist nicht wirklich ein Device, sondern teilt dem Kernel lediglich mit, daß das Root-Dateisystem über das Netzwerk geholt werden soll. Die schwierigere und weniger portable numerische Bestimmung der oben genannten, möglichen Devices für Festplatten im Major-/Minor-Format wird auch akzeptiert. So entspricht z.B. Major 8, Minor 3 der Partition /dev/sda3, so daß man alternativ root=0x803 verwenden könnte. Dies ist einer der wenigen Kernel-Bootparameter, dessen Standard im Kernelimage gespeichert ist, und welcher deshalb mit dem Hilfsprogramm rdev geändert werden kann. 3.1.2. Der Parameter »ro« Wenn der Kernel bootet, wird dabei ein Root-Dateisystem benötigt, um grundlegende Dinge davon abzulesen. Dies ist das Root-Dateisystem, das beim Booten gemountet wird. Wird das Root-Dateisystem jedoch mit Schreibrecht gemountet, kann keine verläßliche Überprüfung der Integrität des Dateisystems vorgenommen werden, weil z.B. gleichzeitig ein anderer Prozeß eine Datei bearbeitet und damit das zu prüfende Dateisystem verändert. Mit der Option ro wird der Kernel aufgefordert, das Root-Dateisystem nur mit Leserecht (engl. readonly) zu mounten, so daß Programme zur Konsistenzprüfung des Dateisystems (fsck) mit Sicherheit annehmen können, daß keinerlei halb geschriebene Dateien existieren, während die Überprüfung stattfindet. Kein Programm oder Prozeß kann Dateien des fraglichen Dateisystems verändern, bis es nicht mit Lese-/Schreibrecht wieder gemountet ist. Auch diese Einstellung ist im Kernelimage gespeichert und kann deshalb mit dem Programm rdev verändert werden. 3.1.3. Der Paramater »rw« Dieser Parameter ist das exakte Gegenteil vom eben Genannten. Hier wird der Kernel nämlich aufgefordert, das Root-Dateisystem mit Lese-/Schreibrecht zu mounten. Die Standardeinstellung ist sowieso das Mounten des Root-Dateisystems mit Lese-/Schreibrecht. Man sollte auf keinen Fall Programme vom Typ »fsck« auf einem Dateisystem laufen lassen, das mit Lese-/Schreibrecht gemountet wurde. Der bereits oben erwähnte, in der Image-Datei gespeicherte Wert ist der gleiche, der auch für diesen Parameter verwendet wird. Der Zugriff darauf erfolgt über rdev. 3.2. Optionen der RAM-Disk-Verwaltung Folgende Optionen beziehen sich alle auf den Umgang des Kernels mit dem RAM-Disk-Device. Eine RAM-Disk wird hauptsächlich während der Installation einer Linux Distribution verwendet. Außerdem ist die RAM-Disk auch sehr nützlich, wenn der Kernel für den Zugriff auf das Root-Dateisystem zuerst Treiber laden muß, die als Modul kompiliert worden sind. 3.2.1. Das Kommando »ramdisk_start=« Damit ein Kernel-Image zusammen mit dem komprimierten Image einer RAM- Disk auf einer Diskette gespeichert werden kann, existiert der Parameter ramdisk_start=. Der Kernel kann nicht in das komprimierte Image des RAM-Disk Dateisystems aufgenommen werden, weil der Kernel beginnend mit Block Null auf der Diskette gespeichert werden muß, so daß das BIOS den Bootsektor laden kann. Dann kann der Kernel sich selbst erstmalig booten und damit zum Laufen bringen. Benutzt man ein unkomprimiertes Image einer RAM-Disk, dann kann der Kernel Teil dieses Images sein, das in die RAM-Disk geladen wird. Die Diskette kann mit LILO gebootet werden. Die beiden können auch getrennt sein wie bei den komprimierten Images. Verwendet man zwei Disketten, wobei sich auf der ersten der Kernel und auf der zweiten das Image einer RAM-Disk befindet, dann startet die RAM-Disk bei Block Null und es wird ein Offset von Null verwendet. Da dies der Standardwert ist, braucht man das Kommando in Wirklichkeit gar nicht benutzen. 3.2.2. Das Kommando »load_ramdisk=« Dieser Parameter teilt dem Kernel mit, ob ein Image einer RAM-Disk geladen werden soll oder nicht. Durch die Angabe von load_ramdisk=1 wird der Kernel veranlaßt, eine Diskette in die RAM-Disk zu laden. Der Standardwert ist Null, was bedeutet, daß der Kernel nicht versuchen soll, eine RAM-Disk zu laden. Eine komplette Beschreibung der neuen Bootparameter und deren Verwendung findet man in der Datei linux/Documentation/ramdisk.txt. Es wird auch beschrieben, wie dieser Parameter mit rdev im Kernel-Image gespeichert werden kann. 3.2.3. Das Kommando »prompt_ramdisk=« Dieser Parameter teilt dem Kernel mit, ob der Anwender aufgefordert werden soll, die Diskette mit dem Image der RAM-Disk einzulegen. Bei einer Konfiguration mit einer Diskette befindet sich das Image der RAM-Disk auf der gleichen Diskette wie der Kernel, der gerade den Lade-/Bootvorgang beendet hat. Somit wird eine Nachfrage nicht benötigt. In diesem Fall kann man prompt_ramdisk=0 verwenden. Bei einer Konfiguration mit zwei Disketten wird man die Möglichkeit des Diskettentauschs benötigen. Somit kann prompt_ramdisk=1 verwendet werden. Da dies der Standardwert ist, muß er eigentlich nicht angegeben werden. Früher haben raffinierte Anwender die Option vga=ask von LILO verwendet, um den Bootprozeß zeitweilig zu stoppen und ein Wechsel von der Boot- zur Rootdiskette zu ermöglichen. Eine komplette Beschreibung der neuen Bootparameter und deren Benutzung findet man in der Datei linux/Documentation/ramdisk.txt Es wird auch beschrieben, wie dieser Parameter bestimmt und via rdev im Kernel-Image gespeichert werden kann. 3.2.4. Das Kommando »ramdisk_size=« Zwar stimmt es, daß die RAM-Disk je nach Bedarf dynamisch wächst, jedoch gibt es eine Obergrenze für ihre Größe, so daß nicht der gesamte Speicher verbraucht wird und es zu Problemen kommt. Der Standardwert ist 4096 (4 MB), was den meisten Ansprüchen genügen sollte. Mit diesem Bootparameter kann man den Standardwert verringern oder vergrößern. Eine komplette Beschreibung der neuen Bootparameter und deren Benutzung findet man in der Datei linux/Documentation/ramdisk.txt Es wird auch beschrieben, wie dieser Parameter bestimmt und via rdev im Kernel-Image gespeichert werden kann. 3.2.5. Das Kommando »ramdisk=« (veraltet) Dieser Parameter ist veraltet und sollte nicht verwendet werden, es sei denn für die Kernelversion v1.3.47 oder ältere. Die Parameter, die heute für das RAM-Disk-Device verwendet werden sollten, sind oben beschrieben. Mit dem Parameter wird die Größe RAM-Disk-Devices in KByte angeben. Würde man z.B. ein Root-Dateisystem auf einer 1,44 MB Diskette in ein RAM-Disk-Device laden wollen, würde man folgendes Kommando verwenden: ramdisk=1440 Dies ist einer der wenigen Kernel-Bootparameter, dessen Standardwert im Kernel-Image gespeichert ist und der somit mit dem Hilfsprogramm rdev verändert werden kann. 3.2.6. Das Kommando »noinitrd« Kernel v2.x und neuere verfügen über ein Feature, bei dem das Root- Dateisystem anfangs eine RAM-Disk ist und der Kernel /linuxrc auf diesem RAM-Image ausführt. Dieses Feature wird typischerweise dazu verwendet, das Laden von Modulen zu ermöglichen, die zum Mounten des eigentlichen Root-Dateisystems benötigt werden. So können z.B. die Module des SCSI-Treibers von dem Image der RAM-Disk geladen werden und anschließend wird das eigentliche Root-Dateisystem auf einer SCSI- Festplatte gemountet. Der eigentliche noinitrd-Parameter bestimmt, was mit den initrd-Daten passiert, nachdem der Kernel gebootet wurde. Wenn dieser Parameter gesetzt wird, werden die Daten nicht auf eine RAM-Disk konvertiert, sondern es kann auf diese Daten unter /dev/initrd zugegriffen werden. Dieser Zugriff ist nur einmal möglich, bevor der Speicher an das System zurückgegeben wird. Umfassende Informationen über die Benutzung der initial RAM-Disk erhält man unter linux/Documentation/initrd.txt. Zusätzlich sollten die neuesten Versionen von LILO und loadlin weitere nützliche Informationen enthalten. 3.3. Bootparameter für den Umgang mit dem Speicher Folgende Parameter ändern sich je nachdem, wie Linux den physikalischen oder virtuellen Systemspeicher erkennt oder mit ihm umgeht. 3.3.1. Der Parameter »mem=« Dieser Parameter dient zwei verschiedenen Zwecken: Der ursprüngliche Zweck war, die Größe des installierten Speichers oder einen kleineren Wert, falls man die Größe des für Linux verfügbaren Speichers verringern wollte, zu spezifizieren. Der andere, kaum verwendete Zweck ist die Bestimmung von mem=nopentium, was den Linux-Kernel auffordert, das 4 MB Seitentabellen-Performance-Feature nicht zu verwenden. Während des Bootvorganges ermittelt Linux durch einen BIOS-Aufruf die Größe des installierten Speichers. Leider ist die Größe, die dieser Aufruf zurückliefern kann, auf 64 MB begrenzt. Erinnert uns das irgendwie an das 1024 Zylinder Limit von IDE-Festplatten? Sind mehr als 64 MB RAM installiert, kann man Linux mit diesem Bootparameter mitteilen, wieviel Speicherplatz vorhanden ist. Hier ein Zitat von Linus über die Verwendung des mem= Parameters: Der Kernel wird alle mem=xx Parameter akzeptieren, die man ihm übergibt. Falls sich allerdings herausstellt, daß man gelogen hat, wird der Kernel früher oder später schrecklich abstürzen. Der Parameter legt die höchste ansprechbare RAM- Adresse fest, so daß z.B. mem=0x1000000 bedeutet, daß man 16 MB Speicher besitzt. Für einen Rechner mit 96 MB wäre der Bootparameter mem=0x6000000. Man sollte jedoch beachten, daß einige Rechner den obersten Teil des Speichers als Cache für das BIOS oder ähnliches benutzen, so daß man möglicherweise nicht wirklich die vollen 96 MB belegen kann. Auch das Gegenteil trifft zu: Einige Chipsätze werden den physikalischen Speicher, der vom BIOS belegt wird, auf den Bereich über dem Speichermaximum abbilden; d.h. der maximale Speicher wird in Wirklichkeit z.B. 96 MB + 384 kB betragen. Teilt man Linux mit, daß es über mehr als den tatsächlich vorhandenen Speicherplatz verfügt, dann wird dies schlimme Folgen haben; vielleicht nicht sofort, aber irgendwann mit Sicherheit. Man beachte, daß der übergebene Wert keine Hexadezimalzahl sein muß und daß die Endungen k bzw. M zur Bestimmung von Kilobytes bzw. Megabytes verwendet werden können, wobei Groß- oder Kleinschreibung keine Rolle spielen. k verursacht eine Verschiebung des Wertes um 10 Bit, während M eine Verschiebung um 20 Bit bewirkt. Die oben genannte Warnung hat insofern noch Gültigkeit, daß ein 96 MB Rechner mit mem=97920k laufen mag, jedoch mit mem=98304k oder mem=96M versagt. 3.3.2. Der Parameter »swap=« Hier wird dem Anwender die Feineinstellung eines Teils der virtuellen Speicherparameter ermöglicht, die mit Diskswapping zu tun haben. Folgende acht Parameter werden akzeptiert: MAX_PAGE_AGE PAGE_ADVANCE PAGE_DECLINE PAGE_INITIAL_AGE AGE_CLUSTER_FRACT AGE_CLUSTER_MIN PAGEOUT_WEIGHT BUFFEROUT_WEIGHT Interessierten Hackern sei die Lektüre von linux/mm/swap.c empfohlen. Auch sollten sie einen Blick in /proc/sys/vm werfen. 3.3.3. Der Parameter »buff=« Ähnlich dem swap=-Parameter wird dem Anwender die Feineinstellung einiger der Parameter für die Buffer-Speicherverwaltung ermöglicht. Folgende sechs Parameter werden akzeptiert: MAX_BUFF_AGE BUFF_ADVANCE BUFF_DECLINE BUFF_INITIAL_AGE BUFFEROUT_WEIGHT BUFFERMEM_GRACE Interessierten Hackern sei die Lektüre von linux/mm/swap.c empfohlen. Auch sollten sie einen Blick in /proc/sys/vm werfen. 3.4. Bootparameter für das NFS-Root-Dateisystem Linux unterstützt Systeme wie laufwerkslose Workstations, die ihr Root-Dateisystem per NFS (Network FileSystem) beziehen. Diese Parameter werden dazu verwendet, der laufwerkslosen Workstation mitzuteilen, von welchem Rechner sie ihr System erhält. Man beachte, daß der Parameter root=/dev/nfs benötigt wird. Detaillierte Informationen über die Verwendung eines NFS-Root-Dateisystems findet man in der Datei linux/Documentation/nfsroot.txt. Es wird empfohlen, diese Datei zu lesen, da folgende Informationen lediglich aus einer Zusammenfassung dieser Datei bestehen. 3.4.1. Der Parameter »nfsroot=« Dieser Parameter teilt dem Kernel mit, welcher Rechner, welches Verzeichnis und welche NFS-Optionen für das Root-Dateisystem verwendet werden sollen. Der Parameter ist folgendermaßen aufgebaut: nfsroot=[:][,] Wird der nfsroot-Parameter nicht auf der Kommandozeile angegeben, dann wird standardmäßig /tftpboot/%s verwendet. Andere mögliche Optionen sind: Bestimmt die IP-Adresse des NFS-Servers. Fehlt dieses Feld, dann wird die von der nfsaddrs-Variablen (siehe unten) bestimmte Default-Adresse verwendet. Dieser Parameter wird z.B. dazu verwendet, die Benutzung mehrerer Server für RARP und NFS zu ermöglichen. Normalerweise kann dieses Feld leer bleiben. Name des Verzeichnisses auf dem Server, das als root gemountet werden muß. Ist in der Zeichenkette ein %s-Token enthalten, dann wird der Token durch die ASCII-Darstellung der IP-Adresse des Clients ersetzt. Standard-NFS-Optionen. Alle Optionen sind durch Kommas getrennt. Fehlt das Optionen-Feld, werden folgende Standardwerte verwendet: port = wie vom Portmap-Daemon angegeben rsize = 1024 wsize = 1024 timeo = 7 retrans = 3 acregmin = 3 acregmax = 60 acdirmin = 30 acdirmax = 60 flags = hard, nointr, noposix, cto, ac 3.4.2. Der Parameter »nfsaddrs=« Dieser Bootparameter bestimmt die verschiedenen Adressen der Netzwerkschnittstellen, die zur Kommunikation über's Netzwerk benötigt werden. Wird dieser Parameter nicht angegeben, dann versucht der Kernel unter Verwendung von RARP und/oder BOOTP, diese Parameter herauszufinden. Der Syntax sieht folgendermaßen aus: nfsaddrs=:::::: IP-Adresse des Clients. Ist dieses Feld leer, wird die Adresse entweder durch RARP oder durch BOOTP bestimmt. Welches Protokoll verwendet wird, hängt von dem Parameter ab und davon, was während der Kernelkonfiguration aktiviert wurde. Ist dieser Parameter nicht leer, dann wird weder RARP noch BOOTP benutzt. IP-Adresse des NFS-Servers. Wird RARP zur Bestimmung der Client- Adresse verwendet und ist dieser Parameter nicht leer, dann werden nur Antworten vom festgelegten Server akzeptiert. Zur Verwendung verschiedener RARP- und NFS-Server bestimmt man hier den RARP-Server oder läßt das Feld leer und legt den NFS-Server mit dem nfsroot-Parameter fest (siehe oben). Bleibt dieser Eintrag aus, dann wird die Adresse des Servers verwendet, welcher auf die RARP- oder BOOTP-Anfrage geantwortet hat. IP-Adresse eines Gateways, falls der Server sich in einem anderen Subnetz befindet. Ist dieser Eintrag leer, dann wird kein Gateway verwendet und es wird angenommen, daß sich der Server im lokalen Netzwerk befindet, außer wenn durch BOOTP ein Wert empfangen wird. Netmask für die lokale Netzwerkschnittstelle. Ist dieser Eintrag leer, dann wird die Netmask von der Client-IP-Adresse abgeleitet, wenn nicht durch BOOTP ein Wert empfangen wird. Name des Clients. Bleibt dieses Feld leer, dann wird die Client- IP-Adresse in ASCII-Notation verwendet oder der durch BOOTP empfangene Wert. Name des zu verwendenden Netzwerk-Devices. Ist dieses Feld leer, dann werden alle Devices für RARP-Anfragen verwendet und das erste Device für BOOTP. Für NFS wird das Device benutzt, von dem entweder RARP- oder BOOTP-Antworten empfangen wurden. Besitzt man nur ein Device, kann man dieses Feld getrost leer lassen. Zu verwendende Methode für die automatische Konfiguration. Ist dieses entweder rarp oder bootp, dann wird das angegebene Protokoll verwendet. Ist der Wert both oder leer, dann werden beide Protokolle in dem Umfang verwendet, wie es ihnen während der Kernelkonfiguration ermöglicht wurde. Der Eintrag none schließt die automatische Konfiguration aus. In diesem Fall müssen alle notwendigen Werte in den vorherigen Feldern bestimmt werden. Der Parameter kann alleine als Wert für den Parameter nfsaddrs erscheinen, wobei die ganzen »:«-Zeichen davor entfallen. In diesem Fall wird die automatische Konfiguration verwendet. Jedoch ist der Wert none in diesem Fall nicht verfügbar. 3.5. Weitere verschiedene Kernel-Bootparameter Diese verschiedenen Bootparameter erlauben dem Benutzer die Feineinstellung bestimmter interner Parameter. 3.5.1. Der Parameter »debug« Mittels der Funktion printk() schickt der Kernel wichtige und weniger wichtige Nachrichten an den Administrator. Wird die Nachricht als wichtig angesehen, dann wird die Funktion printk() eine Kopie auf der aktuellen Konsole ausgeben und sie an klogd() übergeben, so daß sie auf Festplatte gespeichert wird. Der Grund für die Ausgabe wichtiger Nachrichten auf der Konsole und gleichzeitiger Protokollierung auf der Festplatte liegt darin, daß unter unglücklichen Umständen wie z.B. einem Plattenausfall die Nachricht nicht zur Festplatte gelangt und somit verloren geht. Der Grenzwert dafür, was als wichtig oder nicht wichtig betrachtet wird, wird von der Variablen console_loglevel festgelegt. Standardmäßig wird alles, was wichtiger ist als DEBUG (Level 7), auf der Konsole ausgegeben. Die verschiedenen Level sind in der Include- Datei kernel.h definiert. Das Festlegen von debug als Bootparameter setzt den Grenzwert der Konsole auf 10, so daß alle Mitteilungen des Kernels auf der Konsole erscheinen. Der Grenzwert der Konsole kann normalerweise auch bei der Ausführung mittels einer Option des Programmes klogd festgelegt werden. Informationen darüber kann man der Manpage zu der auf dem System installierten Version entnehmen. 3.5.2. Der Parameter »init=« Der Kernel wird beim Booten immer das init-Programm starten, welches getty-Programme startet, »rc«-Skripts laufen läßt, u.ä. und somit den Rechner für die Benutzer einrichtet. Der Kernel schaut zuerst nach /sbin/init, dann nach /etc/init und als letzte Möglichkeit wird er versuchen, /bin/sh zu verwenden (möglicherweise auf /etc/rc). Wurde z.B. das init-Programm verfälscht und somit das Booten unmöglich gemacht, dann kann man einfach am Bootprompt init=/bin/sh verwenden, was beim Booten direkt eine Shell öffnet und somit ein Ersetzen des verfälschten Programms ermöglicht. 3.5.3. Der Parameter »no387« Einige i387 Koprozessoren haben Fehler, die sich bei der Verwendung im 32 Bit Protected Mode zeigen. Einige der frühen i387 Koprozessoren von ULSI verursachen z.B. massive Totalsperren während der Ausführung von Fließkomma-Berechnungen, was offensichtlich ein Bug in den FRSAV/FRRESTOR Anweisungen ist. Die Verwendung des Bootparameters no387 veranlaßt Linux, den mathematischen Koprozessor zu ignorieren, sogar wenn einer vorhanden ist. Natürlich muß der Kernel dann so kompiliert werden, daß sich die Emulation eines Koprozessors im Kernel befindet. Dies ist möglicherweise auch dann sinnvoll, wenn man einen dieser wirklich alten i386er hat, die einen 80287 FPU verwenden können, da Linux keine 80287 FPUs unterstüzt. 3.5.4. Der Parameter »no-hlt« Die Familie der i386 CPUs und deren Nachfolger verfügen über die Anweisung »hlt«, die der CPU mitteilt, daß nichts geschehen wird, solange nicht ein externes Gerät (Tastatur, Modem, Platte, etc.) die CPU auffordert, eine Aufgabe auszuführen. Dieses erlaubt der CPU in einen Modus zu schalten, in dem weniger Energie verbraucht wird. In diesem Modus verharrt sie wie ein Zombie, bis sie von einem externen Gerät, gewöhnlich durch einen Interrupt, geweckt wird. Einige der frühen i486DX-100 CPUs hatten insofern ein Problem mit der Anweisung »hlt«, daß sie nach deren Ausführung nicht mehr verläßlich in den Betriebsmodus zurückkehren konnten. Durch die Benutzung der Anweisung no-hlt wird Linux mitgeteilt, einfach eine Endlosschleife zu durchlaufen, wenn es nichts anderes zu tun gibt und die CPU nicht zu stoppen, wenn es keine aktiven Prozesse gibt. Dieses ermöglicht Benutzern mit solchen »defekten« CPUs die Verwendung von Linux, obwohl sie gut beraten wären, sich durch eine möglicherweise noch vorhandene Garantie einen Ersatz zu suchen. 3.5.5. Der Parameter »no-scroll« Die Angabe dieses Parameters beim Booten setzt Bildlauf-Features außer Kraft, die die Verwendung von Braille-Terminals erschweren. 3.5.6. Der Parameter »panic=« Für den unwahrscheinlichen Fall einer Kernel-Panik wird für gewöhnlich gewartet, bis jemand vorbeikommt, die Nachricht der Panik auf dem Bildschirm entdeckt und den Rechner neu bootet. Bei einer Kernel-Panik handelt es sich um einen internen Fehler, der von Kernel erkannt und als ernst genug erachtet wurde, um sich laut zu beschweren und dann alles zu stoppen. Falls sich ein Rechner jedoch unbewacht in einer abgelegenen Ecke befindet, mag es wünschenswert sein, daß automatisch ein Reset stattfindet, so daß der Rechner wieder zum normalen Betrieb zurückkehrt. Die Angabe von panic=30 beim Booten hätte z.B. zur Folge, daß der Kernel 30 Sekunden nach der Kernel-Panik versuchen würde, sich selbst zu booten. Der Standardwert ist Null und führt zum Standardverhalten, das darin besteht, endlos zu warten. Man beachte, daß dieser Zeitlimit-Wert auch durch die /proc/sys/kernel/panic sysctl-Schnittstelle gelesen und gesetzt werden kann. 3.5.7. Der Parameter »profile=« Kernel-Entwickler können eine Option aktivieren, die es ihnen erlaubt, herauszufinden, wie und wo der Kernel seine CPU-Zyklen einsetzt, um das äußerste an Effizienz und Leistung herauszuholen. Mit dieser Option kann man die Profil-Verschiebungszählung beim Booten bestimmen. Normalerweise wird diese auf 2 gesetzt. Man kann den Kernel auch mit automatisch aktivierter Profiling kompilieren. In jedem Fall braucht man ein Tool wie readprofile.c, das die Ausgabe von /proc/profile verwenden kann. 3.5.8. Der Parameter »reboot=« Diese Option kontrolliert die Art des Reboots, die Linux beim Reset des Rechners ausführt. Seit den späten Kerneln der Version 2.0.x ist der Standard ein »kalter« Neustart (kompletter Reset, BIOS macht einen Speicher-Check, etc.) statt eines »warmen« Neustarts (kein kompletter Reset, kein Speicher-Check). Die Voreinstellung wurde in einen Kaltstart geändert, da dieser bei billiger/kaputter Hardware, die es nicht schafft, neu zu booten, wenn ein Warmstart erforderlich wäre, normalerweise funktioniert. Zum Wiederherstellen des alten Zustands, nämlich der Verwendung eines Warmstarts, verwendet man reboot=w. Tatsächlich funktioniert auch jedes beliebige Wort, das mit w beginnt. Warum sollte man sich darum kümmern? Einige Platten-Kontroller mit eingebautem Cache-Speicher können einen Warmstart erkennen und Daten aus dem Cache auf die Festplatte schreiben. Nach einem Kaltstart würde der Kontroller eventuell zurückgesetzt werden und die noch auf die Festplatte zu schreibenden Daten im Cache würden verloren gehen. Andere Anwender haben Systeme, die recht lange für den Speicher-Check brauchen oder die ein SCSI BIOS enthalten, das nach einem Kaltstart länger für die Initialisierung braucht. 3.5.9. Der Parameter »reserve=« Dieser wird dazu benutzt, Teile der I/O Ports vor der Überprüfung zu schützen. Das Kommando ist folgendermaßen aufgebaut: reserve=iobase,extent[,iobase,extent]... Bei einigen Rechnern mag es notwendig sein, die automatische Hardwareerkennung der Gerätetreiber davon abzuhalten, in einer bestimmten Region nach Geräten zu suchen. Der Grund dafür kann z.B. schlecht entwickelte Hardware sein, die den Bootvorgang stoppt (wie z.B. einige Ethernetkarten), irrtümlicherweise erkannte Hardware, Hardware, deren Zustand durch eine frühere Erkennung geändert wurde oder einfach Hardware, die vom Kernel nicht initialisiert werden soll. Der Bootparameter reserve geht dieses Problem dadurch an, daß er einen I/O Port-Bereich angibt, der nicht geprüft werden soll. Diese Region wird in der Registrationstabelle des Kernels für Ports so behandelt, als ob unter der Adresse bereits ein Gerät mit dem Namen reserved gefunden wurde. Man beachte, daß dieser Mechanismus für die meisten Rechner nicht notwendig sein dürfte. Er ist nur bei Problemen und in besonderen Fällen erforderlich. Die I/O Ports in dem angegebenen Bereich sind gegen eine Geräteerkennung geschützt, bei der zuerst die Funktion check_region() ausgeführt wird, statt blind einen I/O Bereich zu prüfen. Dieses wird dann eingesetzt, wenn Treiber bei der Erkennung z.B. durch eine NE2000-Karte hängenbleiben oder irrtümlich andere Geräte als eigene erkannt werden. Ein korrekter Gerätetreiber sollte keine reservierten Bereiche prüfen, wenn nicht ein anderer Bootparameter dieses ausdrücklich verlangt. Das bedeutet, daß reserve meistens zusammmen mit einem anderen Bootparameter verwendet wird. Wenn man also einen reservierten Bereich festlegt, der ein bestimmtes Gerät schützen soll, dann muß man im allgemeinen explizit eine Erkennung dieses Gerätes erzwingen. Die meisten Treiber ignorieren die Registrierungstabelle für Ports, wenn ihnen eine bestimmte Adresse genannt wird. Die Bootzeile reserve=0x300,32 blah=0x300 hält z.B. alle Gerätetreiber, mit Ausnahme des Treibers für »blah« davon ab, 0x300-0x31f zu prüfen. Wie üblich bei Boot-Argumenten gibt es ein Limit von elf Parametern, d.h. man kann nur fünf reservierte Bereiche pro reserve Schlüsselwort bestimmen. Bei ungewöhnlich komplizierten Anfragen sind jedoch mehrere reserve Argumente möglich. 3.5.10. Der Parameter »vga=« Man beachte, daß es sich hierbei nicht um einen wirklichen Bootparameter handelt. Es ist vielmehr eine Option, die von LILO interpretiert wird und nicht vom Kernel wie all die anderen Bootparameter. Sie wird jedoch so häufig verwendet, daß sie an dieser Stelle eine Erwähnung verdient. Sie kann auch durch die Verwendung von rdev -v festgelegt werden und ebenso durch vidmode auf der Datei vmlinuz. Dieses ermöglicht dem Setup-Code die Benutzung des Video-BIOS zur Änderung des Standard-Anzeige-Modus vor dem tatsächlichen Booten des Linux-Kernels. Typische Modi sind 80x50, 132x44 usw. Man verwendet diese Option am besten, indem man mit vga=ask beginnt, worauf man eine Liste verschiedener Modi erhält, die man mit dem Grafik-Adapter benutzen kann, bevor man den Kernel bootet. Hat man einmal eine Nummer aus obiger Liste gewählt, kann man sie später anstelle von ask setzen. Weitere Informationen findet man in der Datei linux/Documentation/svga.txt, die mit allen neueren Kernel-Versionen ausgeliefert wird. Man beachte, daß neuere Kernelversionen (v2.1 und höher) den Setup- Code, der den Grafik-Modus ändert, als Option enthalten. Diese ist aufgelistet als Video mode selection support, d.h. man muß diese Option aktivieren, um dieses Feature verwenden zu können. 4. Bootparameter für SCSI-Peripheriegeräte Dieser Abschnitt enthält eine Beschreibung der Bootparameter, die zur Weitergabe von Informationen über die installierten SCSI-Host-Adapter und SCSI-Geräte verwendet werden. 4.1. Parameter für Mid-Level-Treiber Das SCSI-System von Linux gliedert sich in zwei Teile. Für jeden SCSI-Adapter gibt es einen speziellen Low-Level-Treiber, der dessen Funktionalität über eine definierte Schnittstelle den Mid-Level- Treibern zugänglich macht. Für jeden SCSI-Gerätetyp wie z.B. Festplatten, CD-ROMs oder Streamer gibt es einen speziellen Mid-Level- Treiber. 4.1.1. Maximale Anzahl überprüfter LUNs (»max_scsi_luns=«) Jedes SCSI-Gerät kann eine Reihe von »Sub-Geräten« enthalten. Das beste Beispiel dafür sind die CD-ROM-Wechsler. Jede CD in diesem Wechsler wird als »Logical Unit Number« (LUN) dieses bestimmten Gerätes angesprochen. Die meisten Geräte jedoch, wie z.B. Festplatten, Bandlaufwerke u.ä. bestehen nur aus einer Geräteeinheit und erhalten LUN Null. Ein Problem ergibt sich bei einigen Geräten mit einer einzigen LUN. Diese Geräte, alte, aber leider auch neue, besitzen eine schlechte Firmware, die mit der Überprüfung für LUNs ungleich null nicht umgehen kann. Als Reaktion auf die Überprüfung hängen sich die Geräte auf und blockieren im schlimmsten Fall sogar den gesamten SCSI-Bus, so daß auch andere Geräte nicht mehr angesprochen werden können. Neuere Kernel verfügen über eine Konfigurations-Option, die es ermöglicht, die maximale Anzahl von geprüften LUNs festzulegen. Standardmäßig untersucht man nur LUN Null, um das oben erwähnte Problem zu vermeiden. Zur Bestimmung der Anzahl von geprüften LUNs beim Booten gibt man max_scsi_luns=n als Bootparameter ein, wobei n eine Zahl zwischen 1 und 8 ist. Um oben genannte Probleme zu vermeiden, würde man n=1 verwenden, um solche defekten Geräte nicht zu verwirren. 4.1.2. Parameter für den SCSI-Tape-Treiber (»st=«) Ein Teil der Boot-Konfiguration des Treibers für SCSI-Bandlaufwerke kann mit folgendem Kommando erfolgen: st=buf_größe[,schreib_grenzwert[,max_bufs]] Die ersten zwei Zahlen werden in kB-Einheiten angegeben. Der Standardwert für buf_größe ist 32 kB und die maximal zu bestimmende Größe sind lächerliche 16384 kB. schreib_grenzwert ist der Grenzwert, bei dem der Puffer an das Laufwerk weitergegeben wird. Standardwert hierbei sind 30 kB. Die maximale Anzahl von Puffern ändert sich je nach der Zahl der erkannten Laufwerke. Standardwert ist 2. Hier eine Beispielverwendung: st=32,30,2 Umfassende Details findet man in der Datei README.st im Verzeichnis scsi des Kernel-Quell-Baums. 4.2. Parameter für SCSI-Host-Adapter Allgemeine Anmerkungen zu diesem Abschnitt: iobase Der erste I/O Port, der vom SCSI-Host belegt wird. Er wird in der Hexadezimalschreibweise angegeben und liegt für gewöhnlich zwischen 0x200 und 0x3ff. irq Der Hardware-Interrupt, den die Karte per Konfiguration verwendet. Die gültigen Werte sind abhängig von der fraglichen Karte. Normalerweise gelten die Werte 5, 7, 9, 10, 11, 12 und 15. Die anderen Werte werden normalerweise für übliche Peripheriegeräte wie IDE-Festplatten, Disketten, serielle Anschlüsse etc. verwendet. dma Der von der Karte verwendete DMA-Kanal (Direct Memory Access). Dies gilt typischerweise nur für Busmaster-Karten. PCI und VLB Karten benötigen keinen ISA-DMA-Kanal. scsi-id Die ID, die der Host-Adapter verwendet, um sich auf dem SCSI-Bus zu identifizieren. Nur einige Host-Adapter erlauben die Änderung dieses Werts, da er bei den meisten intern fest eingestellt ist. Gewöhnlich ist der Standardwert ID 7. Die Seagate und Future Domain TMC-950-Boards jedoch verwenden ID 6. parity Legt fest, ob der SCSI Host-Adapter von den angeschlossenen Geräten erwartet, daß sie für alle ausgetauschten Informationen einen Paritätswert zur Verfügung stellen. Der Wert 1 aktiviert den Paritäts-Check und 0 schaltet ihn ab. Auch hier gilt, daß nicht alle Adapter die Auswahl eines Paritätsverhaltens als Bootparameter unterstützen. 4.2.1. Adaptec aha151x, aha152x, aic6260, aic6360, SB16-SCSI (»aha152x=«) Die aha-Zahlen beziehen sich auf Karten und die aic-Zahlen beziehen sich auf den tatsächlichen SCSI-Chip auf diesem Kartentyp, Soundblaster-16 SCSI eingeschlossen. Die automatische Hardwareerkennung des Treibers für diesen SCSI Host schaut nach einem installierten BIOS. Falls keines vorhanden ist, wird die Karte nicht gefunden. Für diesen Fall wird man einen Bootparameter folgender Form verwenden müssen: aha152x=iobase[,irq[,scsi-id[,reconnect[,parity]]]] Wurde der Treiber mit aktiviertem Debugging kompiliert, dann kann ein sechster Wert zur Bestimmung des Debug-Levels gesetzt werden. Alle Parameter verhalten sich wie eingangs dieses Abschnitts beschrieben. Ein reconnect Wert ungleich null erlaubt Geräten die Verwendung von Disconnect/Reconnect. Hier eine Beispielverwendung: aha152x=0x340,11,7,1 Man beachte, daß die Angabe der Parameter einer bestimmten Reihenfolge folgen muß, d.h. wenn man eine Paritätseinstellung angeben will, dann muß man auch einen iobase-, einen irq-, einen scsi-id- und einen reconnect-Wert angeben. 4.2.2. Adaptec aha154x (»aha1542=«) Dies sind die Karten aus der aha154x-Serie. Die Karten aus der aha1542-Serie verfügen über einen i82077 Floppy-Kontroller, die Karten der Serie aha1540 hingegen nicht. Diese sind Busmaster-Karten und haben Parameter zur Festlegung der »Fairness«, die dazu verwendet wird, den Bus mit anderen Geräten zu teilen. Der Bootparameter sieht folgendermaßen aus: aha1542=iobase[,buson,busoff[,dmaspeed]] Gewöhnlich ist einer der folgenden iobase Werte gültig: 0x130, 0x134, 0x230, 0x234, 0x330 oder 0x334. Clone-Karten lassen möglicherweise andere Werte zu. Die buson, busoff Werte beziehen sich auf die Anzahl von Mikrosekunden, in denen die Karte den ISA-Bus beherrscht. Die Standardwerte sind 11 µs an und 4 µs aus, so daß andere Karten wie z.B. eine ISA LANCE Ethernetkarte eine Chance haben, auf den ISA-Bus zuzugreifen. Der Wert dmaspeed bezieht sich auf die Geschwindigkeit (in MB/s) in der der DMA-Transfer erfolgt. Der Standardwert ist 5 MB/s. Karten einer neueren Revision ermöglichen die Auswahl dieses Werts als Teil der Konfiguration per Software, ältere Karten verwenden Jumper. Man kann Werte bis 10 MB/s benutzen, vorausgesetzt, das Motherboard kann damit umgehen. Bei der Verwendung von Werten über 5 MB/s sollte man vorsichtig vorgehen. 4.2.3. Adaptec aha274x, aha284x, aic7xxx (»aic7xxx=«) Diese Boards können einen Parameter folgender Form annehmen: aic7xxx=extended,no_reset Der Wert extended, falls ungleich Null, besagt, daß die erweiterte Übersetzung für große Platten eingeschaltet ist. Der Wert no_reset, falls ungleich Null, teilt dem Treiber mit, keinen Reset auf dem SCSI- Bus auszuführen, wenn der Host-Adapter beim Booten initialisiert wird. 4.2.4. AdvanSys SCSI Host-Adapter (»advansys=«) Der AdvanSys-Treiber akzeptiert bis zu 4 I/O Adressen, unter denen der Treiber eine AdvanSys SCSI-Karte sucht. Man beachte, daß diese Werte überhaupt keinen Einfluß auf die EISA- oder PCI-Karten haben. Sie werden nur für die Überprüfung von ISA- und VLB-Karten eingesetzt. Wurde der Treiber mit eingeschaltetem Debugging kompiliert, kann durch Hinzufügen des Parameters 0xdeb[0-f] bestimmt werden, bis zu welchem Grad Debugging-Meldungen ausgegeben werden sollen. 0-f ermöglicht die Festlegung des Levels der Debugging-Meldungen auf jeden der 16 Level. 4.2.5. Always IN2000-Host-Adapter (»in2000=«) Im Gegensatz zu den Bootparametern der anderen SCSI Host-Adapter verwendet der IN2000-Treiber für die meisten seiner Integer-Parameter ASCII-Strings als Präfix. Hier eine Liste von unterstützten Parametern: ioport:addr Wobei addr die I/O-Adresse einer Karte ist, die gewöhnlich kein ROM besitzt. noreset Verhindert einen Reset des SCSI-Busses beim Booten. Diesem Parameter können keine optionalen Argumente übergeben werden. nosync:x x ist eine Bitmaske, wobei die ersten 7 Bit mit den 7 möglichen SCSI-Geräten übereinstimmen (Bit 0 für das Gerät mit ID0, etc). Um die Sync-Übertragung auf ein Gerät zu verhindern, setzt man dessen Bit. Standardmäßig ist Sync für alle Geräte ausgeschaltet. period:ns ns ist die minimale # von Nanosekunden für einen SCSI- Datentransfer. Standard ist 500; erlaubte Werte sind 250 bis 1000. disconnect:x x = 0 verhindert grundsätzlich Disconnects; x = 2 erlaubt immer Disconnects. x = 1 führt »adaptive« Disconnects durch. Dieses ist der Standard und wohl allgemein die beste Wahl. debug:x Ist »DEBUGGING_ON« angegeben, dann ist x eine Bitmaske, durch die verschiedene Arten von Debug-Ausgaben ein- oder ausgeschaltet werden; siehe hierzu die Definition der DB_xxx Konstanten in in2000.h. proc:x Ist »PROC_INTERFACE« angegeben, dann ist x eine Bitmaske, die festlegt, wie die /proc-Schnittstelle funktioniert und was sie macht; siehe hierzu die Definition der PR_xxx Konstanten in in2000.h. Hier einige Anwendungs-Beispiele : in2000=ioport:0x220,noreset in2000=period:250,disconnect:2,nosync:0x03 in2000=debug:0x1e in2000=proc:3 4.2.6. AMD AM53C974-basierte Hardware (»AM53C974=«) Im Gegensatz zu anderen Treibern verwendet dieser keine Bootparameter, um I/O-, IRQ- oder DMA-Kanäle festzulegen. Da der AM53C974 ein PCI- Gerät ist, sollte dafür auch kein Grund bestehen. Statt dessen teilen die Parameter für gewöhnlich die Transfermodi und Transferraten mit, die zwischen dem Host- und dem Zielgerät verwendet werden sollen. Dies läßt sich am besten anhand eines Beispiels beschreiben: AM53C974=7,2,8,15 Dies würde folgendermaßen interpretiert werden: Für die Kommunikation zwischen dem SCSI-Kontroller mit ID7 und dem SCSI-Gerät mit ID2 soll eine Transferrate von 8 MHz im Synchronmodus mit max. 15 Bytes Offset ausgehandelt werden. Weitere Informationen findet man in der Datei linux/drivers/scsi/README.AM53C974 4.2.7. BusLogic SCSI-Hosts mit v1.2.x Kerneln (»buslogic=«) In älteren Kerneln akzeptiert der buslogic-Treiber nur einen Parameter, und zwar die iobase. Folgende Werte sind zulässig: 0x130, 0x134, 0x230, 0x234, 0x330 und 0x334. 4.2.8. BusLogic SCSI-Hosts mit v2.x Kerneln (»BusLogic=«) Bei v2.x Kerneln akzeptiert der BusLogic-Treiber viele Parameter. Die folgende detaillierte Beschreibung ist direkt Leonard N. Zubkoffs Treiber in den v2.0 Kernels entnommen. Beim BusLogic-Treiber beginnt der Bootparameter mit dem Identifier BusLogic=, optional gefolgt von einer durch Komma getrennten Ganzzahlenfolge und darauf optional gefolgt von einer durch Komma getrennten Stringfolge. Jeder Bootparameter gilt für einen BusLogic Host-Adapter. Bei Systemen, die mehrere BusLogic Host-Adapter enthalten, können mehrere Bootparameter verwendet werden. Die erste angegebene Ganzzahl ist die I/O-Adresse, unter der der Host- Adapter angesprochen werden kann. Fehlt diese Angabe, wird der Standardwert 0 benutzt. Das bedeutet, dieser Eintrag gilt für den ersten BusLogic-Host-Adapter, der während der automatischen Hardwareerkennung gefunden wurde. Wurden irgendwelche I/O-Adressen als Bootparameter angegeben, dann wird die automatische Hardwareerkennung ausgelassen. Die zweite angegebene Ganzzahl legt die »Tagged Queue Depth« fest, die für Zielgeräte, die »Tagged Queuing« unterstützen, zu verwenden ist. Unter der »Queue Depth« versteht man die Anzahl von SCSI-Kommandos, die gleichzeitig als auszuführend angegeben werden dürfen. Fehlt eine Angabe, wird standardmäßig 0 verwendet, d.h. es wird ein automatisch bestimmter Wert verwendet, basierend auf der maximalen »Queue Depth« des Host-Adapters und der Anzahl, dem Typ, der Geschwindigkeit und den Fähigkeiten der erkannten Zielgeräte. Bei Host-Adaptern, die »ISA Bounce Buffer« benötigen, wird die »Tagged Queue Depth« automatisch auf BusLogic_TaggedQueueDepth_BB gesetzt, um ausschweifendes Allokieren von »DMA Bounce Buffer«-Speicher im voraus zu vermeiden. Zielgeräte, die »Tagged Queuing« nicht unterstützen, verwenden eine »Queue Depth« von BusLogic_UntaggedQueueDepth. Die dritte angegebene Ganzzahl ist die »Bus Settle Time« in Sekunden. Diese gibt die Zeit an, die man zwischen einem Host-Adapter Hard Reset, der einen SCSI Bus Reset einleitet, und der Eingabe von SCSI- Kommandos wartet. Fehlt eine Angabe, dann wird standardmäßig 0 verwendet, d.h. es wird der Wert von BusLogic_DefaultBusSettleTime verwendet. Die vierte angegebene Ganzzahl sind die Local Options. Fehlt die Angabe, dann wird standardmäßig 0 verwendet. Man beachte, daß Local Options nur für einen bestimmten Host-Adapter gelten. Die fünfte angegebene Ganzzahl sind die Global Options. Fehlt die Angabe, wird standardmäßig 0 verwendet. Man beachte, daß Global Options auf alle Host Adapter angewendet werden. Die String-Optionen dienen der Kontrolle über »Tagged Queuing«, »Error Recovery« (Fehlerkorrektur) und Host-Adapter-Überprüfung. Die »Tagged Queuing«-Bestimmung beginnt mit TQ: und erlaubt die ausdrückliche Festlegung, ob »Tagged Queuing« auf Zielgeräten, die dieses unterstützen, erlaubt ist. Folgende Optionen zur Bestimmung stehen zur Verfügung: TQ:Default Ob »Tagged Queuing« erlaubt ist, hängt von der Firmware-Version des BusLogic Host-Adapters ab und davon, ob es der »Tagged Queue Depth«-Wert erlaubt, mehrere Kommandos in die Warteschlange zu stellen. TQ:Enable »Tagged Queuing« wird für alle Zielgeräte auf diesem Host- Adapter aktiviert, wobei jegliche Beschränkungen übergangen werden, die ansonsten, basierend auf der Host Adapter Firmware- Version auferlegt werden würden. TQ:Disable »Tagged Queuing« wird für alle Zielgeräte auf diesem Host- Adapter deaktiviert. TQ: »Tagged Queuing« wird für jedes einzelne Zielgerät kontrolliert. ist eine Sequenz aus Y-, N- und X-Zeichen. Y aktiviert »Tagged Queuing«, N deaktiviert es und X akzeptiert den Standardwert, basierend auf der Firmware-Version. Das erste Zeichen bezieht sich auf Zielgerät 0, das zweite auf Zielgerät 1 usw.; falls die Sequenz aus Y, N und X Zeichen nicht alle Zielgeräte abdeckt, werden nicht spezifizierte Zeichen als X angenommen. Man beachte, daß das ausdrückliche Verlangen nach »Tagged Queuing« zu Problemen führen kann; diese Option dient primär dazu, das Deaktivieren von »Tagged Queuing« auf Zielgeräten zu ermöglichen, die es nicht korrekt durchführen. Die »Error Recovery Strategy«-Spezifikation beginnt mit ER:. Diese Option ermöglicht es, festzulegen, was für eine Aktion als »Error Recovery« ausgeführt werden soll, wenn »ResetCommand« ausgeführt wird, weil ein SCSI-Kommando nicht erfolgreich beendet werden konnte. Folgende Optionen zur Bestimmung stehen zur Verfügung: ER:Default Ausgehend von der Empfehlung des SCSI-Subsystems wird »Error Recovery« zwischen einem Hard Reset und den »Bus Device Reset«-Optionen wählen. ER:HardReset »Error Recovery« wird einen Host-Adapter Hard Reset einleiten, was zusätzlich einen SCSI Bus Reset verursacht. ER:BusDeviceReset »Error Recovery« wird eine »Bus Device Reset«-Mitteilung zu dem jeweiligen Zielgerät schicken, das den Fehler verursacht hat. Wird noch einmal die »Error Recovery« für dieses Zielgerät eingeleitet und konnte kein SCSI-Kommando an dieses Zielgerät erfolgreich ausgeführt werden, seit die »Bus Device Reset«-Nachricht geschickt wurde, dann wird ein Hard Reset ausgelöst. ER:None »Error Recovery« wird unterdrückt. Diese Option sollte nur dann gewählt werden, wenn ein SCSI Bus-Reset oder »Bus Device Reset« das Zielgerät veranlaßt, komplett und unwiderruflich zu versagen. ER: »Error Recovery« wird für jedes einzelne Zielgerät kontrolliert. ist eine Sequenz aus D-, H-, B- und N-Zeichen. Mit D wird das Standardverhalten gewählt, H steht für »Hard Reset«, B für »Bus Device Reset« und mit N wird »None« gewählt. Das erste Zeichen bezieht sich auf Zielgerät 0, das zweite auf Zielgerät 1 usw. Werden mit D, H, B und N nicht alle möglichen Zielgeräte abgedeckt, dann werden undefinierte Zeichen als D angenommen. Die automatische Hardwareerkennung für Host-Adapter umfaßt folgende Zeichenketten: NoProbe Es soll keine Überprüfung stattfinden; somit werden keine BusLogic-Host-Adapter erkannt. NoProbeISA Die Standard ISA I/O-Adressen werden nicht untersucht; somit werden nur PCI-Host-Adapter erkannt. NoSortPCI PCI-Host-Adapter werden in der vom PCI BIOS bereitgestellten Reihenfolge aufgezählt, wobei die Einstellungen der Option AutoSCSI »Use Bus And Device # For PCI Scanning Seq.« ignoriert werden. 4.2.9. EATA SCSI-Karten (»eata=«) Seit den späten Kernelversionen v2.0 akzeptieren die EATA-Treiber die Überprüfung eines Bootparameters, der die iobase(s) bestimmt. Dieses sieht folgendermaßen aus: eata=iobase1[,iobase2][,iobase3]...[,iobaseN] Der Treiber überprüft die Adressen in der Reihenfolge, in der sie aufgelistet sind. 4.2.10. Future Domain TMC-8xx, TMC-950 (»tmc8xx=«) Der Überprüfungscode für diese SCSI-Hosts schaut nach einem installierten BIOS; falls keines vorhanden ist, wird die Karte nicht gefunden werden. Auch wenn der Signatur-String des BIOS nicht erkannt wurde, wird die Karte nicht gefunden. In jedem der beiden Fälle wird man dann einen Bootparameter folgender Form verwenden: tmc8xx=mem_base,irq Der Wert mem_base ist der Wert des in den Speicher eingeblendeten I/O- Bereichs, den die Karte verwendet. Dieser ist für gewöhnlich einer der folgenden Werte: 0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000 oder 0xde000. 4.2.11. Future Domain TMC-16xx, TMC-3260, AHA-2920 (»fdomain=«) Der Treiber erkennt diese Karten entsprechend einer Liste von bekannten BIOS ROM-Signaturen. Eine komplette Liste bekannter BIOS- Ausgaben erhält man in der Datei linux/drivers/scsi/fdomain.c. Diese wird mit einer Fülle von Informationen eingeleitet. Ist das BIOS dem Treiber nicht bekannt, dann kann man dies folgendermaßen überbrücken: fdomain=iobase,irq[,scsi_id] 4.2.12. IOMEGA Parallel Port ZIP-Laufwerk (»ppa=«) Dieses ist ein Treiber für den IOMEGA Parallel Port SCSI Adapter, welcher in den IOMEGA ZIP-Laufwerken enthalten ist. Er könnte auch mit dem original IOMEGA PPA3-Gerät funktionieren. Der Bootparameter für diesen Treiber sieht folgendermaßen aus: ppa=iobase,speed_high,speed_low,nybble Alle außer iobase sind optional festlegbare Werte. Will man einen der optionalen Parameter verändern, dann sollte man einen Blick in die Datei linux/drivers/scsi/README.ppa werfen. Dort findet man genaue Informationen darüber, was von diesen Parametern kontrolliert wird. 4.2.13. NCR5380-basierte Kontroller (»ncr5380=«) Je nach Board kann der 5380 entweder über I/O-Ports oder einen eingeblendeten Speicherbereich angesprochen werden. Eine Adresse unter 0x400 ist für gewöhnlich ein I/O-Port. PCI- und EISA-Hardware verwenden jedoch I/O-Adressen über 0x3ff. In jedem Fall gibt man die Adresse, den Wert des Interrupts und des DMA-Kanals an. Hier ein Beispiel einer I/O-Karte: ncr5380=0x350,5,3. Verwendet die Karte keine Interrupts, dann können mit einem IRQ-Wert von 255 (0xff) Interrupts deaktiviert werden. Ein IRQ-Wert von 254 bedeutet eine automatische Hardwareerkennung. Weitere Informationen findet man in der Datei linux/drivers/scsi/README.g_NCR5380. 4.2.14. NCR53c400-basierte Kontroller (»ncr53c400=«) Die generische 53c400-Unterstützung erfolgt mit demselben Treiber wie für die oben erwähnte generische 5380-Unterstützung. Der Bootparameter ist identisch zum obig genannten, mit der Ausnahme, daß vom 53c400 kein DMA-Kanal verwendet wird. 4.2.15. NCR53c406a-basierte Kontroller (»ncr53c406a=«) Dieser Treiber verwendet einen Bootparameter folgender Form ncr53c406a=PORTBASE,IRQ,FASTPIO wobei die IRQ- und FASTPIO-Parameter optional sind. Ein Interrupt-Wert von 0 schaltet die Verwendung von Interrupts aus. Der Wert 1 für den FASTPIO-Parameter aktiviert die Verwendung von insl- und outsl- Anweisungen statt den aus einem einzigen Byte bestehenden inb- und outb-Anweisungen. Während der Kompilierung eines neuen Kernels steht DMA als Option zur Verfügung. 4.2.16. Pro Audio Spectrum (»pas16=«) PAS16 verwendet einen NCR5380 SCSI-Chip und neuere Modelle unterstützen die Konfiguration ohne Jumper. Der Bootparameter sieht folgendermaßen aus: pas16=iobase,irq Der einzige Unterschied besteht darin, daß man einen IRQ-Wert von 255 verwenden kann, welcher dem Treiber mitteilt, ohne die Verwendung von Interrupts zu arbeiten, was jedoch Geschwindigkeitsverluste mit sich bringt. Die iobase ist gewöhnlich 0x388. 4.2.17. Seagate ST-0x (»st0x=«) Der Code zur Überprüfung für diese SCSI-Hosts sucht nach einem installierten BIOS. Ist keines vorhanden, wird die Karte nicht gefunden. Auch wenn die Signatur-Zeichenkette des BIOS nicht erkannt wird, wird die Karte nicht gefunden. In jedem Fall wird man einen Bootparameter folgender Form verwenden: st0x=mem_base,irq Der Wert mem_base ist der Wert der in den Speicher eingeblendeten I/O- Region, den die Karte verwendet. Dieser wird für gewöhnlich einer der folgenden Werte sein: 0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000 oder 0xde000. 4.2.18. Trantor T128 (»t128=«) Diese Karten basieren ebenfalls auf dem NCR5380-Chip und verstehen folgende Optionen: t128=mem_base,irq Gültige Werte für mem_base sind: 0xcc000, 0xc8000, 0xdc000 und 0xd8000. 4.2.19. Ultrastor SCSI-Karten (»u14-34f=«) Man beachte, daß es anscheinend zwei unabhängige Treiber für diese Karte gibt, nämlich CONFIG_SCSI_U14_34F, der u14-34f.c benutzt, und CONFIG_SCSI_ULTRASTOR, der ultrastor.c verwendet. u14-34f ist derjenige, der seit den späten Kernelversionen v2.0 einen Bootparameter folgender Form akzeptiert: u14-34f=iobase1[,iobase2][,iobase3]...[,iobaseN] Der Treiber überprüft die Adressen in der Reihenfolge, wie sie aufgelistet sind. 4.2.20. Western Digital WD7000-Karten (»wd7000=«) Die automatische Erkennung für wd7000 sucht nach einer bekannten BIOS ROM-Zeichenkette und kennt einige Standardeinstellungen. Werden die korrekten Werte für die eigene Karte nicht geliefert oder hat man eine nicht erkannte BIOS-Version, dann kann man einen Bootparameter folgender Form verwenden: wd7000=irq,dma,iobase 4.3. SCSI-Host-Adapter, die keine Bootparameter akzeptieren Zur Zeit verwenden die Treiber folgender SCSI-Karten keine Bootparameter. In einigen Fällen kann man Werte »hartkodieren«, indem man, falls nötig, den Treiber selbst editiert. · Adaptec aha1740 (EISA-Überprüfung) · NCR53c7xx,8xx (PCI, beide Treiber) · Qlogic Fast (0x230, 0x330) · Qligic ISP (PCI) 5. Festplatten In diesem Abschnitt werden alle Bootparameter aufgelistet, die mit Standard-MFM/RLL-, ST-506-, XT- und (E)IDE-Laufwerken verbunden sind. Man beachte, daß sowohl der IDE- als auch der generische ST-506 HD- Treiber die Option hd= akzeptieren. 5.1. IDE Disk-/CD-ROM-Treiber-Parameter Der IDE-Treiber akzeptiert eine Reihe von Parametern, die von Spezifikationen der Plattengeometrie bis zur Unterstützung für höher entwickelte oder kaputte Kontroller-Chips reichen. Es folgt eine Zusammenfassung aller möglichen Bootparameter. Benötigt man weitere Informationen, sollte man unbedingt einen Blick in die Datei ide.txt im Verzeichnis linux/Documentation werfen, dem diese Zusammenfassung entnommen wurde. Bei dem Parameter hdx= können für x Werte von a bis h verwendet werden. Für x bei dem Parameter idex= können Werte von 0 bis 3 Verwendung finden. Beispielsweise würde Linux hdc= und ide1= erkennen. hdx=noprobe Laufwerk mag vorhanden sein, aber es soll nicht automatisch nach ihm gesucht werden. hdx=none Das Laufwerk ist nicht vorhanden. Die CMOS-Einstellungen sollen ignoriert und das Laufwerk nicht erkannt werden. hdx=nowerr Das WRERR_STAT-Bit soll bei diesem Laufwerk ignoriert werden. hdx=cdrom Das Laufwerk ist vorhanden und es handelt sich um ein CD-ROM- Laufwerk. hdx=cyl,head,sect Ein Plattenlaufwerk mit angegebener Geometrie ist vorhanden. hdx=autotune Der Treiber soll versuchen, die Geschwindigkeit der Schnittstelle auf den schnellsten unterstützten PIO-Modus einzustellen. Wenn möglich, soll nur der Modus dieses Laufwerkes verändert werden. Diese Option wird nicht von allen Chipsätzen voll unterstützt. Kann zu Problemen mit bestimmten IDE-Laufwerken führen. idex=noprobe Es soll nicht versucht werden, auf diese Schnittstelle zuzugreifen oder sie zu verwenden. idex=base Die IDE-Schnittstelle soll unter der angegebenen Adresse gesucht werden, wobei base normalerweise 0x1f0 oder 0x170 ist und angenommen wird, daß ctl base+0x206 ist. idex=base,ctl Es wird sowohl base als auch ctl bestimmt. idex=base,ctl,irq Legt base, ctl und irq fest. idex=autotune Hat die gleiche Funktion wie hdx=autotune, bezieht sich allerdings auf alle Laufwerke an einer Schnittstelle. idex=noautotune Der Treiber versucht nicht, die Geschwindigkeit der Schnittstelle einzustellen. Dies ist der Standard für die meisten Chipsätze mit Ausnahme des cmd640. idex=serialize Es wird nicht gleichzeitig auf idex und eine weitere IDE- Schnittstelle zugegriffen. Dies ist für einige fehlerhafte Chipsätze sehr nützlich. Das Folgende gilt nur auf ide0, und die Standardwerte für die base und ctl Ports dürfen nicht geändert werden. ide0=dtc2278 Prüfe und unterstütze die DTC2278-Schnittstelle. ide0=ht6560b Prüfe und unterstütze die HT6560B-Schnittstelle. ide0=cmd640_vlb Ist nur für VLB-Karten mit dem CMD640-Chip notwendig. Die PCI- Version wird automatisch erkannt. ide0=qd6580 Prüfe und unterstütze die qd6580-Schnittstelle. ide0=ali14xx Prüfe und unterstütze die ali14xx-Chipsätze (ALI M1439/M1445). ide0=umc8672 Prüfe und unterstütze die umc8672-Chipsätze. Alles Übrige wird mit der Nachricht »BAD OPTION« abgewiesen. 5.2. Standard ST-506-Platten-Treiber-Optionen (»hd=«) Der Standard-Plattentreiber kann, ähnlich wie der IDE-Treiber, Parameter für die Geometrie von Platten akzeptieren. Man beachte jedoch, daß er nur drei Werte (C/H/S) erwartet; nur einer mehr oder weniger, und der Parameter wird einfach von ihm ignoriert. Er akzeptiert auch nur hd= als Argument, d.h. hda=, hdb= usw. sind hier nicht gültig. Das Format sieht folgendermaßen aus: hd=cyls,heads,sects Wenn zwei Platten installiert sind, wird das Obenstehende mit den Geometrie-Parametern der zweiten Platte wiederholt. 5.3. XT-Platten-Treiber-Optionen (»xd=«) Sollten Sie zu den Unglücklichen gehören, die eine dieser alten 8 Bit- Karten verwenden, die Daten keuchend mit 125 kB/s verschieben, dann kommt hier der Knüller. Der Überprüfungscode für diese Karten schaut nach einem installierten BIOS. Falls keines vorhanden ist, dann wird die Karte nicht erkannt werden. Wenn der Signatur-String Ihres BIOS nicht erkannt wurde, wird sie ebenfalls nicht gefunden. In jedem Fall wird man dann einen Bootparameter folgender Form verwenden müssen: xd=type,irq,iobase,dma_chan Der Wert type bestimmt den einzelnen Hersteller der Karte, und zwar wie folgt: · 0: generic · 1; DTC · 2, 3, 4: Western Digital · 5, 6, 7: Seagate · 8: OMTI Der einzige Unterschied zwischen den verschiedenen Typen desselben Herstellers liegt in dem BIOS-String, der für die Erkennung verwendet wird. Dieser wird nicht benutzt, wenn der Typ angegeben wurde. Die xd_setup()-Funktion überprüft die Werte nicht und nimmt an, daß alle vier Werte eingetragen wurden. Man sollte sie nicht enttäuschen. Hier ist eine beispielhafte Verwendung für einen WD1002-Kontroller mit ausgeschaltetem bzw. entferntem BIOS, wobei die standardmäßigen Parameter vom XT-Kontroller verwendet werden: xd=2,5,0x320,3 6. CD-ROMs (nicht-SCSI/-ATAPI/-IDE) In diesem Abschnitt werden alle möglichen Bootparameter aufgelistet, die zu den CD-ROM-Geräten gehören. Man beachte, daß dies nicht für SCSI- oder IDE-/ATAPI-CD-ROMs gilt. Informationen über diese CD-ROM- Typen findet man in den entsprechenden Abschnitten. Man beachte, daß es für die meisten dieser CD-ROM-Laufwerke Dokumentationsdateien gibt, die man lesen sollte. Sie alle sind günstig plaziert: linux/Documentation/cdrom. 6.1. Die Aztech-Schnittstelle (»aztcd=«) Dieser Kartentyp hat folgende Syntax: aztcd=iobase[,magic_number] Setzt man magic_number auf 0x79, dann wird der Treiber einen Versuch starten und im Falle einer unbekannten Firmware irgendwie laufen. Alle übrigen Werte werden ignoriert. 6.2. Die CDU-31A- und CDU-33A-Sony-Schnittstelle (»cdu31a=«) Diese CD-ROM-Schnittstelle kann auf einigen der Pro Audio Spectrum Soundkarten gefunden werden und auf anderen Schnittstellen-Karten von Sony. Die Syntax ist folgendermaßen: cdu31a=iobase,[irq[,is_pas_card]] Setzt man einen IRQ-Wert auf Null, dann wird dem Treiber damit mitgeteilt, daß die Hardware Interrupts nicht unterstützt, was bei einigen PAS-Karten der Fall ist. Unterstützt die eigene Karte Interrupts, dann sollte man diese nutzen, da diese die CPU-Last des Treibers verringern. Falls eine Pro Audio Spectrum verwendet werden soll, muß für is_pas_card die Zeichenkette PAS eingetragen werden. Andernfalls sollte die Option überhaupt nicht bestimmt werden. 6.3. Die CDU-535-Sony-Schnittstelle (»sonycd535=«) Diese CD-ROM-Schnittstelle hat folgende Syntax: sonycd535=iobase[,irq] Für die iobase kann eine Null als »Platzhalter« verwendet werden, falls man einen IRQ-Wert bestimmen will. 6.4. Die GoldStar-Schnittstelle (»gscd=«) Diese CD-ROM-Schnittstelle hat folgende Syntax: gscd=iobase 6.5. Die ISP16-Schnittstelle (»isp16=«) Diese CD-ROM-Schnittstelle hat folgende Syntax: isp16=[port[,irq[,dma]]][[,]drive_type] Der Wert Null für irq oder dma besagt, daß sie nicht benutzt werden. Erlaubte Werte für drive_type sind noisp16, Sanyo, Panasonic, Sony und Mitsumi. Die Verwendung von noisp16 deaktiviert den gesamten Treiber. 6.6. Die Mitsumi Standard-Schnittstelle (»mcd=«) Diese CD-ROM-Schnittstelle hat folgende Syntax: mcd=iobase,[irq[,wait_value]] wait_value wird als interner Timeout-Wert für diejenigen verwendet, die Probleme mit ihrem Laufwerk haben. Ob diese Option vorhanden ist, kann während der Kompilierung des Kernels festgelegt werden. 6.7. Die Mitsumi XA-/MultiSession-Schnittstelle (»mcdx=«) Zur Zeit verfügt dieser experimentelle Treiber über eine Setup- Funktion, jedoch sind bis jetzt (seit 1.3.15) keine Parameter implementiert. Dieser Treiber ist für die gleichen Laufwerke wie der vorher beschriebene gedacht, allerdings bietet dieser weitere Möglichkeiten. 6.8. Die Optics Storage-Schnittstelle (»optcd=«) Dieser Kartentyp hat folgende Syntax: optcd=iobase 6.9. Die Philips CM206-Schnittstelle (»cm206=«) Dieser Kartentyp hat folgende Syntax: cm206=[iobase][,irq] Zahlen zwischen 3 und 11 werden vom Treiber als IRQ-Werte interpretiert und Zahlen zwischen 0x300 und 0x370 als I/O Ports, so daß man eine oder beide Zahlen in beliebiger Reihenfolge angeben kann. Der Treiber akzeptiert auch cm206=auto zum Aktivieren der automatischen Hardwareerkennung. 6.10. Die Sanyo-Schnittstelle (»sjcd=«) Diese Karte hat folgende Syntax: sjcd=iobase[,irq[,dma_channel]] 6.11. Die SoundBlaster Pro-Schnittstelle (»sbpcd=«) Diese Karte hat folgende Syntax sbpcd=iobase,type wobei type einer der folgenden Zeichenketten ist: SoundBlaster, LaserMate oder SPEA. Groß- oder Kleinschreibung spielt keine Rolle. Die I/O-Basisadresse ist die der CD-ROM-Schnittstelle und nicht die des Teils der Karte, der den Sound produziert. 7. Andere Hardware-Geräte Alle übrigen Geräte, die nicht in eine der oben erwähnten Kategorien passen, wurden hier zusammengefaßt. 7.1. Ethernet-Geräte (»ether=«) Unterschiedliche Treiber verwenden unterschiedliche Parameter. Ihnen allen gemeinsam ist, daß sie alle über einen IRQ-Wert, einen Wert der I/O Port-Basisadresse und einen Namen verfügen. In seiner allgemeinsten Form schaut dies in etwa so aus: ether=irq,iobase[,param_1[,param_2,...param_8]]],name Das erste, nicht numerische Argument wird als Name verwendet. Die param_n Werte haben normalerweise für jede(n) einzelne Karte bzw. Treiber eine unterschiedliche Bedeutung. Typische param_n Werte werden zur Bestimmung von Dingen wie der »Shared Memory«-Adresse, der Auswahl der Schnittstelle, der Bestimmung des DMA-Kanal u.ä. verwendet. Dieser Parameter wird am häufigsten dafür eingesetzt, die automatische Hardwareerkennung für eine zweite Ethernetkarte zu erzwingen, da standardmäßig nur nach einer gesucht wird. Dieses erreicht man mit einem einfachen Befehl: ether=0,0,eth1 Man beachte, daß im obigen Beispiel der Wert Null für den Interrupt und die I/O-Basisadresse den oder die Treiber auffordert, eine automatische Hardwareerkennung durchzuführen. Falls Sie Module verwenden, sollten sie folgendes bedenken: Oben genanntes Kommando wird keine Überprüfung nach einer zweiten Karte erzwingen, wenn der Treiber für diese Karte zur Laufzeit als Modul geladen wird, weil er nicht im Kernel einkompiliert ist. Die meisten Linux-Distributionen verwenden ein bloßes Kernel-Gerüst zusammen mit einer großen Auswahl an Treibern in Modulform. Das Ethernet HOWTO verfügt über eine komplette und ausführliche Dokumentation über die Verwendung mehrerer Karten und über die spezifische Implementation der param_n Werte bei den jeweiligen Treibern. Interessierten Lesern sei empfohlen, sich in dem entsprechenden Abschnitt dieses Dokuments komplette Informationen über ihre spezielle Karte zu holen. 7.2. Der Disketten-Treiber (»floppy=«) Es gibt eine Fülle von Optionen für den Treiber der Diskettenlaufwerke, die in der Datei README.fd unter linux/drivers/block aufgelistet sind. Diese Informationen wurden direkt dieser Datei entnommen. floppy=mask,allowed_drive_mask Setzt die Bitmaske der möglichen Laufwerke auf mask. Standardmäßig sind nur die Einheiten 0 und 1 eines jeden Floppy- Controllers zugelassen. Dies liegt darin begründet, daß bestimmte ungewöhnliche Hardware wie z.B. PCI-Motherboards von ASUS die Tastatur durch Zugriff auf die Einheiten 2 oder 3 durcheinanderbringen. Diese Option ist durch die Option cmos etwas veraltet. floppy=all_drives Setzt die Bitmaske der möglichen Laufwerke auf »alle Laufwerke«. Man verwende diese Option, wenn man mehr als zwei Laufwerke an einem Floppy-Controller angeschlossen hat. floppy=asus_pci Die Bitmaske wird so eingestellt, daß sie nur die Einheiten 0 und 1 erlaubt. (Standard) floppy=daring Teilt den Floppy-Treiber mit, daß man einen gut funktionierenden Floppy-Controller hat. Dies ermöglicht ein effizienteres und glatteres Arbeiten, kann jedoch bei bestimmten Controllern versagen. Bestimmte Aktionen können dadurch beschleunigt werden. floppy=0,daring Teilt dem Floppy-Treiber mit, daß der Floppy-Controller mit Vorsicht behandelt werden soll. floppy=one_fdc Teilt dem Floppy-Treiber mit, daß nur ein Floppy-Controller vorhanden ist. (Standard) floppy=two_fdc oder floppy=address,two_fdc Teilt dem Floppy-Treiber mit, daß zwei Floppy-Controller vorhanden sind. Es wird angenomen, daß sich der zweite Floppy- Controller auf der Adresse address befindet. Ist keine Adresse angegeben, wird 0x370 angenommen. floppy=thinkpad Teilt dem Floppy-Treiber mit, daß ein Thinkpad verwendet wird. Thinkpads verwenden eine umgekehrte Konvention für die Leitung, die einen Wechsel der Diskette anzeigt. floppy=0,thinkpad Teilt dem Floppy-Treiber mit, daß kein Thinkpad vorhanden ist. floppy=drive,type,cmos Setzt den CMOS-Typ von drive auf type. Zusätzlich ist dieses Laufwerk in der Bitmaske erlaubt. Dieses ist dann hilfreich, wenn mehr als zwei Floppy-Laufwerke vorhanden sind, da im CMOS- RAM des BIOSes lediglich die Werte für zwei Diskettenlaufwerke gespeichert werden können. Ebenfalls nützlich ist diese Option, wenn das BIOS nicht die Standardtypen benutzt. Wenn cmos für die ersten beiden Laufwerke auf 0 gesetzt wird (Standard), dann wird der Floppy-Treiber den physikalischen CMOS-Speicher für diese Laufwerke lesen. floppy=unexpected_interrupts Gibt einen Warnhinweis aus, wenn ein unerwarteter Interrupt erhalten wird. (Standardverhalten) floppy=no_unexpected_interrupts oder floppy=L40SX Gibt keine Nachricht aus, wenn ein unerwarteter Interrupt erhalten wird. Dieses wird auf IBM L40SX Laptops in bestimmten Grafikmodi benötigt. Es scheint eine Interaktion zwischen Grafikkarte und Floppy zu bestehen. Die unerwarteten Interrupts betreffen nur die Performance und können beruhigt ignoriert werden. 7.3. Der Sound-Treiber (»sound=«) Der Treiber für Soundkarten kann auch Bootparameter annehmen, um die hineinkompilierten Werte zu übergehen. Dies wird jedoch nicht empfohlen, da es ziemlich komplex ist. Es ist bzw. war in der Datei Readme.Linux unter linux/drivers/sound beschrieben. Ein Bootparameter folgender Form wird akzeptiert sound=device1[,device2[,device3...[,device11]]] wobei jeder deviceN Wert von folgendem Format ist: 0xTaaaId, und die Bytes folgendermaßen verwendet werden: · T: Geräte-Typ: 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16 und 7=SB16-MPU401 · aaa: I/O-Adresse in hex. · I: Interrupt in hex (i.e 10=a, 11=b, ...) · d: DMA-Kanal. Wie man sieht, ein ganz schönes Durcheinander. Man ist wohl besser beraten, sich, wie empfohlen, seine eigenen, persönlichen Werte hineinzukompilieren. Die Verwendung des Bootparameters sound=0 deaktiviert den gesamten Sound-Treiber. 7.4. Der Bus-Maus-Treiber (»bmouse=«) Der Bus-Maus-Treiber akzeptiert nur einen Parameter, und zwar den Wert des zu verwendenden Interrupts. 7.5. Der MS-Bus-Maus-Treiber (»msmouse=«) Der MS-Maustreiber akzeptiert nur einen Parameter, und zwar den zu verwendenden Hardware IRQ-Wert. 7.6. Der Druckertreiber (»lp=«) Bei den Kernelversionen nach 1.3.75 kann man dem Druckertreiber mitteilen, welche Ports verwendet werden sollen und welche nicht. Letzteres ist dann praktisch, wenn man verhindern will, daß der Druckertreiber alle zur Verfügung stehenden parallelen Ports beansprucht, so daß andere Treiber wie z.B. PLIP oder PPA sie statt dessen verwenden können. Das Argument besteht aus mehreren Paaren von I/O-Adressen und Interrupts. lp=0x3bc,0,0x378,7 verwendet z.B. den Port auf 0x3bc im IRQ-losen Polling-Modus, und benutzt IRQ 7 für den Port auf 0x378. Der Port unter 0x278 würde, falls vorhanden, nicht überprüft werden, da die automatische Hardwareerkennung nur ohne ein lp=-Argument stattfindet. Zum kompletten Deaktivieren des Druckertreibers kann man lp=0 verwenden. 7.7. Der ICN ISDN-Treiber (»icn=«) Dieser ISDN-Treiber erwartet einen Bootparameter folgender Form: icn=iobase,membase,icn_id1,icn_id2 wobei iobase die I/O Port-Adresse der Karte ist, membase die Startadresse des Shared Memory Speichers ist und die zwei icn_id einmalige ASCII-Zeichenketten-Identifier sind. 7.8. Der PCBIT ISDN-Treiber (»pcbit=«) Dieser Bootparameter verwendet Paare von Ganzzahlen-Argumenten, z.B.: pcbit=membase1,irq1[,membase2,irq2] Hierbei ist membaseN die Shared Memory-Basisadresse und irqN die Interrupt-Einstellung der Nten Karte. Standard ist IRQ 5 und ein eingeblendeter Speicher ab 0xD0000. 7.9. Der Teles ISDN-Treiber (»teles=«) Dieser ISDN-Treiber erwartet einen Bootparameter folgender Form: teles=iobase,irq,membase,protocol,teles_id wobei iobase die I/O Port Adresse, membase die Shared Memory- Basisadresse der Karte ist; irq ist der von der Karte verwendete Interrupt und teles_id ist ein eindeutiger ASCII-String-Bezeichner. 7.10. Der DigiBoard-Treiber (»digi=«) Der DigiBoard-Treiber akzeptiert eine Zeichenkette von 6 durch Kommas getrennten Bezeichnern oder Ganzzahlen. Hier die 6 Werte in Reihenfolge: 1. Aktivieren (E) oder Deaktivieren (D) der Karte 2. Kartentyp: PC/Xi (0), PC/Xe (1), PC/Xeve (2) oder PC/Xem (3) 3. Aktivieren (E) oder Deaktivieren (D) der wechselnden Pin-Anordnung 4. Anzahl der I/O-Ports dieser Karte 5. I/O-Port, über den die Karte konfiguriert wird (in hex, falls String-Bezeichner verwendet werden) 6. Basisadresse des Speicher-Fensters (in hex, falls String-Bezeichner verwendet werden) Hier ein Beispiel eines korrekten Bootparameters sowohl in Bezeichner- als auch in Ganzzahlen-Form: digi=E,PC/Xi,D,16,200,D0000 digi=1,0,0,16,512,851968 Man beachte, daß der Treiber standardmäßig den I/O-Port 0x200 und die Shared Memory-Basisadresse 0xD0000 voreingestellt hat, falls kein digi= Bootparameter angegeben wurde. Es wird keine automatische Hardwareerkennung durchgeführt. Weitere Informationen findet man in der Datei linux/Documentation/digiboard.txt. 7.11. Der RISCom/8 Multiport Seriell-Treiber (»riscom8=«) Bis zu vier Karten werden unterstützt, indem man vier eindeutige I/O Port-Werte für jede einzelne Karte angibt. Weitere Informationen findet man in der Datei linux/Documentation/riscom8.txt. 7.12. Das Baycom Seriell/Parallel Radio Modem (»baycom=«) Der Bootparameter für diese Geräte hat folgendes Format: baycom=modem,io,irq,options[,modem,io,irq,options] Die Verwendung von modem=1 bedeutet, daß man das ser12-Gerät hat, modem=2 bedeutet, man hat das par96-Gerät. options=0 bedeutet die Verwendung von Hardware-DCD, und options=1 bedeutet die Verwendung von Software-DCD. io und irq sind wie gewöhnlich die I/O Port-Basisadresse und der Interrupt. Weitere Informationen findet man in der Datei README.baycom, die sich zur Zeit im Verzeichnis /linux/drivers/char/ befindet. 8. Schlußbemerkung Sollten Ihnen irgendwelche Tippfehler ins Auge gesprungen sein, oder haben Sie veraltete Informationen in diesem Dokument gefunden, dann lassen Sie es mich bitte wissen. Es macht nicht viel Mühe, den Text durchzugehen. Danke, Paul Gortmaker (gpg109@rsphy1.anu.edu.au)