Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Debian Restauration d'une config LVM / mdadm raid 1

Restauration d'une config LVM / mdadm raid 1

14 réponses
Avatar
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=f84fe148: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.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Pascal Hambourg
Damien TOURDE a écrit :

C'est un RAID 1 mdadm, avec une unique partition LVM



Une partition donc un ensemble RAID partitionné, avec une table de
partition ? Qu'en dit fdisk ou autre ?

J'ai mis dans le fichier de backup l'uuid que me donne blkid



Quel UUID ?

:~# e2fsck -f /dev/md0



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 ?
Avatar
Damien TOURDE
Bonjour,

Merci de ta réponse :

On 31/01/2016 20:14, Pascal Hambourg wrote:
Damien TOURDE a écrit :
C'est un RAID 1 mdadm, avec une unique partition LVM


Une partition donc un ensemble RAID partitionné, avec une table de
partition ? Qu'en dit fdisk ou autre ?


:~# 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é
:~#


J'ai mis dans le fichier de backup l'uuid que me donne blkid


Quel UUID ?


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.


:~# e2fsck -f /dev/md0


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 ?


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
]
}
}
}
}
Avatar
Pascal Hambourg
Damien TOURDE a écrit :


On 31/01/2016 20:14, Pascal Hambourg wrote:
Damien TOURDE a écrit :
C'est un RAID 1 mdadm, avec une unique partition LVM


Une partition donc un ensemble RAID partitionné, avec une table de
partition ? Qu'en dit fdisk ou autre ?


:~# 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



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.

J'ai mis dans le fichier de backup l'uuid que me donne blkid


Quel UUID ?


Celui l'UUID "physique" de la partition (c'est comme ça que je le vois)
qui contient LVM.



C'est l'UUID de l'ensemble RAID, qui permet de reconnaître ses membres.
Aucun rapport avec 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"



Ç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.

:~# file -s /dev/md0
/dev/md0: LVM2 PV (Linux Logical Volume Manager), UUID:
b6SEem-WYJK-xcUT-946V-lS0q-Yxic-yFWaxf, size: 164561289216



Ç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.
Avatar
Damien TOURDE
Merci,

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:
Damien TOURDE a écrit :

On 31/01/2016 20:14, Pascal Hambourg wrote:
Damien TOURDE a écrit :
C'est un RAID 1 mdadm, avec une unique partition LVM


Une partition donc un ensemble RAID partitionné, avec une table de
partition ? Qu'en dit fdisk ou autre ?


:~# 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


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.

J'ai mis dans le fichier de backup l'uuid que me donne blkid


Quel UUID ?


Celui l'UUID "physique" de la partition (c'est comme ça que je le vois)
qui contient LVM.


C'est l'UUID de l'ensemble RAID, qui permet de reconnaître ses membres.
Aucun rapport avec 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"


Ç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.

:~# file -s /dev/md0
/dev/md0: LVM2 PV (Linux Logical Volume Manager), UUID:
b6SEem-WYJK-xcUT-946V-lS0q-Yxic-yFWaxf, size: 164561289216


Ç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.



Avatar
Damien TOURDE
Bonjour,

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:
Merci,

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:
Damien TOURDE a écrit :
On 31/01/2016 20:14, Pascal Hambourg wrote:
Damien TOURDE a écrit :
C'est un RAID 1 mdadm, avec une unique partition LVM


Une partition donc un ensemble RAID partitionné, avec une table de
partition ? Qu'en dit fdisk ou autre ?


:~# 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


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.

J'ai mis dans le fichier de backup l'uuid que me donne blkid


Quel UUID ?


Celui l'UUID "physique" de la partition (c'est comme ça que je le vois)
qui contient LVM.


C'est l'UUID de l'ensemble RAID, qui permet de reconnaître ses membres.
Aucun rapport avec 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"


Ç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.

:~# file -s /dev/md0
/dev/md0: LVM2 PV (Linux Logical Volume Manager), UUID:
b6SEem-WYJK-xcUT-946V-lS0q-Yxic-yFWaxf, size: 164561289216


Ç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.







Avatar
Christophe De Natale
Le lundi 01 février 2016 à 20:40 +0100, Damien TOURDE a écrit :
Bonjour,

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".



Bonsoir,

Du coup, as-tu trouver la raison de cette situation ?

Bonne soirée,

--
Christophe De Natale
Avatar
Damien TOURDE
J'ai 2 pistes :

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:
Le lundi 01 février 2016 à 20:40 +0100, Damien TOURDE a écrit :
Bonjour,

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".



Bonsoir,

Du coup, as-tu trouver la raison de cette situation ?

Bonne soirée,

Avatar
Pascal Hambourg
Damien TOURDE a écrit :

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).



Non, les UUID sont générés pseudo-aléatoirement et indépendamment de
tout identifiant matériel.

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.



Et surtout, le RAID est là pour éviter que cela ait des conséquences
visibles.
Avatar
Damien TOURDE
Alors la 3 ème possibilité c'est que pour booter plus vite, j'ai dit à
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:
Damien TOURDE a écrit :
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).


Non, les UUID sont générés pseudo-aléatoirement et indépendamment de
tout identifiant matériel.

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.


Et surtout, le RAID est là pour éviter que cela ait des conséquences
visibles.



Avatar
Pascal Hambourg
Damien TOURDE a écrit :
Alors la 3 ème possibilité c'est que pour booter plus vite, j'ai dit à
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é.



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é.
1 2