Newsgroup: it.comp.os.linux.sys
Titolo: Ordine scsi

Ho un x445, con controller lsi integrato e pacco raid, su cui ho
aggiunto un controller scsi; quando la macchina bootstrappa il kernel
carica prima il driver del controller su pci rimappando scorrettamente
l'ordine dei device scsi e causando il classico kernel panic in quanto
non viene trovata la partizione con il s.o.. Come posso fare a
risolvere il problema? Basta creare una nuova immagine di intrd? Devo
passare dei parametri in append a lilo?
Grazie

max bunker wrote:

puoi settare da bios l' ordine di boot , e fin qui' ci siamo , poi
bisognerebbe sapere che scheda ci hai messo , mi pare strano che siano
gestite dallo stesso driver a meno che tu non usi un cassetto esterno 2104
gestito da una serveraid.
ciao.
-- 
Il miglior cuoco e' la fame.
                -- Anonima

poi bisognerebbe sapere che scheda ci hai messo , mi pare strano che siano
Due schede emulex attaccate a una san EMC2, se stacco la fibra la
macchina non va in kernel panic.
Ecco quello che accade con fibra attaccata, il kernel:
-  carica prima i driver delle emulex (lpfcdd.o) , alloca dei device
scsi (sda,sdb,etc) per lo storage in fibra
- carica i driver del controller integrato lsi 1030  (mptscsi.o, mi
pare)  e quindi i dischi interni (che normalmente sono su sda) sono
mappati su un device diverso con tutte le conseguneze del caso.
Grazie
Max
p.s.: per adesso ho risolto facendo partire la macchina con la fibra
staccata e poi facendo un rmmod e insmod dei moduli delle emulex per
far "sentire" le lun sull'emc, ma come capirai è una soluzione
tampone, non posso chiedere al cliente di staccare la fibra ogni volta
che riavvia la macchina  :-)



Basterà un man lilo ??
       disk=<device-name>
              Defines  non-standard  parameters for the specified
              disk.  See section "Disk geometry" of user.tex  for
              details.   Especially useful is the `bios=' parame­
              ter.  The BIOS numbers your disks 0x80, 0x81,  etc.
              and  it  is  impossible  to decide which Linux disk
              corresponds to which BIOS disk (since this  depends
              on  the BIOS setup, and on the type of BIOS), so if
              you have an unusual setup you  need  to  state  the
              correspondence  between Linux disks and BIOS disks.
              For example,
                     disk=/dev/sda
                          bios=0x80
                     disk=/dev/hda
                          bios=0x81
              would say that your SCSI disk  is  the  first  BIOS
              disk,  and  your  (primary  master) IDE disk is the
              second BIOS disk.
sarà questo ??
Max

 
Sorry, lilo.conf

 
mi pare di capire che i driver siano compilati come moduli.
io integrerei nel kernel il driver per il controller di boot, in modo che 
venga riconosciuto subito, e lascerei il driver del controller per la 
fibra come modulo, in modo che venga riconosciuto solo in un secondo 
momento.
oppure, invertirei l'ordine dei moduli nel file di cfg apposito della tua 
distro.
hai già provato?
-- 
+-------
| Paolo opg
|
| janickg ( at ) hotmail ( dot ) com
| (fake address in reply-to field!)
+-------

> mappati su un device diverso con tutte le conseguneze del caso.
devi modificare l' initrd in modo da caricare all' avvio solo i module della
scsi , lo puoi fare in 2 modi , o eliminando da modules/modules.conf i
moduli relativi alla fibra e ricreando con mkinitrd oppure gunzippandosi
initrd-XXXXX e montandolo col loopback x modificarlo , dopodiche' rivai col
lilo e funziona.
mai avuto problemi in questo modo con fastt/shark , x l' emc dovrebbe essere
uguale.
ciao.
ps: hai gia' caricato il summit sul 445 ? senno' poi ti tocca ricominciare
da capo.
-- 
Il vino e' nemico dell'uomo.
E chi fugge di fronte al nemico e' un vigliacco.
                -- Anonimo veneto

lilo e funziona.
Credo che opterò per questa soluzione, anche perchè (scusate se non
l'ho detto prima) stiamo parlando di vmware esx server 2.01; delle
modifiche a lilo potrebbero inficiare l'aggiornamento del lilo in
seguito a modifiche fatte dal cliente sulle advanced options, che di
fatto vengono integrate con append sul lilo.conf (Se vmware trova dei
parametri aggiunti a manina nel lilo fallisce nel modificare le
options in append)
Grazie !

mi pare di capire che i driver siano compilati come moduli.
e qui ci sarebbe da approfondire qualcosa che non ho capito: quando
lilo passa il controllo al kernel quest'ultimo sembra aver bulit-in i
moduli per la gestione dei device in questione, infatti li individua
correttamente. Però a boot completato (siccome presnte nel
modules.conf) facendo un lsmod  trovo il modulo delle emulex caricato
(non dovrei vederlo se fosse built in) e posso scricarlo e ricaricarlo
per fargli sentire il bind della san. D'altro canto sono certo che il
modulo sia built-in nel kernel in quanto i device vengono riconosciuti
correttamente quando il kernel è in ram e non è stato ancora passato
il controllo ad init.
Forse non ho ancora capito bene il processo di boot di linux? 
May be.......illuminatemi!!!!

> l'ho detto prima) stiamo parlando di vmware esx server 2.01; delle
???
allora che cavolo c' entra , assegni la fibra alle VM invece che alla
management console ed il gioco è fatto!
riconfigura il vmnix va' ;-)
ciao.
-- 
Se la vita non e' come la volevi, hai chiesto qualcos'altro?


Dopo aver seguito il consiglio di nero ed aver apero initrd credo di
aver svelato l'arcano, il kernel carica i moduli grazie all'immagine
intrd caricata in ram; a questo punto credo che la soluzione sia
evidente:
- modifico l'intrd e rimuovo il driver delle emulex
- metto una riga in rc.local per caricare i driver che gesticono le
emulex
In questo modo sono sicuro che i driver delle emulex vengano caricati
dopo e che i device vengano mappati correttamente.
Coreggetemi se sbaglio!

riconfigura il vmnix va' ;-)
Magari il cliente vuole creare un vmfs da service console e vuole
sharare la fibra tra service console e vm; si infatti in principio
avevo fatto così ma poi ho dovuto fare retromarcia......  :-)

> Coreggetemi se sbaglio!
tutto corretto se mi parli di linux , ma tu' sei su una VM , 
cambia il MONDO!!!
la management console che stai modificando non è reale , almeno dopo che
sono partiti i moduli del vmnix , stai modificando un linux "virtuale".
leggi l' altro mio post.
ciao.
-- 
La verita' e' la cosa di maggior valore che abbiamo -- percio'
lasciatecela usare con economia.
                -- Mark Twain

 avevo fatto così ma poi ho dovuto fare retromarcia......  :-)
è sconsigliatissimo dalla stessa vmware , perdi un sacco di prestazioni ,
tra l' altro cambia solo il caricamento del modulo , il fs lo vedi cmq
anche da service console.
-- 
"A Natale mia madre faceva sempre il tacchino: un'imitazione orrenda!"
                -- Mario Zucca


credo che udev invece di devfs possa aiutarti. Credo ma non l'ho ancora
sperimentato troppo. Se ho ben capito permette di mapparti i device in modo
piu' statico che non un semplice sd*, che verrebbe alterato con l'aggiunta
di un disco in mezzo alla catena. Se capita fammi sapere come risolvi
perche' interessa anche a me
-- 
There's no real need to do housework -- after four years it doesn't get
any worse.