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.
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 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:
/dev/hdaN
bis /dev/hddN
, welches Partition
N auf der ST-506-kompatiblen Platte `a bis d' ist.
/dev/sdaN
bis /dev/sdeN
, welches Partition
N auf der SCSI-kompatiblen Platte `a bis e' ist.
/dev/xdaN
bis /dev/xdbN
, welches Partition
N auf der XT-kompatiblen Platte `a bis b' ist.
/dev/fdN
, welches das Floppy-Platten-Laufwerk
Nummer N ist.
N=0 wäre das DOS-Laufwerk `A:' und N=1 wäre `B:'.
/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.
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.
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
.
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=<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.
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.
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.
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.
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.
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.
Folgende Parameter ändern sich, je nach, wie Linux den physikalischen oder virtuellen Systemspeicher erkennt oder behandelt.
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.
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.
Ä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.
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.
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:
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 ü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>
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.
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.
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.
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 des Clients. Bleibt dieses Feld leer, dann wird die Client-IP-Adresse in ASCII-Notation verwendet oder der von BOOTP empfangene Wert.
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.
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.
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 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 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.
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.
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.
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-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.
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.
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.
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.
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.