OMV6 pb de montage sur un RAID5

df -h

Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev 1,5G 0 1,5G 0% /dev
tmpfs 299M 2,3M 297M 1% /run
/dev/sdb1 35G 4,6G 28G 15% /
tmpfs 1,5G 84K 1,5G 1% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 1,5G 1,3M 1,5G 1% /tmp
 
Un montage direct ne fonctionne pas ?
Code: 
mount -t ext4 /dev/md0 /srv/dev-disk-by-uuid-859fd2c7-9889-4eb1-be78-7cc7cc8b7387
 
visiblement il n'arrive pas à lire le superblock (c'est le disque de parité de la grappe ??)

root@gs1900:~# mount -t ext4 /dev/md0 /srv/dev-disk-by-uuid-859fd2c7-9889-4eb1-be78-7cc7cc8b7387
mount: /srv/dev-disk-by-uuid-859fd2c7-9889-4eb1-be78-7cc7cc8b7387: can't read superblock on /dev/md0.
 
R76 a dit:
visiblement il n'arrive pas à lire le superblock (c'est le disque de parité de la grappe ??)
Cliquez pour agrandir...
Cela sert a ce protéger contre la perte/la corruption, le systèmes de fichiers stockent des copies de leurs informations de configuration critiques (taille de partition, taille de bloc, emplacement du journal, type, etc.) à plusieurs endroits différents du disque physique.

Je ne sais pas si cette commande est possible sur OMV6, pourrai tu essayer : ( cela permet de voir si le superblock est présent )
Code: 
dumpe2fs_64 -h /dev/md0

On arrive au bout de mes compétences a ce sujet, ensuite j'ai peur de te faire des manipulations destructrices, je suis encore loin de maitriser le RAID ou OMV
 
dumpe2fs_64 -h /dev/md0
-bash: dumpe2fs_64 : commande introuvable

la cde ne semble pas reconnue sous debian11/omv6

Pour ce qui est des cdes destructrices de toute façon au pire je devrais redescendre la sauvegarde de la veille (volumineuse mais bon) et perdre le boulot de la journée mais resté bloqué n'est pas mieux.

tu pensais à quel type de cde ?
Et si je décroche un disque de la VM, OMV v essayer de reconstruire le raid avec les disques restants ??
 
Dans l'interface d'OMV au niveau du raid j'ai les détails suivants :

Version : 1.2
Raid Level : raid5
Array Size : 1947990016 (1857.75 GiB 1994.74 GB)
Used Dev Size : 973995008 (928.87 GiB 997.37 GB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Intent Bitmap : Internal

Update Time : Sun Jan 8 14:26:46 2023
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Consistency Policy : bitmap

Name : gs1900:0 (local to host gs1900)
UUID : 29dd21e9:59cf16e5:2c4b3654:c833dfb7
Events : 1110

Number Major Minor RaidDevice State
0 8 0 0 active sync /dev/sda
1 8 32 1 active sync /dev/sdc
2 8 48 2 active sync /dev/sdd
 
R76 a dit:
dumpe2fs_64 -h /dev/md0
-bash: dumpe2fs_64 : commande introuvable
Cliquez pour agrandir...
Zut, mais je m'en doutait un peu.

R76 a dit:
Dans l'interface d'OMV au niveau du raid j'ai les détails suivants :
Cliquez pour agrandir...
Oui, tout semble indiquer que tout est ok, mais il doit y avoir une subtilité qui fait que le montage du systeme de fichier coince

Pourrai tu nous donner le contenu de fstab :
Code: 
cat /etc/fstab

Tu pourrai essayer :
Code: 
fsck /dev/md0
Cela pour faire un check de md0

Ensuite, pour le montage de ce qui est contenu dans fstab :
Code: 
mount -a
 
pas grave, donc :

cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda1 during installation
UUID=eeb657a7-29d8-44d6-8767-b3ca6f95d70e / ext4 errors=remount-ro 0 1
# swap was on /dev/sda5 during installation
UUID=865d161b-4421-45cf-bc5d-4edceabcc42c none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
# >>> [openmediavault]
/dev/disk/by-uuid/859fd2c7-9889-4eb1-be78-7cc7cc8b7387 /srv/dev-disk-by-uuid-859fd2c7-9889-4eb1-be78-7cc7cc8b7387 ext4 defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
Message automatiquement fusionné :

Fsck semble etre en mode "Lama Fâché" :

fsck /dev/md0
fsck from util-linux 2.36.1
e2fsck 1.46.5 (30-Dec-2021)
/dev/md0 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Error reading block 449315329 (Erreur d'entrée/sortie) while getting next inode from scan. Ignore error<y>?
/dev/md0: e2fsck canceled.

/dev/md0: ********** WARNING: Filesystem still has errors **********
 
Ton systeme de fichier semble corrompu. Si tu as une sauvegarde je te conseil de restaurer.

Certains systeme ont des superblock de backup, ... mais je ne serai pas t'aider a les manipuler sous OMV.

@Bambusa29 aurait une idée peut etre ?

R76 a dit:
Bon ma femme siffle un arrêt de jeu et comme est elle est ceinture noire j'obéi !
Cliquez pour agrandir...
Je comprends 😅
 
Oui si j'avais plus de temps je persisterai mais là utiliser la sauvegarde me semble plus judicieux.
Le plus frustrant restant de ne pas avoir le fin mot de l'histoire mais je ne doute pas que les essais effectués aujourd'hui soient utiles à d'autres !
Un grand merci pour ton assistance et comme disais Mandela :

"Je gagne toujours. Quand je gagne, je gagne et quand je perds, j'apprends." :);)
 
  • J'aime
Réactions: EVO
Bon ben au final avant de tout exploser j'ai tenter un :

fsck.ext4 -v /dev/md0

Et là miracle :
1673186180589.png
Comme quoi mon grand père avait raison, y-a de la veine pour les crapules !

Allez bonne galette à tous et encore merci EVOTk !
 
:) Super ! Content que tu es retrouvé l’accès :) fsck n'avais pas du réussir a déterminer le type du systeme de fichier de lui meme.
C'est bon a savoir
 
Vous devez vous connecter ou vous enregistrer pour répondre ici.
Haut Bas