Problème de boot grub sur un serveur en etch

Le
Guy Roussin
Bonjour,

J'ai un serveur NEC qui comporte des disques internes en RAID hard
sur un contrôleur LSI megaraid (8300XLP). J'ai installé dessus une
debian etch.
Ce serveur comporte aussi une autre carte contrôleur LSI megaRAID
et une petite baie de disques externe.

Tout allait bien jusqu'à ce que je créée une partition (LVM) sur
la baie de disque. Impossible de booter, grub n'est plus vu
le système me réclame un OS.

En effet le contrôleur megaraid de la baie est vu par le système
*avant* le contrôleur megaraid des disques internes. Et impossible de
changer l'ordre des contrôleurs :-(

Comment puis-je me sortir de cette affaire ?

Merci.

--
Guy Roussin

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean-Yves F. Barbier
Le #16686121
Guy Roussin a écrit :
Bonjour,

J'ai un serveur NEC qui comporte des disques internes en RAID hard
sur un contrôleur LSI megaraid (8300XLP). J'ai installé dessus une
debian etch.
Ce serveur comporte aussi une autre carte contrôleur LSI megaRAID
et une petite baie de disques externe.

Tout allait bien jusqu'à ce que je créée une partition (LVM) sur
la baie de disque. Impossible de booter, grub n'est plus vu ...
le système me réclame un OS.

En effet le contrôleur megaraid de la baie est vu par le système
*avant* le contrôleur megaraid des disques internes. Et impossible de
changer l'ordre des contrôleurs :-(

Comment puis-je me sortir de cette affaire ?



c'est très étrange que cela n'arrive que maintenant!
n'aurais-tu pas déplacé ce ctrlr dans un autre slot PCI?

tu peux déjà essayer de voir ce qui se passe en bootant avec une knoppix.

j'ai déjà eu le cas avec des ctrlrs IDE; la seule solution que j'ai
trouvé a été de recompiler un kernel en demandant que les ctrlrs externes
soient pris en compte avant les internes (je sais, c'est l'inverse, mais
l'inverse de l'inverse se remet à l'endroit:)
et j'ai implanté le nouveau kernel par un chroot fait à partir d'une knoppix

maintenant, avec udev, ou bien avec un paramètre du driver [je suppose
que c'est le même driver pour les 2 ctrlrs], il-y-a sans doute une solution
plus élégante permettant de forcer l'ordre de détection (n° d'Id du périf,
ou Id PCI, ou...)

JY
--
God made the world in six days, and was arrested on the seventh.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Guy Roussin
Le #16686741
> c'est très étrange que cela n'arrive que maintenant!
n'aurais-tu pas déplacé ce ctrlr dans un autre slot PCI?


Non, je n'ai rien déplacé. La baie de disque n'était pas
configurée. La seule manip que j'ai faite s'est de créer une
partition lvm sur la baie.

tu peux déjà essayer de voir ce qui se passe en bootant avec une knoppix.
j'ai déjà eu le cas avec des ctrlrs IDE; la seule solution qu e j'ai
trouvé a été de recompiler un kernel en demandant que le s ctrlrs externes
soient pris en compte avant les internes (je sais, c'est l'inverse, mai s
l'inverse de l'inverse se remet à l'endroit:)
et j'ai implanté le nouveau kernel par un chroot fait à parti r d'une
knoppix

maintenant, avec udev, ou bien avec un paramètre du driver [je sup pose
que c'est le même driver pour les 2 ctrlrs], il-y-a sans doute une solution
plus élégante permettant de forcer l'ordre de détection (n° d'Id du périf,
ou Id PCI, ou...)


Mais là mon problème est plus en amont : grub n'est même p as vu. Il faudrait
un bout de grub qui dise d'aller voir sur le contrôleur suivant ...
Par ailleurs, les contrôleurs sont tous les deux des contrôleur s
LSI SAS megaraid qui utilisent le même driver megasas.ko.

Ou alors booter sur un cd ou une disquette qui dise d'aller chercher l'OS sur
le disque du second contrôleur ?

Pour moi, le problème doit être un peu identique au fait d'essa yer de
booter sur un disque esclave lorsqu'un master est présent et qu'il c ontient
des datas.


--
Guy Roussin

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Jean-Yves F. Barbier
Le #16686971
Guy Roussin a écrit :
c'est très étrange que cela n'arrive que maintenant!
n'aurais-tu pas déplacé ce ctrlr dans un autre slot PCI?





Non, je n'ai rien déplacé. La baie de disque n'était pas
configurée. La seule manip que j'ai faite s'est de créer une
partition lvm sur la baie.



je n'ai jamais vu ça: même un HD tout neuf apparaît dans la liste;
à moins, bien sur, que la ctrlr ne masque justement ces HDz (ça doit
être le cas)

ça explique que grub ne soit plus vu:
simplifions en disant que tu as 2 HDz: /dev/sda sur le ctrlr interne, et
/dev/sdb sur l'externe.
Tant que tu n'as pas touché à /dev/sdb, il n'est pas apparu dans le système,
mais dès que tu y a touché, il est devenu /dev/sda puisque scanné en 1er,
donc plus de grub!

ça laisse plusieurs possibilités:

1- tu réinstalles un grub sur le nouveau /dev/sda et tu le chaînes avec
l'ancien (avec lilo, c'est possible, avec grub, sèpô),
[pas génial]

2- tu échanges les HDz afin que /dev/sda retrouve sa place,
[à mon avis, solt la plus simple]

3- tu implantes un nouveau kernel qui swap les ctrlrs int et ext.

.......
Par ailleurs, les contrôleurs sont tous les deux des contrôleurs
LSI SAS megaraid qui utilisent le même driver megasas.ko.



Ou alors booter sur un cd ou une disquette qui dise d'aller chercher
l'OS sur
le disque du second contrôleur ?



c'est pourquoi je te parlais de knoppix: c'est une distro sur CD (et même
DVD)basée sur Debian, et qui permet d'explorer pratiquement tout sans
toucher aux
systèmes dèjà installés sur les HDz:
http://www.knopper.net/knoppix-mirrors/

pour démarrer en fr, dès que tu arrives au prompt, entre:
linux lang=fr (attention: 'a' et 'q' sont inversés: tu es en clavier US,
le '=' est à la même place)

le passage en root dans une console se fait par la Cde:
sudo su
(pas de mot de passe)

et profites-en pour faire un cat /proc/interrupts, histoire de voir si les 2
ctrlrs sont bien détectés, ou s'il n'y en a qu'un seul (auquel cas, il
faudra aller jeter un coup d'oeil dans les docs/source du driver pour savoir
s'il lui faut un parm spécial, ou si un 'append=' (ça c'est dans lilo) ou
son équivalent dans grub, est nécessaire.

Pour moi, le problème doit être un peu identique au fait d'essayer de
booter sur un disque esclave lorsqu'un master est présent et qu'il contient
des datas.



non, tu n'est pas sous w$: les *ix permettent de booter sur quasiment
n'importe quel HD.

JY
--
<miguel> any new sendmail hole I have to fix before going on vacations?
-- Seen on #Linux

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Guy Roussin
Le #16697391
Merci Jean-Yves,

Finalement un examen un peu plus attentif des options du bios
m'a permis d'intervertir l'ordre des contrôleurs megaraid au boot
(leurs noms étaient un peu cabalistique).

Et maintenant c'est ok. La première tentative de boot se fait
bien sur le 2eme controleur.

Guy

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Publicité
Poster une réponse
Anonyme