Re: HS: mdadm et grub2
Le 24/01/2011 12:03, Pascal Hambourg a écrit :
Daniel Huhardeaux a écrit :
[...]
J'en suis arrivé à la conclusion
que le raid avec mdadm fait que l'ecriture a bien lieu sur le premier
disque et pas sur le second. Cela explique pourquoi mon sdb ne démarrait
pas puisqu'il ne devait en fait avoir rien d'écrit :-(
J'ai du mal à comprendre comment tu arrives à cette conclusion. As-tu
examiné réellement le contenu du second disque ?
Comme le disque seul ne démarre pas (le BIOS l'a bien noté comme seul
disque présent) donc logiquement vu apr lÓS comme sda. Comme il ne boot
pas c'est que grub ne trouve pas ce qu'il cherche. Comme avant de
commencer mes tests raid j'ai vérifier que mdadm me donnait bien mes
espaces raid en up et ok, forcément le second disque devrait ressembler
au premier.
Je n'ai effectivement pas démarrer sur un CD pour vérifier ce que
contenait le disque.
J'ai rebranché les deux disques, chacun comme il était connecté à la
livraison. Un dd if=/dev/sda of=/dev/sdb est entrain de tourner. Je
redémarrerai ensuite sur chaque disque pour voir si tout est ok, puis
les remettrai dans l'espace raid.
AMA ça risque de donner des trucs bizarres car je ne pense pas que les
superblocs des partitions RAID des deux disques soient censés être
totalement identiques.
Bien sûr. Mais cela m'a permis de confirmer que les deux disques étaient
fonctionnels et que chacun *dans le même setup raid* arrivait à démarrer.
Le problème pourrait venir de la correspondance entre les noms de
périphérique pour Linux et le BIOS pour le second disque.
Il ne parle que de disque C: J'ai comme seul choix de dire celui que je
veux pour représenter ce disque C:
"C:" désigne simplement le premier disque, celui qui sera amorcé par le
BIOS et vu comme hd0 par grub.
OK mais cela ne sert a rien puisque:
- si j'ai les deux disques, je peux choisir sur lequel je veux démarrer
- si je n'ai qu'un disque, il ne me présente que celui ci
Dans tous les cas de figure, si mon disque sda est HS sdb devient sda
donc il doit démarrer
L'idée est qu'il faut installer grub sur le second disque /dev/sdb en
lui disant qu'il est le premier disque pour le BIOS, c'est-à-dire hd0.
Car sinon lors du boot sur ce disque il cherchera à lire sur hd1 alors
qu'il sera effectivement hd0. Le disque amorcé par le BIOS est toujours
vu comme hd0.
Avec grub 1, j'avais dû faire ceci pour l'installer aussi sur le second
disque /dev/hdb :
# grub
grub> device (hd0) /dev/hdb
grub> root (hd0,0)
grub> setup (hd0)
Grub2 est capable de démarrer sur /dev/md0 (/boot dans mon cas).
Ensuite, le but du raid n'est pas de trifouiller dans le BIOS ou dans
Grub pour arriver à démarrer le serveur si sda lache! L'option fallback
de menu.lst est faite pour cela dans grub1
default 0
fallback 1
[...]
title Debian GNU/Linux, kernel 2.6.32-bpo.5-amd64
root (hd0,0)
kernel /vmlinuz-2.6.32-bpo.5-amd64 root=/dev/mapper/vg0-DomU0 ro
initrd /initrd.img-2.6.32-bpo.5-amd64
title Debian GNU/Linux, kernel 2.6.32-bpo.5-amd64
root (hd1,0)
kernel /vmlinuz-2.6.32-bpo.5-amd64 root=/dev/mapper/vg0-DomU0 ro
initrd /initrd.img-2.6.32-bpo.5-amd64
J'ai eu un entretien avec le support technique de Dell: ce modèle est
livré avec le contrôleur sur la carte mère ou dans un slot PCI avec un
contrôleur standard sur la CM. Bien évidemment je suis dans le premier
cas :-(.
Sur leur conseils je refais l'installation en SATA = ATA ou SATA = AHCI,
il est possible que d'avoir laissé RAID en supprimant l'espace raid
virtuel, et malgré que les deux disques aient été reconnus par l'OS,
fasse qu'une partie de la gestion disque ai tout de même été gérée par
le S100.
--
Daniel
Reply to: