101.1 Leçon 1

Certification :

LPIC-1

Version :

5.0

Thème :

101 Architecture système

Objectif :

101.1 Détermination et configuration des paramètres du matériel

Leçon :

1 sur 1

Introduction

Depuis les débuts de l’informatique, les fabricants d’ordinateurs professionnels et personnels ont intégré dans leurs machines une variété de composants matériels qui devaient être pris en charge à leur tour par le système d’exploitation. Tâche difficile voire impossible du point de vue des développeurs de systèmes d’exploitation, à moins que l’industrie ne se mette d’accord sur les normes relatives aux jeux d’instructions et à la communication avec les périphériques. De la même manière que la couche d’abstraction standardisée fournie par le système d’exploitation à une application, ces normes facilitent le développement et la maintenance d’un système d’exploitation qui n’est pas lié à un type de matériel spécifique. Ceci étant dit, la complexité du matériel intégré sous le capot nécessite parfois certains ajustements quant à la manière dont les ressources matérielles sont exposées au système afin que celui-ci puisse être installé et fonctionner correctement.

Certains de ces réglages peuvent même être effectués en l’absence de système d’exploitation. La plupart des ordinateurs offrent un outil de configuration qui peut être exécuté à l’allumage de la machine. Jusque vers le début des années 2000, cet utilitaire de configuration était implémenté dans le BIOS (Basic Input/Output System, système élémentaire d’entrée/sortie), la norme pour le firmware (micrologiciel) contenant les routines de configuration de base que l’on peut trouver sur les cartes mère x86. À partir de la fin de la première décennie des années 2000, les machines basées sur l’architecture x86 ont commencé à remplacer le BIOS par une nouvelle implémentation appelée UEFI (Unified Extensible Firmware Interface, interface micrologicielle extensible unifiée) dotée de fonctionnalités plus sophistiquées pour l’identification, les tests et la configuration matérielle ainsi que les mises à jour du firmware. Malgré cette évolution, il n’est pas rare de nos jours d’avoir recours à l’utilitaire de configuration BIOS, étant donné que les deux implémentations répondent au même besoin.

Note	Les menus détails sur les points communs et les différences entre le BIOS et l’UEFI seront traités dans une leçon ultérieure.

Activation des périphériques

L’utilitaire de configuration du système s’affiche lorsqu’on appuie sur une touche spécifique lors de l’allumage de l’ordinateur. Cette touche peut varier d’un fabricant à l’autre, mais il s’agit généralement de la touche Suppr ou de l’une des touches de fonction comme F2 ou F12. La combinaison de touches à utiliser est souvent affichée à l’écran juste après l’allumage.

Le BIOS permet de prendre en charge ou de désactiver les périphériques intégrés, d’activer la protection contre les erreurs et de modifier les paramètres matériels tels que les interruptions matérielles (IRQ) et l’accès direct à la mémoire (DMA). La modification de ces paramètres est rarement nécessaire sur les machines modernes, mais leur ajustement peut s’avérer nécessaire pour résoudre des problèmes spécifiques. Certaines technologies RAM, par exemple, sont compatibles avec des taux de transfert de données plus élevés que celui par défaut, il est donc recommandé de le remplacer par le taux de transfert spécifié par le fabricant. Certains processeurs offrent des fonctionnalités pas forcément requises pour une installation particulière, et qui peuvent être désactivées. La désactivation de ces fonctionnalités permet de réduire la consommation en énergie tout en augmentant la protection du système, étant donné que certaines fonctionnalités du CPU qui contiennent des bugs peuvent également être désactivées.

Lorsque la machine est équipée d’un certain nombre de périphériques de stockage, il est important de définir celui qui contient le bon chargeur de démarrage et qui doit apparaître en premier dans l’ordre d’amorçage des périphériques. Le système d’exploitation peut ne pas se lancer lorsqu’un périphérique incorrect apparaît en tête de liste dans les vérifications de démarrage du BIOS.

Inspection du matériel sous Linux

Une fois que les périphériques ont été correctement identifiés, il appartient au système de leur associer les composants logiciels requis pour leur bon fonctionnement. Lorsqu’un matériel ne fonctionne pas comme prévu, il est important de savoir à quel niveau exactement se situe le problème. Lorsqu’un composant matériel n’est pas détecté par le système d’exploitation, il y a de fortes chances pour que la pièce - ou le port auquel elle est connectée - soit défectueuse. Lorsque la partie matérielle est correctement détectée mais qu’elle ne fonctionne pas comme elle devrait, le problème se situe probablement du côté du système d’exploitation. Par conséquent, l’une des premières étapes lorsqu’on traite les problèmes liés au matériel consiste à vérifier si le système d’exploitation détecte correctement le périphérique. Il existe deux méthodes de base pour identifier les ressources matérielles sur un système Linux : utiliser des commandes dédiées à cet effet ou lire des fichiers spécifiques dans des systèmes de fichiers spéciaux.

Commandes pour l’inspection

Les deux commandes essentielles pour identifier les périphériques connectés dans un système Linux sont :

lspci: Affiche tous les périphériques actuellement connectés au bus PCI (Peripheral Component Interconnect). Les périphériques PCI peuvent être intégrés à la carte mère, comme un contrôleur de disque, ou alors ils peuvent être connectés sur les ports d’extension de la carte mère, comme une carte graphique externe.
lsusb: Répertorie les périphériques USB (Universal Serial Bus) actuellement connectés à la machine. Même s’il existe des périphériques USB pour presque tous les usages imaginables, l’interface USB est utilisée principalement pour connecter des périphériques d’entrée - claviers, dispositifs de pointage - et des supports de stockage amovibles.

La sortie des commandes lspci et lsusb consiste en une liste de tous les périphériques PCI et USB identifiés par le système d’exploitation. Cependant, il se peut que le périphérique ne soit pas encore pleinement opérationnel, étant donné que chaque pièce matérielle requiert un composant logiciel pour contrôler le périphérique correspondant. Ce composant logiciel est appelé un module du noyau et il peut faire partie du noyau Linux officiel ou être ajouté depuis une source tierce.

Les modules du noyau Linux associés aux périphériques matériels sont également appelés pilotes ou drivers, comme dans d’autres systèmes d’exploitation. En revanche, les pilotes pour Linux ne sont pas toujours fournis par les fabricants de ces périphériques. Même si certains fabricants fournissent leurs propres pilotes binaires à installer séparément, de nombreux pilotes sont écrits par des développeurs indépendants. Historiquement, les composants qui fonctionnent sous Windows, par exemple, peuvent ne pas avoir de module de noyau correspondant pour Linux. De nos jours, les systèmes d’exploitation basés sur Linux offrent un support matériel important et la plupart des appareils fonctionnent sans problème.

Les commandes directement liées au matériel requièrent souvent les droits root pour être exécutées ou affichent seulement des informations limitées lorsqu’elles sont invoquées par un utilisateur normal, il peut donc être nécessaire de se connecter en tant que root ou d’exécuter la commande avec sudo.

La sortie suivante de la commande lspci, par exemple, affiche quelques périphériques identifiés :

$ lspci
01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2)
04:02.0 Network controller: Ralink corp. RT2561/RT61 802.11g PCI
04:04.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI Multi-Channel I/O Controller (rev 02)
04:0b.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 70)

La sortie de ces commandes peut compter des dizaines de lignes, les exemples précédents et suivants ne contiennent que les sections qui nous intéressent. Les nombres hexadécimaux au début de chaque ligne représentent l’adresse unique du périphérique PCI correspondant. La commande lspci affiche davantage de détails sur un périphérique donné lorsque son adresse est précisée par l’option -s, suivie de l’option -v :

$ lspci -s 04:02.0 -v
04:02.0 Network controller: Ralink corp. RT2561/RT61 802.11g PCI
    Subsystem: Linksys WMP54G v4.1
    Flags: bus master, slow devsel, latency 32, IRQ 21
    Memory at e3100000 (32-bit, non-prefetchable) [size=32K]
    Capabilities: [40] Power Management version 2
    kernel driver in use: rt61pci

La sortie affiche maintenant beaucoup plus de détails sur le périphérique à l’adresse 04:02.0. Il s’agit d’une carte réseau dont le nom interne est Ralink corp. RT2561/RT61 802.11g PCI. L’entrée Subsystem est associée à la marque et au modèle de l’appareil — Linksys WMP54G v4.1 — et peut servir à des fins de diagnostic.

Le module du noyau peut être identifié dans la ligne kernel driver in use, qui affiche le module rt61pci. D’après toutes les informations recueillies, il est correct de supposer que :

Le périphérique a été identifié.
Un module de noyau correspondant a été chargé.
Le périphérique devrait être prêt à l’emploi.

Une autre façon de vérifier quel module du noyau est utilisé pour un périphérique donné est fournie par l’option -k, disponible dans les versions plus récentes de lspci :

$ lspci -s 01:00.0 -k
01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2)
    kernel driver in use: nvidia
    kernel modules: nouveau, nvidia_drm, nvidia

Pour le périphérique en question, une carte graphique NVIDIA, lspci nous indique à la ligne kernel driver in use: nvidia que le module en question est nommé nvidia, et tous les modules correspondants du noyau sont listés à la ligne kernel modules : nouveau, nvidia_drm, nvidia.

La commande lsusb est similaire à lspci, mais liste exclusivement les informations USB :

$ lsusb
Bus 001 Device 029: ID 1781:0c9f Multiple Vendors USBtiny
Bus 001 Device 028: ID 093a:2521 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 020: ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter
Bus 001 Device 011: ID 04f2:0402 Chicony Electronics Co., Ltd Genius LuxeMate i200 Keyboard
Bus 001 Device 007: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

La commande lsusb affiche les ports USB disponibles et les périphériques qui y sont connectés. Tout comme pour lspci, l’option -v affiche des informations plus détaillées. Un périphérique spécifique peut être sélectionné pour l’inspection en fournissant son ID à l’option d :

$ lsusb -v -d 1781:0c9f
Bus 001 Device 029: ID 1781:0c9f Multiple Vendors USBtiny
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.01
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x1781 Multiple Vendors
  idProduct          0x0c9f USBtiny
  bcdDevice            1.04
  iManufacturer           0
  iProduct                2 USBtiny
  iSerial                 0
  bNumConfigurations      1

Avec l’option -t, la commande lsusb affiche le mappage en vigueur des périphériques USB sous forme d’une arborescence hiérarchique :

$ lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
            |__ Port 2: Dev 11, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 2: Dev 11, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 3: Dev 20, If 0, Class=Wireless, Driver=btusb, 12M
            |__ Port 3: Dev 20, If 1, Class=Wireless, Driver=btusb, 12M
            |__ Port 3: Dev 20, If 2, Class=Application Specific Interface, Driver=, 12M
            |__ Port 1: Dev 7, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
        |__ Port 2: Dev 28, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 3: Dev 29, If 0, Class=Vendor Specific Class, Driver=, 1.5M

Il est possible que tous les périphériques ne soient pas associés à un module correspondant. La communication avec certains périphériques peut être gérée directement par l’application, sans passer par l’intermédiaire d’un module. Néanmoins, il y a des informations importantes dans les résultats fournis par lsusb -t. Lorsqu’un module approprié existe, son nom apparaît à la fin de la ligne correspondant au périphérique, comme dans Driver=btusb. La Class du périphérique identifie la catégorie générale, comme Human Interface Device, Wireless ou Mass Storage, entre autres. Pour vérifier quel périphérique utilise le module btusb qui figure dans le listing ci-dessus, les numéros de Bus et de Dev doivent être fournis en argument à l’option -s de la commande lsusb :

$ lsusb -s 01:20
Bus 001 Device 020: ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter

Il est courant de se retrouver avec un grand nombre de modules de noyau chargés à tout moment dans un système Linux standard. La meilleure façon d’interagir avec eux consiste à utiliser les commandes fournies par le paquet kmod, qui est un ensemble d’outils pour gérer les tâches communes avec les modules du noyau Linux comme l’insertion, la suppression, la liste, la vérification des propriétés, la résolution des dépendances et des alias. La commande lsmod, par exemple, affiche tous les modules actuellement chargés :

$ lsmod
Module                  Size  Used by
kvm_intel             138528  0
kvm                   421021  1 kvm_intel
iTCO_wdt               13480  0
iTCO_vendor_support    13419  1 iTCO_wdt
snd_usb_audio         149112  2
snd_hda_codec_realtek  51465  1
snd_ice1712            75006  3
snd_hda_intel          44075  7
arc4                   12608  2
snd_cs8427             13978  1 snd_ice1712
snd_i2c                13828  2 snd_ice1712,snd_cs8427
snd_ice17xx_ak4xxx     13128  1 snd_ice1712
snd_ak4xxx_adda        18487  2 snd_ice1712,snd_ice17xx_ak4xxx
microcode              23527  0
snd_usbmidi_lib        24845  1 snd_usb_audio
gspca_pac7302          17481  0
gspca_main             36226  1 gspca_pac7302
videodev              132348  2 gspca_main,gspca_pac7302
rt61pci                32326  0
rt2x00pci              13083  1 rt61pci
media                  20840  1 videodev
rt2x00mmio             13322  1 rt61pci
hid_dr                 12776  0
snd_mpu401_uart        13992  1 snd_ice1712
rt2x00lib              67108  3 rt61pci,rt2x00pci,rt2x00mmio
snd_rawmidi            29394  2 snd_usbmidi_lib,snd_mpu401_uart

La sortie de la commande lsmod est divisée en trois colonnes :

Module: Le nom du module.
Size: La quantité de RAM occupée par le module, en octets.
Used by: Les modules dépendants.

Certains modules requièrent d’autres modules pour fonctionner correctement, comme c’est le cas pour les modules des périphériques audio :

$ lsmod | fgrep -i snd_hda_intel
snd_hda_intel          42658  5
snd_hda_codec         155748  3 snd_hda_codec_hdmi,snd_hda_codec_via,snd_hda_intel
snd_pcm                81999  3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
snd_page_alloc         13852  2 snd_pcm,snd_hda_intel
snd                    59132  19 snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_via,snd_pcm,snd_seq,snd_hda_codec,snd_hda_intel,snd_seq_device

La troisième colonne, Used by, indique les modules qui ont besoin du module figurant dans la première colonne pour fonctionner correctement. Beaucoup de modules de l’architecture audio de Linux, préfixés par snd, sont interdépendants. Lors de la recherche de problèmes pendant le diagnostic du système, il peut être utile de décharger certains modules spécifiques actuellement chargés. La commande modprobe peut être utilisée pour charger et décharger les modules du noyau : pour décharger un module et ses modules connexes tant qu’ils ne sont pas utilisés par un processus en cours, la commande modprobe -r doit être utilisée. Par exemple, pour décharger le module snd-hda-intel (le module pour un périphérique audio Intel HDA) et d’autres modules liés au système audio :

# modprobe -r snd-hda-intel

Outre le chargement et le déchargement des modules du noyau pendant le fonctionnement du système, il est possible de modifier les paramètres des modules lors du chargement du noyau, ce qui est comparable à la transmission d’options aux commandes. Chaque module accepte des paramètres spécifiques, mais la plupart du temps les valeurs par défaut sont recommandées et les paramètres supplémentaires ne sont pas nécessaires. Dans certains cas, il est toutefois nécessaire d’utiliser ces paramètres pour modifier le comportement d’un module de manière à ce qu’il fonctionne comme prévu.

En utilisant le nom du module comme seul argument, la commande modinfo affiche une description, le fichier, l’auteur, la licence, l’identification, les dépendances et les paramètres disponibles pour le module donné. Les paramètres personnalisés d’un module peuvent être rendus persistants en les incluant dans le fichier /etc/modprobe.conf ou dans des fichiers individuels avec l’extension .conf dans le répertoire /etc/modprobe.d/. L’option -p fera en sorte que la commande modinfo affiche tous les paramètres disponibles en ignorant les autres informations :

# modinfo -p nouveau
vram_pushbuf:Create DMA push buffers in VRAM (int)
tv_norm:Default TV norm.
                Supported: PAL, PAL-M, PAL-N, PAL-Nc, NTSC-M, NTSC-J,
                        hd480i, hd480p, hd576i, hd576p, hd720p, hd1080i.
                Default: PAL
                NOTE Ignored for cards with external TV encoders. (charp)
nofbaccel:Disable fbcon acceleration (int)
fbcon_bpp:fbcon bits-per-pixel (default: auto) (int)
mst:Enable DisplayPort multi-stream (default: enabled) (int)
tv_disable:Disable TV-out detection (int)
ignorelid:Ignore ACPI lid status (int)
duallink:Allow dual-link TMDS (default: enabled) (int)
hdmimhz:Force a maximum HDMI pixel clock (in MHz) (int)
config:option string to pass to driver core (charp)
debug:debug string to pass to driver core (charp)
noaccel:disable kernel/abi16 acceleration (int)
modeset:enable driver (default: auto, 0 = disabled, 1 = enabled, 2 = headless) (int)
atomic:Expose atomic ioctl (default: disabled) (int)
runpm:disable (0), force enable (1), optimus only default (-1) (int)

L’exemple ci-dessus affiche tous les paramètres disponibles pour le module nouveau, un module de noyau fourni par le projet Nouveau comme alternative aux pilotes propriétaires pour les cartes graphiques NVIDIA. L’option modeset, par exemple, permet de contrôler si la résolution et la profondeur d’affichage sont définies dans l’espace noyau plutôt que dans l’espace utilisateur. L’ajout de options nouveau modeset=0 au fichier /etc/modprobe.d/nouveau.conf désactivera la fonctionnalité modeset du noyau.

Lorsqu’un module pose problème, le fichier /etc/modprobe.d/blacklist.conf peut être utilisé pour bloquer le chargement du module. Par exemple, pour empêcher le chargement automatique du module nouveau, la ligne blacklist nouveau doit être ajoutée au fichier /etc/modprobe.d/blacklist.conf. Cette action est requise lorsque le module propriétaire nvidia est installé et que le module par défaut nouveau doit être ignoré.

Note

Rien ne vous empêche de modifier le fichier /etc/modprobe.d/blacklist.conf qui est déjà présent sur le système par défaut. Cependant, la méthode privilégiée consiste à créer un fichier de configuration séparé, /etc/modprobe.d/<nom_du_module>.conf, qui contiendra les paramètres spécifiques au module du noyau en question.

Fichiers d’informations et fichiers de périphériques

Les commandes lspci, lsusb et lsmod agissent comme des frontaux pour lire les informations relatives au matériel stockées par le système d’exploitation. Ce type d’information est conservé dans des fichiers spéciaux dans les répertoires /proc et /sys. Ces répertoires sont des points de montage vers des systèmes de fichiers non présents dans une partition de périphérique, mais uniquement dans l’espace RAM utilisé par le noyau pour stocker la configuration d’exécution et les informations sur les processus en cours. Ces systèmes de fichiers ne sont pas destinés au stockage conventionnel de fichiers, ils sont donc appelés pseudo-systèmes de fichiers et n’existent que lorsque le système est en cours d’exécution. Le répertoire /proc contient des fichiers avec des informations concernant les processus en cours et les ressources hardware. Parmi les fichiers importants dans /proc pour l’inspection du matériel, on trouve :

/proc/cpuinfo: Liste des informations détaillées sur le(s) processeur(s) trouvé(s) par le système d’exploitation.
/proc/interrupts: Une liste des numéros des interruptions par dispositif d’entrée/sortie pour chaque CPU.
/proc/ioports: Liste les plages de ports d’entrée/sortie actuellement enregistrées et utilisées.
/proc/dma: Liste les canaux DMA (accès direct à la mémoire) enregistrés en cours d’utilisation.

Les fichiers du répertoire /sys ont un rôle similaire à ceux du répertoire /proc. Cependant, le répertoire /sys a pour vocation spécifique de stocker les informations sur les périphériques et les données du noyau relatives au hardware, tandis que /proc contient également des informations sur les différentes structures de données du noyau, y compris les processus en cours d’exécution et la configuration.

Un autre répertoire directement lié aux périphériques dans un système Linux standard est /dev. Chaque fichier à l’intérieur de /dev est associé à un périphérique système, en particulier les périphériques de stockage. Un ancien disque dur IDE, par exemple, lorsqu’il est connecté au premier canal IDE de la carte mère, sera représenté par le fichier /dev/hda. Chaque partition de ce disque sera identifiée par /dev/hda1, /dev/hda2 jusqu’à la dernière partition trouvée.

Les périphériques amovibles sont gérés par le sous-système udev, qui crée les périphériques correspondants dans /dev. Le noyau Linux capture l’événement de détection du hardware et le transmet au processus udev, qui identifie alors le périphérique et crée dynamiquement les fichiers correspondants dans /dev, en utilisant un jeu de règles prédéfinies.

Dans les distributions Linux actuelles, udev se charge de l’identification et de la configuration des périphériques déjà présents lors de la mise sous tension de la machine (détection coldplug) et des périphériques identifiés lorsque le système est en cours d’exécution (détection hotplug). Udev s’appuie sur SysFS, le pseudo-système de fichiers pour les informations relatives au hardware monté dans /sys.

Note

Hotplug est le terme utilisé pour désigner la détection et la configuration d’un périphérique lorsque le système est en cours d’exécution, par exemple lorsqu’un périphérique USB est inséré. Le noyau Linux supporte les fonctionnalités hotplug depuis la version 2.6, permettant à la plupart des bus système (PCI, USB, etc.) de déclencher des événements hotplug lorsqu’un périphérique est connecté ou déconnecté.

Au fur et à mesure que de nouveaux périphériques sont détectés, udev recherche une règle correspondante dans les règles prédéfinies stockées dans le répertoire /etc/udev/rules.d/. Les règles les plus importantes sont fournies par la distribution, mais de nouvelles règles peuvent être ajoutées pour des cas de figure spécifiques.

Périphériques de stockage

Sous Linux, les périphériques de stockage sont appelés périphériques bloc de manière générique, étant donné que les données de ces périphériques sont lues et écrites en blocs de données bufferisées de tailles et de positions différentes. Chaque périphérique bloc est identifié par un fichier dans le répertoire /dev, le nom du fichier dépendant du type de périphérique (IDE, SATA, SCSI, etc.) et de ses partitions. Les lecteurs CD/DVD et les disquettes floppy, par exemple, auront leur nom attribué en conséquence dans /dev : un lecteur CD/DVD connecté au second canal IDE sera identifié comme /dev/hdc (/dev/hda et /dev/hdb sont réservés aux périphériques maître et esclave sur le premier canal IDE) et un ancien lecteur de disquettes floppy sera identifié comme /dev/fdO, /dev/fd1, etc.

À partir de la version 2.4 du noyau Linux, la plupart des périphériques de stockage sont désormais identifiés comme s’il s’agissait de périphériques SCSI, quel que soit leur type de matériel. Les périphériques bloc IDE, SSD et USB seront préfixés par sd. Pour les disques IDE, le préfixe sd sera utilisé, mais la troisième lettre sera choisie selon que le lecteur est un maître ou un esclave (dans le premier canal IDE, le maître sera sda et l’esclave sera sdb). Les partitions sont listées par ordre numérique. Les chemins /dev/sda1, /dev/sda2, etc. sont utilisés pour la première et la deuxième partition du périphérique bloc identifié en premier et /dev/sdb1, /dev/sdb2, etc. sont utilisés pour identifier la première et la deuxième partition du périphérique bloc identifié en second. L’exception à ce schéma intervient avec les cartes mémoire (cartes SD) et les périphériques NVMe (SSD connectés au bus PCI Express). Pour les cartes SD, les chemins /dev/mmcblk0p1, /dev/mmcblk0p2, etc. sont utilisés pour la première et la deuxième partition du périphérique identifié en premier et /dev/mmcblk1p1, /dev/mmcblk1p2, etc. sont utilisés pour identifier la première et la deuxième partition du périphérique identifié en second. Les périphériques NVMe reçoivent le préfixe nvme, comme dans /dev/nvme0n1p1 et /dev/nvme0n1p2.

Exercices guidés

Admettons qu’un système d’exploitation soit incapable de démarrer après l’ajout d’un deuxième disque SATA au système. Sachant que tous les composants ne sont pas défectueux, quelle pourrait être la cause possible de cette défaillance ?
Imaginons que vous vouliez vous assurer que la carte graphique externe connectée au bus PCI de votre nouvel ordinateur de bureau est bien celle annoncée par le fabricant, mais l’ouverture du boîtier du PC annulera la garantie. Quelle commande pourrait être utilisée pour lister les détails de la carte graphique tels qu’ils ont été détectés par le système d’exploitation ?
La ligne suivante est un extrait de la sortie générée par la commande lspci :
```
03:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 2208 [Thunderbolt] (rev 05)
```
Quelle commande devez-vous exécuter pour identifier le module du noyau utilisé pour ce périphérique spécifique ?
Un administrateur système veut essayer différents paramètres pour le module de noyau bluetooth sans redémarrer le système. Cependant, toute tentative de déchargement du module avec modprobe -r bluetooth entraîne l’erreur suivante :
```
modprobe: FATAL: Module bluetooth is in use.
```
Quelle est la cause possible de cette erreur ?

Exercices d’approfondissement

Il n’est pas rare de tomber sur des machines anciennes dans des environnements de production, comme certains équipements qui utilisent une connectique obsolète pour communiquer avec l’ordinateur de contrôle, d’où la nécessité d’accorder une attention particulière à certaines particularités de ces machines anciennes. Certains serveurs x86 avec un ancien firmware BIOS, par exemple, ne démarreront pas si le clavier n’est pas détecté. Comment éviter ce problème particulier ?
Les systèmes d’exploitation construits autour du noyau Linux sont également disponibles pour une grande variété d’architectures informatiques autres que x86, comme dans les ordinateurs monocartes basés sur l’architecture ARM. Un utilisateur attentif remarquera l’absence de la commande lspci sur de telles machines, comme le Raspberry Pi. Quelle différence avec les machines x86 justifie cette absence ?
De nombreux routeurs disposent d’un port USB permettant la connexion d’un périphérique externe, comme un disque dur USB. Comme la plupart d’entre eux utilisent un système d’exploitation basé sur Linux, comment un disque dur USB externe sera-t-il nommé dans le répertoire /dev/, en supposant qu’aucun autre périphérique bloc conventionnel ne soit présent dans le routeur ?
En 2018, la vulnérabilité matérielle connue sous le nom de Meltdown a été découverte. Elle concerne presque tous les processeurs des différentes architectures. Les versions récentes du noyau Linux peuvent indiquer si le système actuel est vulnérable. Comment obtenir ces informations ?

Résumé

Cette leçon couvre les concepts fondamentaux sur la manière dont le noyau Linux gère les ressources matérielles, notamment dans l’architecture x86. La leçon aborde les sujets suivants :

Comment les paramètres définis dans les utilitaires de configuration BIOS ou UEFI peuvent affecter la manière dont le système d’exploitation interagit avec le matériel.
Comment utiliser les outils fournis par un système Linux standard pour obtenir des informations sur le hardware.
Comment identifier les périphériques de stockage fixes et amovibles dans le système de fichiers.

Voici les procédures et les commandes abordées :

Commandes pour inspecter le matériel détecté : lspci et lsusb.
Commandes pour gérer les modules du noyau : lsmod et modprobe.
Fichiers spéciaux liés au matériel, soit les fichiers trouvés dans le répertoire /dev/ ou dans les pseudo-systèmes de fichiers dans /proc/ et /sys/.

Réponses aux exercices guidés

Admettons qu’un système d’exploitation soit incapable de démarrer après l’ajout d’un deuxième disque SATA au système. Sachant que tous les composants ne sont pas défectueux, quelle pourrait être la cause possible de cette défaillance ?

L’ordre des périphériques d’amorçage doit être configuré dans l’utilitaire de configuration BIOS, faute de quoi le BIOS risque de ne pas pouvoir exécuter le chargeur de démarrage.
Imaginons que vous vouliez vous assurer que la carte graphique externe connectée au bus PCI de votre nouvel ordinateur de bureau est bien celle annoncée par le fabricant, mais l’ouverture du boîtier du PC annulera la garantie. Quelle commande pourrait être utilisée pour lister les détails de la carte graphique tels qu’ils ont été détectés par le système d’exploitation ?

La commande lspci fournira des informations détaillées sur tous les périphériques actuellement connectés au bus PCI.
La ligne suivante est un extrait de la sortie générée par la commande lspci :
```
03:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 2208 [Thunderbolt] (rev 05)
```
Quelle commande devez-vous exécuter pour identifier le module du noyau utilisé pour ce périphérique spécifique ?

La commande lspci -s 03:00.0 -v ou lspci -s 03:00.0 -k
Un administrateur système veut essayer différents paramètres pour le module de noyau bluetooth sans redémarrer le système. Cependant, toute tentative de déchargement du module avec modprobe -r bluetooth entraîne l’erreur suivante :
```
modprobe: FATAL: Module bluetooth is in use.
```
Quelle est la cause possible de cette erreur ?

Le module bluetooth est utilisé par un processus en cours.

Réponses aux exercices d’approfondissement

Il n’est pas rare de tomber sur des machines anciennes dans des environnements de production, comme certains équipements qui utilisent une connectique obsolète pour communiquer avec l’ordinateur de contrôle, d’où la nécessité d’accorder une attention particulière à certaines particularités de ces machines anciennes. Certains serveurs x86 avec un ancien firmware BIOS, par exemple, ne démarreront pas si le clavier n’est pas détecté. Comment éviter ce problème particulier ?

L’utilitaire de configuration BIOS permet de désactiver le verrouillage de l’ordinateur en cas d’absence de clavier.
Les systèmes d’exploitation construits autour du noyau Linux sont également disponibles pour une grande variété d’architectures informatiques autres que x86, comme dans les ordinateurs monocartes basés sur l’architecture ARM. Un utilisateur attentif remarquera l’absence de la commande lspci sur de telles machines, comme le Raspberry Pi. Quelle différence avec les machines x86 justifie cette absence ?

Contrairement à la plupart des machines x86, un ordinateur basé sur ARM comme le Raspberry Pi n’a pas de bus PCI, de sorte que la commande lspci ne sert à rien.
De nombreux routeurs disposent d’un port USB permettant la connexion d’un périphérique externe, comme un disque dur USB. Comme la plupart d’entre eux utilisent un système d’exploitation basé sur Linux, comment un disque dur USB externe sera-t-il nommé dans le répertoire /dev/, en supposant qu’aucun autre périphérique bloc conventionnel ne soit présent dans le routeur ?

Les noyaux Linux modernes identifient les disques durs USB comme des périphériques SATA, le fichier correspondant sera donc /dev/sda puisqu’il n’existe aucun autre périphérique bloc conventionnel dans le système.
En 2018, la vulnérabilité matérielle connue sous le nom de Meltdown a été découverte. Elle concerne presque tous les processeurs des différentes architectures. Les versions récentes du noyau Linux peuvent indiquer si le système actuel est vulnérable. Comment obtenir ces informations ?

Le fichier /proc/cpuinfo a une ligne qui affiche les bugs connus pour le CPU en question, comme bugs : cpu_meltdown.