Voici des param�tres qui ne sont pas li�s � des p�riph�riques particuliers. Ils sont simplement li�s � un certain nombre de param�tres internes au noyau, comme la gestion m�moire, celle du disque RAM, celle du syst�me de fichiers racine, etc.
Les options suivantes d�terminent toutes la fa�on dont le noyau s�lectionne et manipule le syst�me de fichiers racine.
Ce param�tre indique au noyau quel p�riph�rique doit �tre utilis� comme "root filesystem" (racine du syst�me de fichiers) pendant le d�marrage. Par d�faut, c'est le p�riph�rique racine du syst�me sur lequel le noyau a �t� construit. Par exemple, si le noyau en question a �t� construit sur un syst�me qui utilise `/dev/hda1' comme partition racine, alors le p�riph�rique racine par d�faut sera `/dev/hda1'. Pour outrepasser cette valeur et s�lectionner le second lecteur de disquette comme p�riph�rique racine, il faut utiliser `root=/dev/fd1'. Les p�riph�riques racine valides sont un des p�riph�riques suivants :
(1) /dev/hdaN � /dev/hddN, o� N est la partition pour les disques `a � d' compatibles ST-506.
(2) /dev/sdaN � /dev/sdeN, o� N est la partition pour les disques `a � e' compatibles SCSI.
(3) /dev/xdaN � /dev/xdbN, o� N est la partition pour les disques `a � b' compatibles XT.
(4) /dev/fdN, o� N est le num�ro du lecteur de disquette. La valeur N=0 correspond au disque DOS `A:', et N=1 correspond � `B:'.
(5) /dev/nfs, qui n'est pas vraiement un p�riph�rique, mais plut�t un indicateur pour dire au noyau de rechercher le syst�me de fichiers racine via le r�seau.
La plus maladroite et la moins compatible des sp�cifications
des p�riph�riques disque ci-dessus, qui est le format
nombre majeur/nombre mineur est aussi accept�e (par exemple
/dev/sda3 a pour major 8, et pour minor 3,
vous pouvez donc utiliser root=0x803 comme alternative).
C'est un des param�tres de d�marrage qui a sa valeur par d�faut
stock�e dans l'image du noyau, et qui peut �tre aussi modifi�e
par l'utilitaire rdev.
Quand le noyau d�marre, il a besoin du syst�me de fichiers racine, pour �num�rer les �l�ments de base de celui-ci. C'est le syst�me de fichiers racine qui est mont� au d�marrage. Cependant, si le syst�me de fichiers racine est mont� avec un acc�s en �criture, vous ne pourrez pas contr�ler de fa�on fiable l'int�grit� du syst�me de fichiers, car il peut y avoir des fichiers en cours d'�criture. L'option `ro' indique au noyau de monter le syst�me de fichiers racine en lecture seule, de fa�on que les programmes de contr�le de coh�rence du syst�me de fichiers (fsck) puissent �tre certain qu'il n'y a pas d'�critures en cours pendant la dur�e du test. Aucun programme ou processus ne peut �crire dans les fichiers situ�s sur le syst�me de fichiers en question jusqu'� ce qu'il ait �t� `remont�' avec un acc�s en lecture/�criture.
C'est un des param�tres de d�marrage qui a sa valeur par d�faut
stock�e dans l'image du noyau, et qui peut �tre aussi modifi�e
par l'utilitaire rdev.
Ceci est le contraire le plus parfait de ce qui pr�c�de, c'est � dire que ce param�tre indique au noyau de monter le syst�me de fichier racine en lecture/�criture. N'ex�cutez surtout pas un programme de type `fsck' sur un syst�me de fichiers mont� en lecture/�criture.
La m�me valeur stock�e dans le fichier image mentionn� ci-dessus
est aussi accessible via rdev
Les options suivantes correspondent � la fa�on dont le noyau g�re le p�riph�rique disque virtuel, qui est souvent utilis� comme zone d'amor�age durant la phase d'installation, ou pour des machines qui utilisent des pilotes modulaires qui doivent �tre install�s pour acc�der au syst�me de fichiers racine.
Pour permettre � une image du noyau de loger sur une disquette, conjointement avec une image compress�e du disque virtuel, la commande `ramdisk_start=<offset>' est ajout�e. Le noyau ne peut pas �tre inclus dans l'image compress�e du syst�me de fichiers du disque virtuel, car il doit �tre stock� � partir du bloc z�ro de fa�on � ce que le BIOS puisse charger le secteur d'amorce (bootsector) et que le noyau puisse alors s'auto-lancer.
Note : Si vous utilisez une image du disque virtuel non compress�e, alors le noyau peut faire partie de l'image du syst�me de fichiers qui est charg� sur le disque virtuel, et la disquette peut-�tre lanc�e avec LILO, ou les deux peuvent �tre distincts comme c'est fait pour les images compress�es.
Si vous utilisez deux disques boot/root (noyau sur le disque 1, image u disque virtuel sur le disque 2) alors, le disque virtuel d�marrera au bloc z�ro, et un d�placement (offset) de z�ro sera utilis�. Etant donn� que c'est la valeur par d�faut, vous n'aurez pas besoin actuellement d'utiliser cette commande.
Ce param�tre indique au noyau si il essaye de charger une image du disque virtuel ou pas. En sp�cifiant `load_ramdisk=1' on indiquera au noyau de charger une disquette dans le disque virtuel. La valeur par d�faut est z�ro, ce qui signifie que le noyau n'essaiera pas de charger un disque virtuel.
Voyez le fichier linux/Documentation/ramdisk.txt
pour une description compl�te des nouveaux param�tres de d�marrage,
et comment les utiliser. La fa�on dont ces param�tres peuvent �tre
positionn�s et stock�s dans l'image du noyau via 'rdev' est aussi
d�crite.
Ce param�tre indique au noyau si il doit ou non vous demander d'ins�rer la disquette contenant l'image du disque virtuel. Dans une configuration � une seule disquette, l'image du disque virtuel est sur la m�me disquette que le noyau qui vient juste de se charger/d�marrer, et donc un message d'invite est inutile. Dans ce cas, on peut utiliser `prompt_ramdisk=0'. Dans une configuration avec deux disquettes, vous devez avoir la possibilit� de changer de disquette, et alors `prompt_ramdisk=1' peut-�tre utilis�. Etant donn� que c'est la valeur par d�faut, on n'a pas vraiment besoin de l'indiquer.
Note Historique : Des gens sournois on l'habitude d'utiliser l'option de LILO `vga=ask' pour stopper temporairement le d�marrage et avoir ainsi une chance de pouvoir passer de la disquette boot � la disquette root.
Voyez le fichier linux/Documentation/ramdisk.txt
pour une description compl�te des nouveaux param�tres de d�marrage,
et comment les utiliser. La fa�on dont ces param�tres peuvent �tre
positionn�s et stock�s dans l'image du noyau via 'rdev' est aussi
d�crite.
Bien que ce soit vrai que le disque virtuel augmente sa taille de fa�on dynamique, il existe une limite maximum afin qu'il n'utilise pas toute la m�moire vive (RAM) disponible et vous laisse dans une triste situation. Par d�faut, la taille est de 4096 (c.a.d. 4MB) qui doit �tre suffisant pour la plupart des besoins. Vous pouvez �craser cette taille par d�faut pour une plus grande ou une plus petite avec ce param�tre de d�marrage.
Voyez le fichier linux/Documentation/ramdisk.txt
pour une description compl�te des nouveaux param�tres de d�marrage,
et comment les utiliser. La fa�on dont ces param�tres peuvent �tre
positionn�s et stock�s dans l'image du noyau via 'rdev' est aussi
d�crite.
NOTE : Ce param�tre est obsol�te, et ne doit pas �tre utilis� exept� sur les noyaux v1.3.47 et ceux plus anciens. Les commandes que l'on peut utiliser pour les disques virtuels sont document�es ci-dessous.
Ceci indique la taille en Kilo-Octets du disque virtuel (RAM disk) que vous pouvez �ventuellement utiliser. Par exemple, si vous souhaitez avoir un syst�me de fichiers racine sur une disquette 1.44 Mo charg� sur le disque virtuel, vous devrez utiliser :
ramdisk=1440
C'est un des param�tres de d�marrage qui a sa valeur par d�faut
stock�e dans l'image du noyau, et qui peut �tre aussi modifi�
par l'utilitaire rdev.
La version v2.x du noyau et les versions plus r�centes
poss�dent la caract�ristique de pouvoir avoir le syst�me de fichiers
racine initialement sur un disque virtuel, et le noyau ex�cute
linuxrc sur cette image m�moire. Cette caract�ristique est
g�n�ralement utilis�e pour permettre de charger des modules
n�cessaires au montage du syst�me de fichiers racine r��l (par
exemple : charger les modules du pilote SCSI stock�s dans l'image
du disque virtuel, et alors monter le syst�me de fichiers racine
r��l sur un disque SCSI).
Le param�tre `noinitrd' actuel d�termine ce qui arrive aux donn�es
initrd apr�s que le noyau ait d�marr�. Lorsqu'il est indiqu�,
au lieu de se convertir en disque virtuel, il est accessible via
/dev/initrd, et peut-�tre lu juste avant que la RAM soit
lib�r�e pour le syst�me. Pour de plus amples d�tails sur l'utilisation
du disque RAM initial, consultez linux/Documentation/initrd.txt.
De plus, les versions les plus r�centes LILO et LOADLIN
doivent contenir des informations compl�mentaires tr�s int�ressantes.
Les param�tres suivants modifient la fa�on dont linux d�tecte ou g�re la m�moire physique et virtuelle de votre syst�me.
Ce param�tre vise deux objectifs : L'objectif principal est
d'indiquer la quantit� de m�moire install�e (ou une valeur plus
petite si vous d�sirez limiter le quantit� de m�moire disponible
pour linux). Le second ojectif (tr�s utilis�) est de sp�cifier
mem=nopentium qui indique au noyau de linux de ne pas utiliser
les caract�ristiques de la table de performance de pages de 4 MO
(4MB page table performance).
L'appel initial au BIOS d�fini dans la sp�cification des PC, et qui
renvoie la taille de la m�moire install�e, a �t� con�u pour �tre capable
de donner des tailles m�moire jusqu'� 64 Mo (H� oui, encore une manque de
pr�voyance, tout comme les disques de 1024 cylindres...Pfffff). Linux
utilise cet appel au BIOS au d�marrage pour d�terminer quelle est la
quantit� de m�moire install�e. Si vous avez plus de 64 Mo de m�moire vive
install�e, vous pouvez utiliser ce param�tre de d�marrage pour indiquer �
Linux quelle est la quantit� de m�moire dont vous disposez. Voici une
citation de Linus sur l'utilisation du param�tre `mem='.
"Le noyau acceptera tous les param�tres `mem=xx' que vous lui donnerez, et s'il s'aper�oit que vous lui avez menti, il plantera lamentablement t�t ou tard. Le param�tre indique la plus haute zone adressable, donc `mem=0x1000000' signifie que vous avez 16 Mo de m�moire, par exemple. Pour une machine ayant 96 Mo de m�moire, le param�tre serait `mem=0x6000000'."
NOTE NOTE NOTE: certaines machines peuvent utiliser le sommet de la m�moire pour le cache du BIOS ou quelque chose d'autre, c'est pourquoi il se peut que vous n'ayez pas vraiment la totalit� de ces 96 Mo comme m�moire adressable. Le contraire est aussi exact : certaines puces feront un plan de la m�moire physique couverte par la zone BIOS dans la zone situ�e juste au dessus du sommet de la m�moire, donc le sommet de la m�moire peut �tre actuellement 96Mo + 384ko par exemple. Si vous indiquez � Linux qu'il a plus de m�moire qu'il doit en avoir actuellement, des choses plut�t d�sagr�ables vous arriveront : peut-�tre pas tout de suite, mais un jour s�rement.''
Notez que cet argument n'a pas besoin d'�tre en hexad�cimal, et que
les suffixes `k' et `M' (en majuscule ou minuscule, peu importe) peuvent
�tre utilis�s pour indiquer respectivement kilo-octets et M�ga-octets
(le `k' multiplie par 10 votre valeur et le `M' la multiplie par 20).
La mise en garde expos�e ci-dessus reste vraie en cela qu'une machine
avec 96 Mo peut fonctionner avec mem=97920k mais �chouer avec soit
mem=98304k ou mem=96M.
Il permet � l'utilisateur de r�gler certains des param�tres de la m�moire virtuelle qui sont li�s aux fichiers d'�change (swap) sur disque. Il accepte les huit param�tres suivants :
MAX_PAGE_AGE PAGE_ADVANCE PAGE_DECLINE PAGE_INITIAL_AGE AGE_CLUSTER_FRACT AGE_CLUSTER_MIN PAGEOUT_WEIGHT BUFFEROUT_WEIGHT
Les utilisateurs avertis pourront jeter un coup d'oeuil au fichier
linux/mm/swap.c et sur les donn�es du r�pertoire
/proc/sys/vm.
Comme le param�tre `swap=', il permet � l'utilisateur de r�gler certains des param�tres relatifs � la gestion des tampons m�moire. Il accepte les six param�tres suivant :
MAX_BUFF_AGE BUFF_ADVANCE BUFF_DECLINE BUFF_INITIAL_AGE BUFFEROUT_WEIGHT BUFFERMEM_GRACE
Les utilisateurs avertis pourront jeter un coup d'oeuil au fichier
linux/mm/swap.c et sur les donn�es du r�pertoire
/proc/sys/vm.
Linux supporte des syst�mes comme les stations de travail sans
disques � condition que leur syst�me de fichiers racine soit de
type NFS (Network FileSystem ou Syst�me de Fichiers R�seau).
Ces param�tres sont utilis�s pour indiquer � la station exempte
de disque sur quelle machine elle doit aller chercher son syst�me.
Notez aussi que le param�tre root=/dev/nfs est requis.
Des informations d�taill�es sur l'utilisation d'un syst�me de
fichiers racine NFS sont contenues dans
linux/Documentation/nfsroot.txt. Je vous conseille de lire
ce fichier, car ce qui suit est juste un r�sum� rapide extrait
directement de ce document.
Ce param�tre indique au noyau quelle machine, quel r�pertoire et quelles options NFS sont utilis�es pour son syst�me de fichiers racine. La structure du param�tre est la suivante :
nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
Si le param�tre nfsroot n'est pas donn� sur la ligne de commande, on utilisera par d�faut `/tftpboot/%'. Les autres options sont les suivantes :
<server-ip> - Indique l'adresse IP du serveur NFS. Si ce champ n'est pas indiqu�, l'adresse par d�faut d�termin�e par la variable nfsaddrs (voir ci-dessous) est utilis�e. Une des utilisations de ce param�tre est par exemple l'utilisation de serveurs diff�rents pour RARP et NFS. G�n�ralement vous pouvez le laisser � blanc.
<root-dir> - Nom du r�pertoire sur le serveur � monter en tant que racine. Si il y a un caract�re `%' dans la cha�ne, le caract�re sera remplac� par la repr�sentation ASCII de l'adresse IP du client.
<nfs-options> - Options NFS standard. Toutes les options sont s�par�es par des virgules. Si le champ option n'est pas indiqu�, les valeurs suivantes sont utilis�es par d�faut :
port = tel que donn� par le d�mon portmap du serveur rsize = 1024 wsize = 1024 timeo = 7 retrans = 3 acregmin = 3 acregmax = 60 acdirmin = 30 acdirmax = 60 flags = hard, nointr, noposix, cto, ac
Ce param�tre de d�marrage positionne les diff�rentes adresses qui sont n�cessaires � la communication sur le r�seau. Si ce param�tre n'est pas indiqu�, le noyau essaie d'utiliser RARP et/ou BOOTP pour calculer ces param�tres. La structure est la suivante :
nfsaddrs=<my-ip>:<serv-ip>:<gw-ip>:<netmask>:<name>:<dev>:<auto>
<my-ip> - Adresse IP du client. Si elle est vide, cette adresse sera d�termin�e par RARP ou BOOTP. Le protocole utilis� d�pend de ce qui a �t� activ� pendant la configuration du noyau et sur le param�tre <auto>. Si ce param�tre n'est pas vide, ni RARP, ni BOOTP ne seront utilis�s.
<serv-ip> - Adresse IP du serveur NFS. Si RARP est utilis� pour d�terminer l'adresse du client et que ce param�tre N'EST PAS vide, seules les r�ponses du serveur sp�cifi� seront accept�es. Pour utiliser diff�rents serveurs NFS et RARP, indiquez votre serveur RARP ici (ou laissez le � blanc), et indiquez votre serveur NFS dans le param�tre nfsroot (voir ci-dessus). Si cette entr�e est � blanc, l'adresse utilis�e est celle du serveur qui r�pond � la requ�te RARP ou BOOTP.
<gw-ip> - Adresse IP d'une passerelle (gateway) si le serveur est sur un sous-r�seau diff�rent. Si cette entr�e est vide, aucune passerelle n'est utilis�e et le serveur est suppos� �tre sur le r�seau local, � moins qu'une valeur n'ait �t� re�ue par BOOTP.
<netmask> - Masque de r�seau pour les interfaces de r�seau local. Si ce param�tre est vide, le masque de r�seau est d�duit de l'adresse IP du client, � moins qu'une valeur n'ait �t� re�ue par BOOTP.
<name> - Nom du client. Si il est vide, l'adresse IP du client est utilis�e en notation ASCII, sauf si une valeur a �t� re�ue par BOOTP.
<dev> - Nom du p�riph�rique r�seau � utiliser. Si le param�tre est vide, tous les p�riph�riques sont utilis�s pour les requ�tes RARP, et le premier trouv� pour BOOTP. Pour NFS, le p�riph�rique utilis� est celui pour lequel on a re�u une r�ponse � RARP ou BOOTP. Si vous n'avez qu'un p�riph�rique, vous pouvez sans aucun risque le laisser � blanc.
<auto> - M�thode � utiliser pour l'autoconfiguration. Si `rarp' ou `bootp' sont indiqu�s, le protocole sp�cifi� est utilis�. Si la valeur est `both' ou vide, les deux protocoles seront utilis�s � condition qu'ils aient �t� activ�s durant la configuration du noyau. Utiliser 'none' signifie pas d'autoconfiguration; Dans ce cas, vous devez indiquer toutes les valeurs n�cessaires dans les champs pr�c�dents.
Le param�tre <auto> peut appara�tre seul comme valeur du param�tre nfsaddrs (sans tous les caract�res `:' avant). Dans ce cas, l'autoconfiguration est utilis�e. Toutefois, la valeur `none' n'est pas disponible dans ce cas.
Ces diff�rents param�tres de d�marrage permettent � l'utilisateur de g�rer certains param�tres internes du noyau.
Le noyau envoie des messages importants (et moins importants)
� l'op�rateur via la fonction printk(). Si le message est
consid�r� comme important, la fonction printk() envoie une
copie sur la console active, mais le transmet aussi � la fonction
klogd() qui l'archive sur le disque. La raison pour laquelle
le message est envoy� � la console et archiv� sur disque, est
simple : dans certaines circonstances malheureuses (par exemple
une d�faillance du disque) le message ne serait pas �crit sur
le disque et serait perdu.
Le seuil � partir duquel un message est consid�r� comme important,
ou ne l'est pas, est d�termin� par la variable console_loglevel.
Par d�faut, l'affichage sur la console est d�clench� pour tout ce
qui depasse le DEBUG (niveau 7). Ces niveaux sont d�finis dans
le fichier include kernel.h. Le fait de sp�cifier comme
param�tre de d�marrage debug forcera le niveau de suivi
� 10, de fa�on que tous les messages du noyau apparaissent
sur la console.
Le niveau de suivi de la console peut aussi �tre positionn�
pendant l'utilisation via une option du programme klogd().
Consultez la page du manuel correspondant � la version install�e
sur votre syst�me, pour voir comment utiliser ce programme.
Par d�faut, le noyau lance le programme `init' au d�marrage,
qui prend alors soin de configurer l'ordinateur pour les utilisateurs
en lan�ant les programmes getty, les scripts `rc' et tout le reste.
Le noyau recherche d'abord /sbin/init, ensuite
/etc/init (secondaire), et en dernier recours, il essaiera
d'utiliser /bin/sh (�ventuellement /etc/rc).
Si par exemple, votre programme init est corrompu et donc stopp� vous
serez en mesure de d�marrer, en utilisant le param�tre de d�marrage
init=/bin/sh qui vous positionnera directement dans un shell
au d�marrage, vous permettant de remplacer les programmes corrompus.
Certains coprocesseurs i387 ont des bogues qui apparaissent lorsqu'ils sont utilis�s en mode prot�g� 32 bits. Par exemple, certaines puces ULSI-387 r�centes, provoquent un blocage irr�versible lorsqu'elles font des calculs un virgule flottante, apparemment d� � un bug dans les instructions FRSAV/FRRESTOR. L'utilisation du param�tre de d�marrage `no387' fait ignorer � Linux le coprocesseur math�matique s'il y en a un. Bien s�r, votre noyau doit alors obligatoirement �tre compil� avec l'option d'�mulation du coprocesseur ! Cela peut aussi �tre int�ressant si vous poss�dez une de ces tr�s vielles machines 386 qui peuvent utiliser une FPU 80287, alors que Linux ne peut pas.
La famille des processeurs i386 (et les suivantes) ont une instruction `htl' qui indique au processeur que rien ne va se produire jusqu'� ce qu'un p�riph�rique externe (clavier, modem, disque, etc.) demande au processeur d'accomplir une t�che. Ceci permet au processeur de se mettre dans un mode `low-power' (�conomie d'�nergie) dans lequel il reste � l'�tat de zombi jusqu'� ce qu'un p�riph�rique externe le r�veille (g�n�ralement via une interruption). Certaines puces i486DX-100 r�centes ont un probl�me avec l'instruction `htl' qui est le suivant : elles ne peuvent pas retourner en mode op�rationnel de fa�on fiable apr�s que cette instruction ait �t� utilis�e. L'utilisation de l'instruction `no-hlt' indique � Linux de simplement ex�cuter une boucle infinie quand il n'y a rien d'autre � faire, et de ne pas arr�ter votre processeur quand il n'y a aucune activit�e. Ceci permet aux personnes qui utilisent ces puces d�fectueuses d'utiliser Linux, bien qu'ils doivent �tre inform�s du fait que le remplacement dans le cadre de la garantie est possible.
L'utilisation de ce param�tre au d�marrage d�sactive le d�filement d'�cran (scrolling) qui rend difficile l'emploi de terminaux Braille.
Dans le cas tr�s d�sagr�able d'une alerte du noyau (kernel panic),
c'est � dire une erreur interne qui a �t� d�tect�e par le noyau, et
pour laquelle il a d�cid� qu'elle �tait suffisamment grave
pour r�ler bruyamment et tout arr�ter ; le comportement par d�faut
est d'en rester l� jusqu'� ce que quelqu'un se penche sur le probl�me,
visualise le message sur l'�cran et red�marre la machine.
Cependant, si une machine fonctionne sans surveillance dans un local
isol� il peut-�tre souhaitable qu'il red�marre de lui-m�me afin que la
machine revienne en ligne. Par exemple, l'utilisation de `panic=30'
au d�marrage forcera le noyau � essayer de red�marrer 30 secondes
apr�s que l'alerte du noyau se soit produite. Une valeur � z�ro donne
le comportement par d�faut, qui est d'attendre �ternellement.
Notez que cette valeur d'attente peut aussi �tre lu et positionn�e
via l'interface sysctl /proc/sys/kernel/panic.
Les d�veloppeurs du noyau peuvent activer une option qui leur permet
de suivre comment et ou le noyau consomme ses cycles CPU, dans le but
d'augmenter ses capacit�s et ses performances. Cette option vous permet
de positionner cet indicateur de suivi au moment du d�marrage.
G�n�ralement il est positionn� � deux. Vous pouvez aussi compiler
votre noyau avec l'option de suivi par d�faut. Dans tous les cas,
il vous faudra un outil comme readprofile.c afin d'utiliser
les donn�es fournies par /proc/profile.
Cette option contr�le le type de red�marrage que Linux fera lorsque
vous ferez une remise � z�ro de votre ordinateur (g�n�ralement
via /sbin/init en faisant un Ctrl-Alt-Suppr).
Le comportement par d�faut des derniers noyaux v2.0 est de faire
un red�marrage `� froid' (c.a.d. remise � z�ro compl�te, le BIOS
comtr�le la m�moire, etc.) au lieu d'un red�marrage `� chaud'
(c.a.d pas de remise � z�ro totale, pas de contr�le de la m�moire).
Il a �t� modifi� pour prendre la valeur froid par d�faut depuis
que cela semble fonctionner sur des mat�riels bon march� ou
endommag�s qui ne voulaient pas red�marrer lorsqu'un red�marrage �
chaud �tait requis. Pour retrouver l'ancien comportement (c.a.d
red�marrage � chaud) utilisez reboot=w en fait n'importe quel
mot comman�ant par w fonctionnera.
Pourquoi cela pourrait-il vous ennuyer ? Certains disques incluant de la m�moire cache peuvent d�tecter un red�marrage � chaud, et �crire les donn�es du cache sur le disque. Lors d'un red�marrage � froid, la carte peut-�tre remise � z�ro, et les donn�es stock�es dans la m�moire cache seront perdues. D'autres ont signal� que des syst�mes prenaient beaucoup de temps pour v�rifier la m�moire, et/ou des BIOS SCSI qui �taient tr�s long � s'initialiser lors d'un d�marrage � froid, et c'est par cons�quent une excellente raison pour utiliser le red�marrage � chaud.
Ceci est utilis� pour prot�ger les zones des ports d'I/O des programmes de test. La syntaxe de la commande est la suivante :
reserve=iobase,extent[,iobase,extent]...
Sur certaines machines, il peut-�tre n�cessaire d'emp�cher les pilotes de p�riph�riques de contr�ler les p�riph�riques � une certaine adresse (auto-test). Ceci peut-�tre n�cessaire pour du mat�riel mal con�u qui peut provoquer un bloquage au d�marrage (comme par exemple certaines cartes r�seaux ethernet), du mat�riel mal reconnu, du mat�riel dont l'�tat a �t� modifi� par un test r�cent, ou encore si vous ne voulez pas que le noyau initialise certains mat�riels.
Le param�tre de d�marrage reserve s'attaque � ce probl�me en
sp�cifiant une zone d'un port d'entr�e/sortie qui n'a pas besoin
d'�tre test�e. Cette zone est "r�serv�e" (verrouill�e) dans la table
d'enregistrement des ports du noyau comme si un p�riph�rique avait
d�j� �t� trouv� dans cette zone (avec le nom reserved).
Notons que ce m�canisme n'est pas n�cessaire sur la plupart des machines.
Il est indispensable d'utiliser ce param�tre uniquement en cas de probl�me
ou dans certains cas particuliers.
Les ports d'entr�e/sortie dans la zone sp�cifi�e sont prot�g�s contre
les contr�les de p�riph�riques qui font un check_region() au lieu
de tester aveugl�ment une r�gion d'entr�e/sortie. Ceci a �t� introduit
pour �tre utilis� lorsqu'un pilote plante, avec la NE2000 par exemple,
ou identifie de fa�on
incorrecte un autre p�riph�rique comme �tant le sien.
Un pilote de p�riph�rique correct ne doit pas tester une zone r�serv�e,
� moins qu'un autre param�tre de d�marrage lui demande explicitement
de le faire. Ceci implique que le param�tre reserve doit �tre le
plus souvent utilis� avec un autre param�tre de d�marrage. Par cons�quent
si vous sp�cifiez une r�gion reserve pour pr�server un p�riph�rique
particulier, vous devrez en g�n�ral aussi sp�cifier de fa�on explicite
un test pour ce p�riph�rique. La plupart des pilotes ignorent la table
d'enregistrement des ports si on leur donne une adresse sp�cifique.
Par exemple, la ligne de d�marrage
reserve=0x300,32 blah=0x300
laisse tous les pilotes de p�riph�riques, except� le pilote pour `blah',
tester 0x300-0x31f.
Comme d'habitude avec les param�tres de d�marrage, il existe une limite �
11 param�tres, c'est pourquoi vous ne pouvez indiquer que 5 zones
prot�g�es par mot cl� reserve. Plusieurs ordres reserve
peuvent �tre utilis�s si vous avez une requ�te vraiment tr�s complexe.
Notez que ce n'est pas vraiment un param�tre de d�marrage. C'est une
option interpr�t�e par LILO et non pas par le kernel, contrairement �
tous les autres arguments. Pourtant, son utilisation est devenue si
commune qu'une mention lui est r�serv�e ici. Il peut aussi �tre positionn�
gr�ce � rdev -v ou par equivalence avec vidmode sur
le fichier vmlinuz. Cela permet au programme de configuration d'utiliser
le BIOS vid�o pour changer le mode d'�cran par d�faut, avant le d�marrage
du noyau de Linux. Les modes courants sont 80x50, 132x44, etc. Le
meilleur moyen d'utiliser cette option est de demarrer avec
vga=ask, qui vous demandera � l'aide d'une liste des diff�rents
modes que vous pourrez utiliser avec votre carte vid�o, avant de d�marrer
le noyau. Une fois que vous avez le nombre que vous voulez utiliser,
provenant de la liste ci-dessus, vous pouvez, plus tard, le placer � la
place de 'ask'. Pour plus d'informations, veuillez, s'il vous plait,
regarder le fichier linuxDocumentation/svga.txt/ qui existe
depuis les derni�res versions du noyau. Notez que les noyaux r�cents
(version 2.1 et sup�rieures) ont leur programme de configuration qui
permettent de changer le mode vid�o, sous la forme d'une option, list�e
comme un Support de s�lection de mode vid�o (Video mode
selection support), donc vous devez s�lectionner cette option si
vous voulez cette caract�ristique.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:26