Newsgroup: it.comp.os.linux.sys
Titolo: debian - preload modules & floppy boot

ragazzi, aiutatemi a fare chiarezza...
dunque, la situazione e' questa:
ho un controller ide-raid (quello del proliant dl320) che non e'
riconosciuto da woody in fase di installazione.
ho trovato i sorgenti di questo controller in rete, ho compilato il
modulo megaide.o e, con kernel 2.4.25, funziona benissimo:
modconf->megaide.o-> e i due dischi ide vengono visti come un unico
disco scsi sda dal controller.
Il punto, ovviamente, e' che io vorrei passare questo modulo _durante
l'installazione_ di woody in modo da utilizzare fin da subito il
controller raid (ora se booto con bf24 mi vede hda+hdc e non va bene).
Ho visto che Tannoiser ha spesso consigliato questo floppy di moduli
aggiuntivi da passare durante l'installazione di woody bf24:
http://people.debian.org/~blade/install/preload/
 (1)
quindi ho ricompilato il megaide.o partendo dai sorci del 2.4.18, ho
messo il modulo nella dir /boot del floppy (1) ma quando provo a
passarlo in fase di preload dei moduli mi restituisce un "installation
failed".
Ho controllato e non ci sono dipendenze.
Perche', secondo voi, non funziona?
Come alternativa se non riuscissi in questo modo avrei pensato di
sostituire il kernel 2.4.18 del boot-floppy di debian con il kernel
2.4.25 + modulo megaide.o che funziona.
Qui pero' ho le idee ancora piu' confuse?
E' fattibile una cosa di questo tipo?
Leggendo tra gli archivi mi sembra di aver capito di si' ma non mi sono
chiari i passaggi.
Come alternativa se non riuscissi in quest'ultimo modo avrei pensato di
darmi all'ippica.:-)
grazie in anticipo,
a.

 E' fattibile una cosa di questo tipo?
Io ho fatto qualcosa del genere pero', per sicurezza, ho compilato
staticamente il driver aggiuntivo nel kernel customizzato.
Alessandro.

 staticamente il driver aggiuntivo nel kernel customizzato.
mi potresti dare piu' dettagli su come ti sei creato il floppy con il
kernel ad hoc? 
preciso, forse mi sono spiegato male, che nel mio caso il modulo non e'
incluso in nessun kernel tree. l'aggiunta al 2.4.25 l'ho fatta partendo
dai sorgenti del controller trovati in rete.
ciao e grazie,
a.

 kernel ad hoc?
Se non ricordo male ho preso l'immagine del floppy di boot standard (che si
basa su syslinux) e ho semplicemente sostituito il file che contiene
l'immagine del kernel. La cosa piu' difficile e' stata ottenere un kernel
abbastanza piccolo da stare sul floppy.
Alessandro.

 E' fattibile una cosa di questo tipo?
A seconda di quanto vuoi sbatterti, hai diverse strade:
- cercare se esiste una patch backport di tale driver, per kernel
  2.4.18, quindi procedere come hai fatto (difficile, IMHO).
- _modificare_ il boot floppy alla "grezza": compila un 2.4.25, con
  i supporti che ti servono (consiglio: statico). Quindi prendi il boot
  floppy di woody, ovvero la sua immagine. Montala in loop, e sostituisci
  i file che ti servono (vmlinuz e initrd.img).
  Una volta fatto boot, e quindi l'installazione, ti converra` procedere
  in maniera piu` ortodossa.
- aprire la macchina, installare al volo un hd di comodo su un normale
  canale ide. fare un installazione minimale che ti permetta di avere
  quanto ti serve per compilare un kernel con le feature che desideri.
  una volta fatto boot, con il tuo kernel nuovo, spostare
  l'installazione minimale, e quindi terminare la stessa.
Per pigrizia, adotto le soluzioni 2 o 3 a seconda dei casi (2 se penso
di dover installare piu` di una macchina uguale).
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Sheep are not a substitute for caffeine.

   in maniera piu` ortodossa.
Ho fatto anche questa prova; ho ricompilato un bf2.4 con controller e
scheda eth,
presi i 6 dischetti di rescue di woody,
montato il primo (rescue.bin) in loop, cancellato il linux.bin
(e anche il file che conteneva system.map causa mancanza di spazio),
e sostituito con il kernel compilato rinominandolo linux.bin
e lanciando lo script nella directory  rdev.sh che si "impossessa del
kernel sul dischetto"; smontato e boottato caricando drivers e
sistema base via rete.
Ora  (pausa fiatone),
il bello e' che il sistema base si prende il kernel da internet
e non copia quello del dischetto  :-)
Cosi', prima di rebootare per la via del tasksel, modificando sources.list
anche quello da rete, ho trasferito il kernel dal dischetto su
(per questa prova) /sda8.
Al reboot non andava, e qui ho interrotto questa prova,
ma mi ricordo che lo script rdev.sh che si trovava sul primo
floppy rescue.bin quando vi si copiava un altro kernel,
faceva queste cose:  (procedura debian installation, capitolo 10)
rdev $IMG -R 1
rdev $IMG -r 0
rdev $IMG -v 1
rdev $IMG /dev/ram0
e che rdev (sda8)/vmlinuz mi restituisce  /dev/ram0
Domanda:
Quel kernel sul server non andava perche' devo dargli un bel
rdev /vmlinuz /dev/sda8   ?   (ricordo che c'e' GAG in MBR)
Ma se poi volessi spostare il kernel in un'altra partizione
dovrei rifare rdev?
Non esiste un "rdev /vmlinuz liberatutti" ?
In quel caso dovrebbe essere solo lilo a lanciare il kernel
e non piu' il kernel pensare ad autocaricarsi.
Ovvero, ho bootato il server con il kernel statico nel floppy,
trasferito quel kernel dal floppy in /  e non va perche',
penso io, il kernel ha passato quei comandi rdev,
e devo ripulirlo / riaddomesticarlo.
O no?
(Potrei anche copiare il kernel ricompilato nella versione
 precedente al passaggio RDEV.SH, ma vorrei sapere
come si pulisce un kernel da modifiche "rdev", o se
invece magari non serve, e sto sbagliando altro.).
--
RobiZ    -    ( x => i)@
WARNING: SCO may claim that this mail
includes its copyright code.

 Non esiste un "rdev /vmlinuz liberatutti" ?
No. E` per questo che esiste lilo.
(tra le altre cose).
Il problema "potrebbe" nascere dal fatto che lo usi da gag, mai provato.
Diversamente, l'opzione in lilo:
root=/path
fa esattamente quello che fai con rdev: indichi la root directory.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
There's going to be no serious problem after this.  --Ken Thompson