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 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 knoppixmaintenant, 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...)
Mais là mon problème est plus en amont : grub n'est même pas 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ô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 ? 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. -- Guy Roussin