/usr/share/doc/HOWTO/de-html/DE-BootPrompt-HOWTO-3.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.65">
 <TITLE>Linux BootPrompt HOWTO: Allgemeine, ger&auml;teunabh&auml;ngige Bootparameter       </TITLE>
 <LINK HREF="DE-BootPrompt-HOWTO-4.html" REL=next>
 <LINK HREF="DE-BootPrompt-HOWTO-2.html" REL=previous>
 <LINK HREF="DE-BootPrompt-HOWTO.html#toc3" REL=contents>
</HEAD>
<BODY>
<A HREF="DE-BootPrompt-HOWTO-4.html"><IMG SRC="next.png" ALT="Weiter"></A>
<A HREF="DE-BootPrompt-HOWTO-2.html"><IMG SRC="prev.png" ALT="Zurück"></A>
<A HREF="DE-BootPrompt-HOWTO.html#toc3"><IMG SRC="toc.png" ALT="Inhalt"></A>
<HR>
<H2><A NAME="DE-BootPrompt-HOWTO-general"></A> <A NAME="s3">3.</A> <A HREF="DE-BootPrompt-HOWTO.html#toc3">Allgemeine, ger&auml;teunabh&auml;ngige Bootparameter       </A></H2>


<P>Hierbei handelt es sich um Bootparameter, die mit keinem speziellen
Hardware-Treiber verkn&uuml;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.</P>


<H2><A NAME="ss3.1">3.1</A> <A HREF="DE-BootPrompt-HOWTO.html#toc3.1">Root-Dateisystem Optionen        </A>
<!--Bootparameter!Root-Dateisystem--></H2>


<P>Folgende Optionen beziehen sich alle auf das Vorgehen des Kernels
bei der Auswahl und dem Umgang mit dem Root-Dateisystem.</P>


<H3>Der Parameter »root=« </H3>


<P>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 <CODE>/dev/hda1</CODE> als Root-Partition verwendete, dann 
geht der Kernel davon aus, da&szlig; sich das Root-Dateisystem auf
<CODE>/dev/hda1</CODE> befindet. Will man diesen Standardwert au&szlig;er
Kraft setzen und z.B. das zweite Diskettenlaufwerk als Root-Device
verwenden, w&uuml;rde man <CODE>root=/dev/fd1</CODE> w&auml;hlen.</P>
<P>G&uuml;ltige Root-Devices sind:</P>
<P>
<UL>
<LI><CODE>/dev/hdaN</CODE> bis <CODE>/dev/hddN</CODE>: Partition N
auf der ST-506-kompatiblen (IDE) Festplatte <CODE>a</CODE> bis 
<CODE>d</CODE>
</LI>
<LI><CODE>/dev/sdaN</CODE> bis <CODE>/dev/sdeN</CODE>: Partition N 
auf der SCSI-kompatiblen Festplatte <CODE>a</CODE> bis <CODE>e</CODE>
</LI>
<LI><CODE>/dev/xdaN</CODE> bis <CODE>/dev/xdbN</CODE>: Partition N 
auf der XT-kompatiblen Festplatte <CODE>a</CODE> bis <CODE>b</CODE>
</LI>
<LI><CODE>/dev/fdN</CODE>: Diskettenlaufwerk mit der Nummer N. 
N=0 w&auml;re das DOS-Laufwerk »A:« und N=1 w&auml;re 
»B:«.
</LI>
<LI><CODE>/dev/nfs</CODE>: Dieses ist nicht wirklich ein Device,
sondern teilt dem Kernel lediglich mit, da&szlig; das Root-Dateisystem
&uuml;ber das Netzwerk geholt werden soll.</LI>
</UL>
</P>
<P>Die schwierigere und weniger portable numerische Bestimmung
der oben genannten, m&ouml;glichen Devices f&uuml;r Festplatten im
Major-/Minor-Format wird auch akzeptiert. So entspricht z.B.
Major 8, Minor 3 der Partition <CODE>/dev/sda3</CODE>, so da&szlig; man
alternativ <CODE>root=0x803</CODE> verwenden k&ouml;nnte.</P>
<P>Dies ist einer der wenigen Kernel-Bootparameter, dessen Standard
im Kernelimage gespeichert ist, und welcher deshalb mit dem
Hilfsprogramm <CODE>rdev</CODE> ge&auml;ndert werden kann.</P>


<H3>Der Parameter »ro« </H3>


<P>Wenn der Kernel bootet, wird dabei ein Root-Dateisystem
ben&ouml;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&auml;&szlig;liche &Uuml;berpr&uuml;fung
der Integrit&auml;t des Dateisystems vorgenommen werden, weil
z.B. gleichzeitig ein anderer Proze&szlig; eine Datei bearbeitet
und damit das zu pr&uuml;fende Dateisystem ver&auml;ndert. Mit der Option 
<CODE>ro</CODE>
wird der Kernel aufgefordert, das Root-Dateisystem nur mit
Leserecht (engl. readonly)
zu mounten, so da&szlig; Programme zur Konsistenzpr&uuml;fung des
Dateisystems (fsck) mit Sicherheit annehmen k&ouml;nnen, da&szlig;
keinerlei halb geschriebene Dateien existieren, w&auml;hrend
die &Uuml;berpr&uuml;fung stattfindet. Kein Programm oder
Proze&szlig; kann Dateien des fraglichen Dateisystems ver&auml;ndern,
bis es nicht mit Lese-/Schreibrecht wieder gemountet ist.</P>
<P>Auch diese Einstellung ist im Kernelimage gespeichert und kann
deshalb mit dem Programm <CODE>rdev</CODE> ver&auml;ndert werden.</P>


<H3>Der Paramater »rw« </H3>


<P>Dieser Parameter ist das exakte Gegenteil vom eben Genannten. 
Hier wird der Kernel n&auml;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.</P>
<P>Der bereits oben erw&auml;hnte, in der Image-Datei gespeicherte
Wert ist der gleiche, der auch f&uuml;r diesen Parameter verwendet
wird. Der Zugriff darauf erfolgt &uuml;ber <CODE>rdev</CODE>.</P>


<H2><A NAME="ss3.2">3.2</A> <A HREF="DE-BootPrompt-HOWTO.html#toc3.2">Optionen der RAM-Disk-Verwaltung        </A>
<!--Bootparameter!RAM-Disk-->       <!--RAM-Disk!Bootparameter--></H2>


<P>Folgende Optionen beziehen sich alle auf den Umgang des
Kernels mit dem RAM-Disk-Device. Eine RAM-Disk wird haupts&auml;chlich
w&auml;hrend der Installation einer Linux Distribution verwendet.
Au&szlig;erdem ist die RAM-Disk auch sehr n&uuml;tzlich, wenn der Kernel
f&uuml;r den Zugriff auf das Root-Dateisystem zuerst Treiber laden
mu&szlig;, die als Modul kompiliert worden sind.</P>


<H3>Das Kommando »ramdisk_start=« </H3>

<P>Damit ein Kernel-Image zusammen mit dem komprimierten Image
einer RAM-Disk auf einer Diskette gespeichert werden kann,
existiert der Parameter <CODE>ramdisk_start=&lt;offset&gt;</CODE>.
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&szlig;, so da&szlig; das
BIOS den Bootsektor laden kann. Dann kann der Kernel sich selbst
erstmalig booten und damit zum Laufen bringen.</P>
<P>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&ouml;nnen auch getrennt sein wie bei den
komprimierten Images.</P>
<P>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.</P>

<H3>Das Kommando »load_ramdisk=« </H3>


<P>Dieser Parameter teilt dem Kernel mit, ob ein Image einer RAM-Disk
geladen werden soll oder nicht. Durch die Angabe von
<CODE>load_ramdisk=1</CODE> wird der Kernel
veranla&szlig;t, eine Diskette in die RAM-Disk zu laden. Der Standardwert
ist Null, was bedeutet, da&szlig; der Kernel nicht versuchen soll,
eine RAM-Disk zu laden.</P>
<P>Eine komplette Beschreibung der neuen Bootparameter
und deren Verwendung findet man in der Datei
<CODE>linux/Documentation/ramdisk.txt</CODE>. Es wird auch beschrieben,
wie dieser Parameter mit <CODE>rdev</CODE> im Kernel-Image
gespeichert werden kann.</P>

<H3>Das Kommando »prompt_ramdisk=« </H3>


<P>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&ouml;tigt. In diesem Fall kann man 
<CODE>prompt_ramdisk=0</CODE> verwenden. Bei einer Konfiguration 
mit zwei Disketten wird man die M&ouml;glichkeit des Diskettentauschs
ben&ouml;tigen. Somit kann <CODE>prompt_ramdisk=1</CODE> verwendet
werden. Da dies der Standardwert ist, mu&szlig; er eigentlich nicht
angegeben werden. Fr&uuml;her haben raffinierte Anwender die Option
<CODE>vga=ask</CODE> von LILO verwendet,
um den Bootproze&szlig; zeitweilig zu stoppen und ein Wechsel von
der Boot- zur Rootdiskette zu erm&ouml;glichen.</P>
<P>Eine komplette Beschreibung der neuen Bootparameter
und deren Benutzung findet man in der Datei
<CODE>linux/Documentation/ramdisk.txt</CODE> Es wird auch beschrieben,
wie dieser Parameter bestimmt und via <CODE>rdev</CODE> im Kernel-Image
gespeichert werden kann.</P>

<H3>Das Kommando »ramdisk_size=« </H3>


<P>Zwar stimmt es, da&szlig; die RAM-Disk je nach Bedarf dynamisch
w&auml;chst, jedoch gibt es eine Obergrenze f&uuml;r ihre
Gr&ouml;&szlig;e, so da&szlig; nicht der gesamte Speicher verbraucht wird und
es zu Problemen kommt. Der Standardwert ist 4096
(4&nbsp;MB), was den meisten Anspr&uuml;chen gen&uuml;gen sollte. Mit
diesem Bootparameter kann man den Standardwert verringern oder
vergr&ouml;&szlig;ern.</P>
<P>Eine komplette Beschreibung der neuen Bootparameter
und deren Benutzung findet man in der Datei
<CODE>linux/Documentation/ramdisk.txt</CODE> Es wird auch beschrieben,
wie dieser Parameter bestimmt und via <CODE>rdev</CODE> im Kernel-Image
gespeichert werden kann.</P>

<H3>Das Kommando »ramdisk=« (veraltet)</H3>


<P>Dieser Parameter ist veraltet und sollte nicht verwendet
werden, es sei denn f&uuml;r die Kernelversion v1.3.47 oder
&auml;ltere.  Die Parameter, die heute f&uuml;r das RAM-Disk-Device
verwendet werden sollten, sind oben beschrieben.</P>
<P>Mit dem Parameter wird die Gr&ouml;&szlig;e RAM-Disk-Devices in KByte angeben.
W&uuml;rde man z.B. ein Root-Dateisystem auf einer 1,44&nbsp;MB Diskette
in ein RAM-Disk-Device laden wollen, w&uuml;rde man folgendes
Kommando verwenden:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
ramdisk=1440
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Dies ist einer der wenigen Kernel-Bootparameter, dessen
Standardwert im Kernel-Image gespeichert ist und der somit mit dem
Hilfsprogramm <CODE>rdev</CODE> ver&auml;ndert werden kann.</P>


<H3>Das Kommando »noinitrd«</H3>


<P>Kernel v2.x und neuere verf&uuml;gen &uuml;ber ein Feature, bei
dem das Root-Dateisystem anfangs eine RAM-Disk sein kann und 
der Kernel auf diesem RAM-Image <CODE>/linuxrc</CODE> ausf&uuml;hrt. Dieses
Feature wird typischerweise dazu verwendet, das Laden von
Modulen zu erm&ouml;glichen, die zum Mounten des eigentlichen
Root-Dateisystems ben&ouml;tigt werden. So k&ouml;nnen z.B. die Module des
SCSI-Treibers von dem Image der RAM-Disk geladen werden und
anschlie&szlig;end wird das eigentliche Root-Dateisystem auf einer
SCSI-Festplatte gemountet.</P>
<P>Der eigentliche <CODE>noinitrd</CODE>-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 
<CODE>/dev/initrd</CODE> zugegriffen werden. Dieser Zugriff ist nur
einmal m&ouml;glich, bevor der Speicher an das System zur&uuml;ckgegeben
wird. Umfassende Informationen &uuml;ber
die Benutzung der initial RAM-Disk erh&auml;lt man unter
<CODE>linux/Documentation/initrd.txt</CODE>. Zus&auml;tzlich sollten
die neuesten Versionen von LILO und loadlin weitere
n&uuml;tzliche Informationen enthalten.</P>


<H2><A NAME="ss3.3">3.3</A> <A HREF="DE-BootPrompt-HOWTO.html#toc3.3">Bootparameter f&uuml;r den Umgang mit dem Speicher        </A>
<!--Bootparameter!Speicher-->       <!--Speicher--></H2>


<P>Folgende Parameter &auml;ndern sich je nachdem, wie Linux den
physikalischen oder virtuellen Systemspeicher erkennt oder
mit ihm umgeht.</P>


<H3>Der Parameter »mem=« </H3>


<P>Dieser Parameter dient zwei verschiedenen Zwecken: Der
urspr&uuml;ngliche Zweck war, die Gr&ouml;&szlig;e des installierten Speichers
oder einen kleineren Wert, falls man die Gr&ouml;&szlig;e des f&uuml;r Linux
verf&uuml;gbaren Speichers verringern wollte, zu spezifizieren.         
Der andere, kaum verwendete Zweck ist die Bestimmung von 
<CODE>mem=nopentium</CODE>, was den Linux-Kernel auffordert, das 4 MB
Seitentabellen-Performance-Feature nicht zu verwenden.</P>
<P>W&auml;hrend des Bootvorganges ermittelt Linux durch einen 
BIOS-Aufruf die Gr&ouml;&szlig;e des installierten Speichers. Leider ist
die Gr&ouml;&szlig;e, die dieser Aufruf zur&uuml;ckliefern kann, auf 64&nbsp;MB
begrenzt. Erinnert uns das irgendwie an das 1024 Zylinder Limit
von IDE-Festplatten?  Sind mehr als 64&nbsp;MB RAM installiert, 
kann man
Linux mit diesem Bootparameter mitteilen, wieviel Speicherplatz
vorhanden ist. Hier ein Zitat von Linus &uuml;ber die Verwendung
des <CODE>mem=</CODE> Parameters:</P>
<P>
<BLOCKQUOTE>
Der Kernel wird alle <CODE>mem=xx</CODE> Parameter akzeptieren, die
man ihm &uuml;bergibt. Falls sich allerdings herausstellt, da&szlig; man
gelogen hat, wird der Kernel fr&uuml;her oder sp&auml;ter schrecklich
abst&uuml;rzen. Der Parameter legt die h&ouml;chste ansprechbare
RAM-Adresse fest, so da&szlig; z.B. <CODE>mem=0x1000000</CODE> bedeutet,
da&szlig; man 16&nbsp;MB Speicher besitzt. F&uuml;r einen Rechner 
mit 96&nbsp;MB w&auml;re der Bootparameter <CODE>mem=0x6000000</CODE>.
Teilt man Linux mit, da&szlig; es &uuml;ber mehr als den tats&auml;chlich vorhandenen
Speicherplatz verf&uuml;gt, dann wird dies schlimme Folgen haben;
vielleicht nicht sofort, aber irgendwann mit Sicherheit.
</BLOCKQUOTE>
</P>
<P>Man beachte, da&szlig; der &uuml;bergebene Wert keine Hexadezimalzahl sein 
mu&szlig; und da&szlig; die Endungen <CODE>k</CODE> bzw. <CODE>M</CODE> zur Bestimmung von
Kilobytes bzw. Megabytes verwendet werden k&ouml;nnen, wobei
Gro&szlig;- oder Kleinschreibung keine Rolle spielen.
<CODE>k</CODE> verursacht eine Verschiebung des Wertes
um 10&nbsp;Bit, w&auml;hrend <CODE>M</CODE> eine Verschiebung 
um 20&nbsp;Bit bewirkt. F&uuml;r einen Rechner mit z.B. 128&nbsp;MB
RAM w&uuml;rde man <CODE>mem=128m</CODE> verwenden.</P>


<H3>Der Parameter »swap=« </H3>


<P>Hier wird dem Anwender die Feineinstellung eines Teils der
virtuellen Speicherparameter erm&ouml;glicht, die mit Diskswapping
zu tun haben. Folgende acht Parameter werden akzeptiert:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
MAX_PAGE_AGE
PAGE_ADVANCE
PAGE_DECLINE
PAGE_INITIAL_AGE
AGE_CLUSTER_FRACT
AGE_CLUSTER_MIN
PAGEOUT_WEIGHT
BUFFEROUT_WEIGHT
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Interessierten Hackern sei die Lekt&uuml;re von
<CODE>linux/mm/swap.c</CODE> empfohlen. Auch sollten sie einen Blick
in <CODE>/proc/sys/vm</CODE> werfen. Das Kernel enth&auml;lt 
n&uuml;tzliche Dokumentationen zu diesem Thema im Verzeichnis 
<CODE>linux/Documentation/vm/</CODE>.</P>


<H3>Der Parameter »buff=« </H3>



<P>&Auml;hnlich dem <CODE>swap=</CODE>-Parameter wird dem Anwender
die Feineinstellung einiger der Parameter f&uuml;r die
Buffer-Speicherverwaltung erm&ouml;glicht. Folgende sechs Parameter
werden akzeptiert:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
MAX_BUFF_AGE
BUFF_ADVANCE
BUFF_DECLINE
BUFF_INITIAL_AGE
BUFFEROUT_WEIGHT
BUFFERMEM_GRACE
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Interessierten Hackern sei die Lekt&uuml;re von
<CODE>linux/mm/swap.c</CODE> empfohlen. Auch sollten sie einen Blick
in <CODE>/proc/sys/vm</CODE> werfen. Das Kernel enth&auml;lt 
n&uuml;tzliche Dokumentationen zu diesem Thema im Verzeichnis 
<CODE>linux/Documentation/vm/</CODE>.</P>


<H2><A NAME="ss3.4">3.4</A> <A HREF="DE-BootPrompt-HOWTO.html#toc3.4">Bootparameter f&uuml;r das NFS-Root-Dateisystem        </A>
<!--Bootparameter!NFS-Root-Dateisystem-->       <!--NFS!Root-Dateisystem--></H2>


<P>Linux unterst&uuml;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&auml;lt. Man beachte, da&szlig; der Parameter <CODE>root=/dev/nfs</CODE>
ben&ouml;tigt wird. Detaillierte Informationen &uuml;ber die
Verwendung eines NFS-Root-Dateisystems findet man in der Datei
<CODE>linux/Documentation/nfsroot.txt</CODE>. Es wird empfohlen,
diese Datei zu lesen, da folgende Informationen lediglich aus
einer Zusammenfassung dieser Datei bestehen.</P>

<H3>Der Parameter »nfsroot=« </H3>


<P>Dieser Parameter teilt dem Kernel mit, welcher Rechner, welches
Verzeichnis und welche NFS-Optionen f&uuml;r das Root-Dateisystem
verwendet werden sollen. Der Parameter ist folgenderma&szlig;en
aufgebaut:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
nfsroot=[&lt;server-ip>:]&lt;root-verz>[,&lt;nfs-optionen>]
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Wird der <CODE>nfsroot</CODE>-Parameter nicht auf der Kommandozeile angegeben,
dann wird standardm&auml;&szlig;ig <CODE>/tftpboot/%s</CODE> 
verwendet. Andere
m&ouml;gliche Optionen sind:</P>
<P>
<DL>
<DT><B>&lt;server-ip&gt;</B><DD>
<P>Bestimmt die IP-Adresse des NFS-Servers. Fehlt dieses
Feld, dann wird die von der <CODE>nfsaddrs</CODE>-Variablen
(siehe unten) bestimmte Default-Adresse
verwendet. Dieser Parameter wird z.B. dazu verwendet,
die Benutzung mehrerer Server f&uuml;r RARP und NFS
zu erm&ouml;glichen. Normalerweise kann dieses Feld
leer bleiben.</P>

<DT><B>&lt;root-verz&gt;</B><DD>
<P>Name des Verzeichnisses auf dem Server, das als root
gemountet werden mu&szlig;. Ist in der Zeichenkette ein
<CODE>%s</CODE>-Token enthalten, dann wird der Token durch
die ASCII-Darstellung der IP-Adresse des Clients ersetzt.</P>

<DT><B>&lt;nfs-optionen&gt;</B><DD>
<P>Standard-NFS-Optionen. Alle Optionen sind durch Kommas
getrennt. Fehlt das Optionen-Feld, werden folgende
Standardwerte verwendet:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
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
</PRE>
</CODE></BLOCKQUOTE>
</P>

</DL>
</P>


<H3>Der Parameter »nfsaddrs=« </H3>


<P>Dieser Bootparameter bestimmt die verschiedenen Adressen der
Netzwerkschnittstellen, die zur Kommunikation &uuml;ber's Netzwerk
ben&ouml;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&szlig;en
aus:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
nfsaddrs=&lt;meine-ip>:&lt;serv-ip>:&lt;gw-ip>:&lt;netmask>:&lt;name>:&lt;dev>:&lt;auto>
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>
<DL>
<DT><B>&lt;meine-ip&gt;</B><DD>
<P>IP-Adresse des Clients. Ist dieses Feld leer,
wird die Adresse entweder durch RARP oder durch BOOTP
bestimmt. Welches Protokoll verwendet wird, h&auml;ngt von dem
<CODE>&lt;auto&gt;</CODE> Parameter ab und davon, was w&auml;hrend der
Kernelkonfiguration aktiviert wurde. Ist dieser Parameter
nicht leer, dann wird weder RARP noch BOOTP benutzt.</P>

<DT><B>&lt;serv-ip&gt;</B><DD>
<P>IP-Adresse des NFS-Servers. Wird RARP zur Bestimmung
der Client-Adresse verwendet und ist dieser Parameter
<EM>nicht</EM> leer, dann werden nur Antworten vom festgelegten
Server akzeptiert. Zur Verwendung verschiedener RARP-
und NFS-Server bestimmt man hier den RARP-Server
oder l&auml;&szlig;t das Feld leer und legt den NFS-Server
mit dem <CODE>nfsroot</CODE>-Parameter fest (siehe oben). Bleibt dieser
Eintrag aus, dann wird die Adresse des Servers verwendet,
welcher auf die RARP- oder BOOTP-Anfrage geantwortet hat.</P>

<DT><B>&lt;gw-ip&gt;</B><DD>
<P>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&szlig; sich der Server im lokalen Netzwerk befindet,
au&szlig;er wenn durch BOOTP ein Wert empfangen wird.</P>

<DT><B>&lt;netmask&gt;</B><DD>
<P>Netmask f&uuml;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.</P>

<DT><B>&lt;name&gt;</B><DD>
<P>Name des Clients. Bleibt dieses Feld leer, dann wird
die Client-IP-Adresse in ASCII-Notation verwendet oder
der durch BOOTP empfangene Wert.</P>

<DT><B>&lt;dev&gt;</B><DD>
<P>Name des zu verwendenden Netzwerk-Devices. Ist
dieses Feld leer, dann werden alle Devices f&uuml;r
RARP-Anfragen verwendet und das erste Device f&uuml;r
BOOTP. F&uuml;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.</P>

<DT><B>&lt;auto&gt;</B><DD>
<P>Zu verwendende Methode f&uuml;r die automatische Konfiguration. Ist
dieses entweder <CODE>rarp</CODE> oder <CODE>bootp</CODE>, dann wird
das angegebene Protokoll verwendet. Ist der Wert
<CODE>both</CODE> oder leer, dann werden beide Protokolle in
dem Umfang verwendet, wie es ihnen w&auml;hrend der
Kernelkonfiguration erm&ouml;glicht wurde. Der Eintrag
<CODE>none</CODE> schlie&szlig;t die automatische Konfiguration aus. 
In diesem
Fall m&uuml;ssen alle notwendigen Werte in den vorherigen
Feldern bestimmt werden.</P>

</DL>
</P>
<P>Der Parameter <CODE>&lt;auto&gt;</CODE> kann alleine als Wert f&uuml;r den
Parameter <CODE>nfsaddrs</CODE> erscheinen, wobei die ganzen 
»:«-Zeichen davor entfallen.
In diesem Fall wird die automatische Konfiguration verwendet. Jedoch
ist der Wert <CODE>none</CODE> in diesem Fall nicht verf&uuml;gbar.</P>


<H2><A NAME="ss3.5">3.5</A> <A HREF="DE-BootPrompt-HOWTO.html#toc3.5">Weitere verschiedene Kernel-Bootparameter </A>
</H2>


<P>Diese verschiedenen Bootparameter erlauben dem Benutzer die
Feineinstellung bestimmter interner Parameter.</P>

<H3>Der Parameter »debug«        <!--Bootparameter!Debug-Level--></H3>


<P>Mittels der Funktion <CODE>printk()</CODE> schickt der Kernel wichtige
und weniger wichtige Nachrichten an den Administrator. Wird die
Nachricht als wichtig angesehen, dann wird die Funktion
<CODE>printk()</CODE> eine Kopie auf der aktuellen Konsole ausgeben und
sie an <CODE>klogd()</CODE> &uuml;bergeben, so da&szlig;
sie auf Festplatte gespeichert wird. Der Grund f&uuml;r die
Ausgabe wichtiger Nachrichten auf der Konsole und gleichzeitiger
Protokollierung auf der Festplatte liegt darin, da&szlig; unter
ungl&uuml;cklichen Umst&auml;nden wie z.B. einem Plattenausfall
die Nachricht nicht zur Festplatte gelangt und somit verloren geht.</P>
<P>Der Grenzwert daf&uuml;r, was als wichtig oder nicht wichtig
betrachtet wird, wird von der Variablen <CODE>console_loglevel</CODE>
festgelegt. Standardm&auml;&szlig;ig wird alles, was wichtiger ist
als <CODE>DEBUG</CODE> (Level 7), auf der Konsole ausgegeben. Die
verschiedenen Level sind in der Include-Datei <CODE>kernel.h</CODE>
definiert. Das Festlegen von <CODE>debug</CODE> als Bootparameter
setzt den Grenzwert der Konsole auf 10, so da&szlig; <EM>alle</EM> 
Mitteilungen des Kernels auf der Konsole erscheinen.</P>
<P>Der Grenzwert der Konsole kann normalerweise auch bei der
Ausf&uuml;hrung mittels einer Option des Programmes <CODE>klogd</CODE>
festgelegt werden. Informationen dar&uuml;ber kann man der
Manpage zu der auf dem System installierten Version entnehmen.</P>


<H3>Der Parameter »init=«        <!--Bootparameter!init-->       <!--init--></H3>


<P>Der Kernel wird beim Booten immer das <CODE>init</CODE>-Programm
starten, welches getty-Programme startet, »rc«-Skripts 
laufen l&auml;&szlig;t, u.&auml;. und somit den Rechner f&uuml;r die Benutzer
einrichtet.  Der Kernel schaut zuerst nach <CODE>/sbin/init</CODE>,
dann nach <CODE>/etc/init</CODE> und als letzte
M&ouml;glichkeit wird er versuchen, <CODE>/bin/sh</CODE> zu
verwenden (m&ouml;glicherweise auf <CODE>/etc/rc</CODE>). Wurde
z.B. das <CODE>init</CODE>-Programm verf&auml;lscht und somit das Booten
unm&ouml;glich gemacht, dann kann man einfach am Bootprompt
<CODE>init=/bin/sh</CODE> verwenden, was beim Booten direkt eine
Shell &ouml;ffnet und somit ein Ersetzen des verf&auml;lschten
Programms erm&ouml;glicht.</P>


<H3>Der Parameter »kbd-reset«        <!--Bootparameter!Tastaturkontroller-->       <!--Tastatur!Bootparameter--></H3>


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


<H3>Der Parameter »maxcpus=«        <!--Bootparameter!SMP-->       <!--SMP!Bootparameter--></H3>


<P>Die mit dem Parameter &uuml;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 <CODE>nosmp</CODE> Parameter.</P>


<H3>Der Parameter »mca-pentium«        <!--Bootparameter!IBM Model 95-->       <!--IBM!Model 95--></H3>


<P>Die IBM Model 95 Microchannel Rechner scheinen sich beim dem
Test aufzuh&auml;ngen, den Linux durchf&uuml;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&uuml;ckt werden.</P>


<H3>Der Parameter »md=«        <!--Bootparameter!RAID-->       <!--RAID!Bootparameter--></H3>


<P>Wenn sich das Root-Dateisystem sich auf einem <EM>Multiple
Device</EM> befindet, kann dieser Parameter verwendet werden, 
um dem Kernel das Layout des Multiple Devices mitzuteilen.
Hierf&uuml;r mu&szlig; nat&uuml;rlich die Bootunterst&uuml;tzung einkompiliert
sein. Das Format dieses Parameter sieht so aus:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
md=md_device_num,raid_level,chunk_size_factor,fault_level,dev0,dev1,...,devN
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Siehe auch die Datei <CODE>linux/Documentation/md.txt</CODE>.
Hierbei ist <CODE>md_device_num</CODE> die Nummer des md Devices;
0 w&uuml;rde f&uuml;r <CODE>md0</CODE>, 1 f&uuml;r <CODE>md1</CODE> usw. stehen.
F&uuml;r <CODE>raid_level</CODE> kann -1 (Linearer Modus) oder 0
(Striped Modus) verwendet werden. Andere Modi werden zur Zeit
nicht unterst&uuml;tzt. Die Option <CODE>chunk_size_factor</CODE>
kann nur f&uuml;r RAID-0 und RAID-1 benutzt werden. Mit ihr wird
die Chunk Size gesetzt; aus dem &uuml;bergebenen Wert wird die
Chunk Size berechnet, in dem die PAGE_SIZE um den angegebenen
Wert nach links geshiftet wird. Mit <CODE>fault_level</CODE>
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. <CODE>dev0,dev1,...,devN</CODE> ist eine
durch Kommata getrennte Liste von Devices, aus denen das md
Device gebildet wird, z.B. <CODE>/dev/hda1,/dev/hdc1,/dev/sda1</CODE>.</P>


<H3>Der Parameter »no387«        <!--Bootparameter!Koprozessor-->       <!--Koprozessor--></H3>


<P>Einige i387 Koprozessoren haben Fehler, die sich bei der
Verwendung im 32&nbsp;Bit Protected Mode zeigen. Einige der
fr&uuml;hen i387 Koprozessoren von ULSI 
verursachen z.B. massive Totalsperren
w&auml;hrend der Ausf&uuml;hrung von Flie&szlig;komma-Berechnungen, was
offensichtlich ein Bug in den FRSAV/FRRESTOR Anweisungen ist.
Die Verwendung des Bootparameters <CODE>no387</CODE> veranla&szlig;t Linux,
den mathematischen Koprozessor zu ignorieren, sogar wenn
einer vorhanden ist. Nat&uuml;rlich mu&szlig; der Kernel dann so
kompiliert werden, da&szlig; sich die Emulation eines Koprozessors
im Kernel befindet.
Dies ist m&ouml;glicherweise auch dann sinnvoll, wenn man
einen dieser <EM>wirklich</EM> alten i386er hat, die einen 80287 FPU
verwenden k&ouml;nnen, da Linux keine 80287 FPUs unterst&uuml;zt.</P>


<H3>Der Parameter »no-hlt«        <!--Bootparameter!no-hlt--></H3>


<P>Die Familie der i386 CPUs und deren Nachfolger verf&uuml;gen
&uuml;ber die Anweisung »hlt«, die der CPU mitteilt, da&szlig;
nichts geschehen wird, solange nicht ein externes Ger&auml;t
(Tastatur, Modem, Platte, etc.) die CPU auffordert, eine Aufgabe
auszuf&uuml;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&auml;t, gew&ouml;hnlich durch 
einen Interrupt, geweckt wird.
Einige der fr&uuml;hen i486DX-100 CPUs hatten
insofern ein Problem mit der Anweisung »hlt«,
da&szlig; sie nach deren
Ausf&uuml;hrung nicht mehr verl&auml;&szlig;lich in den Betriebsmodus
zur&uuml;ckkehren konnten. Durch die Benutzung der Anweisung
<CODE>no-hlt</CODE> wird Linux mitgeteilt, einfach eine Endlosschleife
zu durchlaufen, wenn es nichts anderes zu tun gibt und die
CPU <EM>nicht</EM> zu stoppen, wenn es keine aktiven Prozesse gibt.
Dieses erm&ouml;glicht Benutzern mit solchen »defekten« CPUs die
Verwendung von Linux, obwohl sie gut beraten w&auml;ren, sich
durch eine m&ouml;glicherweise noch vorhandene Garantie einen Ersatz
zu suchen.</P>

<H3>Der Parameter »no-scroll«        <!--Bootparameter!Braille-Terminals-->       <!--Braille-Terminals--></H3>


<P>Die Angabe dieses Parameters beim Booten setzt Bildlauf-Features
au&szlig;er Kraft, die die Verwendung von Braille-Terminals erschweren.</P>


<H3>Der Parameter »noapic«        <!--Bootparameter!SMP-->       <!--SMP!Bootparameter-->       <!--Bootparameter!APIC-->       <!--APIC--></H3>


<P>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 
<CODE>linux/Documentation/IO-APIC.txt</CODE> zu finden.</P>


<H3>Der Parameter »nosmp«</H3>


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


<H3>Der Parameter »panic=«        <!--Bootparameter!Kernel-Panic--></H3>


<P>F&uuml;r den unwahrscheinlichen Fall einer Kernel-Panik 
wird f&uuml;r gew&ouml;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&uuml;nschenswert sein, da&szlig; automatisch ein Reset
stattfindet, so da&szlig; der Rechner wieder zum normalen
Betrieb zur&uuml;ckkehrt. Die Angabe von <CODE>panic=30</CODE> beim
Booten h&auml;tte z.B. zur Folge, da&szlig; der Kernel 30
Sekunden nach der Kernel-Panik versuchen w&uuml;rde, sich
selbst zu booten. Der Standardwert ist Null und f&uuml;hrt zum
Standardverhalten, das darin besteht, endlos zu warten.</P>
<P>Man beachte, da&szlig; dieser Zeitlimit-Wert auch durch die
<CODE>/proc/sys/kernel/panic</CODE> sysctl-Schnittstelle gelesen
und gesetzt werden kann.</P>


<H3>Der Parameter »pirq=«        <!--Bootparameter!PCI-->       <!--PCI!Bootparameter--></H3>


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


<H3>Der Parameter »profile=«        <!--Kernel!Profiling--> </H3>


<P>Kernel-Entwickler k&ouml;nnen eine Option aktivieren,
die es ihnen erlaubt, herauszufinden, wie und wo der Kernel
seine CPU-Zyklen einsetzt, um das &auml;u&szlig;erste an
Effizienz und Leistung herauszuholen. Mit dieser Option
kann man die Profil-Verschiebungsz&auml;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
<CODE>readprofile.c</CODE>, das die Ausgabe von <CODE>/proc/profile</CODE>
verwenden kann.</P>


<H3>Der Parameter »reboot=«        <!--Bootparameter!Reboot-->       <!--Reboot--></H3>


<P>Diese Option kontrolliert die Art des Reboots, die Linux
beim Reset des Rechners ausf&uuml;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&auml;ndert, da dieser bei billiger/kaputter Hardware, die es
nicht schafft, neu zu booten, wenn ein Warmstart erforderlich
w&auml;re, normalerweise funktioniert. Zum Wiederherstellen des
alten Zustands, n&auml;mlich der Verwendung eines Warmstarts,
verwendet man <CODE>reboot=w</CODE>.
Tats&auml;chlich funktioniert auch jedes beliebige Wort, das
mit <CODE>w</CODE> beginnt.</P>
<P>Warum sollte man sich darum k&uuml;mmern? Einige
Platten-Kontroller mit eingebautem Cache-Speicher k&ouml;nnen
einen Warmstart erkennen und Daten aus dem Cache auf die
Festplatte schreiben. Nach einem Kaltstart w&uuml;rde der Kontroller
eventuell zur&uuml;ckgesetzt werden und die noch auf die Festplatte
zu schreibenden Daten im Cache w&uuml;rden verloren gehen. Andere
Anwender haben Systeme, die recht lange f&uuml;r den Speicher-Check
brauchen oder die ein SCSI BIOS enthalten,
das nach einem Kaltstart l&auml;nger f&uuml;r die Initialisierung
braucht.</P>


<H3>Der Parameter »reserve=«        <!--Bootparameter!reservierte I/O-Bereiche-->       <!--I/O Ports--></H3>


<P>Dieser wird dazu benutzt, Teile der I/O Ports vor der
&Uuml;berpr&uuml;fung zu <EM>sch&uuml;tzen</EM>. Das Kommando ist
folgenderma&szlig;en aufgebaut:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
reserve=iobase,extent[,iobase,extent]...
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Bei einigen Rechnern mag es notwendig sein, die automatische
Hardwareerkennung der Ger&auml;tetreiber
davon abzuhalten, in einer bestimmten Region nach Ger&auml;ten
zu suchen. Der Grund
daf&uuml;r kann z.B. schlecht entwickelte Hardware sein, die
den Bootvorgang <EM>stoppt</EM> (wie z.B. einige Ethernetkarten),
irrt&uuml;mlicherweise erkannte Hardware, Hardware, deren Zustand
durch eine fr&uuml;here Erkennung ge&auml;ndert wurde oder
einfach Hardware, die vom Kernel nicht initialisiert werden soll.</P>
<P>Der Bootparameter <CODE>reserve</CODE> geht dieses Problem dadurch an,
da&szlig; er einen I/O Port-Bereich angibt, der nicht gepr&uuml;ft
werden soll. Diese Region wird in der Registrationstabelle
des Kernels f&uuml;r Ports so behandelt, als ob unter der Adresse
bereits ein Ger&auml;t
mit dem Namen <CODE>reserved</CODE> gefunden wurde. Man
beachte, da&szlig; dieser Mechanismus f&uuml;r die meisten Rechner
nicht notwendig sein d&uuml;rfte. Er ist nur bei Problemen und
in besonderen F&auml;llen erforderlich.</P>
<P>Die I/O Ports in dem angegebenen Bereich sind gegen eine 
Ger&auml;teerkennung gesch&uuml;tzt, bei der zuerst die Funktion
<CODE>check_region()</CODE> ausgef&uuml;hrt wird, statt blind einen 
I/O Bereich zu pr&uuml;fen. Dieses wird dann
eingesetzt, wenn Treiber bei der Erkennung z.B. durch eine
NE2000-Karte h&auml;ngenbleiben
oder irrt&uuml;mlich andere Ger&auml;te als eigene erkannt
werden. Ein korrekter Ger&auml;tetreiber sollte keine reservierten
Bereiche pr&uuml;fen, wenn nicht ein anderer Bootparameter dieses
ausdr&uuml;cklich verlangt. Das bedeutet, da&szlig; <CODE>reserve</CODE>
meistens zusammmen mit einem anderen Bootparameter verwendet
wird. Wenn man also einen reservierten Bereich festlegt,
der ein bestimmtes Ger&auml;t sch&uuml;tzen soll, dann mu&szlig;
man im allgemeinen explizit eine Erkennung dieses
Ger&auml;tes erzwingen. Die meisten Treiber ignorieren die 
Registrierungstabelle f&uuml;r Ports, wenn ihnen eine bestimmte Adresse
genannt wird.</P>
<P>Die Bootzeile</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
reserve=0x300,32  blah=0x300
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>h&auml;lt z.B. alle Ger&auml;tetreiber, mit Ausnahme des Treibers
f&uuml;r »blah« davon ab, 0x300-0x31f zu pr&uuml;fen.</P>
<P>Wie &uuml;blich bei Boot-Argumenten gibt es ein Limit von
elf Parametern, d.h. man kann nur f&uuml;nf reservierte Bereiche pro
<CODE>reserve</CODE> Schl&uuml;sselwort bestimmen. Bei ungew&ouml;hnlich
komplizierten Anfragen sind jedoch mehrere <CODE>reserve</CODE> Argumente
m&ouml;glich.</P>


<H3>Der Parameter »vga=«        <!--Bootparameter!Bildschirmmodus-->       <!--vidmode--></H3>


<P>Man beachte, da&szlig; 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&auml;ufig verwendet, da&szlig;
sie an dieser Stelle eine Erw&auml;hnung verdient. Sie kann auch
durch die Verwendung von <CODE>rdev -v</CODE> festgelegt werden und ebenso
durch <CODE>vidmode</CODE> auf der Datei <CODE>vmlinuz</CODE>. Dieses erm&ouml;glicht
dem Setup-Code die Benutzung des Video-BIOS zur &Auml;nderung
des Standard-Anzeige-Modus vor dem tats&auml;chlichen Booten des
Linux-Kernels. Typische Modi sind 80x50, 132x44 usw. Man verwendet
diese Option am besten, indem man mit <CODE>vga=ask</CODE> beginnt, worauf
man eine Liste verschiedener Modi erh&auml;lt, die man mit dem
Grafik-Adapter benutzen kann, bevor man den Kernel bootet. Hat
man einmal eine Nummer aus obiger Liste gew&auml;hlt, kann man
sie sp&auml;ter anstelle von <CODE>ask</CODE> setzen. Weitere Informationen
findet man in der Datei <CODE>linux/Documentation/svga.txt</CODE>,
die mit allen neueren Kernel-Versionen ausgeliefert wird.</P>
<P>Man beachte, da&szlig; neuere Kernelversionen (v2.1 und h&ouml;her)
den Setup-Code, der den Grafik-Modus &auml;ndert, als Option
enthalten. Diese ist aufgelistet als <EM>Video mode selection
support</EM>, d.h. man mu&szlig; diese Option aktivieren, um dieses
Feature verwenden zu k&ouml;nnen.</P>


<HR>
<A HREF="DE-BootPrompt-HOWTO-4.html"><IMG SRC="next.png" ALT="Weiter"></A>
<A HREF="DE-BootPrompt-HOWTO-2.html"><IMG SRC="prev.png" ALT="Zurück"></A>
<A HREF="DE-BootPrompt-HOWTO.html#toc3"><IMG SRC="toc.png" ALT="Inhalt"></A>
</BODY>
</HTML>
doc-linux-de 2003.10-5 / usr / share / doc / HOWTO / de-html / DE-BootPrompt-HOWTO-3.html
