Inhalt

3. Allgemeine, Geräte-unabhängige Bootparameter

Hier handelt es sich um Bootparameter, die mit keinem speziellen Gerät oder Peripheriegerät verknüpft sind. Statt dessen sind sie mit bestimmten internen Kernel-Parametern verbunden, wie z.B. der Umgang mit Speicher, Ramdisk, Root-Dateisystem und andere.

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.

Der Parameter `root='

Dieser Parameter teilt dem Kernel mit, welches Gerät beim Booten als Root-Dateisystem benutzt werden soll. Die Standardeinstellung ist hierbei der Wert des Root-Geräts des Systems, auf dem der Kernel gebaut wurde. Wurde der fragliche Kernel z.B. auf einem System gebaut, das /dev/hda1 als Root-Partition verwendete, dann wäre das Standard- Root-Gerät /dev/hda1. Will man diesen Standard-Wert außer Kraft setzen und das zweite Diskettenlaufwerk als Root-Gerät wählen, würde man root=/dev/fd1 wählen.

Gültige Root-Geräte:

  1. /dev/hdaN bis /dev/hddN, welches Partition N auf der ST-506-kompatiblen Platte `a bis d' ist.
  2. /dev/sdaN bis /dev/sdeN, welches Partition N auf der SCSI-kompatiblen Platte `a bis e' ist.
  3. /dev/xdaN bis /dev/xdbN, welches Partition N auf der XT-kompatiblen Platte `a bis b' ist.
  4. /dev/fdN, welches das Floppy-Platten-Laufwerk Nummer N ist. N=0 wäre das DOS-Laufwerk `A:' und N=1 wäre `B:'.
  5. /dev/nfs, was eigentlich kein wirkliches Gerät ist, sondern eher ein Kennzeichen, das den Kernel auffordert, das Root-Dateisystem über das Netzwerk zu holen.

Die schwierigere und weniger portierbare numerische Bestimmung der oben genannten, möglichen Plattengeräte im major/minor-Format wird auch akzeptiert. (z.B. /dev/sda3 ist major 8, minor 3, d.h. man könnte als Alternative auch root=0x803 verwenden.)

Dies ist einer der wenigen Kernel-Bootparameter, dessen Standard im Kernelimage gespeichert ist, und welcher deshalb mit dem Hilfsprogramm rdev geändert werden kann.

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 man keine verläßliche Überprüfung der Dateisystem-Integrität vornehmen, während halb-geschriebene Dateien geprüft werden. Mit der Option `ro' wird der Kernel aufgefordert, das Root-Dateisystem als `readonly' zu mounten, so daß Programme zur Konsistenzprüfung des Dateisystems (fsck) mit Sicherheit annehmen können, daß keinerlei halb-geschriebene Dateien geprüft werden, während die Überprüfung stattfindet. Kein Programm oder Prozeß kann Dateien des fraglichen Dateisystems beschreiben bis es nicht mit Lese/Schreibrecht wieder gemountet ist.

Dies ist einer der wenigen Kernel-Bootparameter, dessen Standard im Kernelimage gespeichert ist, und welcher deshalb mit dem Hilfsprogramm rdev geändert werden kann.

Der Paramater `rw'

Dies ist das exakte Gegenteil vom eben genannten. Hier wird der Kernel nämlich aufgefordert, das Root-Dateisystem mit Lese/Schreibrecht zu mounten. Die Default-Einstellung ist sowieso das Mounten des Root-Datei-Systems 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, welches normalerweise für Bootstrapping-Rechner während des Installationsvorgangs verwendet wird, oder für Rechner mit Modultreibern, die zum Zwecke des Zugriffs auf das Root-Dateisystem installiert werden müssen.

Das Kommando `ramdisk_start='

Das Kommando `ramdisk_start=<offset>' ermöglicht einem Kernel-Image, zusammen mit einem komprimierten Ramdisk-Image auf einer Floppy zu bleiben. Der Kernel kann nicht in das komprimierte Ramdisk-Dateisystem-Image aufgenommen werden, weil er beginnend mit Block Null gespeichert werden muß, so daß das BIOS den Bootsektor laden kann. Dann kann der Kernel sich selbst erstmalig booten und damit zum Laufen bringen.

Wichtig: Benutzt man ein unkomprimiertes Ramdisk-Image, dann kann der Kernel Teil des Dateisystem-Images sein, das in die Ramdisk geladen wird und die Floppy kann mit LILO gebootet werden. Die beiden können auch getrennt sein wie bei den komprimierten Images.

Verwendet man ein 2-Disketten Boot/Root-Setup (Kernel auf Diskette 1, Ramdisk-Image auf Diskette 2) dann startet die Ramdisk 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.

Das Kommando `load_ramdisk='

Dieser Parameter teilt dem Kernel mit, ob er ein Ramdisk-Image laden soll oder nicht. `load_ramdisk=1' soll den Kernel veranlassen, eine Floppy in die Ramdisk zu laden. Der Standardwert ist Null, was bedeutet, daß der Kernel nicht versuchen soll, eine Ramdisk 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 bestimmt und via rdev im Kernel-Image gespeichert werden kann.

Das Kommando `prompt_ramdisk='

Dieser Parameter teilt dem Kernel mit, ob er einen Prompt ausgeben soll mit dem man aufgefordert wird, die Floppy mit dem Ramdisk-Image einzulegen. Bei einer 1-Disketten-Konfiguration befindet sich das Ramdisk-Image auf der gleichen Floppy wie der Kernel, der gerade den Lade-/Bootvorgang beendet hat. Somit wird ein Prompt nicht benötigt. In diesem Fall kann man das Kommando `prompt_ramdisk=0' verwenden. Bei einer 2-Disketten- Konfiguration 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. (Geschichtliche Anmerkung: Heimtückische Anwender verwendeten gewöhnlich die Option `vga=ask' LILO, um den Bootprozeß zeitweilig zu stoppen und ein Umschalten von der Boot- zur Rootfloppy 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.

Das Kommando `ramdisk_size='

Zwar stimmt es, daß die Ramdisk je nach Bedarf dynamisch wächst, jedoch gibt es eine Obergrenze für ihre Größe, so daß nicht der gesamte RAM verbraucht wird und einem Schwierigkeiten erspart werden. Der Standardwert ist 4096 (4MB), 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.

Das Kommando `ramdisk=' (veraltet)

Wichtig: Dieser Parameter ist veraltet und sollte nicht verwendet werden, es sei denn für die Kernelversion v1.3.47 oder ältere. Die Kommandos, die für das Ramdisk-Device verwendet werden sollten sind oben beschrieben.

Dies gibt in KB die Größe des RAM-Disk-Devices an. Würde man z.B. ein Root-Dateisystem auf einer 1,44 MB Floppy 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 somit mit dem Hilfsprogramm rdev verändert werden kann.

Das Kommando `noinitrd' (initial RAM-Disk)

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 (z.B. Laden der SCSI-Treiber-Module, die im RAM-Disk-Image gespeichert sind und anschließendes Mounten des eigentlichen Root-Dateisystems auf einer SCSI-Diskette.)

Der eigentliche `noinitrd'-Parameter bestimmt, was mit den initrd-Daten passiert, nachdem der Kernel gebootet hat. Wenn Sie bestimmt werden, statt auf eine RAM-Disk konvertiert zu werden, sind die Daten erhältlich unter /dev/initrd, welche eingesehen werden kann bevor der RAM wieder dem System übergeben 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 nach, wie Linux den physikalischen oder virtuellen Systemspeicher erkennt oder behandelt.

Der Parameter `mem='

Dieser Parameter dient zwei verschiedenen Zwecken: Der ursprüngliche Zweck war die Bestimmung der installierten Speicherkapazität (oder ein kleinerer Wert, falls man den Speicherplatz für Linux verringern wollte). Der andere (und kaum verwendete) Zweck ist die Bestimmung von mem=nopentium, das den Linux-Kernel auffordert, das 4 MB Seitentabellen-Performance-Feature nicht zu verwenden.

Der ursprüngliche BIOS-Aufruf, definiert in der PC-Spezifikation, der den installierten Speicherplatz wiedergibt, wurde nur deswegen eingeführt, um bis zu 64 MB angeben zu können. (Richtig, wieder mangelnde Voraussicht, genau wie bei den 1024 Zylinder-Platten... seufz.) Linux verwendet diesen BIOS-Aufruf beim Booten zur Bestimmung des installierten Speicherplatzes. 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:

The kernel will accept any `mem=xx' parameter you give it, and if it turns out that you lied to it, it will crash horribly sooner or later. The parameter indicates the highest addressable RAM address, so `mem=0x1000000' means you have 16 MB of memory, for example. For a 96 MB machine this would be `mem=0x6000000'.

WICHTIG WICHTIG WICHTIG: Einige Rechner verwenden möglicherweise den größtmöglichen Speicherplatz für das Bereithalten des BIOS im Cache o. ä., so daß man möglicherweise nicht wirklich die vollen 96 MB belegen kann. Auch das Gegenteil trifft zu: Einige Chipsets 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 Parameter keine Hexadezimalzahl sein muß und daß die Endungen `k' und `M' (egal, ob Groß- oder Kleinschreibung) zur Bestimmung von Kilobytes, beziehungsweise Megabytes verwendet werden können. (`k' verursacht auf dem Wert eine Verschiebung von 10 Bit und `M' verursacht eine Verschiebung um 20 Bit.) 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.

Der Parameter `swap='

Hier wird dem Anwender die Feineinstellung eines Teils der virtuellen Speicherparameter ermöglicht, die mit Diskswapping zu tun haben. Folgende 8 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 auf die `Goodies' in /proc/sys/vm werfen.

Der Parameter `buff='

Ähnlich dem `swap='-Parameter wird dem Anwender die Feineinstellung einiger der Parameter für die Buffer-Speicherverwaltung ermöglicht. Folgende 6 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 auf die `Goodies' in /proc/sys/vm werfen.

3.4 Bootparameter für das NFS-Root-Dateisystem

Linux unterstützt Systeme wie laufwerkslose Workstations, indem ihr Rootfilesystem als NFS (Network FileSystem) besteht. 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 Information lediglich aus einer Zusammenfassung dieser Datei besteht.

Der Parameter `nfsroot='

Dieser Parameter teilt dem Kernel mit, welcher Rechner, welches Verzeichnis und welche NFS-Optionen für das Rootfilesystem ver- wendet werden sollen. Der Parameter ist folgendermaßen aufgebaut:

nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]

Wird der nfsroot-Parameter nicht auf der Kommandozeile angegeben, dann wird defaultmäßig `/tftpboot/%s' verwendet. Andere mögliche Optionen sind:

<server-ip>

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.

<root-dir>

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.

<nfs-options>

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

Der Parameter `nfsaddrs='

Dieser Bootparameter bestimmt die verschiedenen Adressen der Netzwerkschnittstellen, die zur Kommunikation übers Netzwerk benötigt werden. Wird dieser Parameter nicht angegeben, dann versucht der Kernel die Verwendung von RARP und/oder BOOTP, um diese Parameter herauszufinden. Dies sieht folgendermaßen aus:

nfsaddrs=<my-ip>:<serv-ip>:<gw-ip>:<netmask>:<name>:<dev>:<auto>

<my-ip>

IP-Adresse des Clients. Ist dieses Feld leer, wird die Adresse entweder von RARP oder von BOOTP bestimmt. Welches Protokoll verwendet wird, hängt vom <auto> Parameter ab und davon, was während der Kernelkonfiguration aktiviert wurde. Ist dieser Parameter nicht leer, dann wird weder RARP noch BOOTP benutzt.

<serv-ip>

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 im nfsroot- Parameter fest (siehe oben). Bleibt dieser Eintrag aus, dann wird die Adresse des Servers verwendet, welcher auf die RARP- oder BOOTP-Anfrage antwortete.

<gw-ip>

IP-Adresse eines Gateways, falls der Server sich auf einem anderen Subnetz befindet. Ist dieser Eintrag leer, dann wird kein Gateway verwendet und es wird angenommen, daß sich der Server auf dem lokalen Netzwerk befindet, bis BOOTP einen Wert erhält.

<netmask>

Netzmaske für die lokale Netzwerkschnittstelle. Ist dieser Eintrag leer, dann wird die Netzmaske von der Client-IP-Adresse abgeleitet, bis BOOTP einen Wert erhält.

<name>

Name des Clients. Bleibt dieses Feld leer, dann wird die Client-IP-Adresse in ASCII-Notation verwendet oder der von BOOTP empfangene Wert.

<dev>

Name des zu verwendenden Netzwerk-Geräts. Ist dieses Feld leer, dann werden alle Geräte für RARP-Anfragen verwendet und das erste für BOOTP. Für NFS wird das Gerät benutzt, von dem entweder RARP- oder BOOTP-Antworten empfangen wurden. Besitzt man nur ein Gerät kann man dieses Feld getrost leer lassen.

<auto>

Zu verwendende Methode für die AutoKonfiguration. Ist dies 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 AutoKonfiguration aus. In diesem Fall müssen alle notwendigen Werte in den vorherigen Feldern bestimmt werden.

Der Parameter <auto> kann alleine als Wert für den Parameter nfsaddrs erscheinen (ohne die ganzen `:' Zeichen davor). In diesem Fall wird Autokonfiguration 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.

Der Parameter `debug'

Mittels der Funktion printk() schickt der Kernel wichtige (und weniger wichtige) Nachrichten an den Operator. Wird die Nachricht als wichtig angesehen, dann wird die Funktion printk() eine Kopie auf die aktuelle Konsole senden und sie an das Hilfsprogramm klogd() aushändigen, so daß sie auf Festplatte aufgezeichnet wird. Der Grund für die Ausgabe wichtiger Nachrichten auf der Konsole und gleichzeitiger Protokollierung durch die Festplatte liegt darin, daß unter unglücklichen Umständen (z.B. ein Plattenausfall) die Nachricht nicht zur Festplatte gelangt und somit verlorengeht.

Der Level 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 festgehalten. (Die verschiedenen Level sind in der include-Datei kernel.h) definiert. Das Festlegen von debug als Bootparameter setzt den Loglevel der Konsole auf 10, so daß alle Kernel- Mitteilungen auf der Konsole erscheinen.

Der Loglevel der Konsole kann normalerweise auch bei der Ausführung mittels einer Option an das Programm klogd() festgelegt werden. Informationen darüber kann man der Manpage zu der auf dem System installierten Version entnehmen.

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 (herabgesetzt) 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 den Bootprompt init=/bin/sh verwenden, was beim Booten direkt eine Shell öffnet und somit ein Ersetzen des verfälschten Programms ermöglicht.

Der Parameter `no387'

Einige i387 Koprozessor-Chips haben Bugs, die sich bei der Verwendung im 32 bit-geschützten Modus zeigen. Einige der frühen ULSI-387 Chips verursachen z.B. massive Totalsperren während der Ausführung von Fließpunkt-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 mit mathematischer Emulations-Unterstützung kompiliert sein! Dies ist möglicherweise auch dann sinnvoll, wenn man einen dieser wirklich alten 386er hat, die einen 80287 FPU verwenden können, da Linux keinen 80287 verwenden kann.

Der Parameter `no-hlt'

Die i386-Familie der 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. Dies erlaubt der CPU in einen `low-power' Modus einzutreten, wo sie wie ein Zombie verharrt, bis sie von einem externen Gerät geweckt wird (gewöhnlich durch einen Interrupt). Einige der frühen i486DX-100 Chips 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 laufen zu lassen, wenn es nichts anderes zu tun gibt und die CPU nicht zu stoppen, wenn es keine aktiven Prozesse gibt. Dies ermöglicht Benutzern mit solchen kaputten Chips die Verwendung von Linux, obwohl sie gut beraten wären, sich durch eine möglicherweise vorhandene Garantie einen Ersatz zu suchen.

Der Parameter `no-scroll'

Die Angabe dieses Parameters beim Booten setzt Bildlauf-Features außer Kraft, die die Verwendung von Braille-Terminals erschweren.

Der Parameter `panic='

Für den unwahrscheinlichen Fall einer Kernel-Panic (ein interner Fehler, der vom Kernel erkannt wurde und den der Kernel als ernst genug erachtet, um sich laut zu beschweren und dann alles zu stoppen), wird für gewöhnlich gewartet, bis jemand vorbeikommt, die Panik-Message auf dem Bildschirm entdeckt und den Rechner neu bootet. 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-Panic versuchen würde, sich selbst zu booten. Standardwert ist Null und führt zum Standardverhalten, das darin besteht, endlos zu warten.

Man beachte, daß dieser Zeitlimit-Wert auch durch die Schnittstelle /proc/sys/kernel/panic sysctl gelesen und festgelegt werden kann.

Der Parameter `profile='

Kernel-Entwickler können eine Option aktivieren, die es ihnen erlaubt, festzulegen, 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 automatischer Aktivierung des Profiling kompilieren. In jedem Fall braucht man ein Tool wie readprofile.c , das die Ausgabe /proc/profile verwenden kann.

Der Parameter `reboot='

Diese Option kontrolliert die Art des Reboots, die Linux beim Reset des Rechners ausführt (normalerweise via /sbin/init das Control-Alt-Delete ausführt). Seit den späten v2.0-Kerneln 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 dies bei billiger/kaputter Hardware, die es nicht schafft neu zu booten, wenn ein Warmstart erforderlich wäre, normalerweise funktioniert. Zum Wiederherstellen des alten Zustands (hier: Warmstart) 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 wahrnehmen und Daten vom Cache auf die Festplatte schreiben. Nach einem Kaltstart wird die Speicherkarte möglicherweise zurückgeschaltet und die write-back-Daten im Cache-Speicher gehen verloren. Andere haben Systeme, die lange für den Speicher-Check brauchen und/oder SCSI BIOSe, die nach einem Kaltstart länger für die Initialisierung brauchen als guten Grund für den Einsatz eines Warmstarts gemeldet.

Der Parameter `reserve='

Dieser wird dazu benutzt, I/O Port-Bereiche vor Überprüfungen zu schützen. Das Kommando ist folgendermaßen aufgebaut:

reserve=iobase,extent[,iobase,extent]...

Bei einigen Rechnern mag es notwendig sein, Gerätetreiber davon abzuhalten, in einer bestimmten Region nach Geräten zu suchen (automatische Hardwareerkennung). 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 Port-Registrationstabelle des Kernels so behandelt, als ob dort bereits ein Gerät gefunden wurde (trägt den Namen reserved). 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 sind gegen eine Geräteerkennung geschützt, bei der vorrangig check_region() ausgeführt wird, statt daß blind ein I/O Bereich geprüft wird. Dies wird dann eingesetzt, wenn Treiber auf einem NE2000 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 dies 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 eine genaue Erkennung für dieses Gerät bestimmen. Die meisten Treiber ignorieren die Port- Registrations-Tabelle, 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 11 Parametern, d.h. man kann nur 5 reservierte Bereiche pro reserve Schlüsselwort bestimmen. Bei ungewöhnlich komplizierten Anfragen sind jedoch mehrere reserve Argumente möglich.

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ähnug verdient. Sie kann auch durch die Verwendung von rdev -v festgelegt werden und ebenso durch vidmode auf der Datei vmlinuz. Dies 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.


Inhalt