Erreur sur Raid5 : Primary GPT table is corrupt

Support Debian
Tags: #<Tag:0x00007f63f3308c58>
#22

Sauf inattention de ma part, tu n’avais pas encore mentionné ce message d’erreur de départ.
Il semble lié à un service de systemd, quotaon.service, dont le rôle est d’activer les quotas des systèmes de fichiers, c’est-à-dire l’allocation de l’espace disque par utilisateur. On peut voir dans /etc/fstab que des options de quota sont présentes dans les options de montage du volume RAID. Je n’en sais pas plus, ce n’est pas un domaine que je maîtrise.

En tout cas ce n’est pas lié au message d’erreur de fdisk concernant la table de partition GPT, qui semble bénin. Si tu veux te débarrasser de cette erreur-là, je t’ai déjà indiqué la première étape (wipefs).

#23

Je ne sais pas si le Failed signalé sur le Quota est le problème qui empêche le système de fonctionner normalement.

Mais cela peut expliquer le fonctionnement bancal actuel ? Penses-tu que cela soit causé par la coupure de courant ? Je m’interroge sur la fiabilité de l’installation.

Voici la sortie wipefs /dev/sdd

[code]offset type

0x57541e95e00 gpt [partition table]

0x1000 linux_raid_member [raid]
LABEL: openmediavault:data
UUID: bdea5781-fef1-8b66-6a31-66c8d6ec3fad[/code]

#24

Moi non plus mais comme c’est le démarrage d’un service lancé par systemd qui échoue, cela ne m’étonnerait pas. Il faudrait le conseil de quelqu’un qui s’y connaît. Peut-être un autre fil évoquant spécifiquement cette erreur ?

C’est possible. La coupure a entraîné un arrêt brutal sans démontage propre des systèmes de fichiers. Il se peut que cela ait causé une incohérence qui n’empêche pas le montage du volume RAID mais provoque une erreur avec l’activation des quotas.

Tu peux tenter une vérification du système de fichiers après l’avoir démonté :
umount /dev/md0 fsck /dev/md0
Si cela dit que le système de fichiers est propre, essayer de forcer la vérification
fsck -f /dev/md0

wipefs a détecté la signature GPT de la table de partition de secours dans le dernier secteur du disque. Tu peux la supprimer avec
wipefs -o 0x57541e95e00 /dev/sdd

#25

Je ne parviens pas à faire le umount sur md0 car actuellement busy, et la liste des processus en cours est assez longue.

Quant au wipefs il n’est pas possible, j’obtiens l’erreur 'Probing initialisation failed: Perpherique ou ressource occupé"

#26

Il va falloir le faire en mode dépannage ou depuis un système live.

#27

J’ai eu la même erreur sous un système live. La seule action que j’ai pu effectuer est la réparation du Raid avec Gparted.

Grace à cela OMV démarre normalement est j’ai de nouveau accès à l’interface web avec les 3 disques branchés (alors qu’auparavant il fallait que j’en débranche un pour obtenir le même resultat).
Bien que les 3 disques soient visibles sous OMV le raid est actif mais avec 2 disques uniquement. J’ai accès à une partie des données. Enfin je déborde vers un autre sujet dont ce forum n’est pas le thème.

#28

Quelle même erreur ? Il y en avait deux.
Que veux-tu dire par “la réparation du RAID avec Gparted” ?

#29

En session Live (http://gparted.org/livecd.php) j’ai rencontré l’erreur de Périphérique Occupé lors du wipefs. J’ai donc utilisé la seul option qui était possible, c’est à dire “Vérifier”. La vérification a été relativement rapide (30 min environ) et les logs ont montré que des réparations ont été effectuées.

Je n’ai pas rencontré l’erreur qui bloquait le chargement normal d’OpenMediaVault.

#30

Le disque était occupé probablement parce que l’ensemble RAID md0 était actif. S’il n’est pas monté, il est possible de le désactiver avec
mdadm --stop /dev/md0
Ensuite, wipefs devrait fonctionner.

Sur quoi as-tu fait une vérification exactement ? Sur md0 ou le disque sdX qui a une table de partition ?
30 minutes c’est très long, donc je suppose que c’est une vérification du système de fichiers sur md0, l’équivalent de fsck.

Lors du démarrage dans le système live ou ensuite lors du redémarrage sur OMV ?
Dans le premier cas, probablement parce que GParted Live n’active pas les quotas.
Dans le second cas, peut-être parce que la vérification a corrigé une erreur du système de fichiers qui empêchait l’activation des quotas.

C’est étonnant. Est-ce encore le même disque qui a été exclu ?
En tout cas maintenant tu connais la commande pour le réintégrer lorsque l’ensemble est actif avec les deux autres disques.

#31

La vérification a été effectuée sur le md0. Elle a pris relativement peu de temps et il me semble en effet qu’il s’agissait d’une vérification du système de fichiers comme tu l’as mentionné.

Je n’ai pas rencontré d’erreur lors du chargement d’OMV. La réparation a sans doute eu l’effet escompté.

Merci encore pour tes conseils, j’ai pu récupérer la plupart des données.

#32

A l’occasion, essaie quand même de supprimer cette table de partition GPT sur l’un des disques en RAID. Je pense que pour pouvoir le faire il faudra démarrer en mode dépannage ou avec Gparted live, démonter et arrêter l’ensemble RAID.

umount /dev/md0 mdadm --stop /dev/md0

#33

J’ai récupéré la plupart de mes données et puis j’ai craqué et j’ai acheté un Nas. Vu mon niveau Linux je devrais avoir un peu plus de flexibilité et facilité avec ce dernier.
Merci en tout cas @PascalHambourg pour la qualité de nos échanges.