8.8. Configuration du chargeur d'amorçage

Il est probablement déjà fonctionnel, mais il est toujours bon de savoir configurer et installer un chargeur d'amorçage au cas où celui-ci disparaîtrait du Master Boot Record (enregistrement d'amorçage maître). Cela peut se produire suite à l'installation d'un autre système d'exploitation, tel que Windows. Ces connaissances vous permettront également d'en modifier la configuration si l'actuelle ne vous convient pas.

8.8.1. Identifier ses disques

CULTURE udev et /dev/

Le répertoire /dev/ abrite traditionnellement des fichiers dits « spéciaux », destinés à représenter les périphériques du système (voir encadré B.A.-BA Droits d'accès à un périphérique). À une lointaine époque, il contenait des fichiers spéciaux correspondant à tous les périphériques possibles. Cette structure statique présentait un certain nombre d'inconvénients, notamment parce qu'elle restreignait le nombre de périphériques utilisables (puisque leur liste était codée en dur) et qu'elle empêchait de savoir quels fichiers spéciaux correspondaient à un périphérique existant.

De nos jours, les fichiers spéciaux sont gérés de manière entièrement dynamique, ce qui correspond mieux à la nature des périphériques informatiques (dont la plupart peuvent être branchés et débranchés « à chaud »). Le noyau coopère avec udev (Section 9.11.3, « Fonctionnement de udev ») pour créer et supprimer ces fichiers à la volée lorsque les périphériques apparaissent ou disparaissent. Cela permet de ne pas avoir à stocker le répertoire /dev/ sur un système de stockage persistant ; au contraire, il est dans un système de fichiers en mémoire qui commence vide et qui ne contient que les entrées pertinentes.

Le noyau fournit de nombreuses informations à propos d'un périphérique lors de son ajout et y ajoute une paire d'identifiants (majeur/mineur). udevd utilise ces informations pour créer le fichier spécial sous le nom voulu et avec les permissions les plus pertinentes. Il peut aussi créer des alias et lancer des actions supplémentaires (par exemple des tâches d'initialisation ou d'enregistrement). Le comportement d'udevd est régi par un vaste ensemble de règles (personnalisables).

Il est ainsi possible, en utilisant les noms affectés de manière dynamique, de garder le même nom pour un périphérique donné, quel que soit le port auquel il est connecté ou l'ordre dans lequel les périphériques ont été branchés, ce qui pourra se révéler très utile si de nombreux périphériques USB sont utilisés. La première partition du premier disque s'appelle généralement /dev/sda1 pour des raisons de compatibilité ascendante, mais elle pourrait tout aussi bien s'appeler /dev/partition-principale, voire les deux à la fois puisqu'il est possible de configurer udevd pour qu'il crée un lien symbolique automatiquement.

En des temps anciens, certains modules noyau se chargeaient automatiquement lorsqu'on tentait d'accéder au périphérique correspondant. Ce n'est désormais plus le cas, le fichier spécial du périphérique n'existant plus avant d'avoir chargé le module… ce qui n'est pas très grave puisque la plupart des modules sont chargés au démarrage grâce à la détection automatique du matériel. Mais pour des périphériques non détectables (comme le bon vieux lecteur de disquettes ou la souris PS/2), cela ne fonctionne pas. Pensez donc à ajouter les modules floppy, psmouse et mousedev dans /etc/modules afin de forcer leur chargement au démarrage.

La configuration du chargeur d'amorçage doit identifier les différents disques et leurs partitions. Linux emploie pour cela un système de fichiers spéciaux (dits en mode « bloc »), stockés dans le répertoire /dev/. Depuis Debian Squeeze, le schéma de nommage a été unifié et tous les disques durs (IDE/PATA, SATA, SCSI, USB, IEEE 1394) sont dorénavant représentés par des /dev/sd*.

Chaque partition est représentée par un numéro d'ordre au sein du disque où elle réside : /dev/sda1 est donc la première partition du premier disque et /dev/sdb3 la troisième partition du deuxième disque.

L'architecture PC (ou « i386 », y compris son jeune cousin « amd64 ») est limitée à quatre partitions « primaires » par disque. Pour outrepasser cette limitation, l'une d'entre elles sera créée comme une partition « étendue » et pourra alors contenir des partitions « secondaires ». Ces dernières portent toujours un numéro supérieur ou égal à 5. La première partition secondaire pourra donc être /dev/sda5, suivie de /dev/sda6, etc.

Une autre restriction de la table de partition MS-DOS est qu'elle ne supporte pas des disques de plus de 2 To, ce qui devient un vrai problème avec les disques récents.

Un nouveau format de table de partition, nommé GPT, permet de dépasser ces contraintes sur le nombre de partitions (il supporte jusqu'à 128 partitions) et sur la taille des disques (qui peuvent aller jusqu'à 8 zétaoctets, ce qui représente plus de 8 milliards de téraoctets). Ainsi, si l'on prévoit de créer de nombreuses partitions physiques sur le même disque, il convient de créer une table de partition au format GPT lors de l'étape du partitionnement.

Il n'est pas toujours facile de mémoriser quel disque est branché sur le second contrôleur SATA ou en troisième position dans la chaîne SCSI, d'autant que le nommage des disques durs branchables à chaud (ce qui inclut entre autres la plupart des disques SATA et des disques externes) n'est pas entièrement déterministe et peut changer d'un boot à l'autre. Heureusement, udev crée, en plus des /dev/sd*, des liens symboliques de nom fixe, qu'on pourra alors utiliser si l'on souhaite identifier de manière non ambiguë l'un ou l'autre disque. Ces liens symboliques sont stockés dans /dev/disk/by-id/. Sur une machine à deux disques physiques, on a par exemple :

mirexpress:/dev/disk/by-id# ls -l
total 0
lrwxrwxrwx 1 root root  9 23 juil. 08:58 ata-STM3500418AS_9VM3L3KP -> ../../sda
lrwxrwxrwx 1 root root 10 23 juil. 08:58 ata-STM3500418AS_9VM3L3KP-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 23 juil. 08:58 ata-STM3500418AS_9VM3L3KP-part2 -> ../../sda2
[...]
lrwxrwxrwx 1 root root  9 23 juil. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697 -> ../../sdb
lrwxrwxrwx 1 root root 10 23 juil. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 23 juil. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part2 -> ../../sdb2
[...]
lrwxrwxrwx 1 root root  9 23 juil. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP -> ../../sda
lrwxrwxrwx 1 root root 10 23 juil. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 23 juil. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part2 -> ../../sda2
[...]
lrwxrwxrwx 1 root root  9 23 juil. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697 -> ../../sdb
lrwxrwxrwx 1 root root 10 23 juil. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 23 juil. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part2 -> ../../sdb2
[...]
lrwxrwxrwx 1 root root  9 23 juil. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0 -> ../../sdc
lrwxrwxrwx 1 root root 10 23 juil. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 23 juil. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part2 -> ../../sdc2
[...]
lrwxrwxrwx 1 root root  9 23 juil. 08:58 wwn-0x5000c50015c4842f -> ../../sda
lrwxrwxrwx 1 root root 10 23 juil. 08:58 wwn-0x5000c50015c4842f-part1 -> ../../sda1
[...]
mirexpress:/dev/disk/by-id#

On constate que certains disques sont listés plusieurs fois (parce qu'ils se comportent à la fois comme des disques ATA et comme des SCSI), mais l'information pertinente est principalement dans le modèle et le numéro de série des disques, à partir desquels on peut retrouver le fichier de périphérique.

Les exemples de fichiers de configuration donnés dans les sections suivantes reposent tous sur le même cas : un seul disque SATA, dont la première partition est dédiée à un ancien Windows et la seconde contient Debian GNU/Linux.

8.8.2. Configuration de LILO

LILO (LInux LOader, ou chargeur de Linux) est le plus ancien chargeur d'amorçage, solide mais rustique. Il écrit dans le MBR l'adresse physique du noyau à démarrer ; c'est pourquoi chaque mise à jour de celui-ci (ou du fichier de configuration de LILO) doit être suivie de la commande lilo. L'oublier produira un système incapable de démarrer si l'ancien noyau a été supprimé ou remplacé, puisque le nouveau ne sera pas au même emplacement sur le disque.

LILO a pour fichier de configuration /etc/lilo.conf ; un fichier simple pour une configuration standard est illustré par l'exemple ci-dessous.

Exemple 8.4. Fichier de configuration de LILO

# Le disque sur lequel LILO doit s'installer.
# En indiquant le disque et non pas une partition,
# on ordonne à LILO de s'installer sur le MBR.
boot=/dev/sda
# la partition qui contient Debian
root=/dev/sda2
# l'élément à charger par défaut
default=Linux

# Noyau le plus récent
image=/vmlinuz
  label=Linux
  initrd=/initrd.img
  read-only

# Ancien noyau (si le noyau nouvellement installé ne démarre pas)
image=/vmlinuz.old
  label=LinuxOLD
  initrd=/initrd.img.old
  read-only
  optional

# Seulement pour un double amorçage Linux/Windows
other=/dev/sda1
  label=Windows

8.8.3. Configuration de GRUB 2

GRUB (GRand Unified Bootloader, ou grand chargeur d'amorçage unifié) est plus récent. Il n'est pas nécessaire de l'invoquer après chaque mise à jour du noyau puisqu'il sait lire les systèmes de fichiers et retrouver tout seul la position du noyau sur le disque. Pour l'installer dans le MBR du premier disque, on saisira simplement grub-install /dev/sda.

ATTENTION Noms des disques pour GRUB

GRUB fait appel au BIOS pour identifier les disques durs. (hd0) correspond au premier disque ainsi détecté, (hd1) au deuxième, etc. Dans la majorité des cas, cet ordre correspond exactement à l'ordre habituel des disques sous Linux, mais des problèmes peuvent survenir lorsque l'on associe disques SCSI et disques IDE. Auparavant GRUB stockait les correspondances qu'il détectait dans le fichier /boot/grub/device.map. De nos jours, GRUB évite ce problème en utilisant les UUIDs ou les étiquettes des systèmes de fichier lors de la génération de grub.cfg. Cependant, le fichier device.map n'est pas encore obsolète, depuis il peut être utilisé pour écraser les paramètres lorsque l'environnement courant est différent de celui au démarrage. Si vous y trouvez des erreurs (parce que vous savez que votre BIOS détecte les disques dans un autre ordre), corrigez-les manuellement et exécutez à nouveau grub-install. grub-mkdevicemap peut être utile pour créer un fichier device.map initial.

Les partitions portent aussi un nom spécifique à GRUB. Lorsque l'on utilise des partitions « classiques » au format MS-DOS, la première partition du premier disque est notée (hd0,msdos1), la seconde (hd0,msdos2), etc.

La configuration de GRUB 2 est stockée dans /boot/grub/grub.cfg, mais ce fichier est (sous Debian) généré à partir d'autres. On prendra donc garde de ne pas le modifier à la main, sous peine de voir ces modifications locales perdues à la prochaine invocation de update-grub (qui peut se faire lors d'une mise à jour de différents paquets). Les modifications les plus courantes du fichier /boot/grub/grub.cfg (pour ajouter des paramètres de ligne de commande au noyau ou changer la durée d'affichage du menu, par exemple) se font par le biais des variables définies dans /etc/default/grub. Pour ajouter des entrées dans le menu, on pourra soit créer un fichier /boot/grub/custom.cfg, soit modifier le fichier /etc/grub.d/40_custom. Pour des personnalisations plus complexes, on pourra modifier les autres fichiers de /etc/grub.d/, ou en ajouter ; il s'agit de scripts qui doivent renvoyer des extraits de configuration, en s'appuyant éventuellement sur des programmes externes. Ce sont ces scripts qui vont mettre à jour la liste des noyaux à démarrer : 10_linux prend en compte les noyaux Linux installés, 20_linux_xen prend en compte les systèmes de virtualisation Xen et 30_os-prober prend en compte d'autres systèmes d'exploitation (Windows, OS X, Hurd).