Je viens de changer un disque dans une grappe raid6 et j'ai un petit
problème de superbloc qui fait que la grappe ne monte pas
automatiquement lors du démarrage du serveur.
sde m'a fait des misères et je l'ai changé. Même partitionnement que
les autres (une seule partition de 73 Go), commençant au même
endroit que les autres et terminant exactement sur le même cylindre.
Tous les disques proviennent du même fabricant et sont parfaitement
identiques.
Root rayleigh:[/etc/mdadm] > mdadm --examine /dev/sdc1
...
Version : 0.90.00
...
Creation Time : Sun Dec 17 16:56:20 2006
...
Dès que j'ajoute /dev/sde1 par mdadm -a /dev/md7 /dev/sde1,
je me retrouve avec un supebloc à la fois sur /dev/sde et sur
/dev/sde1 (!). Cela semble même être le même puisque dès que je vire
le superbloc de /dev/sde, celui de /dev/sde1 disparaît aussi.
Pourtant, je disque sde est partitionné comme suit (et comme tous
les autres) :
Root rayleigh:[/etc/mdadm] > fdisk /dev/sde
Command (m for help): p
Disk /dev/sde: 73.5 GB, 73543163904 bytes
255 heads, 63 sectors/track, 8941 cylinders, total 143638992 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sde1 63 143637164 71818551 fd Linux raid autodetect
Problème : lors du boot, le truc me détecte que /dev/sde et
/dev/sde1 ont des superblocs très proches (tu m'étonnes) et refuse
de le monter me rendant la main avec l'horripilant prompt root pour
remettre d'équerre le système.
Étant borné, j'ai fait un dd de /dev/sdc sur /dev/sde histoire
d'être vraiment sûr que ce partitionnement est identique en tout
point. J'ai vérifié les superblocs, rien à dire, mais dès que je
remonte /dev/sde1 dans la grappe, j'ai de nouveau ce @à#~{@{\ de
superbloc à la fois sur /dev/sde et sur /dev/sde1 !
Y a-t-il une solution ? Je viens de googliser toute la soirée sans
rien trouver... J'ai naturellement essayer les classiques
--zero-superbloc. Rien n'y fait. La machine fautive est une sparc64
tournant sous Debian/testing.
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé dans des cas similaires (En fait, le disque fautif ne s'était pas déclaré en 'fail' correctement. En le forçant à la main, et en reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire 'mdadm -A' ?
-- Le mode sans échec de Windows est la preuve que son mode normal est un échec !
SONY : It only does everything ... until we remove ! PS3 Firmware update 3.21 : The first software update which downgrade !
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé
dans des cas similaires (En fait, le disque fautif ne s'était pas
déclaré en 'fail' correctement. En le forçant à la main, et en
reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les
ordres').
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé dans des cas similaires (En fait, le disque fautif ne s'était pas déclaré en 'fail' correctement. En le forçant à la main, et en reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire 'mdadm -A' ?
-- Le mode sans échec de Windows est la preuve que son mode normal est un échec !
SONY : It only does everything ... until we remove ! PS3 Firmware update 3.21 : The first software update which downgrade !
JKB
Le Tue, 20 Dec 2011 07:14:47 +0100, NiKo écrivait :
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé dans des cas similaires (En fait, le disque fautif ne s'était pas déclaré en 'fail' correctement. En le forçant à la main, et en reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire 'mdadm -A' ?
Merci pour ces liens que je ne connaissais pas. Je veux bien écrire mdadm -a /dev/md7 /dev/sde1 pour ajouter le disque à la grappe existante.
J'ai essayé d'utiliser la technique indiquée dans le second papier pour virer le superbloc autoritairement. Rien n'y fait, dès que je rajouter /dev/sde1 à la grappe, je me retrouve avec un superbloc sur /dev/sde et sur /dev/sde1 !
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Tue, 20 Dec 2011 07:14:47 +0100,
NiKo <NiKo@nomail.svp> écrivait :
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé
dans des cas similaires (En fait, le disque fautif ne s'était pas
déclaré en 'fail' correctement. En le forçant à la main, et en
reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les
ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire
'mdadm -A' ?
Merci pour ces liens que je ne connaissais pas. Je veux bien écrire
mdadm -a /dev/md7 /dev/sde1 pour ajouter le disque à la grappe
existante.
J'ai essayé d'utiliser la technique indiquée dans le second papier
pour virer le superbloc autoritairement. Rien n'y fait, dès que je
rajouter /dev/sde1 à la grappe, je me retrouve avec un superbloc sur
/dev/sde et sur /dev/sde1 !
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Tue, 20 Dec 2011 07:14:47 +0100, NiKo écrivait :
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé dans des cas similaires (En fait, le disque fautif ne s'était pas déclaré en 'fail' correctement. En le forçant à la main, et en reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire 'mdadm -A' ?
Merci pour ces liens que je ne connaissais pas. Je veux bien écrire mdadm -a /dev/md7 /dev/sde1 pour ajouter le disque à la grappe existante.
J'ai essayé d'utiliser la technique indiquée dans le second papier pour virer le superbloc autoritairement. Rien n'y fait, dès que je rajouter /dev/sde1 à la grappe, je me retrouve avec un superbloc sur /dev/sde et sur /dev/sde1 !
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
JKB
Le Tue, 20 Dec 2011 07:14:47 +0100, NiKo écrivait :
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé dans des cas similaires (En fait, le disque fautif ne s'était pas déclaré en 'fail' correctement. En le forçant à la main, et en reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire 'mdadm -A' ?
Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le volume raid de 0.9 en 1.x sur la mailing list. Je vais donc destratifier les messages et tenter l'opération.
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Tue, 20 Dec 2011 07:14:47 +0100,
NiKo <NiKo@nomail.svp> écrivait :
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé
dans des cas similaires (En fait, le disque fautif ne s'était pas
déclaré en 'fail' correctement. En le forçant à la main, et en
reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les
ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire
'mdadm -A' ?
Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un
bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux
superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le
volume raid de 0.9 en 1.x sur la mailing list. Je vais donc
destratifier les messages et tenter l'opération.
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Tue, 20 Dec 2011 07:14:47 +0100, NiKo écrivait :
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé dans des cas similaires (En fait, le disque fautif ne s'était pas déclaré en 'fail' correctement. En le forçant à la main, et en reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire 'mdadm -A' ?
Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le volume raid de 0.9 en 1.x sur la mailing list. Je vais donc destratifier les messages et tenter l'opération.
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
NiKo
Le 20/12/2011 14:11, JKB a écrit :
Le Tue, 20 Dec 2011 07:14:47 +0100, NiKo écrivait :
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé dans des cas similaires (En fait, le disque fautif ne s'était pas déclaré en 'fail' correctement. En le forçant à la main, et en reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire 'mdadm -A' ?
Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le volume raid de 0.9 en 1.x sur la mailing list. Je vais donc destratifier les messages et tenter l'opération.
Cordialement,
JKB
Ah tiens, je ne savais pas cela.
Si tu trouves la méthode pour migrer vers un raid v1.x, je serais intéressé. Toujours bon à avoir sous le coude, puisque je suppose que le problème se posera lors de la prochaine 'upgrade' de Debian.
Merci
-- Le mode sans échec de Windows est la preuve que son mode normal est un échec !
SONY : It only does everything ... until we remove ! PS3 Firmware update 3.21 : The first software update which downgrade !
Le 20/12/2011 14:11, JKB a écrit :
Le Tue, 20 Dec 2011 07:14:47 +0100,
NiKo <NiKo@nomail.svp> écrivait :
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé
dans des cas similaires (En fait, le disque fautif ne s'était pas
déclaré en 'fail' correctement. En le forçant à la main, et en
reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les
ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire
'mdadm -A' ?
Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un
bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux
superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le
volume raid de 0.9 en 1.x sur la mailing list. Je vais donc
destratifier les messages et tenter l'opération.
Cordialement,
JKB
Ah tiens, je ne savais pas cela.
Si tu trouves la méthode pour migrer vers un raid v1.x, je serais
intéressé. Toujours bon à avoir sous le coude, puisque je suppose que le
problème se posera lors de la prochaine 'upgrade' de Debian.
Merci
--
Le mode sans échec de Windows est la preuve que son
mode normal est un échec !
SONY : It only does everything ... until we remove !
PS3 Firmware update 3.21 :
The first software update which downgrade !
Le Tue, 20 Dec 2011 07:14:47 +0100, NiKo écrivait :
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé dans des cas similaires (En fait, le disque fautif ne s'était pas déclaré en 'fail' correctement. En le forçant à la main, et en reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire 'mdadm -A' ?
Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le volume raid de 0.9 en 1.x sur la mailing list. Je vais donc destratifier les messages et tenter l'opération.
Cordialement,
JKB
Ah tiens, je ne savais pas cela.
Si tu trouves la méthode pour migrer vers un raid v1.x, je serais intéressé. Toujours bon à avoir sous le coude, puisque je suppose que le problème se posera lors de la prochaine 'upgrade' de Debian.
Merci
-- Le mode sans échec de Windows est la preuve que son mode normal est un échec !
SONY : It only does everything ... until we remove ! PS3 Firmware update 3.21 : The first software update which downgrade !
On Tue, 20 Dec 2011 09:57:32 -0800 (PST), Toxico Nimbus wrote:
C'est-y pas plutôt mdadm /dev/md7 -a /dev/sde
Oups ! Il fallait lire /dev/sde1 biensûr
Toxico Nimbus
On Mon, 19 Dec 2011 23:18:09 +0000 (UTC), JKB wrote:
Bonjour à tous,
Je viens de changer un disque dans une grappe raid6 et j'ai un
petit
problème de superbloc qui fait que la grappe ne monte pas automatiquement lors du démarrage du serveur.
[SNIP]
Y a-t-il une solution ? Je viens de googliser toute la soirée sans rien trouver... J'ai naturellement essayer les classiques --zero-superbloc. Rien n'y fait. La machine fautive est une sparc64 tournant sous Debian/testing.
Si tu ne grub pas dessus, as-tu essayé de passer en metadata 1.2 ?
Genre zero-superblock suivi d'un create -e 1.2 (éventuellement avec --assume-clean et une prière à la divinité de ton choix).
On Mon, 19 Dec 2011 23:18:09 +0000 (UTC), JKB
<jkb@koenigsberg.invalid> wrote:
Bonjour à tous,
Je viens de changer un disque dans une grappe raid6 et j'ai un
petit
problème de superbloc qui fait que la grappe ne monte pas
automatiquement lors du démarrage du serveur.
[SNIP]
Y a-t-il une solution ? Je viens de googliser toute la soirée sans
rien trouver... J'ai naturellement essayer les classiques
--zero-superbloc. Rien n'y fait. La machine fautive est une sparc64
tournant sous Debian/testing.
Si tu ne grub pas dessus, as-tu essayé de passer en metadata 1.2 ?
Genre zero-superblock suivi d'un create -e 1.2 (éventuellement avec
--assume-clean et une prière à la divinité de ton choix).
On Mon, 19 Dec 2011 23:18:09 +0000 (UTC), JKB wrote:
Bonjour à tous,
Je viens de changer un disque dans une grappe raid6 et j'ai un
petit
problème de superbloc qui fait que la grappe ne monte pas automatiquement lors du démarrage du serveur.
[SNIP]
Y a-t-il une solution ? Je viens de googliser toute la soirée sans rien trouver... J'ai naturellement essayer les classiques --zero-superbloc. Rien n'y fait. La machine fautive est une sparc64 tournant sous Debian/testing.
Si tu ne grub pas dessus, as-tu essayé de passer en metadata 1.2 ?
Genre zero-superblock suivi d'un create -e 1.2 (éventuellement avec --assume-clean et une prière à la divinité de ton choix).
JKB
Le Tue, 20 Dec 2011 18:13:02 +0100, NiKo écrivait :
Le 20/12/2011 14:11, JKB a écrit :
Le Tue, 20 Dec 2011 07:14:47 +0100, NiKo écrivait :
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé dans des cas similaires (En fait, le disque fautif ne s'était pas déclaré en 'fail' correctement. En le forçant à la main, et en reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire 'mdadm -A' ?
Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le volume raid de 0.9 en 1.x sur la mailing list. Je vais donc destratifier les messages et tenter l'opération.
Cordialement,
JKB
Ah tiens, je ne savais pas cela.
Si tu trouves la méthode pour migrer vers un raid v1.x, je serais intéressé. Toujours bon à avoir sous le coude, puisque je suppose que le problème se posera lors de la prochaine 'upgrade' de Debian.
On m'a renvoyé sur les archives de la mailing list. Je suis en train de dépouiller...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Tue, 20 Dec 2011 18:13:02 +0100,
NiKo <NiKo@nomail.svp> écrivait :
Le 20/12/2011 14:11, JKB a écrit :
Le Tue, 20 Dec 2011 07:14:47 +0100,
NiKo <NiKo@nomail.svp> écrivait :
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé
dans des cas similaires (En fait, le disque fautif ne s'était pas
déclaré en 'fail' correctement. En le forçant à la main, et en
reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les
ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire
'mdadm -A' ?
Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un
bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux
superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le
volume raid de 0.9 en 1.x sur la mailing list. Je vais donc
destratifier les messages et tenter l'opération.
Cordialement,
JKB
Ah tiens, je ne savais pas cela.
Si tu trouves la méthode pour migrer vers un raid v1.x, je serais
intéressé. Toujours bon à avoir sous le coude, puisque je suppose que le
problème se posera lors de la prochaine 'upgrade' de Debian.
On m'a renvoyé sur les archives de la mailing list. Je suis en train
de dépouiller...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Tue, 20 Dec 2011 18:13:02 +0100, NiKo écrivait :
Le 20/12/2011 14:11, JKB a écrit :
Le Tue, 20 Dec 2011 07:14:47 +0100, NiKo écrivait :
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé dans des cas similaires (En fait, le disque fautif ne s'était pas déclaré en 'fail' correctement. En le forçant à la main, et en reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire 'mdadm -A' ?
Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le volume raid de 0.9 en 1.x sur la mailing list. Je vais donc destratifier les messages et tenter l'opération.
Cordialement,
JKB
Ah tiens, je ne savais pas cela.
Si tu trouves la méthode pour migrer vers un raid v1.x, je serais intéressé. Toujours bon à avoir sous le coude, puisque je suppose que le problème se posera lors de la prochaine 'upgrade' de Debian.
On m'a renvoyé sur les archives de la mailing list. Je suis en train de dépouiller...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
JKB
Le Tue, 20 Dec 2011 19:00:54 +0100, Toxico Nimbus écrivait :
On Tue, 20 Dec 2011 09:57:32 -0800 (PST), Toxico Nimbus wrote:
C'est-y pas plutôt mdadm /dev/md7 -a /dev/sde
Oups ! Il fallait lire /dev/sde1 biensûr
Ça fonctionne aussi dans l'autre sens. Le problème est un bug de mdadm qui ne sera pas corrigé (dixit les membres causant sur la liste raid du noyau linux).
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Tue, 20 Dec 2011 19:00:54 +0100,
Toxico Nimbus <toxn@free.fr> écrivait :
On Tue, 20 Dec 2011 09:57:32 -0800 (PST), Toxico Nimbus
<tox.nimbus@gmail.com> wrote:
C'est-y pas plutôt
mdadm /dev/md7 -a /dev/sde
Oups ! Il fallait lire /dev/sde1 biensûr
Ça fonctionne aussi dans l'autre sens. Le problème est un bug de mdadm
qui ne sera pas corrigé (dixit les membres causant sur la liste raid du
noyau linux).
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Tue, 20 Dec 2011 19:00:54 +0100, Toxico Nimbus écrivait :
On Tue, 20 Dec 2011 09:57:32 -0800 (PST), Toxico Nimbus wrote:
C'est-y pas plutôt mdadm /dev/md7 -a /dev/sde
Oups ! Il fallait lire /dev/sde1 biensûr
Ça fonctionne aussi dans l'autre sens. Le problème est un bug de mdadm qui ne sera pas corrigé (dixit les membres causant sur la liste raid du noyau linux).
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
JKB
Le Tue, 20 Dec 2011 22:06:51 +0000 (UTC), JKB écrivait :
Le Tue, 20 Dec 2011 18:13:02 +0100, NiKo écrivait :
Le 20/12/2011 14:11, JKB a écrit :
Le Tue, 20 Dec 2011 07:14:47 +0100, NiKo écrivait :
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé dans des cas similaires (En fait, le disque fautif ne s'était pas déclaré en 'fail' correctement. En le forçant à la main, et en reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire 'mdadm -A' ?
Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le volume raid de 0.9 en 1.x sur la mailing list. Je vais donc destratifier les messages et tenter l'opération.
Cordialement,
JKB
Ah tiens, je ne savais pas cela.
Si tu trouves la méthode pour migrer vers un raid v1.x, je serais intéressé. Toujours bon à avoir sous le coude, puisque je suppose que le problème se posera lors de la prochaine 'upgrade' de Debian.
On m'a renvoyé sur les archives de la mailing list. Je suis en train de dépouiller...
Bon, le problème est relativement simple. Après avoir créé la partition sur le nouveau disque, il faut appeler blockdev --rereadpt /dev/sde sous peine de se voir réattribuer le même superblock sur /dev/sde (au lieu de /dev/sde1) car l'ancienne partition était toujours en mémoire dans les tables du noyau...
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Tue, 20 Dec 2011 22:06:51 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> écrivait :
Le Tue, 20 Dec 2011 18:13:02 +0100,
NiKo <NiKo@nomail.svp> écrivait :
Le 20/12/2011 14:11, JKB a écrit :
Le Tue, 20 Dec 2011 07:14:47 +0100,
NiKo <NiKo@nomail.svp> écrivait :
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé
dans des cas similaires (En fait, le disque fautif ne s'était pas
déclaré en 'fail' correctement. En le forçant à la main, et en
reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les
ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire
'mdadm -A' ?
Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un
bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux
superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le
volume raid de 0.9 en 1.x sur la mailing list. Je vais donc
destratifier les messages et tenter l'opération.
Cordialement,
JKB
Ah tiens, je ne savais pas cela.
Si tu trouves la méthode pour migrer vers un raid v1.x, je serais
intéressé. Toujours bon à avoir sous le coude, puisque je suppose que le
problème se posera lors de la prochaine 'upgrade' de Debian.
On m'a renvoyé sur les archives de la mailing list. Je suis en train
de dépouiller...
Bon, le problème est relativement simple. Après avoir créé la
partition sur le nouveau disque, il faut appeler blockdev --rereadpt
/dev/sde sous peine de se voir réattribuer le même superblock sur
/dev/sde (au lieu de /dev/sde1) car l'ancienne partition était
toujours en mémoire dans les tables du noyau...
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Tue, 20 Dec 2011 22:06:51 +0000 (UTC), JKB écrivait :
Le Tue, 20 Dec 2011 18:13:02 +0100, NiKo écrivait :
Le 20/12/2011 14:11, JKB a écrit :
Le Tue, 20 Dec 2011 07:14:47 +0100, NiKo écrivait :
Le 20/12/2011 00:18, JKB a écrit :
Bonjour à tous,
Tiens, je ne saurais que te pointer sur ces pages qui m'ont déjà aidé dans des cas similaires (En fait, le disque fautif ne s'était pas déclaré en 'fail' correctement. En le forçant à la main, et en reconstruisant le raid avec le nouveau disque, tout est rentré 'dans les ordres').
PS : Je suis tout de même étonné de ton 'mdadm -a' ... Voulais tu dire 'mdadm -A' ?
Bon, j'ai eu une réponse sur la kernel mailing list. Il s'agit d'un bug récent de mdadm qui ne serapas corrigé (puisqu'on en est aux superblocs 1.x). Il paraît qu'il y a une manipulation pour migrer le volume raid de 0.9 en 1.x sur la mailing list. Je vais donc destratifier les messages et tenter l'opération.
Cordialement,
JKB
Ah tiens, je ne savais pas cela.
Si tu trouves la méthode pour migrer vers un raid v1.x, je serais intéressé. Toujours bon à avoir sous le coude, puisque je suppose que le problème se posera lors de la prochaine 'upgrade' de Debian.
On m'a renvoyé sur les archives de la mailing list. Je suis en train de dépouiller...
Bon, le problème est relativement simple. Après avoir créé la partition sur le nouveau disque, il faut appeler blockdev --rereadpt /dev/sde sous peine de se voir réattribuer le même superblock sur /dev/sde (au lieu de /dev/sde1) car l'ancienne partition était toujours en mémoire dans les tables du noyau...
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
