[Tech] kernel 2.4.1

[Sergio Ballestrero]

On Fri, 23 Feb 2001, Marco Ermini wrote:
> theold wrote:
> > 
> > Mi è stato detto di porre i quesiti relativi al kernel sulla lista tech
> > (anche se io sono da primissssssssimipassi) ed eccomi qui.

 Patchare il kernel per il supporto PPP over ATM non e' affatto da
primipassi; le altre domande invece sarebbero state bene anche li, a mio
parere.

> > Sto provando e riprovando ad installare il kernel 2.4.1, ma non cavo un
> > ragno dal buco.
> > Anche evitando di applicare le patch per abilitare il pppoatm, la prima
> > parte della configurazione (make mrproper ; 
> 
> "make mrproper" evitalo pure, e' solo una perdita di tempo
> 
> > make xconfig ; make dep ; make
> > clean ; 
> 
> anche make clean dopo make dep e' generalmente una perdita di tempo e basta

 ma dopo una patch e' una buona abitudine, non gliela far perdere troppo
presto :-)

> > Un'altra domanda
> > inserendo in /boot vari vmlinuz ho la possibilità di attivare, alla
> > partenza, la versione del kernel che desidero. Ma in lilo.conf si fa solo
> > riferimento ai diversi vmlinuz e non a diversi System.map. Come fa il
> > sistema a collegarsi al giusto System.map ?
> 
> Perche' sa che stai usando il kernel 2.4.1 e cerca il file System.map-2.4.1.
> Se usassi il kernel 2.4.1-versione-di-pippo cercherebbe
> System.map-2.4.1-versione-di-pippo. Comunque non e' che ti serva ad un gran
> che', non ri preoccupare.

 Marco, ti ha viziato la RedHat :-). Questo dipende da rc.sysinit, che
dice ln -s -f System.map-`uname -r` /boot/System.map
 Non sono sicuro che tutte le distribuzioni facciano coerentemente la
stessa cosa.

 Comunque, per theold, la System.map serve per solo in caso di Oops o
Panic del kernel, per fargli scrivere i nomi simbolici di cio' che era in
esecuzione. Quindi, se non hai interesse nel debuggare il kernel, o gravi
problemi per cui devi mandare a qualcuno un bug report di un kernel panic,
non ti serve. 

 Sergio

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