Réparer le système de fichier ext4 de votre Raspberry Pi

Cet article parle d’un problème tout frais dans ma tête puisqu’il se base sur mon expérience du week-end dernier. Je vais vous expliquer ici comment réparer vos systèmes de fichiers ext4. En effet, il arrive que votre OS ou votre Raspberry commence à faire n’importe quoi avec votre système de fichiers et qu’il casse tout. Imaginez un arrêt brutal de votre Raspberry pendant qu’il était en train de modifier des fichiers système importants. Il y a des chances que celui-ci ne redémarre jamais.

Heureusement, il existe des outils puissants pour réparer tout ça, ou qui vont au moins vous permettre de récupérer ses données.

Ce tutoriel, bien qu’expliqué en détail, s’adresse aux personnes ayant un minimum de connaissance avec Linux et son terminal. Cependant, si je ne suis pas assez clair sur certains points n’hésitez pas à me poser des questions via les commentaires.

Votre Raspberry ne démarre plus ? C’est peut-être le système de fichiers.

Je vous explique rapidement pourquoi je fais cet article : ce week-end j’ai eu la chance de me battre pendant de longues heures avec mon Raspberry Pi 3 défectueux (bataille que j’ai fini par perdre, mais au moins j’ai récupéré mes données).

Je vous restitue un peu le contexte rapidement. Vendredi soir, je travaille sur DaDaRevue pour l’intégration des réseaux sociaux. D’ailleurs, petite parenthèse : vous pouvez maintenant facilement partager mes articles ou même me rejoindre sur ma page Facebook, sur twitter ou encore vous inscrire à mon flux RSS, fin de la parenthèse.
Et voilà que, soudainement, nginx (mon serveur web), me sors une erreur 503 – service indisponible => mon blog était donc inaccessible et en plus de ça je n’avais pas d’accès physique à mon Raspberry Pi.

Pas de soucis, je me connecte en SSH et je relance tout ça. Et là à ma grande stupeur, plus de réponses, ni au SSH ni même au ping. Non seulement mon blog était inaccessible, mais mon Raspberry aussi… Quelque chose cloche, je commence à me dire qu’il doit y avoir un problème un peu plus grave qu’un simple service qui a planté.

Une fois rentré chez moi samedi, je décide de débrancher et rebrancher mon Raspberry (sans me dire que j’aurais peut-être dû brancher un écran avant pour regarder ce qui clochait, parfois on peut être très bête) et là je découvre que mon Raspberry ne veut plus démarrer.

C’est alors que je branche mon écran et que j’aperçois un gros pâté d’insultes du type :

EXT4-fs error (device mmcblk0): ext4_lookup: deleted inode referenced

Je me suis donc dit « hum ça pue cette histoire ». J’ai alors compris que le problème venait de mon système de fichiers qui était totalement corrompu (et quand je dis totalement ce n’est pas un euphémisme, il n’y avait vraiment plus rien de lisible). En réalité mon Raspberry était défectueux et plus particulièrement une soudure du slot SD, résultat j’ai eu une corruption irrécupérable. Mais nous aurons l’occasion de reparler de ça dans un autre article.

J’ai donc passé un certain temps à tenter tout ce que j’ai peu et malgré la perte de quelques images, j’ai pu sauver plus de 99% des fichiers de ma carte SD.

Si dans votre cas la corruption n’est pas aussi grave qu’elle l’était pour moi (si elle est juste logicielle et non matérielle), vous avez de très grandes chances de pouvoir redémarrer sur votre système après cette petite opération de maintenance.

Sauvegarde de la carte SD

La première étape dans ce genre de cas consiste à copier sa carte SD avant de tenter quoi que ce soit. Le but étant d’avoir une copie brute de la carte SD sur laquelle travailler plutôt que de travailler sur la carte directement et de risquer de totalement perdre ses données.

Si vous avez déjà lu mon article sur comment créer une copie de la carte SD de son Raspberry Pi, il est possible que cette première partie vous soit très familière (c’est quasiment la même chose). Auquel cas je vous invite à passer directement à la seconde partie de l’article qui concerne la réparation du système de fichiers.

Pour ce genre de travail on va utiliser Linux car il pourra copier la carte, mais aussi réparer le système de fichier de la carte SD. Dans mon cas je n’avais pas d’ordinateur avec Linux sous la main donc j’ai téléchargé Ubuntu et j’ai créé une clé USB bootable grâce à l’utilitaire Linux Live USB Creator.

dd : l’utilitaire Linux parfait pour ce travail

Pour copier notre carte SD nous allons utiliser l’utilitaire dd de Linux (ne me demandez pas ce que dd signifie, j’ai cherché et il ne semble pas y avoir de réponse définitive à la question).

Petite mise en garde : dd est un des utilitaires Linux les plus puissants, mais aussi l’un des plus dangereux. Une simple erreur et vous pourriez effacer votre carte SD ou votre disque dure à jamais et sans sommation. Je vous conseille donc de lire avec attention les instructions et de faire attention à bien lancer les commandes. Dans le cas contraire, au lieu de faire une copie de votre carte SD, vous pourriez très facilement l’effacer intégralement.

Parmi les tâches les plus courantes pour dd on trouve :

  • Copie brute (par bit ou par bloc) d’une partition ou d’un disque complet vers une autre
  • Création de fichiers uniquement composés de zéros (parfait pour des tests de vitesse d’écriture sur un support)

Dans notre cas nous allons faire une copie bit à bit de notre carte SD. C’est bien plus bas niveau qu’une simple copie de fichiers. dd ne prends pas en compte le système de fichier, il se contente de copier « bêtement » les bits de votre carte SD, vous donnant la chance d’obtenir une copie parfaite de la carte SD. Ce qu’il faut bien comprendre c’est que, si vos fichiers sont corrompus au départ sur votre carte SD, ils le seront exactement de la même manière à l’arrivée.

C’est ce qu’on va appeler une copie physique du support, car elle va respecter au maximum l’arrangement physique des bits du support d’origine contrairement à une copie logicielle qui elle va chercher à copier des fichiers.

Copie physique de la carte SD

Comme expliqué au-dessus nous allons donc utiliser dd pour faire une copie physique de la carte SD ou une image si vous préférez.

Pour cela il faudra trouver le « device » Linux auquel votre carte SD est accrochée.

Après avoir inséré la carte SD, vous devriez voir deux partitions se monter : une pour le boot de votre Raspberry et l’autre pour le système et vos données. N’essayez SURTOUT PAS d’accéder à vos données, si votre système de fichier est corrompu vous pourriez aggraver les choses (surtout si vous faites l’opération avec un disque dure mécanique).

Nous allons donc chercher où se trouve notre carte SD à l’aide de la commande suivante dans un terminal :

 df -h

Dans la réponse de la commande vous devriez avoir deux lignes avec un device du genre mmcblk comme ci-dessous :

/dev/mmcblk0p1   3.8G   0M   3.8G  0% /media/ubuntu/38954165-875496

À gauche, le device attaché à votre carte SD, à savoir /dev/mmcblk0 (on va retirer le p1 qui correspond à la partition sur la carte SD) et tout à droite on trouve le point de montage de votre partition.

Maintenant, il faut démonter les deux partitions afin de pouvoir faire la copie sans problème. On va utiliser la commande umount avec comme argument le point de montage de vos partitions :

umount /media/ubuntu/38954165-875496

Voilà, maintenant nous sommes prêt à faire la fameuse commande dd. Si vous êtes curieux et que vous voulez vérifier que nous n’allons pas faire de bêtise, je vous invite à regarder le manuel de dd.

L’utilisation basique de dd est la suivante :

dd if=chemin_vers_ce_que_vous_voulez_copier of=chemin_vers_la_destination_de_la_copie

Dans mon cas j’ai copié ma carte SD dans un disque USB monté sur /media/ubuntu/2596542-8653 dans le répertoire sauvegarde_sd. Voilà ce que donne la commande finale :

dd if=/dev/mmcblk0 of=/media/ubuntu/2596542-8653/sauvegarde_sd/ma_copie.img status=progress

Après quelques minutes, votre carte SD devrait être totalement copiée. Je vous conseille maintenant de faire un double de cette image.

Monter la copie de la carte SD

Avant de réparer le système de fichier, on va monter l’image, tester la réparation et récupérer ce qu’on peut.

Tout d’abord, il faut savoir sur l’image où commence chaque partition ou, si vous préférez, sur quel octet de l’image la partition 1 commence et pareil pour la partition 2.

Pour connaitre ce fameux octet, il faut regarder la structure de votre image en lançant la commande suivante :

fdisk -l ma_copie.img

La réponse devrait ressembler à ça :

Device         Boot     Start       End  Blocks  Id System
ma_copie.img1            8192    122879   57344   c W95 FAT32 (LBA)
ma_copie.img2          122880   5785599 2831360  83 Linux

Voilà, on a nos deux partitions. La première commence au secteur 8192 et la seconde au secteur 122880. Maintenant, il faut exprimer cela en octet. Le calcul est simple, car les secteurs sont composés chacun de 512 octets.

On fait donc la multiplication du secteur de départ par 512. Notre première partition commence donc à l’octet 4194304 (512*8192) et la seconde débute à l’octet 62914560 (122880*512).

Maintenant, on a plus qu’à utiliser la commande losetup pour accrocher nos partitions à /dev/loop0 et /dev/loop1 en donnant l’octet de départ de chaque partition via l’option –offset:

 losetup –offset 4194304 /dev/loop0 ma_copie.img

losetup –offset 62914560 /dev/loop1 ma_copie.img

Maintenant, si vous créez un dossier pour chaque partition, par exemple :

mkdir /media/ubuntu/partition1

mkdir /media/ubuntu/partition2

Vous pouvez monter vos deux partitions :

mount   /dev/loop0   /media/ubuntu/partition1

mount   /dev/loop1   /media/ubuntu/partition2

Vos deux partitions sont bien montées et vous devriez pouvoir y accéder. Je vous invite à aller jeter un coup d’œil à vos fichiers dans la seconde partition par curiosité. Il y a de grandes chances que ceux-ci soient corrompus et illisibles, mais ne vous inquiétez pas : nous allons essayer de réparer ça et au pire des cas, de récupérer un maximum de fichiers.

Réparer le système de fichiers

Maintenant que nous avons une copie pour travailler, nous allons pouvoir réparer nos deux partitions. Pour ça on va avoir besoin que les partitions ne soient pas montées :

umount /media/ubuntu/partition1

umount /media/ubuntu/partition2

Fsck : l’utilitaire Linux pour réparer une partition

Si vous avez déjà eu des problèmes de partitions sous Linux, vous avez nécessairement déjà entendu parler des utilitaires du type fsck (pour file system check).

Fsck est donc un utilitaire qui va vérifier votre système de fichier pour voir s’il y trouve des erreurs et les réparer.

Il faut savoir que pour chaque système de fichier le fsck est différent et que certains vont être bien plus efficaces que d’autres. Par exemple, pour le ext4 il sera particulièrement puissant (ça tombe bien c’est la partition où il y a votre OS et vos données).

Réparer la partition ext4

Comme je l’ai expliqué, nous allons utiliser fsck qui est particulièrement efficace sur les partitions de type ext4 (la seconde partition dans notre cas).

Revenons à notre système de fichier. Pour votre culture personnelle, sachez que ext4 est un système de fichier dit journalisé, c’est à dire qu’il va avoir un journal qui va enregistrer les opérations en cours. D’après Wikipédia : « le journal est la partie d’un système de fichiers journalisé qui trace les opérations d’écriture tant qu’elles ne sont pas terminées, et cela en vue de garantir l’intégrité des données en cas d’arrêt brutal. » Je n’aurais pas pu mieux l’expliquer.

Vous comprenez maintenant pourquoi l’outil de réparation des systèmes de fichiers fsck est plus efficace sur ext4 que sur d’autres systèmes de fichiers comme fat32 par exemple qui n’est pas journalisé. Ici tant que le journal est intact, il y a de grandes chances pour que le système de fichiers puisse être réparé et même dans le cas où le journal est défectueux, il n’est pas impossible de le réparer lui aussi. Bref, fsck fait des miracles sur l’ext4.

Fini la théorie, passons à la pratique. Commençons par la plus simple vérification du système de fichier pour voir s’il est bel et bien défectueux et facilement réparable:

fsck.ext4 -pvf -C0 /dev/loop1

Les options :

  • -p demande à fsck de vérifier l’intégrité du système de fichier et de réparer de manière automatique ce qui peut être réparé sans risque
  • -v est l’option dite « verbose » qui va donner un maximum d’information sur ce qu’il se passe, c’est pratique pour se faire une idée de l’étendu des dégâts
  • -f force la vérification même si fsck considère qu’il n’y a pas de problème
  • -C0 permet de vous donnez une indication sur la progression (cette option est assez nouvelle, donc ne vous inquiétez pas si votre OS ne la reconnait pas).

Si, à la fin de l’opération fsck vous dit que le système de fichiers à changé et que tout a été réparé alors vous êtes chanceux et vous pouvez faire la même opération sur votre carte SD.
Si au contraire comme moi la réparation automatique de fsck n’a pas suffit et qu’il vous répond qu’il nécessite l’intervention d’un humain, vous pouvez alors tenter la version « brutale » (n’oubliez pas que vous travaillez sur une copie). Je précise que même la méthode « brutale » ne devrait normalement pas empirer les choses.

fsck.ext4 -cDyvf -C0 /dev/loop1

Les options :

  • -y répond yes à chaque question (confirme tout les choix automatiquement)
  • -c vérifie s’il y a des mauvais secteurs
  • -D optimise les répertoires

Voilà, après quelques minutes votre système de fichier devrait être réparé. Encore une fois, même si dans mon cas la réparation n’a pas été parfaite (car mon problème était matériel et non logiciel), il y a de grandes chances qu’elle le soit pour vous. Si vous montez la partition, vous devriez même trouver vos données lisibles.

Tester le résultat

Maintenant que notre partition est réparée, on va tester tout ça. Si vous avez une carte SD à disposition je vous conseille de copier votre image réparée plutôt que de faire le test directement sur votre carte SD. Si vous n’en avez pas à disposition, dans ce cas, copiez l’image réparée sur votre carte SD. Après tout, si vous vous rappelez bien, nous avons fait une copie physique que vous avez gardée de côté et qui n’a pas été modifiée.

On va encore utiliser dd pour copier notre image. Insérez votre carte SD dans votre pc et démontez les partitions avec umount.

Maintenant, lancez la copie de votre image vers la carte SD avec dd :

dd   if=ma_copie.img    of=/dev/mmcblk0   status=progress

Après quelques minutes, votre carte SD réparée est prête à l’emploi. Lancez-vous et testez sur votre Raspberry.

Normalement, si tout s’est bien passé, votre Raspbian devrait démarrer et vous ne devriez plus voir d’erreurs du type  « EXT4-fs error".

Si vous avez encore des erreurs EXT4-fs c’est que la corruption était telle, que fsck n’a pas réussi à régler le problème ou encore que votre problème est ailleurs.

Voilà ce que vous pouvez tester si le problème persiste :

  • Tester avec une autre carte SD (cas de carte SD défectueuse)
  • Faire la copie sur la carte avec un lecteur de carte SD différent (cas du lecteur de carte SD défectueux )
  • Si vous avez utilisé un lecteur de carte intégré à un ordinateur, essayez avec un autre (cas du lecteur SD interne défectueux)
  • Si vous avez une alimentation 5v en rab essayez de changer l’alimentation du Raspberry. Vous allez me dire que le système de fichiers n’a rien à voir avec l’alimentation, mais détrompez-vous. J’ai vu beaucoup de cas sur des forums où le problème venait d’une alimentation défectueuse qui pouvait corrompre le système ou encore juste l’empêcher de démarrer (cas de l’alimentation défectueuse)
  • Si vous avez un autre Raspberry à disposition, testez votre carte SD dessus (cas du Raspberry défectueux)

Dans mon cas la dernière solution a fonctionné, ce qui signifie que mon Raspberry était défectueux. Malheureusement, je m’en suis rendu compte trop tard et à force d’essayer j’ai fini par perdre quelques données.

Si malgré tout cela vous n’avez aucun changement et toujours des erreurs EXT4-fs il y a des chances que votre système de fichier était juste trop corrompu et il ne vous reste plus qu’à récupérer vos données et à refaire une installation propre de Raspbian.

Et surtout, n’oubliez pas ce que l’on dit « il vaut mieux prévenir que guérir ». Alors, n’oubliez pas de faire des sauvegardes régulières de votre système. Ainsi vous pourrez restaurer rapidement et sans trop de pertes votre Raspberry. J’ai écrit un article à ce propos qui explique comment faire une sauvegarde et comment restaurer votre système.

Et la partition boot dans tout ça ?

En effet, je n’ai pas traité de la partition de boot. Pourquoi ? C’est assez simple, si vous avez eu des erreurs EXT4-fs c’est que la partition en cause était votre partition ext4 et non celle de boot.
Je ne dis pas qu’il n’y a pas de cas où la partition de boot est en cause. Ce n’est juste pas le cas ici, quand on a des erreurs du type ext4.

J’écrirais d’ailleurs bientôt un court article sur la réparation de la partition de boot.

 

2 commentaires

  1. Bonjour,
    J’avais permission denied pour la commande dd if=chemin_vers_ce_que_vous_voulez_copier of=chemin_vers_la_destination_de_la_copie.
    Il faut mettre avant sudo -i pour avoir les permissions necessaires

  2. Très bon tuto très bien expliqué, malheureusement je n’ai pu arrivé au bout, je suis bloqué lors du montage de la 2eme partition

    Périphérique Amorçage Début Fin Secteurs Taille Id Type
    sauvegarde_rp.img1 8192 655359 647168 316M c W95 FAT32 (LBA)
    sauvegarde_rp.img2 655360 31115263 30459904 14,5G 83 Linux

    losetup -o 335544320 /dev/loop9 sauvegarde_rp.img
    mount /dev/loop9 /media/xav/partition2
    =>mount: /media/xav/partition2 : wrong fs type, bad option, bad superblock on /dev/loop9, missing codepage or helper program, or other error

    Quelqu’un aurais une idée?

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *