[Primipassi] Kernel 2.4.1

[Sergio Ballestrero]

 Ciao,

On Mon, 5 Feb 2001, theold wrote:

> ... e allora, per poter utilizzare il pppoatm per il mio modem adsl,
> forse è sufficiente aggiornare il kernel alla 2.4.1 (io ho la RH 7.0
> che utilizza la 2.2.16).
> 
> Ho scaricato da Internet tale nuova versione e l'ho scompattata in
> /usr/src/linux-2.4.1, facendo puntare a questa directory il file
> simbolico /usr/src/linux.
> 
> Ho poi eseguito make xconfig e sono entrato in un elenco enorme di
> opzioni, per le quali, per il 99%, non saprei cosa rispondere.

 se guardi gli help delle opzioni, di solito finiscono con la frase 'se
non sapete che cosa sia, non ne avete bisogno' o 'non deselezionate questa
opzione se non sapete cosa state facendo'. 

> Ho comunque potuto optare per l'installazione delle funzionalità per
> abilitare l'ATM.
>
> A questo punto le domande...
> 
> Come posso essere sicuro di aver richiesto l'aggiornamento alla 2.4.1
> di tutte le funzionalità attualmente attive nell'attuale 2.2.16 ?

 Consigli:

 1) il compilatore gcc della RH7 e' unstable e non va bene per il kernel,
    c'e' un pacchetto apposito con kgcc
 2) installa il sorgente del kernel 'ufficiale' RH 
    (kernel-source-2.2.*.rpm), guardati bene quali opzioni sono
    selezionate, prova a ricompilare e far funzionare quello, prima di
    buttarti a testa bassa su un kernel nuovo.
 3) leggiti gli help di tutto cio' che trovi selezionato - tanti
    potrebbero non servirti: altre schede di rete, ISDN, patch per bug di
    chipset EIDE che non hai, etc
 4) quando hai fatto un kernel 2.2 che funziona, cerca di replicare la
    stessa configurazione sul 2.4
 4) il passaggio 2.2.x -> 2.4.x non e' banale, assicurati di avere le
    release aggiornate dei pacchetti necessari (markoer aveva postato una
    lista non molto tempo fa)

> Se qualcosa non è stata attivata, il sistema mantiene la versione
> precedente, oppure rimane non istallata e, quindi, inutilizzabile ?

  Se fai un upgrade dell'RPM del kernel compilato, viene sostituito. Se
usi i sorgenti e compili i kernel, dipende da te, da come installi la
nuova. Il lilo puo' gestire la scelta fra piu' kernel (tab al prompt
LILO:), devi copiare il kernel in /boot e creare una nuova sezione nel
lilo.conf, tipo

 image = /boot/kernel_new
  root = /dev/hd??
  label = new
  optional

 Usa lilo -v per vedere bene cosa fa.

 Ho allegato uno scriptino che uso (per pigrizia) per compilare e
installare i kernel 'di prova'.

> Su Appunti Linux ho letto che potrei optare per ottenere un kernel
> modulare. In quale caso conviene scegliere questo tipo di kernel ?

 Prima di tutto, un kernel puo' essere anche parzialmente modulare. Di
certe cose il kernel ha bisogno subito - ad esempio i driver per il
disco, che quindi deve essere statico. Pero' se hai sia EIDE che SCSI,
puoi compilare statico solo quello del disco di boot, e lasciare l'altro
in un modulo.

 Per un pc di uso 'generico', conviene che sia piu' modulare possibile, a
meno che tu non abbia grossi problemi di RAM o di prestazioni: non sempre
hai bisogno del codice per il PPP, o per il CDROM, e il kernel sa andarsi
a pescare al volo quello che gli serve (vedi modprobe e
/etc/modules.conf). Cosi', se ad esempio cambi scheda di rete o audio, non
hai nel kernel roba che non serve, e non hai bisogno di ricompilarlo. Per
questo i kernel standard delle distribuzioni sono compilati piu' modulari
possibile, e addirittura RH (non so gli altri) utilizza initrd (vedi man
initrd) per i driver SCSI necessari al boot.

 Per una macchina dedicata (server), un kernel statico e' piu' tranquillo
e occupa un pochino meno RAM di kernel+moduli.

 La cosa ideale e' fare un kernel modulare, usare un po' la macchina
tenendo sott'occhio (lsmod) quali moduli sono normalmente caricati, e poi
ricompilare il kernel inserendo quei moduli come statici, lasciando come
moduli quelli usati raramente (ad es. il floppy disk, o il cdrom), ed
eliminando gli altri (per sveltire la compilazione, non che diano
fastidio)

 (quasi tutti) I moduli hanno anche il vantaggio/svantaggio che quando
vengono caricati fanno un reset dell'hardware che controllano. In certi
casi questo e' comodo e/o utile: ad esempio se si ha una scheda ISA di cui
si deve 'indovinare' IO e IRQ, e' veloce farlo con un modulo, passandogli
parametri diversi (almeno fino a quando non becchi quello _molto_
sbagliato e pianti il sistema :-/); oppure se hai una scheda che a volte
si blocca e ha bisogno di un reset a fondo, senza dover fare reboot. In
altri casi, invece, l'hardware puo' non apprezzare di essere inizializzato
una seconda volta... e allora il kernel statico e' un vantaggio.

> Grazie a tutti e... non mi brontolate, dovrò farvi ancora tante altre
> domante, prima di giungere alla soluzione.

 ci conto ;-)

 Sergio

-- 
--------------------------------------------------------------------------
 Things will get better despite             Sergio Ballestrero
our efforts to improve them.                       S.Ballestrero@iname.com
	-- Will Rogers                        

-------------- parte successiva --------------
cd /usr/src/linux

REL=$(cat include/linux/version.h|grep UTS_RELEASE|cut -d\" -f2)
LOG="$0.log"
export MAKEFLAGS="-s -j3 -l4"

function die {
   echo "@@@@@ failed on $1 with code $?"
   exit
}

function xmake {
  echo "@@@@@ make $1"
  #make $1 >> $LOG || die "make $1"
  make $1 || die "make $1"
}

make menuconfig || die 'make menuconfig'

xmake
xmake modules

export MAKEFLAGS="-s"
xmake bzImage
xmake modules_install

if [ $(basename $0) = "kernnew" ] ; then
 EXT="_new"
else
 EXT="-$REL"
fi

cp -v arch/i386/boot/bzImage /boot/kernel$EXT
cp -v System.map /boot/System.map$EXT
if [ ! -s /boot/System.map-$REL ]; then 
   cp -v System.map /boot/System.map-$REL
fi

ls -lat /boot/kernel*

lilo
sync;sync;sleep 1;sync
echo "@@@@@ done."