ne pas charger un pilote au boot?

bonjour à tous,

bon j'ai un souci sur une machine qui comporte des disques ide, sata et scsi
sous debian etch : les disques sata ont été ajoutés après l'installation et
c'est le bazar avec grub et l'ordre réel détecté au boot (les disques sata
en premier) sachant que le système se trouve sur le premier disque scsi.
Bon plutôt que de me prendre la tête à essayer de maîtriser (car ça risque
de prendre du temps) les grub et autres lilo et donc de faire des conneries
(j'ai déjà donné!) j'aimerais indiquer au noyau (à partir de grub) de ne
pas charger le pilote sata promise pour que le pilote scsi soit bien
détecté en premier ainsi ensuite je pourrai charger le sata dans rc.local.
Est-ce possible et comment?

mettre dans un fichier /etc/modprobe.d/blacklist-local une ligne :

blacklist nom-du-pilote

et faire un update-modules ensuite.

Sinon tu peux aussi modifier le fichier /boot/grub/device.map qui
est très simple :

(disque pour GRUB) /dev/dev-pour-linux
...

Enfin il y a dans l'installation de debian un super outil de partitionnement
(simple et clair) pour les disques (partman je crois) pourquoi n'est -il
pas accessible ensuite?
Je demande ça surtout pour les déclarations des lvm après installation.

Il y a bien gparted, mais les {pv,vg,lv}create/extend/etc. restent à faire
à la main.

YBM wrote:

mettre dans un fichier /etc/modprobe.d/blacklist-local une ligne :

blacklist nom-du-pilote

et faire un update-modules ensuite.

eh bé non ça ne marche pas car, à priori (je ne maîtrise pas entièrement la
situation), pour le boot j'ai une image du noyau qui se décompresse
immédiatement en mémoire et où, évidemment, se trouve en module le pilote
sata_promise : et c'est le 1er pilote qui est chargé donc mes disques sata
se retrouvent en sda et sdb (sda=boot scsi de l'installation!) donc
rapidement il cherche la racine qu'il ne trouve pas bien sûr.
Donc ta méthode n'a malheureusement aucun effet puisqu'elle est effective
qu'parès le chargement du noyau. Dommage...

Sinon tu peux aussi modifier le fichier /boot/grub/device.map qui
est très simple :

(disque pour GRUB)  /dev/dev-pour-linux

j'ai également tenté cette solution mais sans aucun succès et même en
modifiant le fstab car si je déclare les disques dans l'ordre de leur
reconnaissance le disque de boot scsi se retrouvent en sdc mais ça ne donne
rien de plus!

Je crois qu'avec lilo il n'y a pas ce problème il boote sur le disque qu'on
lui indique et se fout du reste : c'est pour ça d'ailleurs que j'ai horreur
de grub car il suffit qu'un disque tombe en vrac et ton grub il ne veut
plus rien savoir.
Problème (pour moi) : lilo a l'air beaucoup plus délicat à configurer car
j'ai systématiquement des erreurs avec lilo-config.

Bref je tourne en rond...

Et je le sens bien : si je ne peux plus booter du tout ça va être la méga
galère!
Dans le pire des cas j'aimerais bien installer le grub sur le 1er disque
sata mais il faudrait que je boote en étant déclaré mais comme pour
l'instant c'est impossible!
Le problème vient bien du fait que le pilote sata se charge en premier
quelle que soit les déclarations.

mouais j'suis pas prêt d'en sortir...

Jean-Pierre wrote:

bonjour à tous,

bon j'ai un souci sur une machine qui comporte des disques ide, sata et scsi
sous debian etch : les disques sata ont été ajoutés après l'installation et
c'est le bazar avec grub et l'ordre réel détecté au boot (les disques sata
en premier) sachant que le système se trouve sur le premier disque scsi.
Bon plutôt que de me prendre la tête à essayer de maîtriser (car ça risque
de prendre du temps) les grub et autres lilo et donc de faire des conneries
(j'ai déjà donné!)

Je ne sais pas si la debian fonctionnent avec un initrd
mais si oui le refaire sans le pilote promise

Jean-Pierre wrote:

eh bé non ça ne marche pas car, à priori (je ne maîtrise pas entièrement la
situation), pour le boot j'ai une image du noyau qui se décompresse
immédiatement en mémoire et où, évidemment, se trouve en module le pilote
sata_promise : et c'est le 1er pilote qui est chargé donc mes disques sata

Et si maintenant tout simplement, tu mettais le driver en module ? Et
pas dans le noyau ? udev chargerait le module(driver) après le boot, et
tes drivers scsi seraient chargés en premier ?

Déjà que cay mal (c) de tout foutre dans le noyau /:

S.

YBM wrote:

mettre dans un fichier /etc/modprobe.d/blacklist-local une ligne :

blacklist nom-du-pilote

et faire un update-modules ensuite.

eh bé non ça ne marche pas car, à priori (je ne maîtrise pas entièrement la
situation), pour le boot j'ai une image du noyau qui se décompresse
immédiatement en mémoire et où, évidemment, se trouve en module le pilote
sata_promise : et c'est le 1er pilote qui est chargé donc mes disques sata
se retrouvent en sda et sdb (sda=boot scsi de l'installation!) donc
rapidement il cherche la racine qu'il ne trouve pas bien sûr.
Donc ta méthode n'a malheureusement aucun effet puisqu'elle est effective
qu'parès le chargement du noyau. Dommage...

Il est en dur dans le noyau ou chargé à partir du ramdisk initial ?
(facile à voir : si ton pilote est dans la liste montrée par lsmod
et qu'il est chargé malgré le blacklistage c'est qu'il vient du initrd)

Tu peux alors modifier ton image initrd pour le virer.

Sinon tu peux aussi modifier le fichier /boot/grub/device.map qui
est très simple :

(disque pour GRUB) /dev/dev-pour-linux

j'ai également tenté cette solution mais sans aucun succès et même en
modifiant le fstab car si je déclare les disques dans l'ordre de leur
reconnaissance le disque de boot scsi se retrouvent en sdc mais ça ne donne
rien de plus!

Tu mélange pas un peu tout là ? Grub c'est une chose, fstab n'a rien à
y voir...

Je crois qu'avec lilo il n'y a pas ce problème il boote sur le disque qu'on
lui indique et se fout du reste : c'est pour ça d'ailleurs que j'ai horreur
de grub car il suffit qu'un disque tombe en vrac et ton grub il ne veut
plus rien savoir.
Problème (pour moi) : lilo a l'air beaucoup plus délicat à configurer car
j'ai systématiquement des erreurs avec lilo-config.

GRUB est beaucoup plus souple que LILO, et je ne comprends pas bien ce
que tu racontes avec ton "il boote sur le disque qu'on lui indique et se
fout du reste"... GRUB aussi fait ça si on le lui dit correctement...

Bref je tourne en rond...

Et je le sens bien : si je ne peux plus booter du tout ça va être la méga
galère!
Dans le pire des cas j'aimerais bien installer le grub sur le 1er disque
sata mais il faudrait que je boote en étant déclaré mais comme pour
l'instant c'est impossible!

"en étant déclaré" ??

Le problème vient bien du fait que le pilote sata se charge en premier
quelle que soit les déclarations.

Respire un peu et essaye de configurer tout ça rationnellement, il y
a certainement un moyen de le faire marcher.

GRUB (le boot loader) se moque royalement des pilotes Linux... grub
(l'outil en ligne de commande) lui non puisqu'il tourne sous Linux...
Cependant dans grub on peut tout à fait dire un truc comme
root (hd1,0) et setup (hd1) *même* si ce "(hd1)" est en fait
"(hd0)" au niveau du boot loader (GRUB). Maintenant si le fichier
de correspondance est correct c'est plus clair pour tout le monde...

Le Sat, 16 Jun 2007 13:49:37 +0200, YBM a écrit:

GRUB est beaucoup plus souple que LILO, et je ne comprends pas bien ce
que tu racontes avec ton "il boote sur le disque qu'on lui indique et se
fout du reste"

J'ai malgré tout un cas sur ma machine, avec disque PATA où je n'ai
jamais pu booter avec grub, mais seulement avec lilo, tout ça à priori
à cause du jmicron :
http://forums.gentoo.org/viewtopic-p-3972083-highlight-.html#3972083

--
Christophe PEREZ
Écrivez moi sans _faute !