Newsgroup: it.comp.os.linux.sys
Titolo: ricompilazione del kernel 2.4.20 con debian su SUN

Salute a tutti. Ho una situazione abbastanza strana che non rieco a capire.
Su una SUN ultra1 dove ho installato la debian woody ho aggiornato il
kernel al 2.4.20. Mi è stato utile in quanto ora fa anche lo shutdown
regolarmente.
Ieri ho apportato una modifica al kernel e nella ricompilazione è venuto
fuori un errore quando lavora sui drivers/video:
fonts.c:64: #error No font configurated.
font.c: In function `fbcon_find_font':
ecc ecc
dal momento che l'errore permaneva anche riportando il tutto alla versione
primitiva ho rimesso un kernel vergine e la compilazione è andata
regolarmente in porto poi ho ricompilato ed è saltato fuori lo stesso
errore :((
A nessuno risulta che la compilazione del 2.4.20 incasini qualche cosa che
poi impedisce la ricompilazione?
Ciao & TIA
Antonio
--
    **** !!!! attenzione: campo From alterato !!!! ****
-------------------------------------------------------------
Antonio Madesani: amadesani(at)libero(punto)it

 poi impedisce la ricompilazione?
Ovviamente no!
Hai cambiato il .config ?
Spiega bene come fai a ricompilare il kernel...
Ciak
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Ciak
Ciao, non è la prima volta che ricompilo un kernel, sia su X86 che Sun e
quindi la mia osservazione nasce dal dubbio che vi sia qualche problema. 
Il tuo "ovviamente" lascia il tempo che trova....
Non sarebbe l'unica volta che c'è un problema in un kernel nuovo.
In ogni caso sulla X86 il problema non è presente, sulla Sun pare di si.
Aspetto qualche utilizzatore Sun.
Il .config l'ho cambiato e poi ho rimesso il precedente. Il problema
scompare con un kernel vergine su cui il mio .config compila regolarmente
per poi segnalare un errore alla seconda compilazione.
Ciao


> poi impedisce la ricompilazione?
Occhio che il 2.4.20 e' bacato nella gestione della ext3.
Vedi 
www.ziobudda.net
-- 
Un Ciao in DO Maggiore!
-=) Sbaturzio (=-

 per poi segnalare un errore alla seconda compilazione.
E' un problema cho ho riscontrato su un kernel 2.2.20 per ppc, mentre su
Sparc io ho compilato un paio di volte il 2.2.21 senza alcun problema.
Non saprei a cosa attribuire il problema...ma su macchine un po' lente e'
fastidioso cancellare i sorgenti e reinstallarli!
Cippa Lippa
--------------------------------
Inviato via 
http://usenet.libero.it

 per poi segnalare un errore alla seconda compilazione.
Ok, ma non hai spiegato _cosa fai_ quando compili.
make mrproper tra ogni compilazione ?


 Vedi 
www.ziobudda.net
Diamo la notizia in modo corretto.
Il 2.4.20 puo' dare problemi solo se usi ext3 in modalità "data=journal"


 make mrproper tra ogni compilazione ?
make mrproper (dopo aver messo da parte il vecchio .config)
make config
make dep
make clean
make vmlinux
make modules
make modules_install
e poi trasferimenti vari.
Il problema ha continuato a verificarsi e così ho provato a scaricare
il 2.4.20 (precedentemente avevo patchato il 2.4.19) ho ricompilato ed il
problema è scomparso. Anche se ho provato a fare delle modifiche "strane"
che portavano ad errori di compilazione, appena rimettevo a posto i
corretti settaggi le cose andavano lisce.
Evidentemente si tratta di qualche cosa che caratterizza la SUN (sul x86
non avviene) e che riguarda i miei sorgenti.
Il giochino mi è costato due giorni .....
compilare su una SUN ultra1 è veramente lungo.....
Mi chiedevo "by the way" se fosse possibile compilare su una macchina non
Sparc e poi trasferire gli oggetti ottenuti (vmlinux, moduli e SystemMap)
sulla SUN. Sarebbe utile sfruttare la macchina più veloce per farlo.
Ringrazio tutti coloro che hanno risposto


 Il 2.4.20 puo' dare problemi solo se usi ext3 in modalità "data=journal"
Ammetto la mia ignoranza: con che altre modalita' e' possibile usare la
ext3?


 ext3?
ext3 di default fa il journaling solo dei metadati e non dei dati. Con
quell'opzione fai il journaling dei dati.
Tornando al bug, pare che sia sufficiente fare un sync prima
dell'umount, quindi nei file di shutdown basterebbe mettere un sync
prima di umount -a e dovrebbe risolvere.
Ammetto pero` di avere letto molto velocemente la storia, quindi
controllate prima di provare.
io non uso il journaling dei dati, quindi sono stato abbastanza
tranquillo con l'update.
Bye.

 quell'opzione fai il journaling dei dati.
Argh...hai solleticato la mia curiosita': adesso non riesco piu' a
trattenermi dal fare domande sull'argomento.
Questa opzione (data=journal) dove va messa, nel lilo.conf?
In che casi puo' servire fare il journaling dei dati, oltre ai metadati?  
Cosa sono i metadati?


 Antonio
Rispondo a quest'ultima parte, poiche' io l'ho fatto, devi crearti un
cross-compiler un cross-binutils, e se vuoi fare il vero hacker, una
cros-glibc, il tutto a partire da sorgenti, io ci sono riuscito dopo mesi di
smadonnamenti vari, e grazie ad un tizio che mi ha spedito uno script che mi
cosruisce il cross-ambiente, dato che e' lunghetto, e non vorrei suscitare
le ire dei frequentatori, puoi richiedermelo a dude68 at 
tiscali.it
Una volta fatto il tutto, basta che crei un'alias in .bash_profile che si
chiamera' ad esempio, smake, al cui interno ci sara scritto ARCH=sparc
cros-gcc=sparc-linux-
cosi' quando digiterai smake, partira' il makefile per sparc, poi lo compili
con make e basta, fai make mosules, e via dicendo, poi tramite ftp ti copy
bzImage system.map e i moduli eventualmente compilati, ocio che non puoi
usare lo stesso kernel tree di quello per x86, e devi pure fare dei
soft-link in /usr/include/asm che puntino ad asm-sparc senno' non funge, per
completare l'opera, ti server pure un'altro programmillo che si chiama
elftoaout che serve appunto a trasformare da elf in a.out, tra le altre
cose, puoi anche farti direttamente il tftpboot.img, cosi' puoi bootare da
lan, e evitare di fare passaggi e cose varie via ftp
Per maggiori info scrivimi