Si les deux emplacements de démarrage de ZimaOS échouent et que la console signale des erreurs de montage overlay, des échecs de lecture du superbloc ou des erreurs d’E/S NVMe, ne commencez pas par reconstruire le pool de stockage. Déterminez d’abord si le problème vient du périphérique de démarrage ou des disques de données séparés.
Dans ce cas de juin 2026, les diagnostics en lecture seule ont révélé des erreurs de support répétées sur le NVMe de démarrage, tandis que le grand pool de données Btrfs se trouvait sur des disques distincts. L’utilisateur a remplacé le disque de démarrage, réinstallé ZimaOS, puis confirmé que le pool de données était toujours présent.
Séparez d’abord le périphérique de démarrage du pool de données
La sortie du shell de secours dans le fil de discussion indiquait un NVMe d’environ 119 Go contenant les partitions de démarrage et de données de ZimaOS, ainsi qu’un pool Btrfs distinct composé de plusieurs disques. Cette distinction a modifié le plan de récupération : la défaillance du NVMe de démarrage n’impliquait pas automatiquement celle du pool de stockage.
Commencez par des commandes en lecture seule :
lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
blkid
cat /proc/cmdlineNotez précisément les noms des périphériques avant d’exécuter une commande ciblant un disque ou une partition.
Vérifiez les journaux du noyau pour détecter de vraies erreurs d’E/S
Le cas d’origine comportait des messages répétés critical medium error, Buffer I/O error, des échecs de montage EXT4 et des erreurs NVMe concernant le périphérique de démarrage. Ces messages constituent des preuves bien plus solides d’une défaillance du stockage qu’un simple kernel panic affiché au démarrage.
dmesg -T | grep -Ei 'nvme|I/O error|Buffer I/O|EXT4|superblock|reset|timeout|critical|media'Si les erreurs concernent systématiquement le NVMe de démarrage tandis qu’aucune défaillance n’est signalée sur les disques de données, concentrez l’investigation sur le chemin de démarrage.
Un résultat SMART « PASSED » n’annule pas les erreurs de support
Dans le fil de discussion, le résumé de santé SMART du NVMe indiquait toujours PASSED, alors que les compteurs détaillés montraient 76 erreurs de support et d’intégrité des données, et que le noyau enregistrait déjà des échecs de lecture. La vérification du système de fichiers en lecture seule s’était également interrompue sur des blocs illisibles.
Utilisez des données de santé détaillées telles que smartctl -x /dev/nvmeXn1 ou nvme smart-log /dev/nvmeXn1 après avoir confirmé le nom correct du périphérique. Ne considérez pas le seul état de santé global comme un diagnostic complet.
Commencez par des vérifications du système de fichiers en lecture seule
La communauté a utilisé e2fsck -fn sur la partition overlay EXT4 concernée afin d’inspecter le système de fichiers sans écrire de réparations. Même cette vérification en lecture seule a rencontré des blocs illisibles, ce qui a renforcé le diagnostic de défaillance matérielle.
N’exécutez jamais fsck en mode écriture sur un système de fichiers monté et ne devinez pas les noms des partitions. Si le SSD de démarrage est physiquement défaillant, des tentatives d’écriture répétées peuvent compliquer la récupération.
Pourquoi les emplacements A et B peuvent tous deux échouer
ZimaOS utilise des emplacements système A/B pour la récupération, comme indiqué dans le guide de récupération système de ZimaOS. Cependant, les deux options de démarrage dépendent toujours de composants de stockage partagés en bon état sur le périphérique de démarrage. Un overlay ou un NVMe de démarrage défaillant peut donc empêcher les deux emplacements de terminer le démarrage.
Quand le remplacement est la solution la plus sûre
Une fois que le cas d’origine a révélé des erreurs de support dans le noyau, des compteurs détaillés d’erreurs de support SMART et des blocs illisibles dans le système de fichiers du NVMe de démarrage, la communauté a conseillé de considérer ce SSD comme non fiable plutôt que d’essayer de le réparer sur place. L’utilisateur l’a remplacé et a réinstallé ZimaOS avec succès.
Pendant la réinstallation, identifiez clairement les disques de données et évitez d’initialiser ou de recréer un pool existant. Le guide de dépannage de l’installation de ZimaOS vous aide pour l’installation sur le périphérique de démarrage, tandis que le guide de récupération du stockage après réinstallation rappelle la règle essentielle : ne recréez pas un pool qui contient déjà vos données.
En résumé
Dans ce cas, le kernel panic était dû à une défaillance du NVMe de démarrage et ne prouvait pas que le pool de données distinct avait été détruit. Effectuez les diagnostics en lecture seule, confirmez quel périphérique présente les erreurs d’E/S et laissez les disques de données intacts. L’utilisateur d’origine a remplacé le disque de démarrage défaillant, réinstallé ZimaOS et confirmé que le pool de données existant avait survécu.
