C'est un RAID 1 mdadm, avec une unique partition LVM
J'ai mis dans le fichier de backup l'uuid que me donne blkid
:~# e2fsck -f /dev/md0
C'est un RAID 1 mdadm, avec une unique partition LVM
J'ai mis dans le fichier de backup l'uuid que me donne blkid
root@olorin-fixe:~# e2fsck -f /dev/md0
C'est un RAID 1 mdadm, avec une unique partition LVM
J'ai mis dans le fichier de backup l'uuid que me donne blkid
:~# e2fsck -f /dev/md0
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 ?
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 ?
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 ?
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
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"
:~# file -s /dev/md0
/dev/md0: LVM2 PV (Linux Logical Volume Manager), UUID:
b6SEem-WYJK-xcUT-946V-lS0q-Yxic-yFWaxf, size: 164561289216
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
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"
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
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
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"
:~# file -s /dev/md0
/dev/md0: LVM2 PV (Linux Logical Volume Manager), UUID:
b6SEem-WYJK-xcUT-946V-lS0q-Yxic-yFWaxf, size: 164561289216
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.
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.
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.
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.
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.
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.
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".
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".
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".
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,
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,
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,
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.
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.
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.
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.
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.
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.
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é.
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é.
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é.