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.

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.

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.

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.

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=<offset>. 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.

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.

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.

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.

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.

Das Kommando »noinitrd«

Kernel v2.x und neuere verfügen über ein Feature, bei dem das Root-Dateisystem anfangs eine RAM-Disk sein kann und der Kernel auf diesem RAM-Image /linuxrc 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.

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. 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. Für einen Rechner mit z.B. 128 MB RAM würde man mem=128m verwenden.

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. Das Kernel enthält nützliche Dokumentationen zu diesem Thema im Verzeichnis linux/Documentation/vm/.

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. Das Kernel enthält nützliche Dokumentationen zu diesem Thema im Verzeichnis linux/Documentation/vm/.

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.

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=[<server-ip>:]<root-verz>[,<nfs-optionen>]

Wird der nfsroot-Parameter nicht auf der Kommandozeile angegeben, dann wird standardmäß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-verz>

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-optionen>

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 ü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=<meine-ip>:<serv-ip>:<gw-ip>:<netmask>:<name>:<dev>:<auto>

<meine-ip>

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 <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 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.

<gw-ip>

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>

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>

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

<dev>

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.

<auto>

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 <auto> 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.

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.

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.

Der Parameter »kbd-reset«

Normalerweise wird bei i386 basierten Rechnern der Tastaturkontroller vom Linux Kernel beim Booten nicht initialisiert, da diese Aufgabe vom BIOS übernommen wird. Aber, wie es nicht anders zu erwarten war, machen dieses nicht alle Rechner standardmäßig. Die Verwendung dieses Parameters kann helfen, wenn es Probleme mit der Tastatur gibt. Der Parameter führt einfach dazu, daß beim Booten der Kontroller initialisiert wird.

Der Parameter »maxcpus=«

Die mit dem Parameter übergebene Zahl limitiert die maximale Anzahl von CPUs, die im SMP-Modus aktiviert werden. Die Verwendung der Zahl »0« hat die gleiche Funktion wie der nosmp Parameter.

Der Parameter »mca-pentium«

Die IBM Model 95 Microchannel Rechner scheinen sich beim dem Test aufzuhängen, den Linux durchführt, um den Typ der Kopplung des mathematischen Koprozessors mit der CPU zu ermitteln. Da alle Pentium CPUs einen eingebauten Koprozessor besitzen, kann dieser Test und damit das beschriebene Probleme durch die Verwendung dieses Parameter unterdrückt werden.

Der Parameter »md=«

Wenn sich das Root-Dateisystem sich auf einem Multiple Device befindet, kann dieser Parameter verwendet werden, um dem Kernel das Layout des Multiple Devices mitzuteilen. Hierfür muß natürlich die Bootunterstützung einkompiliert sein. Das Format dieses Parameter sieht so aus:

md=md_device_num,raid_level,chunk_size_factor,fault_level,dev0,dev1,...,devN

Siehe auch die Datei linux/Documentation/md.txt. Hierbei ist md_device_num die Nummer des md Devices; 0 würde für md0, 1 für md1 usw. stehen. Für raid_level kann -1 (Linearer Modus) oder 0 (Striped Modus) verwendet werden. Andere Modi werden zur Zeit nicht unterstützt. Die Option chunk_size_factor kann nur für RAID-0 und RAID-1 benutzt werden. Mit ihr wird die Chunk Size gesetzt; aus dem übergebenen Wert wird die Chunk Size berechnet, in dem die PAGE_SIZE um den angegebenen Wert nach links geshiftet wird. Mit fault_level wird die maximale Anzahl von Fehlern bei RAID-1 festgelegt; da von RAID-1 zur Zeit nicht gebootet werden kann, hat diese Option keine Funktion. dev0,dev1,...,devN ist eine durch Kommata getrennte Liste von Devices, aus denen das md Device gebildet wird, z.B. /dev/hda1,/dev/hdc1,/dev/sda1.

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.

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.

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 »noapic«

Durch die Verwendung dieses Parameters wird einem SMP-Kernel mitgeteilt, nicht die erweiterten Funktionen des Interrupt Kontrollers eines Mehrprozessorrechners zu benutzen. Weitere Informationen hierzu sind in der Datei linux/Documentation/IO-APIC.txt zu finden.

Der Parameter »nosmp«

Mittels dieses Parameters kann ein SMP-Kernel angewiesen werden, auf einem SMP-Rechner nur einen Prozessor zu verwenden. Typischerweise wird dieser Parameter nur fürs Debugging benutzt oder um herauszufinden, ob ein bestimmtes Problem durch SMP verursacht wird.

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.

Der Parameter »pirq=«

Diese Parameter dient dazu, einem SMP-Kernel Informationen über die Interrupts der PCI-Steckplätze für unbekannte oder sich auf der schwarzen Liste befindliche SMP Motherboards zu übergeben. Weitere Informationen hierzu sind in der Datei linux/Documentation/IO-APIC.txt zu finden.

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.

Der Parameter »reboot=«

Diese Option kontrolliert die Art des Reboots, die Linux beim Reset des Rechners ausführt. Seit 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.

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.

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.

Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 17:56:57