[Primipassi] Kernel 2.4.2

[Sergio Ballestrero]

 Ciao Theold,
  e complimenti per l'ottimo lavoro !  Hai niente in contrario se (dopo
qualche ritocco) la metto sulle pagine di Primipassi ?


On Sun, 25 Feb 2001, theold wrote:

> Sono riuscito ad installare il kernel-2.4.2, dopo molte peripezie e prove,
> durante le quali ho incontrato vari intoppi. Mi sembra che funzioni, anche
> se al bootstrap mi segnala alcuni errori (non bloccanti) che vedrò in
> seguito (col vostro aiuto) di sistemare. Il percorso non è stato breve e mi
> sono rimasti tanti dubbi. Sperando di fare cosa gradita, o comunque utile
> per altri alle prime armi, riporto, di seguito, l'iter seguito per
> l'installazione e configurazione del kernel-2.4.2, specificando nei vari
> step i problemi ed i dubbi che mi sono rimasti (quelli che mi torneranno in
> mente man mano che scriverò). Mi farebbe piacere che qualche esperto
> confermasse o correggesse questo modus operandi, possibilmente rispondendo
> anche alle domande-dubbio inserite.

 Provvedo subito !

> Verrà sicuramente una mail molto lunga, me ne scuso anticipatamente, ma
> spero possa rivelarsi utile anche ad altri.
> 
> La mia attuale versione installata è la RedHat 7.0. Ho operato nell'ambiente
> grafico, sia per la facilità d'uso del filemanager e delle sue funzionalità,
> sia per poter utilizzare il comando make xconfig (descritto in seguito).

 make menuconfig offre le stesse comodita' di xconfig, per chi preferisce
la console.

> 1)  Ho scaricato da Internet l'ultima versione del kernel disponibile (la
> 2.4.2). Il file è "linux-2.4.2.tar.bz2". Ho preferito il file di tipo .bz2
> perchè ha una compressione maggiore e, quindi, si scarica più velocemente.
> 
> 2)  Ho spostato tale file nella directory /usr/src. Ho aperto la shell (sono
> l'utente root) e mi sono posizionato nella stessa directory per mezzo del
> comando "cd /usr/src".
> 
> 3)  Nella shell, ho eseguito il comando "cat linux-2.4.2.tar.bz2 | bunzip2 |
> tar xvf -", che ha provveduto a scompattare il file generando la directory
> /usr/src/linux.

 se c'e' un kernel gia' installato, e' bene rimuovere prima il symlink,
per essere sicuri di non sovrascrivere (e, quel che e' peggio, mischiare)
i vecchi sorgenti:
 rm linux

 i tar nuovi supportano direttamente la compressione bzip2:
 tar Ixvf linux-2.4.2.tar.bz2 

> 4)  Ho rinominato tale directory in /usr/src/linux-2.4.2 e poi ho creato un
> file di collegamento simbolico "linux" che punta alla predetta dir. E' stato
> agevole fare ciò con le funzionalità del filemanager.
>    /usr/src/linux   --->   /usr/src/linux-2.4.2

da console:
 mv linux linux-2.4.2
 ln -sf linux-2.4.2 linux

> 5)  In "Appunti di Informatica libera" (Appunti Linux) ho letto che
> bisognerebbe assicurarsi che in /usr/include ci siano tre files (asm + linux
> + scsi) di collegamento simbolico che puntino nel seguente modo:
>    /usr/include/asm   --->   /usr/src/linux/include/asm-i386/
>    /usr/include/linux   --->   /usr/src/linux/include/linux/
>    /usr/include/scsi   --->   /usr/src/linux/include/scsi/
> Questi puntamenti non ci sono, ma non so se è un suggerimento ancora valido,
> oppure valeva solo per le vecchie distribuzioni. Io NON li ho attivati (non
> so se ho fatto bene).

 No, e' bene crearli; non tanto per compilare il kernel, quanto per
compilare altri programmi che possono avere bisogno di quegli include.
 Su distribuzioni RH e simili, questi link vengono creati dal pacchetto 
kernel-headers (che contiene anche i suddetti include)

> 6)  Sergio aveva scritto che il compilatore gcc della RH 7.0 non è idoneo
> per la compilazione del kernel e che, al suo posto, sarebbe meglio
> utilizzare il kgcc. Il rigo 29 del Makefile (/usr/src/linux/Makefile)
> contiene l'istruzione:
>    CC = $(CROSS_COMPILE) gcc
> L'ho sostituito col corrispondente rigo trovato nel Makefile della versione
> 2.2.16-22 (presente nella mia RH 7.0):
>    CC :=$(shell if which $(CROSS_COMPILE)kgcc > /dev/null 2>&1; then echo
> $(CROSS_COMPILE)kgcc; else echo $(CROSS_COMPILE)gcc;
> fi) -D__KERNEL__ -I$(HPATH)
> Sergio, ho fatto bene, o mi volevi consigliare un'altra cosa ?

 No, hai fatto bene. Magari bastava un semplice
 CC = $(CROSS_COMPILE) kgcc

> 7)  Sempre posizionato nella /usr/src/linux-2.4.2 (o anche /usr/src/linux
> che è la stessa cosa), ho eseguito "make mrproper". Marco aveva scritto che
> questo comando è piuttosto inutile: mi piacerebbe sapere se è inutile solo
> quando è la prima volta che si tenta una configurazione (cioè con la dir
> linux allo stato vergine) o è inutile anche dopo vari tentativi di
> configurazione andati male.

 make mrproper, come puoi vedere nel Makefile principale del kernel, fa un
po' di pulizia. Dal kernel 2.0 in poi, il meccanismo delle dipendenze
automatiche funziona bene, quindi quei file vengono sovrascritti quando
necessario, e non cancellarli puo' far risparmiare un po' di tempo di
compilazione.

> 8)  Quindi, ho eseguito make xconfig
> Si è aperta una finestra con una miriade di opzioni. Ad alcune è stato
> facile rispondere (non ho dischi scsi, quindi ne ho disabilitato la relativa
> configurazione) per altre, invece, la scelta fra attivazione, attivazione
> con modulo o disattivazione non è per niente intuitiva. Le scelte proposte
> di default non si sono rivelate sempre le più felici ed inoltre non ho
> trovato gli help sufficientemente chiari (ma forse il vero problema è la mia
> scarsa capacità di tradurre l'inglese). Comunque, per avere un certo
> riferimento, ho aperto il .config della precedente configurazione, che ho
> scoperto che la RedHat aveva salvato nel
> "/usr/src/linux-2.2.16/configs/kernel-2.2.16-i686.config" ed ho effettuato
> le scelte che mi sono sembrate più idonee.
> Questo passo è molto delicato. Nei vari scritti trovati su Internet
> sull'installazione del kernel mi sembra sia stato sempre sottovalutato. In
> effetti, facendo una scelta non adeguata al proprio sistema, è facile che in
> uno degli step successivi si verifichi un errore. In questo caso, si deve
> tornare a questo step (o forse sarebbe meglio al precedente punto 7 ? Marco,
> diccelo tu) e modificare l'opzione sbagliata.
> In ogni caso, viene generato il file .config nella stessa directory, che è
> bene salvarlo anche con un altro nome per confronti successivi. Io, dopo
> ogni modifica col make xconfig, ho copiato il file in bkXX.config (dove XX è
> un progressivo) per avere tutte le configurazioni testate.
> 
> 9)  A questo punto occorre eseguire "make dep".
> 
> 10)  Eseguire "make clean". Marco ha scritto che è inutile, ma mi piacerebbe
> averne una conferma per le stesse osservazioni del precedente punto 7.

 Vedi sopra. Le dependency sono buone, quindi normalmente non ce ne e'
bisogno, specie quando stai facendo delle prove, e non ricompilare tutto
fa spesso risparmiare 2/3 del tempo. Magari, quando hai trovato una
configurazione che sembra andare bene, per puro scrupolo puoi fare un make
clean e ricompilare tutto.

> 11)  Eseguire "make bzImage" (genera il nuovo kernel).
> 
> 12)  Eseguire "make modules" (genera i moduli scelti nella configurazione).
> 
> 13)  Eseguire "make modules_install" (copia i moduli generati in
> /lib/modules/2.4.2).
> 
> 14)  Eseguendo gli step dal 9 al 13, sul video scorrono un'infinità di
> messaggi. Per me (ignorante) sono del tutto incomprensibili. Bisogna
> comunque assicurarsi che nessuno degli ultimi righi visualizzati segnali un
> errore: nel qual caso bisognerebbe modificare la configurazione (precedente
> punto 8).

per ridurre l'output, usa
 make -s 
Questo permette anche di vedere piu' facilmente eventuali warning o errori

> 15)  Se tutto è andato bene, è stato generato il file bzImage nella dir
> /usr/src/linux-2.4.2/arch/i386/boot. Copiarlo nella /boot, rinominandolo
> vmlinuz-2.4.2 (attenzione vmlinuz con la z finale).

 lo puoi chiamare come vuoi; la z non conta, e' solo una convenzione per
identificare i kernel compressi, ma non e' necessaria.

> 16)  Copiare anche i files System.map e vmlinux (che sono stati generati
> nella /usr/src/linux-2.4.2) nella /boot rinominandoli in System.map-2.4.2 e
> vmlinux-2.4.2.

 Il kernel non compresso (vmlinux) non serve ed e' inutilmente ingombrante

> 17)  Nella /boot si trovano anche due files di collegamento simbolico
> vmlinuz e System.map. Dato che nel lilo.conf (passo successivo) si fa
> riferimento al vmlinuz-2.4.2 e, di conseguenza, al System.map-2.4.2,
> possiamo ignorare o anche cancellare questi files (il System.map verrà
> rigenerato automaticamente alla ripartenza e fatto puntare al
> System.map-XX.XX.XX opportuno, relativo al vmlinuz-XX.XX.XX attivato).
> Sempre nella /boot, trovo anche due files: kernel-2.2.16 e
> module-info-2.2.16-22. Mi piacerebbe sapere se potrebbe essere il caso di
> copiare nella /boot due files simili relativi alla 2.4.2 ed eventualmente,
> dove si trovano ?

 kernel e' il vmlinuz - come dicevo, il nome non conta, basta che
corrisponda a quello che scrivi in lilo.conf

 module-info contiene informazioni sui moduli, ma non ne so di piu' e ne
ho sempre fatto tranquillamente a meno.

> 18)  A questo punto si deve modificare il filo /etc/lilo.conf per abilitare
> il sistema alla partenza sia col vecchio kernel 2.2.16-22, che col nuovo
> 2.4.2. Lasciando invariate le prime istruzioni, la parte finale potrebbe
> essere così:
>    default=linux-2.4.2
>    image=/boot/vmlinuz-2.2.16-22
>                   label=linux-2.2.16-22
>                   read-only
>                   root=/dev/hda8
>    image=/boot/vmlinuz-2.4.2
>                   label=linux-2.4.2
>                   read-only
>                   root=/dev/hda8
> 
> 19)  Fatto questo, nella solita shell immettere il comando "lilo" che, sulla
> scorta del lilo.conf, genererà l'eseguibile per l'avvio del computer.

 consiglio lilo -v

> 20)  Il nuovo kernel 2.4.2 richiede anche l'aggiornamento di alcuni
> pacchetti (consultare il /usr/src/linux-2.4.2/Documentation/Changes). Nel
> mio caso ho dovuto adeguare solo i pacchetti util-linux, modutils e ppp.
> Non sto a sviluppare qui l'iter seguito per l'installazione anche dei
> pacchetti. L'operazione, comunque, è andata a buon fine, ma mi chiedo come
> mai, nonostante l'aggiornamento del pacchetto (per es. pppd 2.4.0), se
> eseguo "rpm -qa | grep ppp" mi appare ancora il ppp-2.3.11-7 relativo alla
> precedente versione. L'installazione di un aggiornamento di un pacchetto non
> dovrebbe sostituire in toto il pacchetto presente sul sistema, anche se
> questo era stato generato col comando rpm ?

 Ma hai installato degli rpm nuovi, o hai preso tarball o sorgenti ? 
Perche' se non hai usato l'rpm per installarli, allora nel database dei
pacchetti installati non ci puo' essere traccia di quello che hai fatto.

> Finalmente ho finito. Chiedo venia.

 Ben fatto !

 Ciao,
  Sergio

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