[FAQ] Processus de boot linux

[Greywolf]

Une fois le chargeur de démarrage (LiLo, Grub,...) lancé par le mbr (rappel: le bios cherche d'abord dans le mbr du disque dur qui va scanner le disque pour trouver la partition flaguée bootable et exécuter le contenu du secteur de boot), le noyau est décompressé en mémoire.

 

Pour qu'un noyau s'y retrouve dans le disque dur, il faut au moins qu'il sache gérer nativement le contrôleur IDE du disque (ou SATA) ainsi que le type de systèmes de fichiers (Ext3, ReiserFS, XFS,...).

 

L'utilisation d'une image initrd permet de s'affranchir de compiler en dur ces fonctionnalités en les intégrant en tant que module dans l'image.

 

Lorsque le noyau a retrouvé son disque dur, celui lance le père de tous les processus:

/sbin/init.

 

init va lire le fichier /etc/inittab pour, entre autres, déterminer le niveau d'exécution par défaut du système et va, inévitablement, charger le niveau S qui correspond au minimum vital.

 

Le système linux dispose de 7 niveaux d'exécution numérotés de 0 à 6:

 

0 correspond à la procédure d'extinction de la machine (tapez telinit 0 en root dans une console)

6 correspond à la procédure de redémarrage de la machine (idem)

 

1 correspond au mode d'administration qui charge un minimum de choses et se conclue par l'accès à un shell root direct si la distribution est peu sécurisée ou avec demande de mot de passe dans le cas contraire.

 

2, 3, 4 et 5 permettent de déterminer différents niveaux d'exécution avec différents services chargés

 

2 est normalement multi-utilisateur sans serveur X

5 , sous mandrake, est associée à un système multi-utilisateur avec serveur X.

 

Mais on peut faire ce que l'on veut (après tout c'est notre PC )

 

Ces niveaux d'exécution permettent au système de déterminer dans quel répertoire rcX.d piocher les scripts de démarrage.

• Sous Mandrake, ces scripts se retrouvent dans les répertoires /etc/rc.d/rc[0-6].d
  Sous Debian, ces scripts se retrouvent dans les répertoires /etc/rc[0-6].d
  

En regardant de plus près ces répertoires, on s'aperçoit qu'ils ne contiennent que des liens symboliques vers les scripts du même nom contenus dans le répertoire /etc/rc.d/init.d (Mandrake) ou /etc/init.d (Debian).

 

Ces liens sont tous formés selon la même syntaxe

[S|K]XX<nom_du_script>

 

S indique au système que le script doit être lancé avec l'opérande start (démarrage du service)

K indique au système que le script doit être lancé avec l'opérande stop (arrêt du service)

 

XX est un niveau d'exécution, on peut en effet modifier l'ordre dans lequel se lance ces scripts. Par exemple, pour une carte PCMCIA ethernet sur un portable, le chargement de PCMCIA doit se réaliser avant le montage des interfaces réseaux.

 

Sous Debian, l'utilitaire update-rc.d permet de gérer ces liens.

Sous Mandrake, l'utilitaire est chkconfig.

(je ne rentre pas dans les interfaces graphiques du style KSysV...)

 

Sous Mandrake, il existe un dernier répertoire nommé rc.local, celui-ci peut contenir des scripts maison qui seront lancés à la fin du processus d'init.

 

Pour lancer un service sous mandrake, il est possible d'utiliser la syntaxe

service <nom_du_service> start

 

on peut tout aussi bien faire

/etc/rc.d/init.d/<script_correspondant_au_service> start

 

//ceci est une ébauche de FAQ. Si des mandrakiens peuvent confirmer ou infirmer mes dires

 

//truc amusant: au prompt lilo ou grub, taper init=/bin/sh

[KewlCat]

La même chose sous Slackware (qui, je le rappelle, utilise une structure empruntée à BSD pour ses scripts de boot). Je considère ici que le package sysvinit (optionnel, mettant en place les scripts de boot SytemV) n'a pas été installé.

 

Au niveau de l'init, rien ne change : /sbin/init va lire le contenu de /etc/inittab, et root peut demander à init de passer d'un runlevel à un autre avec la commande telinit <runlevel>

 

Les scripts se situent tous dans un unique répertoire /etc/rc.d

 

Boot de la machine : S comme ... euh... "System initialization" ?

- exécute /etc/rc.d/rc.S

 

Runlevel 0 : halt

- éteint la machine, si on a bien configuré son ACPI ou APM. sinon, arrête tous les processus et affiche "system halted"

- exécute le script /etc/rc.d/rc.0

 

Runlevel 1 : single user

- permet d'obtenir une console d'administration avec la toute puissance de la machine à son entière disposition

- exécute le script /etc/rc.d/rc.K

 

Runlevel 2 : configuré pareil que Runlevel 3

Runlevel 3 : multiuser

- mode par défaut de la slackware, démarre six tty

- exécute /etc/rc.d/rc.M

- (il est appelé depuis rc.M, en fait) exécute rc.local

 

Runlevel 4 : X11 (xdm, kdm, gdm, ce que vous voulez...)

- exécute /etc/rc.d/rc.4

 

Runlevel 5 : configuré pareil que Runlevel 3

 

Runlevel 6 : reboot

- redémarre la machine

- exécute /etc/rc.d/rc.6

 

Les services démarrés lors du boot peuvent être configurés par le script /var/adm/setup/setup.services (s'il n'est pas déjà dans le $PATH)

[Note : /var/adm est un lien symbolique vers /var/log]

Cela dit, ce script se contente de changer l'attribut exécutable des scripts /etc/rc.d/rc.<nom du service>

 

Ces scripts s'utilisent généralement de la façon suivante : /etc/rc.d/rc.service [ start | stop | restart ] ("généralement" parce que certaines fois l'action restart n'est pas prévue)

 

Ainsi, pour redémarrer son serveur Apache, il convient de lancer /etc/rc.d/rc.httpd restart

Pour arrêter les interfaces réseau, il convient de lancer /etc/rc.d/rc.inet1 stop

 

etc.

[KewlCat]

Une fois le chargeur de démarrage (LiLo, Grub,...) lancé par le bios (rappel: le bios cherche d'abord dans le mbr du disque dur puis, s'il ne trouve rien, passe au superblock de la partition flaggée bootable), le noyau est décompressé en mémoire.

J'avais pas noté... Il y a une petite correction à apporter : le BIOS lance ce qui se trouve dans le MBR du disque désigné comme disque de boot. Point. C'est le programme du MBR qui va scanner le disque pour trouver la partition flaguée bootable et exécuter le contenu du secteur de boot.

C'est pour cela que, lorsque le MBR est flingué, ça ne boote plus. On peut mettre ce que l'on veut dans le MBR ou dans le secteur de boot, mais si on veut garder un disque sain, il est conseillé de ne pas installer le bootloader dans le MBR (surtout que, parfois, les constructeurs de DD ne mettent pas qu'un bête scanneur/amorceur dans le MBR...)

[Greywolf]

corrigé

[KewlCat]

Génial

[KewlCat]

Article interessant sur IBM Developerworks : Boot loader showdown décrivant et comparant le fonctionnement de Lilo et Grub.

[KewlCat]

Article sur IBM Developerworks "Inside the Linux boot process" décrivant l'intégralité du processus de boot, du BIOS jusqu'au lancement du premier processus en "user space".