Restauration d'une config LVM / mdadm raid 1
Le
Damien TOURDE
Bonjour,
Suite à une manip physique (changement de pâte thermique), mon raid ne
veut plus se monter. J'ai peut-être touché un câble, mais en tout cas
l'UEFI de la CM reconnait bien 2 disques actifs (+ SSD système, pas de
soucis avec celui là), Debian aussi.
Les 2 disques sont assez vieux (dont un dont le connecteur s'est
"intégré" dans le câble dur à expliquer), mais SMART ne me donne rien
d'alarmant.
Depuis, pour démarrer, je suis obliger de virer le RAID de fstab et il
n'y a pas moyen de monter le disque.
C'est un RAID 1 mdadm, avec une unique partition LVM, et autant les
disques sont bien reconnus, autant LVM n'arrive pas à me trouver de PV,
VG, ni de LV.
J'ai essayé avec vgcfgrestore, mais il me dit qu'il n'arrive pas à
trouver l'uuid correspondant au fichier.
J'ai mis dans le fichier de backup l'uuid que me donne blkid, rien à
faire non plus Je commence à sécher un peu là
Voici ce que je peux vous dire :
root@olorin-fixe:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sun Jan 17 22:18:35 2016
Raid Level : raid1
Array Size : 160704384 (153.26 GiB 164.56 GB)
Used Dev Size : 160704384 (153.26 GiB 164.56 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Thu Jan 21 01:06:17 2016
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : olorin-fixe:0 (local to host olorin-fixe)
UUID : f84fe148:a775eac4:76ff776e:5845be39
Events : 764
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
-
root@olorin-fixe:~# mdadm --examine --scan /dev/sdb1 /dev/sdc1
ARRAY /dev/md/0 metadata=1.2 UUIDø4fe148:a775eac4:76ff776e:5845be39
name=olorin-fixe:0
-
root@olorin-fixe:~# e2fsck -f /dev/md0
e2fsck 1.42.13 (17-May-2015)
ext2fs_open2: Numéro magique invalide dans le super-bloc
e2fsck : Superbloc invalide, tentons d'utiliser les blocs de sauvetage
e2fsck: Numéro magique invalide dans le super-bloc lors de la tentative
d'ouverture de /dev/md0
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>
-
root@olorin-fixe:~# lvscan -a
ACTIVE '/dev/olorin-fixe-vg/root' [20,00 GiB] inherit
ACTIVE '/dev/olorin-fixe-vg/swap_1' [15,76 GiB] inherit
ACTIVE '/dev/olorin-fixe-vg/home' [320,00 GiB] inherit
root@olorin-fixe:~# vgscan
Reading all physical volumes. This may take a while
Found volume group "olorin-fixe-vg" using metadata type lvm2
root@olorin-fixe:~# pvscan
PV /dev/sda5 VG olorin-fixe-vg lvm2 [465,52 GiB / 109,76 GiB free]
Total: 1 [465,52 GiB] / in use: 1 [465,52 GiB] / in no VG: 0 [0 ]
-> Le LVM sur le RAID c'est VG olorin-fixe-storage / LV storage0,
là il reconnait le SSD système uniquement.
Suite à une manip physique (changement de pâte thermique), mon raid ne
veut plus se monter. J'ai peut-être touché un câble, mais en tout cas
l'UEFI de la CM reconnait bien 2 disques actifs (+ SSD système, pas de
soucis avec celui là), Debian aussi.
Les 2 disques sont assez vieux (dont un dont le connecteur s'est
"intégré" dans le câble dur à expliquer), mais SMART ne me donne rien
d'alarmant.
Depuis, pour démarrer, je suis obliger de virer le RAID de fstab et il
n'y a pas moyen de monter le disque.
C'est un RAID 1 mdadm, avec une unique partition LVM, et autant les
disques sont bien reconnus, autant LVM n'arrive pas à me trouver de PV,
VG, ni de LV.
J'ai essayé avec vgcfgrestore, mais il me dit qu'il n'arrive pas à
trouver l'uuid correspondant au fichier.
J'ai mis dans le fichier de backup l'uuid que me donne blkid, rien à
faire non plus Je commence à sécher un peu là
Voici ce que je peux vous dire :
root@olorin-fixe:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sun Jan 17 22:18:35 2016
Raid Level : raid1
Array Size : 160704384 (153.26 GiB 164.56 GB)
Used Dev Size : 160704384 (153.26 GiB 164.56 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Thu Jan 21 01:06:17 2016
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : olorin-fixe:0 (local to host olorin-fixe)
UUID : f84fe148:a775eac4:76ff776e:5845be39
Events : 764
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
-
root@olorin-fixe:~# mdadm --examine --scan /dev/sdb1 /dev/sdc1
ARRAY /dev/md/0 metadata=1.2 UUIDø4fe148:a775eac4:76ff776e:5845be39
name=olorin-fixe:0
-
root@olorin-fixe:~# e2fsck -f /dev/md0
e2fsck 1.42.13 (17-May-2015)
ext2fs_open2: Numéro magique invalide dans le super-bloc
e2fsck : Superbloc invalide, tentons d'utiliser les blocs de sauvetage
e2fsck: Numéro magique invalide dans le super-bloc lors de la tentative
d'ouverture de /dev/md0
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>
-
root@olorin-fixe:~# lvscan -a
ACTIVE '/dev/olorin-fixe-vg/root' [20,00 GiB] inherit
ACTIVE '/dev/olorin-fixe-vg/swap_1' [15,76 GiB] inherit
ACTIVE '/dev/olorin-fixe-vg/home' [320,00 GiB] inherit
root@olorin-fixe:~# vgscan
Reading all physical volumes. This may take a while
Found volume group "olorin-fixe-vg" using metadata type lvm2
root@olorin-fixe:~# pvscan
PV /dev/sda5 VG olorin-fixe-vg lvm2 [465,52 GiB / 109,76 GiB free]
Total: 1 [465,52 GiB] / in use: 1 [465,52 GiB] / in no VG: 0 [0 ]
-> Le LVM sur le RAID c'est VG olorin-fixe-storage / LV storage0,
là il reconnait le SSD système uniquement.
Une partition donc un ensemble RAID partitionné, avec une table de
partition ? Qu'en dit fdisk ou autre ?
Quel UUID ?
Pourquoi diable exécuter e2fsck sur ce qui est censé contenir une table
de partition ou un PV LVM ?
Qu'en dit plutôt file -s /dev/md0 ?
Merci de ta réponse :
On 31/01/2016 20:14, Pascal Hambourg wrote:
:~# fdisk -l /dev/md0
Disque /dev/md0 : 153,3 GiB, 164561289216 octets, 321408768 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
:~# fdisk -l /dev/sdb
Disque /dev/sdb : 153,4 GiB, 164696555520 octets, 321672960 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x2600ee9a
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sdb1 2048 321672959 321670912 153,4G fd RAID Linux
autodétecté
:~# fdisk -l /dev/sdc
Disque /dev/sdc : 153,4 GiB, 164696555520 octets, 321672960 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x40988f99
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sdc1 2048 321672959 321670912 153,4G fd RAID Linux
autodétecté
:~#
Celui l'UUID "physique" de la partition (c'est comme ça que je le vois)
qui contient LVM.
:~# blkid
/dev/sdc1: UUID="f84fe148-a775-eac4-76ff-776e5845be39"
UUID_SUB="5cacc338-609c-442a-2fcb-cde38f976d58" LABEL="olorin-fixe:0"
TYPE="linux_raid_member" PARTUUID="40988f99-01"
/dev/sdb1: UUID="f84fe148-a775-eac4-76ff-776e5845be39"
UUID_SUB="c522994f-024d-e113-5b30-8c864aad35d8" LABEL="olorin-fixe:0"
TYPE="linux_raid_member" PARTUUID="2600ee9a-01"
/dev/md0: TYPE="promise_fasttrack_raid_member"
Et je l'ai mis dans le fichier de config LVM de ce PV (je copie en bas
du mail le fichier de config).
Avec pour résultat :
:~# vgcfgrestore -f
/etc/lvm/backup/olorin-fixe-storage.test olorin-fixe-storage
Couldn't find device with uuid f84fe1-48a7-75ea-c476-ff77-6e58-45be39.
PV unknown device missing from cache
Format-specific setup for unknown device failed
Restore failed.
Avec celui par défaut :
:~# vgcfgrestore -f
/etc/lvm/backup/olorin-fixe-storage.bck olorin-fixe-storage
Couldn't find device with uuid b6SEem-WYJK-xcUT-946V-lS0q-Yxic-yFWaxf.
PV unknown device missing from cache
Format-specific setup for unknown device failed
Restore failed.
Pour e2fsck, c'était un peu en désespoir de cause, histoire de voir si
quelque chose ressortait...
:~# file -s /dev/md0
/dev/md0: LVM2 PV (Linux Logical Volume Manager), UUID:
b6SEem-WYJK-xcUT-946V-lS0q-Yxic-yFWaxf, size: 164561289216
-> Je me suis un peu "perdu" dans les UUID, en gros le "b6SE..." je le
retrouve dans /etc/lvm/backup/olorin-fixe-storage et dans la sortie de
file -s /dev/md0
Et le "f84fe...." je le retrouve dans la sortie de blkid, et
/etc/mdadm/mdadm.conf à la ligne :
ARRAY /dev/md0 level=raid1 num-devices=2 metadata=1.2 name=olorin-fixe:0
UUIDø4fe148:a775eac4:76ff776e:5845be39
devices=/dev/sdb1,/dev/sdc1
------------------------------
Le fichier de config : /etc/lvm/backup/olorin-fixe-storage
# Generated by LVM2 version 2.02.138(2) (2015-12-14): Sun Jan 17
23:02:00 2016
contents = "Text Format Volume Group"
version = 1
description = "Created *after* executing 'lvcreate -L 100G
olorin-fixe-storage -n lvstorage0'"
creation_host = "olorin-fixe" # Linux olorin-fixe 4.3.0-1-amd64 #1
SMP Debian 4.3.3-5 (2016-01-04) x86_64
creation_time = 1453068120 # Sun Jan 17 23:02:00 2016
olorin-fixe-storage {
id = "o7zoRL-xK1j-2mmo-ZFJi-1wFq-iGft-M9MbyQ"
seqno = 2
format = "lvm2" # informational
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192 # 4 Megabytes
max_lv = 0
max_pv = 0
metadata_copies = 0
physical_volumes {
pv0 {
id = "b6SEem-WYJK-xcUT-946V-lS0q-Yxic-yFWaxf"
device = "/dev/md0" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 321408768 # 153,26 Gigabytes
pe_start = 2048
pe_count = 39234 # 153,258 Gigabytes
}
}
logical_volumes {
lvstorage0 {
id = "UiPmCd-2655-ebnc-24Fk-GLqp-bGkj-MKhu7j"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
creation_host = "olorin-fixe"
creation_time = 1453068119 # 2016-01-17 23:01:59 +0100
segment_count = 1
segment1 {
start_extent = 0
extent_count = 25600 # 100 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
}
}
}
Pas de table de partition, donc pas de partition /dev/md0p1. Cas
classique, le RAID partitionné est peu utilisé. Je suppose qu'on préfère
utiliser LVM par dessus pour la gestion des volumes.
C'est l'UUID de l'ensemble RAID, qui permet de reconnaître ses membres.
Aucun rapport avec LVM.
Ça, ça ne me plaît pas. Apparemment blkid voit un identifiant de membre
RAID Promise dans le contenu de l'ensemble RAID et je suppose que ça
l'empêche de voir l'identifiant LVM. Si lvm se base là-dessus pour
retrouver ses PV, ça ne marchera pas.
Ça c'est plutôt rassurant, l'en-tête LVM est présent.
Faudrait voir si on peut forcer lvm à considérer qu'un volume est un PV
même si blkid ne le dit pas.
Autre piste : chercher l'identifiant RAID Promise parasite et l'effacer.
Voir dmraid.
Je vais chercher avec cet axe de recherche, je reviens vers la liste en
cas de trouvaille/échec ;-)
Bonne fin de week-end,
Damien
On 31/01/2016 22:24, Pascal Hambourg wrote:
Après un vgck olorin-fixe-storage, je retrouve, avec les commandes
lvdisplay, vgdisplay et pvdisplay, la mention de l'existence de mon LVM
"perdu".
En revanche, il est "NOT available", et ça, je ne vois pas pourquoi...
mais ça se corrige.
Voici les résultats des 3 commandes (j'enlève le pv du SSD, qui
fonctionne, de tout ça) :
:~# vgdisplay
--- Volume group ---
VG Name olorin-fixe-storage
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 153,26 GiB
PE Size 4,00 MiB
Total PE 39234
Alloc PE / Size 25600 / 100,00 GiB
Free PE / Size 13634 / 53,26 GiB
VG UUID o7zoRL-xK1j-2mmo-ZFJi-1wFq-iGft-M9MbyQ
:~# pvdisplay
--- Physical volume ---
PV Name /dev/md0
VG Name olorin-fixe-storage
PV Size 153,26 GiB / not usable 1,88 MiB
Allocatable yes
PE Size 4,00 MiB
Total PE 39234
Free PE 13634
Allocated PE 25600
PV UUID b6SEem-WYJK-xcUT-946V-lS0q-Yxic-yFWaxf
:~# lvdisplay
--- Logical volume ---
LV Path /dev/olorin-fixe-storage/lvstorage0
LV Name lvstorage0
VG Name olorin-fixe-storage
LV UUID UiPmCd-2655-ebnc-24Fk-GLqp-bGkj-MKhu7j
LV Write Access read/write
LV Creation host, time olorin-fixe, 2016-01-17 23:01:59 +0100
LV Status NOT available
LV Size 100,00 GiB
Current LE 25600
Segments 1
Allocation inherit
Read ahead sectors auto
--------------------------------------
Puis un petit coup de :
:~# vgchange -a y olorin-fixe-storage
Et hop ! C'est reparti !
On 31/01/2016 22:47, Damien TOURDE wrote:
Bonsoir,
Du coup, as-tu trouver la raison de cette situation ?
Bonne soirée,
--
Christophe De Natale
Soit j'ai changé de prise SATA et peut-être donc de contrôleur sur la
CM, ce qui aurait pu changer un UUID (il me semble que l'UUID est généré
avec les caractéristiques du disque et celles du HW en général).
Soit la prise de l'un de mes 2 disques a merdouillé en touchant les
câbles. Comme je le disais dans le premier mail, toute la partie "guide
en plastique" de la prise SATA d'un des disques est restée coincée dans
la partie mâle (câble), et il n'y a plus que les contacts "dans le vide"
sur le disque.
Mais la 2ème "théorie" me semble plus farfelue car je n'ai pas reçu de
mail d'erreur de mdadm.
On 01/02/2016 20:53, Christophe De Natale wrote:
Non, les UUID sont générés pseudo-aléatoirement et indépendamment de
tout identifiant matériel.
Et surtout, le RAID est là pour éviter que cela ait des conséquences
visibles.
ma carte mère de ne pas "détecter" les disques à chaque démarrage, et de
choisir toujours le SSD sauf si F8 est appuyé.
Sinon, je ne vois pas.
On 01/02/2016 21:43, Pascal Hambourg wrote:
Je ne vois pas le rapport avec la non détection du PV qui est contenu
dans un ensemble RAID qui est lui-même parfaitement détecté.