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.
Folgende Optionen beziehen sich alle auf das Vorgehen des Kernels bei der Auswahl und dem Umgang mit dem Root-Dateisystem.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Folgende Parameter ändern sich je nachdem, wie Linux den physikalischen oder virtuellen Systemspeicher erkennt oder mit ihm umgeht.
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 allemem=xxParameter 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=0x1000000bedeutet, daß man 16 MB Speicher besitzt. Für einen Rechner mit 96 MB wäre der Bootparametermem=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.
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.
Ä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.
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.
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:
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
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>
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.
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 <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.
Diese verschiedenen Bootparameter erlauben dem Benutzer die Feineinstellung bestimmter interner Parameter.
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 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.
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.
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.
Die Angabe dieses Parameters beim Booten setzt Bildlauf-Features außer Kraft, die die Verwendung von Braille-Terminals erschweren.
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.
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.
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.
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.
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.