[Mount] GDT blocks insanely large. (résolu)

[Murasakiiru]

Bonjour,

J'ai mis à jour mon système il y a ~un mois, et aujourd'hui lors du reboot de la machine, blocage complet lors du mount de ma partition de 'stockage'.

Explication de ma configuration, j'ai une Arch 4.7.2-1-ARCH, sur laquelle j'ai un premier disque pour mon système, puis trois disques en raid5 pour mon stockage. Aujourd'hui il m'est impossible de remonter la partition du raid, le kernel me retourne le message suivant :

Code : Tout sélectionner

sept. 10 10:48:22 nas sudo[14511]: murasakiiru : TTY=pts/0 ; PWD=/home/murasakiiru ; USER=root ; COMMAND=/usr/bin/mount /mnt/volume1/
sept. 10 10:48:22 nas sudo[14511]: pam_unix(sudo:session): session opened for user root by murasakiiru(uid=0)
sept. 10 10:48:22 nas kernel: EXT4-fs (md127): Number of reserved GDT blocks insanely large: 8189
sept. 10 10:48:22 nas sudo[14511]: pam_unix(sudo:session): session closed for user root

J'ai cherché rapidement sur le net ce message d'erreur sans succès; si quelqu'un par ici aurait une piste pour moi je lui en serai reconnaissant


Merci d'avance,
Mumu

[benjarobin]

Bonjour, as tu essayé un fsck pour réparer ?

[Murasakiiru]

Je viens de faire un fsck sur la partition 'raid' /dev/md127, ça me retourne ceci :

Code : Tout sélectionner

[root@nas ~]# fsck /dev/md127
fsck de util-linux 2.28.1
e2fsck 1.43.1 (08-Jun-2016)
Corruption repérée dans le superbloc. (reserved_gdt_blocks = 8189).

Le superbloc n'a pu être lu ou ne contient pas un système de fichiers
ext2/ext3/ext4 correct. Si le périphérique est valide et qu'il contient réellement
un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
e2fsck avec un autre superbloc :
    e2fsck -b 8193 <périphérique>
 ou
    e2fsck -b 32768 <périphérique>

J'imagine que je dois tenter d’exécuter une des commandes proposée par fsck

[benjarobin]

Hum, déjà quel système de fichier as tu mit sur le raid ? As tu créé une table de partition par dessus le raid ou as tu directement créé le système de fichier par dessus le raid.

Quel est le statut du raid ?

[Murasakiiru]

C'est de l'ext4 sur le raid, et j'ai mis directement le système de fichier dessus (de mémoire ....)

Code : Tout sélectionner

[root@nas ~]# mdadm --detail /dev/md127
/dev/md127:
        Version : 1.2
  Creation Time : Wed Aug  7 01:32:41 2013
     Raid Level : raid5
     Array Size : 3897584512 (3717.03 GiB 3991.13 GB)
  Used Dev Size : 1948792256 (1858.51 GiB 1995.56 GB)
   Raid Devices : 3
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Sat Sep 10 12:14:15 2016
          State : clean
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           Name : NAS:2
           UUID : 2ee3cbad:0b90b344:64fdd9f7:3b71f91e
         Events : 423

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       8       19        1      active sync   /dev/sdb3
       2       8       35        2      active sync   /dev/sdc3
       
       

[Murasakiiru]

Bon j'ai downgrade le kernel à la version précédente et tout semble rentré dans l'ordre ...
Merci pour l'aide benjarobin.

[benjarobin]

Comment c'est possible ? C'était le raid qui était en carafe ? Car fsck ne devrait pas changer de comportement entre les versions du kernel

[Xorg]

Comment c'est possible ? C'était le raid qui était en carafe ? Car fsck ne devrait pas changer de comportement entre les versions du kernel

Et pourtant, j'ai trouvé ce patch qui en est la preuve.
Le patch a été appliqué le 6 juillet, ce qui correspond à la période de développement de Linux 4.7. Et vu que le noyau actuel d'Arch est le 4.7, ça explique tout. Donc oui, c'est normal que ça ne fonctionne pas avec le noyau 4.7 mais uniquement avec les versions antérieures.
Et du coup, s'il n'a pas trouvé de solution sur Internet pour ce problème, c'est sûrement parce que le noyau est encore trop récent et que très peu de personnes sont concernées par ce changement.

[benjarobin]

Euh, en gros ce n'est pas un bug kernel, le code du kernel 4.7 rajoute juste une vérification sur un système de fichier corrompu.
Donc pour moi son système de fichier est corrompu et doit être réparé.
Et je maintiens que je ne comprends pas pourquoi fsck ne reconnaisse pas le système de fichier ext4...

[Xorg]

Oui oui, je n'ai pas parlé de bug non plus.
Effectivement, ça me paraît corrompu à moi aussi :

Code : Tout sélectionner

[...] alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
e2fsck avec un autre superbloc :
    e2fsck -b 8193 <périphérique>
 ou
    e2fsck -b 32768 <périphérique>

Du coup la seule solution que je vois est de tenter d'exécuter la commande e2fsck avec un autre superbloc, en espérant que ça corrige ce soucis et que la partition puisse être montée avec Linux 4.7.

[Murasakiiru]

j'ai tenté de récupéré un autre superblock, mais il ne semble pas y parvenir. Je pense qu'une bonne sauvegarde de mes données s'impose très vite du coup !

[Xorg]

Il doit y avoir moyen de corriger le superbloc. La commande mke2fs -n /dev/md127 devrait te donner la liste de toutes les sauvegardes du superbloc.
Du coup, retente un fsck avec ces valeurs.

[Murasakiiru]

Mouais j'ai testé toutes les valeurs retournée par le mke2fs pour essayer de récupérer un superblock valide mais aucune n'a fonctionnée x)

[benjarobin]

Ce que je ne comprend pas c'est comment le kernel (une vielle version pre 4.7) arrive à monter le système de fichier si fsck ne détecte aucun système de fichier valide. C'est très très étrange, tu ne ferais pas de mauvaise manipulation ?

[Murasakiiru]

Oui j’admets c'est étrange... après mon RAID a peut être été mal construit à la base ... je sais plus trop ce que j'ai fais ça remonte à y'a longtemps.

En tout cas le downgrade du kernel a réellement permis de remount ma partition.

Code : Tout sélectionner

sept. 10 10:48:22 nas kernel: EXT4-fs (md127): Number of reserved GDT blocks insanely large: 8189

Donc ce message d'erreur est bien lié au kernel 4.7

Après l'histoire des superblocks défectueux, je sais pas quoi dire. et je sais pas trop quelles mauvaises manips je peux faire