J'essaie de mettre en place un RAID 1 logiciel sur 2 disques durs
Hitachi SATA de 80 Go pluggués sur une carte controleur PCI SATA de
marque SUNIX SATA2000 avec chipset SiI 3112 A.
Je n'ai pas construit de RAID 'matériel' avec le bios de la carte
controleur.
Je veux faire du raid uniquement sur un disque de stokage, mon / est
monté sur un autre IDE PATA.
Mon problème est que lorsque je reboote, le raid ne se monte pas car
visiblement il a un pb de superblocks.
Voici la liste des opérations effectuées :
- recompilation du noyau evec les options nécessaires :
- SCSI device support (Silicon Image SATA support)
- RAID (raid1)
- installation du package mdadm
- création d'une partition de type Linux raid autodetect (fd) de même
taille sur chacun des disques (sda et sdb) : sda1 et sdb1
- création du système de fichier :
mkreiserfs /dev/md0
- montage de md0 :
mkdir /mnt/array
mount /dev/md0 /mnt/array
- j'adapte mon fstab pour que l'array soit monté au démarrage en y
ajoutant la ligne :
/dev/md0 /mnt/array reiserfs defaults 0 2
Jusque là tout va bien, je peux créer un fichier, voir l'état du RAID
(mdadm --detail /dev/md0), simuler une défaillance sur un des disques
(mdadm /dev/md0 --fail /dev/sda), ajouter un disque de spare ... bref
tout à l'air de fonctionner à merveille. Mais au reboot, ca foire et à
mon avis ca commence à foirer lors du message :
md: invalid superblock checksum on sdb1
md: sdb1 has invalid sb, not importing!
md: md_import_device returned -22
Voici un extrait de mon 'dmesg | less':
Linux version 2.6.8 (root@axteka) (version gcc 3.3.5 (Debian 1:3.3.5-5))
...
libata version 1.02 loaded.
sata_sil version 0.54
PCI: Found IRQ 10 for device 0000:00:09.0
ata1: SATA max UDMA/100 cmd 0xC8804080 ctl 0xC880408A bmdma 0xC8804000
irq 10
ata2: SATA max UDMA/100 cmd 0xC88040C0 ctl 0xC88040CA bmdma 0xC8804008
irq 10
ata1: dev 0 cfg 49:2f00 82:74eb 83:7fea 84:4023 85:74e9 86:3c02 87:4023
88:203f
ata1: dev 0 ATA, max UDMA/100, 160836480 sectors: lba48
ata1: dev 0 configured for UDMA/100
scsi0 : sata_sil
ata2: dev 0 cfg 49:2f00 82:74eb 83:7fea 84:4023 85:74e8 86:3c02 87:4023
88:203f
ata2: dev 0 ATA, max UDMA/100, 160836480 sectors: lba48
ata2: dev 0 configured for UDMA/100
scsi1 : sata_sil
Vendor: ATA Model: HDS722580VLSA80 Rev: V32O
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: HDS722580VLSA80 Rev: V32O
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 160836480 512-byte hdwr sectors (82348 MB)
SCSI device sda: drive cache: write back
sda: sda1
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sdb: 160836480 512-byte hdwr sectors (82348 MB)
SCSI device sdb: drive cache: write back
sdb: sdb1
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
...
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: md0 stopped.
md: invalid superblock checksum on sdb1
md: sdb1 has invalid sb, not importing!
md: md_import_device returned -22
md: invalid superblock checksum on sda1
md: sda1 has invalid sb, not importing!
md: md_import_device returned -22
...
EXT3-fs: unable to read superblock
La dernière ligne, c'est quand il essaie de faire fsckeck sur md0, et
là, il entre dans un shell pour que le fasse manuellement.
Et la tout va bien, je peux monter /dev/md0, ecrire dedans, simuler des pannes, bref tout va bien ... jusqu'au reboot.
Nickel, donc c'est prpbablement lors du boot que ça gauffre (je dis probablement car je me suis retrouvé dans une situation similaire, /dev/md fonctionnel mais pas complètement).
Tout en dur, Ca n'a rien changé. Je commence a désespérer.
'Faut pas... As tu configuré mdadm pour démarrer dans /etc/default/mdadm:
<<<< [/etc/default/mdadm] # This file is automatically generated. # Run 'dpkg-reconfigure mdadm' to modify it. START_DAEMONúlse MAIL_TO="root" AUTOSTARTúlse
Vu que j'utilise pas mdadm ça n'est pas modifié mais dans ton cas je crois que je mettrais AUTOSTART à true (dpkg-reconfigure)...
Jette aussi un oeil à ce que fait /etc/init.d/mdadm-raid
bye
JKr
DaXav wrote:
Et la tout va bien, je peux monter /dev/md0, ecrire dedans, simuler des
pannes, bref tout va bien ... jusqu'au reboot.
Nickel, donc c'est prpbablement lors du boot que ça gauffre (je dis
probablement car je me suis retrouvé dans une situation similaire, /dev/md
fonctionnel mais pas complètement).
Tout en dur, Ca n'a rien changé.
Je commence a désespérer.
'Faut pas... As tu configuré mdadm pour démarrer dans /etc/default/mdadm:
<<<< [/etc/default/mdadm]
# This file is automatically generated.
# Run 'dpkg-reconfigure mdadm' to modify it.
START_DAEMONúlse
MAIL_TO="root"
AUTOSTARTúlse
Vu que j'utilise pas mdadm ça n'est pas modifié mais dans ton cas je
crois que je mettrais AUTOSTART à true (dpkg-reconfigure)...
Jette aussi un oeil à ce que fait /etc/init.d/mdadm-raid
Et la tout va bien, je peux monter /dev/md0, ecrire dedans, simuler des pannes, bref tout va bien ... jusqu'au reboot.
Nickel, donc c'est prpbablement lors du boot que ça gauffre (je dis probablement car je me suis retrouvé dans une situation similaire, /dev/md fonctionnel mais pas complètement).
Tout en dur, Ca n'a rien changé. Je commence a désespérer.
'Faut pas... As tu configuré mdadm pour démarrer dans /etc/default/mdadm:
<<<< [/etc/default/mdadm] # This file is automatically generated. # Run 'dpkg-reconfigure mdadm' to modify it. START_DAEMONúlse MAIL_TO="root" AUTOSTARTúlse
Vu que j'utilise pas mdadm ça n'est pas modifié mais dans ton cas je crois que je mettrais AUTOSTART à true (dpkg-reconfigure)...
Jette aussi un oeil à ce que fait /etc/init.d/mdadm-raid
bye
JKr
DaXav
Tout en dur, Ca n'a rien changé. Je commence a désespérer.
'Faut pas... As tu configuré mdadm pour démarrer dans /etc/default/mdadm:
<<<< [/etc/default/mdadm] # This file is automatically generated. # Run 'dpkg-reconfigure mdadm' to modify it. START_DAEMONúlse MAIL_TO="root" AUTOSTARTúlse
Tout est ok de ce côté.
Vu que j'utilise pas mdadm ça n'est pas modifié mais dans ton cas je crois que je mettrais AUTOSTART à true (dpkg-reconfigure)...
Jette aussi un oeil à ce que fait /etc/init.d/mdadm-raid
Un truc interressant : si j'explore le superblock de mon device :
# mdadm -E /dev/sda1
/dev/sda1: Magic : a92b4efc Version : 00.90.00 UUID : fb88af98:1ddf1555:becadcc7:983e6f42 Creation Time : Sun Jun 26 14:18:43 2005 Raid Level : raid1 Raid Devices : 2 Total Devices : 2 Preferred Minor : 0
Update Time : Sun Jun 26 14:20:04 2005 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : 9f28adf3 - expected 9f28adbb Events : 0.2
Number Major Minor RaidDevice State this 0 8 1 0 active sync /dev/sda1
0 0 8 1 0 active sync /dev/sda1 1 1 8 17 1 active sync /dev/sdb1
C'est le "Checksum : 9f28adf3 - expected 9f28adbb" qui m'inquiète, et c'est bien ça qui fait râler mdadm au boot.
De plus, je suis tombé la dessus en fouillant : http://www.issociate.de/board/post/202402/cannot_write_a_new_superblock.html
Je commence à mettre en cause ma carte controleur ...
Xavier -- Ecrivez moi sans _TARDER
Tout en dur, Ca n'a rien changé.
Je commence a désespérer.
'Faut pas... As tu configuré mdadm pour démarrer dans /etc/default/mdadm:
<<<< [/etc/default/mdadm]
# This file is automatically generated.
# Run 'dpkg-reconfigure mdadm' to modify it.
START_DAEMONúlse
MAIL_TO="root"
AUTOSTARTúlse
Tout est ok de ce côté.
Vu que j'utilise pas mdadm ça n'est pas modifié mais dans ton cas je
crois que je mettrais AUTOSTART à true (dpkg-reconfigure)...
Jette aussi un oeil à ce que fait /etc/init.d/mdadm-raid
Un truc interressant : si j'explore le superblock de mon device :
# mdadm -E /dev/sda1
/dev/sda1:
Magic : a92b4efc
Version : 00.90.00
UUID : fb88af98:1ddf1555:becadcc7:983e6f42
Creation Time : Sun Jun 26 14:18:43 2005
Raid Level : raid1
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Update Time : Sun Jun 26 14:20:04 2005
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Checksum : 9f28adf3 - expected 9f28adbb
Events : 0.2
Number Major Minor RaidDevice State
this 0 8 1 0 active sync /dev/sda1
0 0 8 1 0 active sync /dev/sda1
1 1 8 17 1 active sync /dev/sdb1
C'est le "Checksum : 9f28adf3 - expected 9f28adbb" qui m'inquiète, et
c'est bien ça qui fait râler mdadm au boot.
De plus, je suis tombé la dessus en fouillant :
http://www.issociate.de/board/post/202402/cannot_write_a_new_superblock.html
Je commence à mettre en cause ma carte controleur ...
Tout en dur, Ca n'a rien changé. Je commence a désespérer.
'Faut pas... As tu configuré mdadm pour démarrer dans /etc/default/mdadm:
<<<< [/etc/default/mdadm] # This file is automatically generated. # Run 'dpkg-reconfigure mdadm' to modify it. START_DAEMONúlse MAIL_TO="root" AUTOSTARTúlse
Tout est ok de ce côté.
Vu que j'utilise pas mdadm ça n'est pas modifié mais dans ton cas je crois que je mettrais AUTOSTART à true (dpkg-reconfigure)...
Jette aussi un oeil à ce que fait /etc/init.d/mdadm-raid
Un truc interressant : si j'explore le superblock de mon device :
# mdadm -E /dev/sda1
/dev/sda1: Magic : a92b4efc Version : 00.90.00 UUID : fb88af98:1ddf1555:becadcc7:983e6f42 Creation Time : Sun Jun 26 14:18:43 2005 Raid Level : raid1 Raid Devices : 2 Total Devices : 2 Preferred Minor : 0
Update Time : Sun Jun 26 14:20:04 2005 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : 9f28adf3 - expected 9f28adbb Events : 0.2
Number Major Minor RaidDevice State this 0 8 1 0 active sync /dev/sda1
0 0 8 1 0 active sync /dev/sda1 1 1 8 17 1 active sync /dev/sdb1
C'est le "Checksum : 9f28adf3 - expected 9f28adbb" qui m'inquiète, et c'est bien ça qui fait râler mdadm au boot.
De plus, je suis tombé la dessus en fouillant : http://www.issociate.de/board/post/202402/cannot_write_a_new_superblock.html
Je commence à mettre en cause ma carte controleur ...
Number Major Minor RaidDevice State this 0 8 1 0 active sync /dev/sda1
0 0 8 1 0 active sync /dev/sda1 1 1 8 17 1 active sync /dev/sdb1
C'est le "Checksum : 9f28adf3 - expected 9f28adbb" qui m'inquiète, et c'est bien ça qui fait râler mdadm au boot.
Et sur le second (/dev/sdb1) ça donne la même chose?
De plus, je suis tombé la dessus en fouillant : http://www.issociate.de/board/post/202402/cannot_write_a_new_superblock.html
SI tu regardes bien c'est lors du passage 2.4->2.6 que ça a commecé à aller mal... Tu as essayé avec un 2.4 "récent" et avec le 2.6.12?
Je commence à mettre en cause ma carte controleur ...
Possible aussi...
bye
JKr
Emmanuel Florac
Le Tue, 28 Jun 2005 11:13:34 +0200, Julien K. a écrit :
Oui je viens de lire que "raidtools2" est un package 'de transition' mais qu'il n'est plus maintenu. Il reste cependant "raidtools" qui contient toutes les commandes nécessaires.
Non, surtout pas, mieux vaut passer à mdadm tout de suite... La marche à suivre est assez simple, heureusement.
-- Il y a toujours un bug de plus. Loi de Lubarsky.
Le Tue, 28 Jun 2005 11:13:34 +0200, Julien K. a écrit :
Oui je viens de lire que "raidtools2" est un package 'de transition' mais
qu'il n'est plus maintenu. Il reste cependant "raidtools" qui contient
toutes les commandes nécessaires.
Non, surtout pas, mieux vaut passer à mdadm tout de suite... La marche à
suivre est assez simple, heureusement.
--
Il y a toujours un bug de plus.
Loi de Lubarsky.
Le Tue, 28 Jun 2005 11:13:34 +0200, Julien K. a écrit :
Oui je viens de lire que "raidtools2" est un package 'de transition' mais qu'il n'est plus maintenu. Il reste cependant "raidtools" qui contient toutes les commandes nécessaires.
Non, surtout pas, mieux vaut passer à mdadm tout de suite... La marche à suivre est assez simple, heureusement.
-- Il y a toujours un bug de plus. Loi de Lubarsky.
Julien K.
Emmanuel Florac wrote:
Oui je viens de lire que "raidtools2" est un package 'de transition' mais qu'il n'est plus maintenu. Il reste cependant "raidtools" qui contient toutes les commandes nécessaires.
Non, surtout pas, mieux vaut passer à mdadm tout de suite... La marche à suivre est assez simple, heureusement.
Quels sont les avantages (à part le fait que raidtools n'est plus activement développé)? raidtools convient tout à fait à un cas simple comme celui de Xavier et je trouve que la présence d'un fichier de conf (/etc/raidtab) est salutaire pour éviter les conneries.
De toute façon ça ne marche pas avec mdadm pour une raison que j'ignore.
bye
JKr
Emmanuel Florac wrote:
Oui je viens de lire que "raidtools2" est un package 'de transition' mais
qu'il n'est plus maintenu. Il reste cependant "raidtools" qui contient
toutes les commandes nécessaires.
Non, surtout pas, mieux vaut passer à mdadm tout de suite... La marche à
suivre est assez simple, heureusement.
Quels sont les avantages (à part le fait que raidtools n'est plus
activement développé)? raidtools convient tout à fait à un cas simple comme
celui de Xavier et je trouve que la présence d'un fichier de conf
(/etc/raidtab) est salutaire pour éviter les conneries.
De toute façon ça ne marche pas avec mdadm pour une raison que j'ignore.
Oui je viens de lire que "raidtools2" est un package 'de transition' mais qu'il n'est plus maintenu. Il reste cependant "raidtools" qui contient toutes les commandes nécessaires.
Non, surtout pas, mieux vaut passer à mdadm tout de suite... La marche à suivre est assez simple, heureusement.
Quels sont les avantages (à part le fait que raidtools n'est plus activement développé)? raidtools convient tout à fait à un cas simple comme celui de Xavier et je trouve que la présence d'un fichier de conf (/etc/raidtab) est salutaire pour éviter les conneries.
De toute façon ça ne marche pas avec mdadm pour une raison que j'ignore.
bye
JKr
Emmanuel Florac
Le Wed, 29 Jun 2005 10:57:25 +0200, Julien K. a écrit :
De toute façon ça ne marche pas avec mdadm pour une raison que j'ignore.
En fait il faut aussi le fichier de conf avec mdadm. Il suffit de suivre l'explication debian pour passer de raidtools à mdadm, et ça marche très bien.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
Le Wed, 29 Jun 2005 10:57:25 +0200, Julien K. a écrit :
De toute façon ça ne marche pas avec mdadm pour une raison que
j'ignore.
En fait il faut aussi le fichier de conf avec mdadm. Il suffit de suivre
l'explication debian pour passer de raidtools à mdadm, et ça marche
très bien.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
Le Wed, 29 Jun 2005 10:57:25 +0200, Julien K. a écrit :
De toute façon ça ne marche pas avec mdadm pour une raison que j'ignore.
En fait il faut aussi le fichier de conf avec mdadm. Il suffit de suivre l'explication debian pour passer de raidtools à mdadm, et ça marche très bien.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
DaXav
De toute façon ça ne marche pas avec mdadm pour une raison que j'ignore.
Oui d'ailleurs je ne vois pas pourquoi on dit que mdadm ne nécessite pas de fichier de configuration.
En fait il faut aussi le fichier de conf avec mdadm. Il suffit de suivre l'explication debian pour passer de raidtools à mdadm, et ça marche très bien.
A tord ou a raison, je préfère suivre les indications en cas de paquet deprecated.
Mais comme le dit Julien, mon pb n'est pas là ...
-- Xavier
De toute façon ça ne marche pas avec mdadm pour une raison que
j'ignore.
Oui d'ailleurs je ne vois pas pourquoi on dit que mdadm ne nécessite pas
de fichier de configuration.
En fait il faut aussi le fichier de conf avec mdadm. Il suffit de suivre
l'explication debian pour passer de raidtools à mdadm, et ça marche
très bien.
A tord ou a raison, je préfère suivre les indications en cas de paquet
deprecated.
De toute façon ça ne marche pas avec mdadm pour une raison que j'ignore.
Oui d'ailleurs je ne vois pas pourquoi on dit que mdadm ne nécessite pas de fichier de configuration.
En fait il faut aussi le fichier de conf avec mdadm. Il suffit de suivre l'explication debian pour passer de raidtools à mdadm, et ça marche très bien.
A tord ou a raison, je préfère suivre les indications en cas de paquet deprecated.
Mais comme le dit Julien, mon pb n'est pas là ...
-- Xavier
Julien K.
Emmanuel Florac wrote:
Au cas où tu n'aurais pas bien compris le thread ce n'est pas moi qui suis empêtré dans le montage d'un RAID1. Le mien fonctionne nickel (même monté avec les raidtools de Gentoo).
De toute façon ça ne marche pas avec mdadm pour une raison que j'ignore.
En fait il faut aussi le fichier de conf avec mdadm.
Le fichier de config n'est pas utilisé par mdadm pour créer les panneaux, c'est possible de le faire mais pas obligatoire.
<<<< [mdadm.conf-example] # mdadm will function properly without the use of a configuration file, # but this file is useful for keeping track of arrays and member disks. # In general, a mdadm.conf file is created, and updated, after arrays # are created. This is the opposite behavior of /etc/raidtab which is # created prior to array construction.
et <http://www.linuxdevcenter.com/pub/a/linux/2002/12/05/RAID.html?page=1>
Il suffit de suivre l'explication debian pour passer de raidtools à mdadm, et ça marche très bien.
C'est vrai que Debian propose une "migration douce": il y a un demon qui se lance et qui reconnait tout de suite la structure (enfin il fait ça un peu par essai-erreur à ce que disent les logs).
Enfin mdadm et raidtools ne sont des outils de gestion "userland" des panneaux RAID et peuvent être utilisés indifféremment. Le gros du boulot est fait par le driver md du noyau. J'attends toujours de voir des arguments pertinents en faveur du changement; il y a même quelques subtilités à prendre en compte pour faire marcher mdadm avec un kernel 2.6 (udev).
bye
JKr
Emmanuel Florac wrote:
Au cas où tu n'aurais pas bien compris le thread ce n'est pas moi qui suis
empêtré dans le montage d'un RAID1. Le mien fonctionne nickel (même monté
avec les raidtools de Gentoo).
De toute façon ça ne marche pas avec mdadm pour une raison que
j'ignore.
En fait il faut aussi le fichier de conf avec mdadm.
Le fichier de config n'est pas utilisé par mdadm pour créer les panneaux,
c'est possible de le faire mais pas obligatoire.
<<<< [mdadm.conf-example]
# mdadm will function properly without the use of a configuration file,
# but this file is useful for keeping track of arrays and member disks.
# In general, a mdadm.conf file is created, and updated, after arrays
# are created. This is the opposite behavior of /etc/raidtab which is
# created prior to array construction.
et <http://www.linuxdevcenter.com/pub/a/linux/2002/12/05/RAID.html?page=1>
Il suffit de suivre l'explication debian pour passer de raidtools à
mdadm, et ça marche très bien.
C'est vrai que Debian propose une "migration douce": il y a un demon qui
se lance et qui reconnait tout de suite la structure (enfin il fait ça un
peu par essai-erreur à ce que disent les logs).
Enfin mdadm et raidtools ne sont des outils de gestion "userland" des
panneaux RAID et peuvent être utilisés indifféremment. Le gros du boulot est
fait par le driver md du noyau. J'attends toujours de voir des arguments
pertinents en faveur du changement; il y a même quelques subtilités à
prendre en compte pour faire marcher mdadm avec un kernel 2.6 (udev).
Au cas où tu n'aurais pas bien compris le thread ce n'est pas moi qui suis empêtré dans le montage d'un RAID1. Le mien fonctionne nickel (même monté avec les raidtools de Gentoo).
De toute façon ça ne marche pas avec mdadm pour une raison que j'ignore.
En fait il faut aussi le fichier de conf avec mdadm.
Le fichier de config n'est pas utilisé par mdadm pour créer les panneaux, c'est possible de le faire mais pas obligatoire.
<<<< [mdadm.conf-example] # mdadm will function properly without the use of a configuration file, # but this file is useful for keeping track of arrays and member disks. # In general, a mdadm.conf file is created, and updated, after arrays # are created. This is the opposite behavior of /etc/raidtab which is # created prior to array construction.
et <http://www.linuxdevcenter.com/pub/a/linux/2002/12/05/RAID.html?page=1>
Il suffit de suivre l'explication debian pour passer de raidtools à mdadm, et ça marche très bien.
C'est vrai que Debian propose une "migration douce": il y a un demon qui se lance et qui reconnait tout de suite la structure (enfin il fait ça un peu par essai-erreur à ce que disent les logs).
Enfin mdadm et raidtools ne sont des outils de gestion "userland" des panneaux RAID et peuvent être utilisés indifféremment. Le gros du boulot est fait par le driver md du noyau. J'attends toujours de voir des arguments pertinents en faveur du changement; il y a même quelques subtilités à prendre en compte pour faire marcher mdadm avec un kernel 2.6 (udev).
bye
JKr
DaXav
Et sur le second (/dev/sdb1) ça donne la même chose?
oui même chose.
De plus, je suis tombé la dessus en fouillant : http://www.issociate.de/board/post/202402/cannot_write_a_new_superblock.html
SI tu regardes bien c'est lors du passage 2.4->2.6 que ça a commecé à aller mal... Tu as essayé avec un 2.4 "récent" et avec le 2.6.12?
Même résultat avec un 2.6.12.1
Xavier
Et sur le second (/dev/sdb1) ça donne la même chose?
oui même chose.
De plus, je suis tombé la dessus en fouillant :
http://www.issociate.de/board/post/202402/cannot_write_a_new_superblock.html
SI tu regardes bien c'est lors du passage 2.4->2.6 que ça a commecé à
aller mal... Tu as essayé avec un 2.4 "récent" et avec le 2.6.12?
Et sur le second (/dev/sdb1) ça donne la même chose?
oui même chose.
De plus, je suis tombé la dessus en fouillant : http://www.issociate.de/board/post/202402/cannot_write_a_new_superblock.html
SI tu regardes bien c'est lors du passage 2.4->2.6 que ça a commecé à aller mal... Tu as essayé avec un 2.4 "récent" et avec le 2.6.12?
Même résultat avec un 2.6.12.1
Xavier
Julien K.
On 29-06-2005, DaXav wrote:
De plus, je suis tombé la dessus en fouillant : http://www.issociate.de/board/post/202402/cannot_write_a_new_superblock.html
Si tu regardes bien c'est lors du passage 2.4->2.6 que ça a commecé à aller mal... Tu as essayé avec un 2.4 "récent" et avec le 2.6.12?
Même résultat avec un 2.6.12.1
Bon je sais plus quoi proposer (apparemment je suis pas le seul) si ce n'est:
- essayer avec un noyau 2.4;
- alt: essayer avec les raidtools en 2.4 (failsafe) puis migrer même si c'est vieux, pas supporté... *ça marche*;
- dans le README.udev il est fait mention de ça:
<<<<<[/usr/share/doc/mdadm/README.udev] [...] On udev-enabled systems, device nodes are *not* available by default. Instead, mdadm creates them as needed, but you have to give it permission to do so with the --auto/-a flag (or the auto configuration option in the READ device definition).
Thus, if you are using mdadm on a udev, always use the --auto/-a flag or add an auto=yes configuration option to your RAID device definitions in /etc/mdadm/mdadm.conf.
bye
JKr
On 29-06-2005, DaXav wrote:
De plus, je suis tombé la dessus en fouillant :
http://www.issociate.de/board/post/202402/cannot_write_a_new_superblock.html
Si tu regardes bien c'est lors du passage 2.4->2.6 que ça a commecé à
aller mal... Tu as essayé avec un 2.4 "récent" et avec le 2.6.12?
Même résultat avec un 2.6.12.1
Bon je sais plus quoi proposer (apparemment je suis pas le seul) si ce n'est:
- essayer avec un noyau 2.4;
- alt: essayer avec les raidtools en 2.4 (failsafe) puis migrer même si
c'est vieux, pas supporté... *ça marche*;
- dans le README.udev il est fait mention de ça:
<<<<<[/usr/share/doc/mdadm/README.udev]
[...]
On udev-enabled systems, device nodes are *not* available by default. Instead,
mdadm creates them as needed, but you have to give it permission to do so with
the --auto/-a flag (or the auto configuration option in the READ device
definition).
Thus, if you are using mdadm on a udev, always use the --auto/-a flag or add
an auto=yes configuration option to your RAID device definitions in
/etc/mdadm/mdadm.conf.
De plus, je suis tombé la dessus en fouillant : http://www.issociate.de/board/post/202402/cannot_write_a_new_superblock.html
Si tu regardes bien c'est lors du passage 2.4->2.6 que ça a commecé à aller mal... Tu as essayé avec un 2.4 "récent" et avec le 2.6.12?
Même résultat avec un 2.6.12.1
Bon je sais plus quoi proposer (apparemment je suis pas le seul) si ce n'est:
- essayer avec un noyau 2.4;
- alt: essayer avec les raidtools en 2.4 (failsafe) puis migrer même si c'est vieux, pas supporté... *ça marche*;
- dans le README.udev il est fait mention de ça:
<<<<<[/usr/share/doc/mdadm/README.udev] [...] On udev-enabled systems, device nodes are *not* available by default. Instead, mdadm creates them as needed, but you have to give it permission to do so with the --auto/-a flag (or the auto configuration option in the READ device definition).
Thus, if you are using mdadm on a udev, always use the --auto/-a flag or add an auto=yes configuration option to your RAID device definitions in /etc/mdadm/mdadm.conf.
