LVM Time out waiting for devices Le sujet est résolu

[PascalHambourg]

J'en ai tiré l'historique des commandes :

Code : Tout sélectionner

grep -h description $(ls -tr)
description = "Created *before* executing 'vgreduce --removemissing --force nas'"
description = "Created *before* executing 'pvscan --cache --activate ay --major 8 --minor 0'"
description = "Created *before* executing 'pvscan --cache --activate ay --major 8 --minor 0'"
description = "Created *before* executing 'vgextend nas /dev/sde1'"
description = "Created *before* executing 'lvcreate --name nas --size 4606734336K nas'"
description = "Created *before* executing 'vgreduce --removemissing --force nas'"
description = "Created *after* executing 'vgreduce --removemissing --force nas'"

Le résultat est suffisamment explicite, pas besoin de commenter. Si on regarde dans le détail des fichiers, on voit que le LV a été recréé par lvcreate en utilisant les PV dans un ordre différent de l'ordre original, ce qui était prévisible, donc ça ne pouvait pas marcher.
Je viens de voir qu'il existe une façon plus simple pour toi de l'obtenir avec la commande

Code : Tout sélectionner

vgcfgrestore --list nas

Le fichier a utiliser pour la restauration est bien le 00009.

Code : Tout sélectionner

vgcfgrestore --file /etc/lvm/archive/nas_00009-1254290722.vg nas
lvscan

Si pas d'erreur et le LV est présent,

Code : Tout sélectionner

vgchange -ay nas
lvscan

Si le LV est actif,

Code : Tout sélectionner

blkid /dev/mapper/nas-nas
fsck -n -f /dev/mapper/nas-nas

Si pas d'erreur, monter en lecture seule et vérifier le contenu.

[genpashiro]

Code : Tout sélectionner

vgcfgrestore --file /etc/lvm/archive/nas_00009-1254290722.vg nas

Cannot restore Volume Group nas with 1 PVs marked as missing.
Restore failed.

Ceci étant dû au PV /dev/sdl1 ne faisant plus parti du VG 'nas' comme indiqué par pvscan.

Je dois l'ajouter avec un vgextend ?

[PascalHambourg]

Tu peux essayer, mais je ne comprends pas où LVM voit un PV manquant après le dernier "vgreduce --removemissing".

[PascalHambourg]

Je n'avais pas examiné le fichier assez attentivement, en effet :

Code : Tout sélectionner

		pv4 {
			id = "R7bOf7-yWeU-Kpmp-3agi-LYPA-zCcw-2H06lp"
			device = "[unknown]"	# Hint only

			status = ["ALLOCATABLE"]
			flags = ["MISSING"]
			dev_size = 1953523085	# 931.512 Gigabytes
			pe_start = 2048
			pe_count = 238466	# 931.508 Gigabytes
		}

Il faut peut-être remonter encore plus loin dans les fichiers d'archive... ou bien éditer le fichier pour supprimer le flag "MISSING".

[genpashiro]

Code : Tout sélectionner

nas# vgextend nas /dev/sdl1 
  /dev/sdl1: read failed after 0 of 512 at 1000203747328: Remote I/O error
  /dev/sdl1: read failed after 0 of 512 at 1000203808768: Remote I/O error
  /dev/sdl1: read failed after 0 of 512 at 0: Remote I/O error
  /dev/sdl1: read failed after 0 of 512 at 4096: Remote I/O error
  /dev/sdl: read failed after 0 of 4096 at 0: Remote I/O error
  /dev/sdl: read failed after 0 of 4096 at 1000204795904: Remote I/O error
  /dev/sdl: read failed after 0 of 4096 at 1000204877824: Remote I/O error
  /dev/sdl: read failed after 0 of 4096 at 4096: Remote I/O error
  /dev/sdl1: write failed after 0 of 512 at 4096: Remote I/O error
nas# pvscan
  /dev/sdl: read failed after 0 of 4096 at 0: Remote I/O error
  /dev/sdl: read failed after 0 of 4096 at 1000204795904: Remote I/O error
  /dev/sdl: read failed after 0 of 4096 at 1000204877824: Remote I/O error
  /dev/sdl: read failed after 0 of 4096 at 4096: Remote I/O error
  /dev/sdl1: read failed after 0 of 512 at 1000203747328: Remote I/O error
  /dev/sdl1: read failed after 0 of 512 at 1000203808768: Remote I/O error
  /dev/sdl1: read failed after 0 of 512 at 0: Remote I/O error
  /dev/sdl1: read failed after 0 of 512 at 4096: Remote I/O error
  PV /dev/sda3   VG nas             lvm2 [136,36 GiB / 136,36 GiB free]
  PV /dev/sdb1   VG nas             lvm2 [149,05 GiB / 149,05 GiB free]
  PV /dev/sdc1   VG nas             lvm2 [149,05 GiB / 149,05 GiB free]
  PV /dev/sdd1   VG nas             lvm2 [1,36 TiB / 1,36 TiB free]
  PV /dev/sdf1   VG nas             lvm2 [931,48 GiB / 931,48 GiB free]
  PV /dev/sde    VG nas             lvm2 [698,63 GiB / 698,63 GiB free]
  Total: 6 [3,38 TiB] / in use: 6 [3,38 TiB] / in no VG: 0 [0   ]

[genpashiro]

Je n'avais pas examiné le fichier assez attentivement, en effet :

Code : Tout sélectionner

		pv4 {
			id = "R7bOf7-yWeU-Kpmp-3agi-LYPA-zCcw-2H06lp"
			device = "[unknown]"	# Hint only

			status = ["ALLOCATABLE"]
			flags = ["MISSING"]
			dev_size = 1953523085	# 931.512 Gigabytes
			pe_start = 2048
			pe_count = 238466	# 931.508 Gigabytes
		}

Il faut peut-être remonter encore plus loin dans les fichiers d'archive... ou bien éditer le fichier pour supprimer le flag "MISSING".

device , je peux donc mettre /dev/sdl1 ?

[PascalHambourg]

Oui, mais ce n'est qu'une indication ("hint"), c'est l'UUID qui compte.
Par contre tu as un problème de lecture/écriture sur le disque /dev/sdl. Il est encore bien reconnu ?
Ne tente pas la restauration tant que pvscan rapporte des erreurs.

[genpashiro]

pvscan ne le fait plus apparaître par contre :

Code : Tout sélectionner

lsblk -o name,model,size | grep -v loop
NAME   MODEL              SIZE
sda    MAXTOR STM316081 149,1G
├─sda1                     10G
├─sda2                      1K
├─sda3                  136,4G
└─sda5                    2,8G
sdb    MAXTOR STM316021 149,1G
└─sdb1                  149,1G
sdc    MAXTOR STM316081 149,1G
└─sdc1                  149,1G
sdd    Ext HDD 1021       1,4T
└─sdd1                    1,4T
sde    EXT              698,7G
sdf    My Passport 0748 931,5G
└─sdf1                  931,5G
[color=#00FF40]
sdl    HDS721010CLA630  931,5G
└─sdl1                  931,5G[/color]
sr0    CDDVDW SH-S222A   1024M
sr1    DVDR1660P1        1024M

mais

Code : Tout sélectionner

fdisk -l | grep /dev/sdl

ne retourne rien !!

quelle est la commande fiable pour détecter la présence d"un DD ?

[PascalHambourg]

Ne mets pas de balises de couleur ou autre entre les balises de code, ce n'est pas interprété et affiché tel quel.

fdisk -l | grep /dev/sdl

Mauvaise commande et abus de grep. Utilise plutôt

Code : Tout sélectionner

fdisk -l /dev/sdl

quelle est la commande fiable pour détecter la présence d"un DD ?

Les logs du noyau, /proc/partitions, /sys/block/sdX/*... mais il peut arriver qu'un disque reste présent mais inaccessible quand il ne répond plus.
Ce disque a clairement un problème de fiabilité : disque pourri, connectique (câble, connecteur, boîtier) pourrie, alimentation pourrie...

[genpashiro]

effectivement, vraiment pourri l'ensemble...

Code : Tout sélectionner

fdisk -l /dev/sdl1 
  fdisk: cannot open /dev/sdl1: Input/output error

Du coup, je peux considérer qu'il est là sans l'être quoi...

Je peux tenter de le débrancher/brancher et retenter les commandes de restauration dans ton précèdent message ?

[PascalHambourg]

Oui, mais vérifie le disque avec fdisk, pvscan, etc. avant de lancer vgcfgrestore.
Il suffit qu'un seul des éléments de la chaîne soit pourri.

[genpashiro]

bon après un nième redémarrage, et débranchement/rebranchement du DD en question :

VIré au préalable le flag "MISSING" du fichier de restauration

Code : Tout sélectionner

nas# vgcfgrestore --file /etc/lvm/archive/nas_00009-1254290722.vg nas
  Restored volume group nas
nas# lvscan
  inactive          '/dev/nas/NAS' [4,29 TiB] inherit
nas# vgchange -ay nas
  1 logical volume(s) in volume group "nas" now active
nas# lvscan
  ACTIVE            '/dev/nas/NAS' [4,29 TiB] inherit
nas# blkid /dev/mapper/nas-NAS 
/dev/mapper/nas-NAS: UUID="cf80bbfe-f3ea-4430-a52f-07868dbf7825" TYPE="ext4"
nas# fsck -n -f /dev/mapper/nas-NAS 
fsck from util-linux 2.29.2
e2fsck 1.44.5 (15-Dec-2018)
Warning!  /dev/mapper/nas-NAS is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes

J'attends donc le déroulement de fsck

Par contre,

Code : Tout sélectionner

Warning!  /dev/mapper/nas-NAS is mounted.

alors que je n'avais lancé aucune commande dans ce sens

[PascalHambourg]

Le LV a peut-être été monté automatiquement dès qu'il a été activé, notamment si le montage est défini dans /etc/fstab ou avec une unité systemd. Du coup le résultat de fsck sur un système de fichiers monté n'aura pas beaucoup de sens.

Mais si le disque externe est toujours aussi instable je crains que le problème se reproduise. Sans parler des 1500 secteurs défectueux du disque WD de 1,5 To (hasard, c'est un "green" - jamais eu confiance en cette famille). Tu sais ce qu'il te reste à faire : sauvegarde de ce qui est lisible sur un support fiable.

[genpashiro]

oui, il est clair que si j'arrive pas chance à récupérer ce LVM, je fais les sauvegardes appropriés des fichiers si j'y arrive....

et si oui, je me sépare de ce DD bancale et reconfigure le LV sans lui pour y remettre ensuite les données.

du coup, le fsck sur un volume monté peut tout de même faire son job ?

[genpashiro]

Sans parler des 1500 secteurs défectueux du disque WD de 1,5 To (hasard, c'est un "green" - jamais eu confiance en cette famille). Tu sais ce qu'il te reste à faire : sauvegarde de ce qui est lisible sur un support fiable.

Pour le coup, il est très vieux celui-ci, 6-7 ans je dirais.

Je n'ai pas spécialement de grief sur les WD, mais je suis loin d'être un connaisseur

D'ailleurs, si tu as quelques conseils sur ce que peut être un DD robuste, fiable...je suis preneur !

Là, si je parviens à récupérer mes données, j'avais dans l'idée d'investir dans un NAS WD pour sauvegarder de façon perenne ces données.

[PascalHambourg]

du coup, le fsck sur un volume monté peut tout de même faire son job ?

Non, voir ma réponse précédente.

Pour le coup, il est très vieux celui-ci, 6-7 ans je dirais.

7 ans, ce n'est pas vieux. Ce n'est pas l'âge qui compte le plus, c'est l'état. J'ai des disques bien plus vieux sans le moindre secteur défectueux.

Je n'ai pas spécialement de grief sur les WD,

Moi non plus, seulement la série "green" car ce n'est pas la première fois que vois des problèmes de fiabilité avec celle-ci.

D'ailleurs, si tu as quelques conseils sur ce que peut être un DD robuste, fiable...je suis preneur !

Je ne suis pas en mesure de conseiller une marque, série ou modèle mais il me semble qu'un disque de 4 To (interne bien sûr) serait probablement plus fiable que 7 disques dont certains externes pour un prix modique. Ensuite se pose la question de la redondance avec du RAID et/ou de la sauvegarde (les deux ne font pas la même chose).

[genpashiro]

Le LV a peut-être été monté automatiquement dès qu'il a été activé, notamment si le montage est défini dans /etc/fstab ou avec une unité systemd. Du coup le résultat de fsck sur un système de fichiers monté n'aura pas beaucoup de sens.

Argh! Je n'avais pas fait attention

Il convient de commenter les lignes correspondantes au LVM dans le /etc/fstab ? passer par une commande umount sinon ?

je vais laisser le fsck finir de se dérouler , le but de cette commande vérifier le disque et procède à une réparation des secteurs défectueux ?

[PascalHambourg]

Il convient de commenter les lignes correspondantes au LVM dans le /etc/fstab ?

Au temps de sysvinit ça n'aurait pas eu d'importance, mais avec systemd il faut s'attendre à ce qu'un volume déclaré dans fstab soit monté à tout moment quand il apparaît, et pas seulement au démarrage.

je vais laisser le fsck finir de se dérouler , le but de cette commande vérifier le disque et procède à une réparation des secteurs défectueux ?

Ça ne sert à rien de laisser fsck tourner sur un système de fichiers monté, il n'en sortira rien de pertinent. Si tu veux vraiment passer fsck, il faut démonter le volume d'abord.

Par défaut fsck ne s'occupe pas des secteurs défectueux. Avec l'option -c il scanne le disque et marque les secteurs détectés comme défectueux pour ne plus les utiliser, mais il ne les répare pas. La seule méthode que je connais pour réparer ou réallouer un secteur défecteux consiste à écrire dedans, ce qui détruit les données et ne fonctionne pas toujours.

[genpashiro]

j'ai fait un umount /dev/mapper/nas-NAS et relancer fsck -c -f

il avait terminé en "aborted" forcément

[PascalHambourg]

Tu es conscient que fsck -c va supprimer ou tronquer les fichiers et répertoires occupant des secteurs défectueux ?