Le guide de dépannage original est précieux parce qu’il commence sous l’interface de CasaOS. Lorsqu’un disque, une carte réseau, une carte PCIe ou un périphérique USB se comporte de manière étrange, la première question est de savoir si le système Linux sous-jacent détecte réellement le matériel.
La limite importante en 2026 concerne l’architecture du système d’exploitation. Le guide de 2023 suppose que CasaOS fonctionne sur une installation Linux classique de type Debian/Ubuntu. Les commandes de diagnostic en lecture seule restent utiles, mais les instructions d’installation de paquets et de modification de l’hôte provenant des guides Debian classiques ne doivent pas être appliquées à ZimaOS.
Utiliser dmidecode pour obtenir des informations sur le BIOS et la carte
dmidecode lit les données SMBIOS/DMI telles que :
- fabricant et version du BIOS ;
- date de publication ;
- identifiants du système/de la carte ;
- informations sur la mémoire ;
- capacités du micrologiciel telles que l’UEFI.
Cela est utile pour comparer un problème propre au matériel avec une mise à jour du BIOS ou pour confirmer exactement quelle révision de carte est utilisée.
Utiliser lspci pour confirmer l’énumération du matériel PCIe
lspci répertorie les périphériques vus par le sous-système PCI : GPU, contrôleurs SATA, adaptateurs NVMe, cartes réseau, cartes d’acquisition et autres matériels d’extension.
Si une nouvelle carte réseau PCIe n’apparaît jamais dans lspci, le problème se situe en dessous de Docker/CasaOS. Vérifiez le branchement, l’alimentation, les paramètres du micrologiciel, le partage des lignes et la compatibilité matérielle avant d’installer des logiciels applicatifs.
Utiliser lsusb pour identifier les périphériques USB
lsusb signale les identifiants de fabricant et de produit USB. Ces identifiants sont particulièrement utiles pour diagnostiquer les adaptateurs Wi-Fi, les dispositifs Coral TPU, les ponts de stockage USB, les coordinateurs Zigbee et autres périphériques susceptibles d’exister en plusieurs révisions matérielles sous un même nom commercial.
Utiliser dmesg pour les messages des pilotes et du matériel au démarrage
dmesg peut afficher :
- liaison des pilotes du noyau ;
- échecs de chargement du micrologiciel ;
- événements de déconnexion/reconnexion USB ;
- erreurs d’E/S du stockage ;
- changements de liaison du contrôleur réseau ;
- erreurs PCIe/AER.
Filtrez ou capturez uniquement les sections pertinentes au lieu de publier des milliers de lignes de démarrage sans rapport.
Utiliser lsblk pour distinguer « disque non détecté » de « disque non monté »
lsblk affiche les disques, les partitions, les relations entre les systèmes de fichiers et les points de montage. Un disque présent dans lsblk mais son absence de l’interface Fichiers de CasaOS correspond à un problème différent d’un disque totalement absent de Linux.
Privilégier la découverte en lecture seule avant les commandes de réparation
La partie 1 originale est particulièrement pertinente lorsqu’elle apprend à observer. Des commandes telles que dmidecode, lspci, lsusb, dmesg, et lsblk peut permettre d’identifier la couche problématique sans modifier le stockage ni les paquets.
Faites-le avant de reformater des disques, de réinstaller des pilotes, de modifier récursivement les propriétaires ou de reconstruire Docker.
CasaOS et ZimaOS nécessitent des règles différentes pour modifier l’hôte
CasaOS s’exécute généralement sur un hôte Linux généraliste où apt peut être disponible. ZimaOS est basé sur Buildroot et les recommandations actuelles de la CLI IceWhale indiquent que la plupart des dossiers système restent en lecture seule, même en tant que root.
Utilisez les limites actuelles de la CLI ZimaOS lorsque le même matériel exécute ZimaOS.
Diagnostiquer du matériel vers les couches supérieures
Un ordre utile est le suivant :
- le BIOS ou le micrologiciel détecte le matériel ;
- l’énumération du bus Linux le détecte ;
- un pilote du noyau s’attache ;
- le système d’exploitation crée une interface ou un périphérique bloc utilisable ;
- CasaOS/ZimaOS l’affiche dans l’interface utilisateur ;
- Les applications Docker reçoivent l’appareil ou le chemin.
Passer directement à la sixième couche donne souvent l’impression que les problèmes matériels sont des bugs d’application.
Utilisez blkid pour identifier le type de système de fichiers et l’UUID
La première partie de la source utilise également blkid après lsblk. Cela répond à une autre question : quelle signature de système de fichiers ou de membre LVM la partition contient-elle réellement, et quels UUID/PARTUUID l’identifient ?
Cela est utile lorsqu’un disque apparaît sous Linux, mais qu’un gestionnaire de montage ou de stockage ne reconnaît pas le système de fichiers attendu. Enregistrez la sortie avant de reformater quoi que ce soit.
Enregistrez les informations matérielles avant de modifier les pilotes ou le stockage
Pour un rapport d’assistance reproductible, recueillez la sortie des commandes pertinentes avec :
- modèle de la carte et version du BIOS ;
- version du système d’exploitation ;
- modèle de l’appareil et identifiant PCI/USB ;
- ce qui a changé immédiatement avant l’apparition du problème ;
- si le matériel apparaît dans le BIOS, Linux et l’interface utilisateur de CasaOS/ZimaOS.
Cela permet de distinguer un pilote manquant d’un câble défectueux, d’un système de fichiers non pris en charge ou d’un problème de mappage de conteneur.
FAQ sur le dépannage du matériel Linux
Que dois-je exécuter en premier pour une carte PCIe inconnue ?
lspci est la vérification en lecture seule la plus rapide pour confirmer que le sous-système PCI le détecte.
Quelle commande est la plus utile pour les identifiants de fournisseur et de produit USB ?
lsusb.
Puis-je appliquer à ZimaOS les hypothèses du guide concernant les paquets Debian ?
Non. Conservez les concepts de diagnostic, mais suivez les règles d’extension et de pilotes propres à ZimaOS.
