Forum Linux.noyau Boot RAID 5 en mode dégradé

Posté par  .
Étiquettes : aucune
0
22
nov.
2007
Bonjour à tous, mon premier post ici !

Je viens de mettre en place un RAID5 sur mon poste de travail (Ubuntu 7.10).

J'ai donc une partition /boot sur chacun des 3 disques, et une partition en RAID5 contenant mon système (/).

J'ai installé et configuré grub sur chacun des 3 disques ainsi que configuré initramfs pour y intégrer la prise en charge du raid.

Tout fonctionne bien, je peux booter mon système. Mais (car il y a un mais...), quand je débranche un des disque dur, ca ne boot plus !

Le système n'arrive en fait pas à monter le raid. Après le démarrage échoué, je me retrouve dans la console initramfs. De là, je peux assembler mon raid (en mode dégradé donc), et le monter. Ca veut dire que la prise en charge du raid est possible à ce stade, et c'est ce que je souhaite.

Donc, mon problème est qu'en mode dégradé, le noyau refuse de monter mon raid, alors qu'il le pourrait !
En googlant, j'ai vaguement lu un problème similaire sur des kernel CentOS.

Ma question : pourquoi ?
Y'a t'il un fichier de conf ou un paramètre quelque part pour indiquer au noyau que je souhaite monter le raid, même en mode dégradé ? N'est-ce pas automatique normalement (c'est notament l'interet du raid !!).

D'avance merci pour vos réponses parce que là, je sèche !!

Ben

  • # plus de précisions

    Posté par  . Évalué à 1.

    Si ton système racine est sur le raid, ça me parait assez "normal" comme comportement.

    Ca bloque à quel moment au boot ? Tu as quoi dans les logs ?

    • [^] # Re: plus de précisions

      Posté par  . Évalué à 1.

      Comment ca normal ? J'aimerai justement que mon raid puisse démarrer en mode dégradé.

      Mon système racine est bien en raid, mais ma partition de boot ne l'est pas. D'ailleurs, quand le raid n'est pas dégradé (ie les 3 disques sont présents), le système boot sans aucun problème.

      Ca bloque au tout début, juste après le chargemet de initramfs. Là, il tente d'assembler le raid, n'y parvient pas (pourquoi, je sais pas), et donc n'arrive pas à monter le système racine. Là, il me rend la main sur une console initramfs.
      Comme je l'ai dit, à partir de là, je peux monter manuellement mon raid en mode dégradé.

      Vu où bloque le système, je pense qu'au niveau log j'aurai pas grand chose. Ceci dit, je n'ai pas regardé, il y a peut-être des infos interessantes. Je le fais d'ici 1H.

      Pour résumer, mon problème est : le noyau n'assemble pas automatiquement mon raid s'il est en mode dégradé ; pourquoi ?

      Voilà un problème qui ressemble exactement au mien, sauf qu'il est en raid 1 :
      http://llistes.bulma.net/pipermail/bulmailing/Week-of-Mon-20(...)

      • [^] # Re: plus de précisions

        Posté par  . Évalué à 1.

        Je viens de vérifier, et manifestement, il n'y a pas encore de log à ce stade, ou alors, je ne sais pas où les trouver.

        Je pense aussi à un possible problème dansla conf de grub. Les références aux disques dur dans grub (hd(0,1) par ex) changent-elles si on retire un disque ?

  • # Ou trouver des infos ?

    Posté par  . Évalué à 1.

    Quelqu'un connait-il un forum ou une liste spécialisée dans le raid, ou du moins, qui pourrait répondre à mes questons ? :)

    A votre avis, cela peut-il être un problème lié à grub, ou uniquement au driver md ? Je rapelle que je ne boot pas en mode dégradé, et ce, quelque soit le disque que j'enlève de la grappe. Grub devrait tourner quand je laisse le disque sur lequel le système boot par défaut (le mbr et /boot sont constants) puisqu'il tourne quand les 3 sont présents.
    Aussi, si j'arrive sur la console BusyBox quand le système ne boot pas, c'est bien que grub a fonctionné et que initramfs a été chargé depuis /boot, non ?

    Comment modifier les paramètres de ce driver md ? Dans le noyau ? Est-ce que mettre le driver en dur dans le noyau peut aider ?

  • # La suite

    Posté par  . Évalué à 1.

    Bon, je continue de chercher à résoudre mon problème.

    A la recherche des options de démarrage de mdadm, je décide de décompacter mon image initramfs. De là, un "grep -R -e mdadm *" me donne ca :


    etc/udev/rules.d/85-mdadm.rules:# This file causes block devices with Linux RAID (mdadm) signatures to
    etc/udev/rules.d/85-mdadm.rules:# automatically cause mdadm to be run.
    etc/udev/rules.d/85-mdadm.rules: RUN+="watershed /sbin/mdadm --assemble --scan --no-degraded"
    etc/udev/rules.d/65-mdadm.vol_id.rules:# This file causes Linux RAID (mdadm) block devices to be checked for
    etc/udev/rules.d/65-mdadm.vol_id.rules:SUBSYSTEM!="block", GOTO="mdadm_end"
    etc/udev/rules.d/65-mdadm.vol_id.rules:KERNEL!="md[0-9]*", GOTO="mdadm_end"
    etc/udev/rules.d/65-mdadm.vol_id.rules:ACTION!="add|change", GOTO="mdadm_end"
    etc/udev/rules.d/65-mdadm.vol_id.rules:ATTR{md/array_state}=="|clear|inactive", GOTO="mdadm_end"
    etc/udev/rules.d/65-mdadm.vol_id.rules:IMPORT{program}="/sbin/mdadm --detail --export $tempnode"
    etc/udev/rules.d/65-mdadm.vol_id.rules:LABEL="mdadm_end"


    Que vois-je dans etc/udev/rules.d/85-mdadm.rules ?? "watershed /sbin/mdadm --assemble --scan --no-degraded"
    Je tiendrai donc mon coupable ! Je modifie ce fichier sur mon système (/etc/udev/rules.d/85-mdadm.rules) et je remplace cette ligne par :
    "watershed /sbin/mdadm --assemble --scan --run" (l'option --run est l'inverse de l'option --no-degraded)

    Je reconstitue une image initramfs, vérifie que le fichier concerné est bien modifié, et reboot.
    Résultat, ca plante systèmatiquement, même si le raid n'est pas dégradé !

    De là, j'ai quelques questions. Ma méthode pour résoudre ce problème tient du bricolage. A quoi servent ces fichiers (/etc/udev/rules.d) ? A démarrer les services ? Vous pensez que je m'égare ou qu'au contraire, c'est bien dans ce fichier que tout se joue ?
    Pourquoi ce choix des devs ubuntu de ne pas démarrer le raid en mode dégradé ? Comment contacter ces personnes (liste ?)

    Enfin : pourquoi ca marche pas !? :)

Suivre le flux des commentaires

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