Forum Linux.général mdadm

Posté par sygirard le 24 août 2015 à 16:20. Licence CC By‑SA.

Étiquettes :

août

2015

Bonjour,

pour ceux qui connaissent bien le RAID soft via MDADM, j'ai une petite question.

J'ai 3 disques de 2To sur ma machine, dont 2 en RAID1 (2 partitions, chacune sur un raid différent md0 et md1).
Le disque seul contient le système Linux et d'autres partitions, le RAID1 est fonctionnel et contient des données.

Quelqu'un pourrait-il m'expliquer pourquoi, alors que le RAID1 est valide, lorsque j’éteins mon PC et que je débranche un des disques du RAID, mon PC ne démarre plus ? J'ai une console, qui me demande de taper le mot de passe root. Et je vois bien qu'il a pas réussi à monter mon RAID.

Si j'éteins le PC et que je rebranche le disque, tout remarche bien sur.

Y a-t-il une subtilité dans mdadm ?

Pourquoi ne voit-il pas le disque débranché comme "faulty" et ne démarre-t-il pas avec le second ?

De plus, sur le RAID1 formé par les premières partitions des disques de données, il y a un système Linux CentOS6.5 complet.
Le fichier /etc/mdadm.conf contient deux lignes :

ARRAY /dev/md1 metadata=1.0 name=PiRaid:1 UUID=d34bd559:378e62f6:68ee723f:1512a5c8
ARRAY /dev/md0 metadata=1.2 name=PiRaid:0 UUID=0b6aa00f:0fe211e8:51011f41:8848157b

Et voici le retour de la commande blkid pour les deux partitions :

/dev/sdb1: UUID="d34bd559-378e-62f6-68ee-723f1512a5c8" UUID_SUB="dc7b2963-5fcc-e30c-df12-25bbb511d5e7" LABEL="PiRaid:1" TYPE="linux_raid_member"
/dev/sdc1: UUID="d34bd559-378e-62f6-68ee-723f1512a5c8" UUID_SUB="1257a3d9-cc90-5580-9402-de518816ca70" LABEL="PiRaid:1" TYPE="linux_raid_member"

On remarque qu'elles ont le même UUID que le RAID md1 formé à partir de ces deux partitions.

Mon disque principale (sda) est le disque de 2To avec le syteme Linux.

Si je débranche ce disque, les disques en RAID1 qui étaient en sdb et sdc passent en sda et sdb.
Si je boot sur le système CentOs présent sur le RAID1 cité ci-dessus, il démarre, ce qui est très bien, mais le RAID1 tombe. Je suis obligé de le refaire.
Pourquoi ?

Si j'ai pas été clair, vous dites.

Merci
Sylvain

# UUID de merde ...

Posté par totof2000 le 24 août 2015 à 16:58. Évalué à -4.

Je sais, titre un peu brutal, mais pourquoi mettre des UUID sous cette forme et ne pas mettre un truc plus humainement lisible ? Si vous trouvez ma remarque ridicule, pourquoi utilisez-vous des FQDN ?
# SATA ?

Posté par nono14 (site web personnel) le 24 août 2015 à 20:17. Évalué à -1.

Jamais ce pb en scsi

Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
# Gestionnaire de démarrage

Posté par Kerro le 24 août 2015 à 22:08. Évalué à 2.

Hypothèse : le gestionnaire de démarrage tente de trouver quelque chose sur /dev/sdc car ce disque n'existe plus lorsque tu débranches un disque.

Utilise SystemRescueCD pour vérifier qu'il voit bien tes RAID (avec « cat /proc/mdstat »).
Redémarre ensuite sur SystemRescueCD avec un disque débranché, il devrait toujours voir tes RAID (toujours avec « cat /proc/mdstat », ne monte pas les RAID sinon ils vont être désynchronisés).

Si ça fonctionne bien avec SystemRescueCD, le problème vient probablement de GRUB (ou autre gestionnaire de démarrage) : une partie de ce qu'il attend est sur /dev/sdc
Un petit « grub-install /dev/sda » résoudra le problème.

À première vue c'est tout ce qui me vient à l'esprit.
- [^] # Re: Gestionnaire de démarrage
  
  Posté par KiKouN le 25 août 2015 à 08:49. Évalué à 2.
  
  À noter, je ne sais pas si cela a été corrigé depuis, que même si on installe grub sur tout les disques et que le menu graphique est actif ( configuration par défaut ), grub va essayer d'aller chercher l'image que sur un seul disque. Si bien, que si ce disque n'est pas présent, grub ne démarre pas.
  
  Sous debian, il faut décommenter l'option "GRUB_TERMINAL=console" dans le fichier /etc/default/grub pour désactiver le menu graphique de grub et regénérer la configuration "update-grub"
- [^] # Re: Gestionnaire de démarrage
  
  Posté par sygirard le 25 août 2015 à 14:20. Évalué à 1.
  
  Alors j'ai suivi ton idée.
  
  Avec ma manip, si je démarre SysRescue avec un seul disk RAID, je vois bien mon RAID1 actif, tout va bien.
  
  Si je démarre mon système avec un disque, il démarre pas, me propose une console. Je me connecte, tape le "cat /proc/mdstat" classique, et là il me met que md0 et md1 ne semble pas actif.
  
  Je vais voir ce que ça donne si je vire les deux lignes du fichier /etc/mdadm.conf
  - [^] # Re: Gestionnaire de démarrage
    
    Posté par Kerro le 25 août 2015 à 19:54. Évalué à 3.
    Je vais voir ce que ça donne si je vire les deux lignes du fichier /etc/mdadm.conf
    
    Je t'ai donné la probable solution à ton problème : grub-install /dev/sda
    Je ne vois pas ce que tu vas tripoter dans ce fichier de configuration.
    
    Pour approfondir :
```
# vérifier si un secteur de boot contient grub (boot.img)
head -c 512 </dev/sda | hexdump -Cv      # doit contenir une chaîne de caractères « GRUB .Geom.Hard Disk.Read. Error »

# vérifier si un disque contient le chargeur intermédiaire (core.img)
dd if=/dev/sdX bs=512 count=2 skip=1 2>/dev/null | hexdump -Cv          # doit contenir une chaîne de caractères « loading..Geom.Read. Error »

# note : il n'est pas possible de comparer directement les fichiers boot.img et core.img avec le contenu du disque, car il y a des différences. Je n'ai pas cherché plus loin

# installer/réinstaller Grub sur un/des disque/s
dpkg-reconfigure grub-pc      # puis sélectionner les disques souhaités : /dev/sda + /dev/sdb + etc    (mais pas /dev/md0)

# ou manuellement, pour chaque disque
grub-install /dev/sdx

# ou plus « léger »
grub-bios-setup --verbose --boot-image=i386-pc/boot.img --core-image=i386-pc/core.img  /dev/sdX
# --> message indiquant que device.map n'est pas présent : ce n'est pas un problème
# éventuellement avec un fichier device.map
grub-mkdevicemap --verbose  --device-map=/tmp/device.map
grub-bios-setup --verbose --boot-image=/boot/grub/i386-pc/boot.img --core-image=/boot/grub/i386-pc/core.img --device-map=/tmp/device.map /dev/sdX

# toutes ces deux commandes (dpkg-reconfigure, grub-install, et grub-bios-setup) installent le secteur de démarrage (boot.img) et le chargeur intermédiaire (core.img)
# dpkg-reconfigure et grub-install régénèrent également les fichiers de configuration de Grub
```
    - [^] # C'était GRUB
      
      Posté par sygirard le 31 août 2015 à 14:19. Évalué à 1.
      
      Ne trouvant pas de solution à mon problème, j'ai cherché du coté de l'installation de GRUB.
      
      Ta solution ne m'aide pas vraiment vu que je n'ai pas le même système, mais … elle a au moins eu le mérite de m'orienter dans mes recherches.
      Vu que je ne trouvais rien pouvant régler mon problème via mdadm.
      
      Les deux disques en RAID1 avec CentOS, sont créés par un script qui fait tout (partition, dépacktage, etc …) via un CentOS live custom, ainsi que l'installation de GRUB (pas grub2, grub tout court)
      
      Je faisais ceci :
      root (hd0,0)
      setup (hd0)
      root (hd1,0)
      setup (hd1)
      
      Il faut plutôt faire cela :
      device (hd0) /dev/sdb
      root (hd0,0)
      setup (hd0)
      device (hd0) /dev/sdc
      root (hd0,0)
      setup (hd0)
      
      Ça marche beaucoup mieux ainsi.
      
      Merci
# On final ...

Posté par sygirard le 25 août 2015 à 14:55. Évalué à 0.

Supprimer le contenu du fichier /etc/mdadm.conf n'a pas résolu mon problème, par contre j'avais deux disques RAID1 actifs en /dev/md126 et /dev/md127.

Alors j'ai voulu essayer quelque chose. J'ai juste viré la partie UUID de chaque lignes du fichier mdadm.conf, ce qui donne :

ARRAY /dev/md1 metadata=1.0 name=PiRaid:1
ARRAY /dev/md0 metadata=1.2 name=PiRaid:0

Et là, tout va à merveille. Il y a quelque chose que je pige pas. Ça règle mon problème, c'est bien. Mais j'aimerai comprendre.

Enfin bref, je veux pas aller trop vite mais au final, s…perie de UUID.
- [^] # Re: On final ...
  
  Posté par Kerro le 25 août 2015 à 19:59. Évalué à 2.
```
# script Debian qui fait cela tout seul (tester, puis copier/coller à la fin de /etc/mdadm/mdadm.conf)
/usr/share/mdadm/mkconf

# méthode officielle
mdadm --examine --scan >> /etc/mdadm/mdadm.conf
# ou, suivant le cas (le résultat est en principe le même)
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
#   --examine s'applique aux disques
#   --detail s'applique aux arrays
#   je ne saisi pas la différence

# ajouter --config=partitions pour ne pas tenir compte du fichier /etc/mdadm/mdadm.conf (utile s'il contient des données douteuses, ou s'il n'existe pas)
mdadm --examine --scan --config=partitions >> /etc/mdadm/mdadm.conf

# Mettre à jour initramfs afin de prendre en compte le fichier mdadm.conf au démarrage : 
update-initramfs -u
# ou     update-initramfs -u -k all      pour reconstruire l'initramfs de tous les noyaux connus d'update-initramfs
```
  - [^] # Re: On final ...
    
    Posté par sygirard le 27 août 2015 à 16:24. Évalué à 1.
    
    Je suis pas sous debian, mais sous OpenSuse 12.1
    
    J'ai pas update-initramfs. Je comprends qu'il faille le lancer pour qu'il prenne en compte le nouveau mdadm.conf, mais j'ai l'impression que c'est pas le cas pour mon OpenSuse et ma CentOS.
    
    Un de mes problèmes est réglé, par contre le deuxième.
    
    Je récapitule. J'ai de base :
    - sda : Linux OpenSuse avec GRUB sur MBR
    - sdb et sdc : En RAID1, et Linux CentOS avec GRUB sur MBR des deux disques
    
    Si je laisse mes disques ainsi, si au démarrage du BIOS je choisi de booter sur sdb ou sdc, CentOS démarre et mon RAID1 reste OK
    
    Si j'enlève sda, que je laisse démarrer le BIOS tout seul, mon CentOS démarre, beaucoup plus lentement, et mon RAID1 est KO sur le premier des deux disques.
    
    Pourquoi ?
# disque seul = systeme, raid = data, mais ...

Posté par NeoX le 31 août 2015 à 15:28. Évalué à 2.

c'est tordu ton histoire,

en debranchant les 2 disques du raid1, la machine devrait demarrer normalement
car le raid ne contient que des "données".

et grub doit/devrait etre installé uniquement sur le disque solo, independamment des disques du RAID.

si par contre tu lui a dit de mettre /home sur le raid1, il faut que le raid1 soit actif pour que la machine finisse de demarrer (partitions montées et verifiees).
- [^] # Re: disque seul = systeme, raid = data, mais ...
  
  Posté par sygirard le 01 septembre 2015 à 15:46. Évalué à 1. Dernière modification le 01 septembre 2015 à 15:50.
  
  J'ai une distribution CentOS sur une partition des disques en RAID1
  
  Les disques RAID1 on deux partitions qui forment deux RAID1 :
  - la première avec CentOS
  - la deuxième avec les datas
  
  Et je veux pouvoir booter dessus si pas le disque solo justement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.