Re: Restauration d'une config LVM / mdadm raid 1

2016-02-03 Par sujet Damien TOURDE 
Bonjour,

On 03/02/2016 00:05, Pascal Hambourg wrote:
> /dev/md0: TYPE="promise_fasttrack_raid_member"
> A mon avis, je le répète, c'est de ce côté qu'il faut chercher.
>
>
>
Je pense que tu as raison Pascal, je n'avais pas saisi la signification
de "promise".

Il y a fort longtemps, du temps où j'ignorais la "débilité", et le
risque, du raid pseudo-hardware (ce sont des disques de 150Go tout de
même, il y a plus récent), ces disques étaient utilisés avec un fakeraid
d'une CM MSI.

Depuis, je l'ai ai utilisés sur un petit serveur en RAID mdadm, sans
gros soucis, et à nouveau en RAID mdadm aujourd'hui en attendant de
renouveler les disques pour plus gros.
J'ai arrêté de les mettre sur le serveur car, d'une part, le serveur
n'est plus, et d'autre part, il "grattent" fort donc boucan du diable.

Soit je les ai mal formatés et ils contiennent encore des superblocks de
l'ancien raid géré par le chipset de la vieille CM, soit j'ai fait une
boulette dans la config de ma CM actuelle, je vais creuser là dessus.


Mais je ne trouve pas de cas similaires ou approchant sur Google, il va
falloir faire ça "à l'ancienne", si j'y arrive...


En revanche, je n'avais pas rencontré de soucis sur mon ancien serveur
au niveau du boot... et là, c'est pas logique...

Re: Restauration d'une config LVM / mdadm raid 1

2016-02-02 Par sujet Damien TOURDE 
Si ça peut donner une piste, je n'ai pas trace de mon raid dans :

root@olorin-fixe:~# ls -al /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 120 févr.  2 19:02 .
drwxr-xr-x 5 root root 100 févr.  2 19:02 ..
lrwxrwxrwx 1 root root  10 févr.  2 19:02
431f08fe-abcf-4c69-909e-0433a5626906 -> ../../sda1
lrwxrwxrwx 1 root root  10 févr.  2 19:02
75f98820-d831-4285-9a38-c2a621f52d49 -> ../../dm-0
lrwxrwxrwx 1 root root  10 févr.  2 19:02
829e1d02-f563-48f0-a042-e95ef5cd1b15 -> ../../dm-1
lrwxrwxrwx 1 root root  10 févr.  2 19:02
a0a69a8d-080f-4535-87d0-4b91261e854a -> ../../dm-2

root@olorin-fixe:~# 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/sda1: UUID="431f08fe-abcf-4c69-909e-0433a5626906" TYPE="ext2"
PARTUUID="a89006b2-01"
/dev/sda5: UUID="4sm0Ld-dD6D-scQm-53Lp-BjrT-tFmd-bdPwAV"
TYPE="LVM2_member" PARTUUID="a89006b2-05"
/dev/mapper/olorin--fixe--vg-root:
UUID="75f98820-d831-4285-9a38-c2a621f52d49" TYPE="ext4"
/dev/mapper/olorin--fixe--vg-swap_1:
UUID="829e1d02-f563-48f0-a042-e95ef5cd1b15" TYPE="swap"
/dev/md0: TYPE="promise_fasttrack_raid_member"
/dev/mapper/olorin--fixe--vg-home:
UUID="a0a69a8d-080f-4535-87d0-4b91261e854a" TYPE="ext4"


Pour rappel :

sda -> SSD système avec LVM
sdb+sdc -> RAID 1 mdadm avec LVM (storage)

On 02/02/2016 20:25, Damien TOURDE wrote:
> Bonsoir,
>
> Alors petite rectif, c'est avec "vgimport -a" que mon volume réapparaît.
> Alors que je n'ai jamais fait de vgexport de mes volumes...
>
> D'ailleurs, il me le confirme :
>
> root@olorin-fixe:~# vgimport -a
>   Volume group "olorin-fixe-vg" is not exported
>   Volume group "olorin-fixe-storage" is not exported
>
>
> En revanche, lorsque je remets mon volume dans fstab, je boot en mode
> single-user (avec systemd qui attends 1m30s que le disque réponde).
>
> Voici le log (tronqué) du boot single-user :
> PS: si vous avez besoin du log complet... je le mettrais, mais bon, un
> log de boot c'est un peu gros en
> mail !
>
> [...]
>
> scsi 2:0:0:0: Direct-Access ATA  HDS722516VLSA80  A6MA PQ: 0 ANSI: 5
> févr. 02 18:58:08 olorin-fixe kernel: ata6: SATA link down (SStatus 4
> SControl 300)
> févr. 02 18:58:08 olorin-fixe kernel: scsi 4:0:0:0: Direct-Access
> ATA  HDS722516VLSA80  A6MA PQ: 0 ANSI: 5
> févr. 02 18:58:08 olorin-fixe kernel: sd 1:0:0:0: [sda] 976773168
> 512-byte logical blocks: (500 GB/465 GiB)
> févr. 02 18:58:08 olorin-fixe kernel: sd 2:0:0:0: [sdb] 321672960
> 512-byte logical blocks: (164 GB/153 GiB)
> févr. 02 18:58:08 olorin-fixe kernel: sd 2:0:0:0: [sdb] Write Protect is off
> févr. 02 18:58:08 olorin-fixe kernel: sd 2:0:0:0: [sdb] Mode Sense: 00
> 3a 00 00
> févr. 02 18:58:08 olorin-fixe kernel: sd 1:0:0:0: [sda] Write Protect is off
> févr. 02 18:58:08 olorin-fixe kernel: sd 1:0:0:0: [sda] Mode Sense: 00
> 3a 00 00
> févr. 02 18:58:08 olorin-fixe kernel: sd 2:0:0:0: [sdb] Write cache:
> enabled, read cache: enabled, doesn't support DPO or FUA
> févr. 02 18:58:08 olorin-fixe kernel: sd 1:0:0:0: [sda] Write cache:
> enabled, read cache: enabled, doesn't support DPO or FUA
> févr. 02 18:58:08 olorin-fixe kernel: sd 4:0:0:0: [sdc] 321672960
> 512-byte logical blocks: (164 GB/153 GiB)
> févr. 02 18:58:08 olorin-fixe kernel: sd 4:0:0:0: [sdc] Write Protect is off
> févr. 02 18:58:08 olorin-fixe kernel: sd 4:0:0:0: [sdc] Mode Sense: 00
> 3a 00 00
> févr. 02 18:58:08 olorin-fixe kernel: sd 4:0:0:0: [sdc] Write cache:
> enabled, read cache: enabled, doesn't support DPO or FUA
> févr. 02 18:58:08 olorin-fixe kernel:  sda: sda1 sda2 < sda5 >
> févr. 02 18:58:08 olorin-fixe kernel: sd 1:0:0:0: [sda] Attached SCSI disk
> févr. 02 18:58:08 olorin-fixe kernel: e1000e :00:1f.6 eth0:
> registered PHC clock
> févr. 02 18:58:08 olorin-fixe kernel: e1000e :00:1f.6 eth0: (PCI
> Express:2.5GT/s:Width x1) 30:5a:3a:83:4f:e6
> févr. 02 18:58:08 olorin-fixe kernel: e1000e :00:1f.6 eth0: Intel(R)
> PRO/1000 Network Connection
> févr. 02 18:58:08 olorin-fixe kernel: e1000e :00:1f.6 eth0: MAC: 12,
> PHY: 12, PBA No: FF-0FF
> févr. 02 18:58:08 olorin-fixe kernel: e1000e :00:1f.6 enp0s31f6:
> renamed from eth0
> févr. 02 18:58:08 olorin-fixe kernel:  sdb: sdb1
> févr. 02 18:58:08 olorin-fixe kernel: sd 2:0:0:0: [sdb] Attached SCSI disk
> févr. 02 18:58:08 olorin-fixe kernel:  sdc: sdc1
> févr. 02 18:58:08 olorin-fixe kernel: sd 4:0:0:0: [sdc] Attached SCSI disk
>
> [...]
>
> -- L'unité (unit) hdparm.service a terminé son démarrage, avec le
> résultat done.
> févr. 02 18:58:08 olorin-fixe kernel: md: md0 stopped.
> févr. 02 18:58:08 olorin-fixe kernel: md: bind
> févr. 02 18:58:08 olorin-fixe kernel: md: bind
> févr. 02 18:58:08 olorin-fixe kernel: usb 1-8: new full-speed USB device
> number 4 using

Re: Restauration d'une config LVM / mdadm raid 1

2016-02-02 Par sujet Damien TOURDE 
Bonsoir,

Alors petite rectif, c'est avec "vgimport -a" que mon volume réapparaît.
Alors que je n'ai jamais fait de vgexport de mes volumes...

D'ailleurs, il me le confirme :

root@olorin-fixe:~# vgimport -a
  Volume group "olorin-fixe-vg" is not exported
  Volume group "olorin-fixe-storage" is not exported


En revanche, lorsque je remets mon volume dans fstab, je boot en mode
single-user (avec systemd qui attends 1m30s que le disque réponde).

Voici le log (tronqué) du boot single-user :
PS: si vous avez besoin du log complet... je le mettrais, mais bon, un
log de boot c'est un peu gros en
mail !

[...]

scsi 2:0:0:0: Direct-Access ATA  HDS722516VLSA80  A6MA PQ: 0 ANSI: 5
févr. 02 18:58:08 olorin-fixe kernel: ata6: SATA link down (SStatus 4
SControl 300)
févr. 02 18:58:08 olorin-fixe kernel: scsi 4:0:0:0: Direct-Access
ATA  HDS722516VLSA80  A6MA PQ: 0 ANSI: 5
févr. 02 18:58:08 olorin-fixe kernel: sd 1:0:0:0: [sda] 976773168
512-byte logical blocks: (500 GB/465 GiB)
févr. 02 18:58:08 olorin-fixe kernel: sd 2:0:0:0: [sdb] 321672960
512-byte logical blocks: (164 GB/153 GiB)
févr. 02 18:58:08 olorin-fixe kernel: sd 2:0:0:0: [sdb] Write Protect is off
févr. 02 18:58:08 olorin-fixe kernel: sd 2:0:0:0: [sdb] Mode Sense: 00
3a 00 00
févr. 02 18:58:08 olorin-fixe kernel: sd 1:0:0:0: [sda] Write Protect is off
févr. 02 18:58:08 olorin-fixe kernel: sd 1:0:0:0: [sda] Mode Sense: 00
3a 00 00
févr. 02 18:58:08 olorin-fixe kernel: sd 2:0:0:0: [sdb] Write cache:
enabled, read cache: enabled, doesn't support DPO or FUA
févr. 02 18:58:08 olorin-fixe kernel: sd 1:0:0:0: [sda] Write cache:
enabled, read cache: enabled, doesn't support DPO or FUA
févr. 02 18:58:08 olorin-fixe kernel: sd 4:0:0:0: [sdc] 321672960
512-byte logical blocks: (164 GB/153 GiB)
févr. 02 18:58:08 olorin-fixe kernel: sd 4:0:0:0: [sdc] Write Protect is off
févr. 02 18:58:08 olorin-fixe kernel: sd 4:0:0:0: [sdc] Mode Sense: 00
3a 00 00
févr. 02 18:58:08 olorin-fixe kernel: sd 4:0:0:0: [sdc] Write cache:
enabled, read cache: enabled, doesn't support DPO or FUA
févr. 02 18:58:08 olorin-fixe kernel:  sda: sda1 sda2 < sda5 >
févr. 02 18:58:08 olorin-fixe kernel: sd 1:0:0:0: [sda] Attached SCSI disk
févr. 02 18:58:08 olorin-fixe kernel: e1000e :00:1f.6 eth0:
registered PHC clock
févr. 02 18:58:08 olorin-fixe kernel: e1000e :00:1f.6 eth0: (PCI
Express:2.5GT/s:Width x1) 30:5a:3a:83:4f:e6
févr. 02 18:58:08 olorin-fixe kernel: e1000e :00:1f.6 eth0: Intel(R)
PRO/1000 Network Connection
févr. 02 18:58:08 olorin-fixe kernel: e1000e :00:1f.6 eth0: MAC: 12,
PHY: 12, PBA No: FF-0FF
févr. 02 18:58:08 olorin-fixe kernel: e1000e :00:1f.6 enp0s31f6:
renamed from eth0
févr. 02 18:58:08 olorin-fixe kernel:  sdb: sdb1
févr. 02 18:58:08 olorin-fixe kernel: sd 2:0:0:0: [sdb] Attached SCSI disk
févr. 02 18:58:08 olorin-fixe kernel:  sdc: sdc1
févr. 02 18:58:08 olorin-fixe kernel: sd 4:0:0:0: [sdc] Attached SCSI disk

[...]

-- L'unité (unit) hdparm.service a terminé son démarrage, avec le
résultat done.
févr. 02 18:58:08 olorin-fixe kernel: md: md0 stopped.
févr. 02 18:58:08 olorin-fixe kernel: md: bind
févr. 02 18:58:08 olorin-fixe kernel: md: bind
févr. 02 18:58:08 olorin-fixe kernel: usb 1-8: new full-speed USB device
number 4 using xhci_hcd
févr. 02 18:58:08 olorin-fixe kernel: md: raid1 personality registered
for level 1
févr. 02 18:58:08 olorin-fixe kernel: md/raid1:md0: active with 2 out of
2 mirrors
févr. 02 18:58:08 olorin-fixe kernel: created bitmap (2 pages) for
device md0
févr. 02 18:58:08 olorin-fixe kernel: md0: bitmap initialized from disk:
read 1 pages, set 0 of 2453 bits
févr. 02 18:58:08 olorin-fixe kernel: md0: detected capacity change from
0 to 164561289216
févr. 02 18:58:08 olorin-fixe mdadm-raid[249]: Assembling MD array
md0...done (started [2/2]).
févr. 02 18:58:08 olorin-fixe mdadm-raid[249]: Generating udev events
for MD arrays...done.
févr. 02 18:58:08 olorin-fixe systemd[1]: Started LSB: MD array assembly.
-- Subject: L'unité (unit) mdadm-raid.service a terminé son démarrage
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- L'unité (unit) mdadm-raid.service a terminé son démarrage, avec le
résultat done.
févr. 02 18:58:08 olorin-fixe systemd[1]: Started MD array monitor.
-- Subject: L'unité (unit) mdmonitor.service a terminé son démarrage
-- Defined-By: systemd

[...]

févr. 02 18:59:38 olorin-fixe systemd[1]:
dev-disk-by\x2duuid-f84fe148\x2da775\x2deac4\x2d76ff\x2d776e5845be39.device:
Job
dev-disk-by\x2duuid-f84fe148\x2da775\x2deac4\x2d76ff\x2d776e5845be39.device/start
timed out.
févr. 02 18:59:38 olorin-fixe systemd[1]: Timed out waiting for device
dev-disk-by\x2duuid-f84fe148\x2da775\x2deac4\x2d76ff\x2d776e5845be39.device.
-- Subject: L'unité (unit)
dev-disk-by\x2duuid-f84fe148\x2da775\x2deac4\x2d76ff\x2d776e5845be39.device
a échoué
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- L'unité (unit)

Re: Restauration d'une config LVM / mdadm raid 1

2016-02-02 Par sujet Pascal Hambourg 
Damien TOURDE a écrit :
> Si ça peut donner une piste, je n'ai pas trace de mon raid dans :
> 
> root@olorin-fixe:~# ls -al /dev/disk/by-uuid/

Normal, pas plus qu'il n'y a de trace de sda5 qui contient aussi un PV
LVM et non un système de fichiers ou un swap.

> root@olorin-fixe:~# blkid
(...)
> /dev/md0: TYPE="promise_fasttrack_raid_member"

A mon avis, je le répète, c'est de ce côté qu'il faut chercher.

Re: Restauration d'une config LVM / mdadm raid 1

2016-02-01 Par sujet 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

Re: Restauration d'une config LVM / mdadm raid 1

2016-02-01 Par sujet 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.
>
>
>

Re: Restauration d'une config LVM / mdadm raid 1

2016-02-01 Par sujet 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) :

root@olorin-fixe:~# vgdisplay

  --- Volume group ---
  VG Name   olorin-fixe-storage
  System ID
  Formatlvm2
  Metadata Areas1
  Metadata Sequence No  2
  VG Access read/write
  VG Status resizable
  MAX LV0
  Cur LV1
  Open LV   0
  Max PV0
  Cur PV1
  Act PV1
  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

root@olorin-fixe:~# 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


root@olorin-fixe:~# lvdisplay

  --- Logical volume ---
  LV Path/dev/olorin-fixe-storage/lvstorage0
  LV Namelvstorage0
  VG Nameolorin-fixe-storage
  LV UUIDUiPmCd-2655-ebnc-24Fk-GLqp-bGkj-MKhu7j
  LV Write Accessread/write
  LV Creation host, time olorin-fixe, 2016-01-17 23:01:59 +0100
  LV Status  NOT available
  LV Size100,00 GiB
  Current LE 25600
  Segments   1
  Allocation inherit
  Read ahead sectors auto



--

Puis un petit coup de :
root@olorin-fixe:~# 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 ?
>>> root@olorin-fixe:~# 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.
>>
>>> root@olorin-fixe:~# 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.
>>
>>> root@olorin-fixe:~# 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.
>>
>>
>>
>
>

Re: Restauration d'une config LVM / mdadm raid 1

2016-02-01 Par sujet 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.

Re: Restauration d'une config LVM / mdadm raid 1

2016-02-01 Par sujet 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,
>

Re: Restauration d'une config LVM / mdadm raid 1

2016-02-01 Par sujet 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é.

Re: Restauration d'une config LVM / mdadm raid 1

2016-01-31 Par sujet 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 ?
root@olorin-fixe:~# 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


root@olorin-fixe:~# fdisk -l /dev/sdb
Disque /dev/sdb : 153,4 GiB, 16469620 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é
root@olorin-fixe:~# fdisk -l /dev/sdc
Disque /dev/sdc : 153,4 GiB, 16469620 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é
root@olorin-fixe:~#


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


root@olorin-fixe:~# 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 :

root@olorin-fixe:~# 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 :

root@olorin-fixe:~# 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.

>
>> root@olorin-fixe:~# 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...

root@olorin-fixe:~# 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=f84fe148: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 = []

Re: Restauration d'une config LVM / mdadm raid 1

2016-01-31 Par sujet 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 ?

> root@olorin-fixe:~# 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 ?

Re: Restauration d'une config LVM / mdadm raid 1

2016-01-31 Par sujet 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 ?
>> root@olorin-fixe:~# 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.
>
>> root@olorin-fixe:~# 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.
>
>> root@olorin-fixe:~# 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.
>
>
>

Re: Restauration d'une config LVM / mdadm raid 1

2016-01-31 Par sujet 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 ?
> root@olorin-fixe:~# 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.

> root@olorin-fixe:~# 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.

> root@olorin-fixe:~# 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.