Après la mise sous tension ou un reset matériel, un programme stocké en mémoire morte (souvent une PROM) prend le contrôle. Sur les PC, on appelle généralement ce programme le BIOS.

Ce programme effectue normalement un auto-test 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 batterie de type CMOS. Ainsi la plupart des gens l'appellent CMOS, alors qu'en dehors du monde des PC, elle est généralement appelée nvram (non-volatile ram).

Les paramètres stockés dans la nvram varient d'un système à l'autre, mais au minimum, le programme d'amorçage matériel devrait savoir quel est le périphérique d'amorçage, ou à défaut quels périphériques il faut essayer pour amorcer le système.

Ensuite, la phase de démarrage matériel accède au périphérique d'amorçage, charge le chargeur de démarrage, qui est situé à une position fixe sur le périphérique d'amorçage, et lui passe le contrôle.

Note :

Nous n'abordons pas ici le démarrage à partir du réseau. Ceux qui s'intéressent à ce sujet devraient rechercher du côté de DHCP, TFTP, PXE, Etherboot, et nous rejoindre au démarrage du noyau.

Sur les PC, le chargeur de démarrage est situé sur le premier secteur du périphérique d'amorçage - c'est 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 (64 octets) et un identifiant de disque (2 octets) ne laissent que 446 octets pour le code - et rend quasiment impossible le stockage d'un chargeur de démarrage complet.

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.

Sous Linux, le chargeur de démarrage est normalement lilo(8) ou grub(8). Chacun peut être installé soit en tant que chargeur secondaire (si le MBR installé par DOS pointe vers eux), soit en tant que chargeur en deux parties, car ils fournissent un MBR spécial contenant un code d'amorçage pour charger la seconde partie du chargeur à partir de la partition principale.

Le rôle principal du chargeur de démarrage est de localiser le noyau sur le disque, le charger et l'exécuter. La plupart des chargeurs de démarrage sont interactifs, pour permettre la spécification d'un noyau alternatif (par exemple un noyau de sauvegarde dans le cas où la dernière version compilée ne fonctionne pas) et le passage de paramètres optionnels au noyau.

Quand le noyau est chargé, il initialise les périphériques (via leurs pilotes), démarre le gestionnaire de swap (c'est un « processus noyau », appelé kswapd sur les noyaux Linux modernes), et monte le système de fichiers racine - appelé root filesystem - (/).

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, voir bootparam(7).

C'est uniquement à cet instant que le noyau crée un premier (en espace utilisateur) processus, qui porte le numéro 1. 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.

Quand init démarre, il lit /etc/inittab pour y trouver ses instructions. Ce fichier définit ce qui doit s'exécuter dans les différents modes de fonctionnement (run-levels).

Cela donne à l'administrateur système une méthode simple de gestion dans laquelle chaque run-level est associé à un ensemble de services (par exemple : S correspond à un mode maintenance (single-user), en run-level 2, la plupart des services réseaux sont actifs, etc.). L'administrateur peut changer le run-level courant par init(8) et connaître le run-level courant par runlevel(8).

Toutefois, comme il n'est pas pratique de gérer les services individuellement en éditant ce fichier, inittab se limite à l'appel d'un ensemble de scripts qui démarrent/arrêtent les services.

Note :

La description suivante s'applique aux systèmes basés sur SYSV-R4, qui couvre actuellement la plupart des Unices commerciaux (Solaris, HPUX, Irix, Tru64) ainsi que les distributions majeures de Linux (RedHat, Debian, Mandrake, Suse, Caldera). Quelques systèmes (Slackware Linux, Gentoo Linux, FreeBSD, OpenBSD) utilisent un procédé quelque peu différent pour les scripts de démarrage.

Pour chaque service géré (messagerie, nfs, cron, etc.) il y a 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 », enchaine un « stop » suivi d'un « start », « status » donne l'état du service). Un appel du script sans argument permet d'afficher tous ceux possibles.

Pour permettre aux scripts spécifiques de démarrer/arrêter un run-level spécifique et dans un ordre particulier, il y a des répertoires d'ordonnancement. Ce sont généralement /etc/rc[0-6S].d. Dans chacun de ces répertoires, il y a des liens (généralement symboliques) vers les scripts du répertoire /etc/init.d.

Un premier script (souvent /etc/rc) est appelé par inittab(5) et appelle lui-même les scripts des services grâce aux liens des répertoires d'ordonnancement. 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'odre de démarrage ou d'arrêt au sein d'un même run-level, les noms des liens contiennent des numéros d'ordre. Aussi, pour plus de clarté, ils se terminent par le nom du service auquel il se réfère. Exemple : Le lien /etc/rc2.d/S80sendmail démarre le service sendmail 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.

Si l'on lit le script /etc/rc, on constate ce qui suit :

En premier lieu, les scripts K* sont exécutés pour arrêter les services non concernés par le run-level, suivis des scripts S* pour démarrer ceux qui le deviennent. L'ordre est exactement celui du caractère d'expansion « * », car l'appel successif des différents scripts se fait par une boucle « for ». Pour schématiser, rc exécute « for i in /etc/rc$runlevel.d/K*; do $i stop ; done » puis ensuite « for i in /etc/rc.$runlevel.d/S*; do $i start ; done ».

Pour gérer l'ordre de démarrage et les run-levels, on doit gérer ces liens. Toutefois, sur beaucoup de versions de Linux, il existe des outils qui facilitent cela. (exemple : chkconfig(8)).

Habituellement, les démons démarrés peuvent éventuellement recevoir des options et arguments sur leur ligne de commande. Pour permettre aux administrateurs systèmes de modifier ces paramètres sans éditer le script, des fichiers de configuration sont utilisés. Ils sont stockés dans un répertoire spécifique (/etc/sysconfig sur les systèmes RedHat et Mandrake), et sont utilisés par les scripts de démarrage.

Sur les anciens Unices, ces fichiers contenaient les options de ligne de commande pour les démons, mais sur les systèmes Linux modernes (et aussi sur HPUX), ces fichiers contiennent uniquement des variables shell. Les scripts de démarrage du répertoire /etc/init.d sourcent (par la commande interne « . » du shell) les fichiers de configuration et utilisent ensuite les variables.