Chaque composant est décrit plus en détails ci-dessous.
Ce programme effectue normalement un autotest de la machine et accède à la mémoire non volatile pour y lire quelques paramètres. Dans les PC, cette mémoire est maintenue par une mémoire CMOS entretenue par une batterie. Ainsi la plupart des gens l'appellent CMOS, alors qu'en dehors du monde des PC, elle est généralement appelée NVRAM (RAM non volatile).
Les paramètres stockés dans la NVRAM dépendent des systèmes, mais doivent indiquer a minima quel périphérique peut fournir un chargeur de démarrage, ou quels périphériques peuvent être sondés pour en trouver un. Un tel périphérique est appelé « périphérique d'amorçage ». La phase de démarrage matériel charge le chargeur de démarrage depuis une position fixe sur le périphérique d'amorçage et lui passe le contrôle.
Sur les PC traditionnels, le chargeur de démarrage est situé sur le premier bloc de 512 octets du périphérique d'amorçage – ce bloc est appelé le MBR (Master Boot Record).
Sur la plupart des systèmes, ce chargeur initial est très limité du fait de diverses contraintes. Même sur des systèmes autres que le PC, il existe des limitations concernant la taille et la complexité de ce chargeur, mais la taille du MBR des PC est limitée – 512 octets y compris la table de partition – et rend quasiment impossible d'y insérer beaucoup de fonctionnalités.
Ainsi, sur la plupart des systèmes d'exploitation, le chargeur initial appelle un chargeur de démarrage secondaire situé sur une partition du disque. Ce chargeur de démarrage secondaire peut se trouver dans un plus grand emplacement de stockage persistant, comme une partition de disque.
Sous Linux, le chargeur de démarrage est souvent grub(8) (lilo(8) est une alternative).
Quelques paramètres relatifs à cela peuvent être passés au noyau (par exemple : on peut spécifier un autre système de fichiers racine que celui par défaut). Pour plus d'informations sur les paramètres du noyau Linux, consultez bootparam(7).
C'est uniquement à cet instant que le noyau crée un premier processus en espace utilisateur, qui porte le numéro de processus 1 (PID). Ce processus exécute le programme /sbin/init, en lui passant tout paramètre qui n'est pas déjà géré par le noyau.
Lorsque /sbin/init démarre, il lit /etc/inittab pour y trouver ses instructions. Ce fichier définit ce qui doit s'exécuter lorsque le programme /sbin/init doit entrer dans un mode de fonctionnement (run-level) particulier. Cela donne à l'administrateur une méthode simple pour établir un environnement pour un usage donné. Chaque mode de fonctionnement est associé à un ensemble de services (par exemple, S correspond à un mode maintenance (single-user) et 2 implique le fonctionnement de la plupart des services réseaux).
L'administrateur peut modifier le mode de fonctionnement grâce à init(1) et consulter le mode de fonctionnement actuel avec runlevel(8).
Toutefois, comme il n'est pas pratique de gérer les services individuellement en éditant ce fichier, /etc/inittab se limite à l'appel d'un ensemble de scripts qui démarrent/arrêtent les services.
Pour chaque service géré (messagerie, serveur nfs, cron, etc.), il existe un script de démarrage simple stocké dans un répertoire spécifique (/etc/init.d dans la majorité des versions de Linux). Chacun de ces scripts accepte en unique argument le mot « start » (dont l'effet est le lancement du service) ou le mot « stop » (pour arrêter le service). Le script peut éventuellement accepter d'autres paramètres pratiques (par exemple : « restart », enchaîne un « stop » suivi d'un « start », « status » donne l'état du service). Un appel du script sans argument permet d'afficher tous ceux possibles.
Un premier script (souvent /etc/rc) est appelé par inittab(5) et appelle lui-même le script de chaque service grâce à un lien dans le répertoire d'ordonnancement correspondant. Tous les liens dont le nom commence par « S » sont appelés avec l'argument « start » (et démarrent le service concerné). Tous les liens dont le nom commence par « K » sont appelés avec l'argument « stop » (et arrêtent le service concerné).
Pour définir l'ordre de démarrage ou d'arrêt au sein d'un même run level, le nom d'un lien contient un numéro d'ordre. Aussi, pour rendre les noms plus clairs, ceux-ci se terminent par le nom du service auquel ils se réfèrent. Exemple : le lien /etc/rc2.d/S80sendmail démarre le service sendmail(8) dans le run level 2. Cela est fait après l'exécution de /etc/rc2.d/S12syslog mais avant celle de /etc/rc2.d/S90xfs.
Gérer ces liens revient à gérer l'ordre de démarrage et les run levels. Toutefois, sur beaucoup de systèmes, il existe des outils qui facilitent cela (exemple : chkconfig(8)).
Sur les anciens systèmes UNIX, ces fichiers contenaient les options de ligne de commande pour les démons, mais sur les systèmes Linux modernes (et aussi sur HP-UX), ces fichiers contiennent uniquement des variables shell. Un script de démarrage dans le répertoire /etc/init.d lit et incorpore son fichier de configuration (il « source » le fichier de configuration) et utilise ensuite les valeurs des variables.
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à