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