13.3. Cibles kdump prises en charge
Lorsqu'un crash du noyau est capturé, le fichier dump vmcore peut être écrit directement sur un périphérique, stocké en tant que fichier sur un système de fichiers local ou envoyé sur un réseau. Le tableau ci-dessous contient une liste complète des cibles de vidage qui sont actuellement prises en charge ou explicitement non prises en charge par kdump.
| Type | Objectifs soutenus | Cibles non soutenues |
|---|---|---|
| Dispositif brut | Tous les disques et partitions bruts attachés localement. | |
| Système de fichiers local |
|
Tout système de fichiers local non explicitement répertorié comme pris en charge dans ce tableau, y compris le type |
| Répertoire distant |
Les répertoires distants auxquels on accède en utilisant le protocole |
Répertoires distants du système de fichiers |
|
Accès à des répertoires distants à l'aide du protocole |
Répertoires distants accessibles à l'aide du protocole | Stockages basés sur des chemins multiples. |
|
Accès aux répertoires distants via | ||
|
Répertoires distants auxquels on accède en utilisant le protocole | ||
|
Répertoires distants auxquels on accède en utilisant le protocole | ||
| Répertoires distants accessibles à l'aide d'interfaces de réseau sans fil. | ||
L'utilisation du dump assisté par le micrologiciel (fadump) pour capturer un vmcore et le stocker sur une machine distante à l'aide du protocole SSH ou NFS entraîne le renommage de l'interface réseau en kdump-<interface-name>. Le renommage se produit si le <interface-name> est générique, par exemple *eth#, net#, et ainsi de suite. Ce problème survient parce que les scripts de capture vmcore dans le disque RAM initial (initrd) ajoutent le préfixe kdump- au nom de l'interface réseau pour garantir un nommage persistant. Comme le même initrd est également utilisé pour un démarrage normal, le nom de l'interface est également modifié pour le noyau de production.
