compilazione kernel

[moebius77]

Salve a tutti
ho tentato di installare il nuovo kernel 2.6.17 seguendo l-how to presente nel sito
Non riesco a capire una cosa
vi sono due procedure una successiva all altra
installazione k2.6 e successiva compilazione k2.6
Ora a me i comandi da battere mi son sembrati uguali
o meglio la seconda operazione mi [ sembrata parte della prima
ma visto il risultato .......
Mi sapete dire perch]
esiste una guida pi\ completa
Grazie

[pennega]

la guida che è presente qui su slacky è un pò vecchiotta... prova a leggere quella che ho scritto io... bada che non si riferisce a slack ma a qualsiasi sistema Gnu/Linux comunque alla fine c'è una piccola sezione dedicata alla gestione su slack... la guida la trovi su

http://www.spaghettilinux.org/index.php ... &Itemid=82

fammi sapere se ti piace

[dapuzz]

Ottima guida, forse fin troppo ottima, e 26 pagine sono davvero troppe. L'inizio della sezione 4 con i comandi è molto ben fatta e più che sufficiente. (+1) In breve i passi da seguire sono
1)Scompattare i sorgenti
2)Creare il link /usr/src/linux
3)Copiare il vecchio .config e dare make oldconfig
4) Opzionale: modificare il config con make (x/q)config
5)make && make modules_install
6) copiare la bzImage, system.map e config( per comodità) nel boot
7)aggiustare il bootloader per usare il nuovo kernel
incrociare le dita e riavviare :asd:

Puoi sostituire i passi 5 e 6 e 7 con un make && make install ma per questo leggiti prima la documentazione o rischi di far danni!

[castcarlitos]

Ho letto le prime pagine della guida... per ora... e ci sono alcune imprecisioni e alcune cose non sono ne spiegate ne molto chiare... Non voglio essere polemico, solo cercare di migliorare un gran lavoro fatto per la comunità...

In questa guida si cerca di mettere a disposizione del lettore l'esperienza pratica del redattore e dei sui collaboratori nella compilazione del kernel Gnu/Lnux, in particolare si fa riferimento al ramo 2.6.X.

Almeno il nome... GNU/Linux

il vantaggio di ciò è la possibilità di avere un kernel molto leggero che al suo interno contiene in maniera statica solo lo stretto indispensabile (come ad esempio il supporto per i dischi fissi o i bus della scheda madre o ancora il file system della partizione di root). Questa peculiarità è anche efficace in caso di blocco di qualche modulo non necessario (ad esempio il supporto per la scheda video, quella audio eccetera) che non causeranno il blocco del sistema.

E lo svantaggio?
Lo svantaggio è che il codice inserito come built-in è più veloce, occupa meno memoria e, per componenti sempre collegate, in built-in dovrebbe essere la scelta corretta

BSD Process Accounting: permette al kernel di rilasciare informazioni sui processi come ad esempio il momento della creazione, l'utente proprietario, il nome del comando,
l'occupazione di memoria ecc.. Da inserire come built-in. Si consiglia in oltre di abilitare la
sotto opzione BSD Process Accounting version 3 file format.

Perché si consiglia?? Io compilo kernel da una vita e non l'ho mai inserito...

Auditing support: abilita l' infrastruttura di auditing che può essere usata con un altro sottosistema kernel come SELinux. Da abilitare come built-in insieme alla sotto opzione Enable system-call auditing support.

Da abilitare??? Uno che non si sa compilare un kernel da solo fa auditing del codice???

Symmetric multi-processing support: questa opzione va abilitata solo su sistemi dotati di più di un processore o di processori a più core.

E anche per chi ha processori HyperTreading (es. P4 HT) e per questa "gentaglia" (per chi ha o HT o dual core) selezionare come n° CPU 2 e lo scheduler che fa al loro caso...

Local APIC support on uniprocessors: un APIC locale e' un controller di interrupt integrato nella CPU. Si può tranquillamente abilitare questa voce anche se non si dispone di una CPU con tale controllo: il kernel funzionerà altrettanto bene. Per lo stesso motivo può essere abilita anche la sotto-funzione IO-APIC support on uniprocessors.

Credo che oggi ce l'abbiano tutti, ma è il consiglio di inserirlo come built-in comunque che mi lascia perplesso... Allora perché mi compilo un kernel fatto su misura per me se poi ci metto cose che non mi servono o che non ho???

Enable X86 board specific fixups for reboot: abilitare come built-in, questa permette il riavvio sicuro del sistema per alcune combinazioni hardware-bios.

Come sopra... Se non ho una di queste combinazioni perché la abilito?

High Memory Support: dato che Gnu/Linux può gestire sistemi con 4 GB di memoria fisica per processore è necessario abilitare tale supporto solo si ha una quantità di RAM superiore a 960 MB.

Una macchina a 32 bit può indirizzare nativamente 4GB di RAM, ma non per ogni processore, ma per tutta la macchina... Indirizzi a 32 bit infatti hanno questo come limite...

Use register arguments: non abilitarla.

E perché??? Io la uso da sempre, è una miglioria (basta leggere l'help allegato al kernel) non da problemi, sfrutta la capacità delle CPU moderne di poter salvare fino a 3 parametri nei registri della CPU stessa...

Timer frequency: permette la configurazione della frequenza del timer, va impostata a 1000 Hz se si desidera usare un sistema che dia risposte veloci ad eventi interattivi (uso desktop). Su sistemi che non richiedono queste peculiarità può essere impostato a 100Hz.

Sia per questo discorso, che per quanto riguarda la Kernel Preemption, andrebbe detto anche qual'è il prezzo da pagare per la responsività del sistema... Cioè molto MOLTO lavoro buttato via (overhead) che su un desktop non è importante, su un server SI!

Hardware Monitoring support: abilita il supporto per i dispositivi di monitoraggio hardware come i sensori di temperatura, di tensione la velocità della ventola del processore ecc. Abilitarla come built-in.

Se uno li ha.... E non ha niente a che fare con il Thermal Monitor della CPU....

Dal sotto menù Console display driver support abilitare come built-in Framebuffer
Console support e i vari font: non facendolo si rischia che all' avvio non si veda nulla
anche se il kernel funziona e viene visualizzata l'interfaccia del server X.

I font non sono necessari... C'è già un "modello" di default, solo se si vuole una personalizzazione sono da selezionare...

Profiling support: in questa sezione si abilita il supporto per la creazione dei profili tipo OPROFILE.

Per cosa? A chi serve?

Ciao e complimenti comunque per la guida

[pennega]

In primis grazie per i consigli e stai pur certo che ne terrò conto nei prossimi rilasci... questo è un lavoro in continua espansione e quindi le imprecisoni ci sono... tra l'altro devo anche correggere la parte sulle versioni del kernel...

Il primo errore che mi hai segnalato mi è proprio sfuggito e mi sà che è li dalla prima versione dellla guida...

Per qunato riguarda i moduli aggiungerò volentieri gli svantagi che mi hai indicato... anche se io preferisco usare i moduli i gusti son gusti

Grazie della precisazione sull' HyperTreading

Poi quelli che ho scritto sono semplicente dei consigli e comunque il modo generale di inserire quelle parti (poi credo si sia capito che se una parte può essere inserita come modulo nulla vieti di mettere come built-in)... è chiaro che se a me non serve Selinux è inutile cha abilito il supporto auditing, o se non ho periferiche di whatchdog non mi serve a nulla abilitarle così come le altre periferiche... ma li io non posso entrare in merito spetta ad ogniuno sapere l'hardware che ha il suo pc... tantè che ho inserito i programmi per poterlo sapere nel caso non si sappia...

Appena trovo il tempo correggo e ti informo delle modifiche
Grazie ancora

[castcarlitos]

WOW, grazie della risposta

Tu scrivi spesso:

abilitare come built-in

e pensavo che fosse il suggerimento che davi al lettore

Tutto qui... Grasssssssie

[pennega]

ehheheehh
perchè non avrei dovuto rispondere... le critiche, quando costruttive, sono sempre ben accette e le tue mi son sembrate ben argomentate

in effetti ora che mi ci fai pensare la questione forse non è tanto chiara vedrò di mettere delle note che esplicitano la mia posizione nel raccontare tutte quelle belle cose

[castcarlitos]

Mitico

[moebius77]

ho trovato la guida molto esaustiva anche per il commento dei moduli da inserire oppure no
ma c'è una cosa che non riesco proprio a comprendere ....
alla fine della compilazione , prima dell'installazione ,rammenti la possibilità di copiare i sorgenti in una directory con un nome differente in modo tale da non toccare i moduli sel sistema corrente (funzionanti) questo in virtù di qualche errore di compilazione che potrebbe dare adito ad problemi tipo kernel panic etc..
Ora il punto è l'operazione di copiatura dei moduli in una differente directory , quando va effettuta ?
il sistema all'avvio in che directory va a cercare i moduli?
passando da un kernel 2.4 a un 2.6 tale operazione va efettuata o no ?i moduli non sono differenti da versione a versione ?

[castcarlitos]

alla fine della compilazione , prima dell'installazione ,rammenti la possibilità di copiare i sorgenti in una directory con un nome differente in modo tale da non toccare i moduli sel sistema corrente (funzionanti) questo in virtù di qualche errore di compilazione che potrebbe dare adito ad problemi tipo kernel panic etc..
Ora il punto è l'operazione di copiatura dei moduli in una differente directory , quando va effettuta ?
il sistema all'avvio in che directory va a cercare i moduli?
passando da un kernel 2.4 a un 2.6 tale operazione va efettuata o no ?i moduli non sono differenti da versione a versione ?

Io non ho capito il problema... Provo a pormelo da solo in questo modo...

Se tu compili un kernel con i moduli che ti servono, il processo di installazione li mette in /lib/modules/"uname -r"/........ , e fin qui tutto bene .

DIciamo che hai deciso, nella prima compilazione di un kernel vanilla 2.6.18, di abilitare il supporto per i dispositivi di loop come modulo, in /lib/modules/2.6.18/kernel/drivers/block/ ti troverai il modulo loop.ko.

Se nelle successive modifiche al config del kernel (dello stesso, altrimenti il problema non si pone, ogni versione crea la sua directory) decidi di abilitarlo come built-in, non succede niente, il pezzo di codice di cui avevi bisogno si trova nel tuo kernel monolitico, e il tuo modulo (ora inutile) se ne sta sempre nella sua cartellina .

Se invece decidi di tenere entrambe le versioni e di sceglierle all'avvio, quella con il loop built-in, nel momento in cui cercherai ad esempio di montare un'immagine iso, lo farà senza chiedere niente (Mitica ) mentre la prima, quella con il modulo, alla richiesta del montaggio (che brutto , cioè quando chiedi di inserire nel filesystem root nel punto scelto l'immagine cd) capirà di non poterlo fare e cercherà se c'è un modulo (nel percorso corretto) che "glielo sappia spiegare " ...

E nel caso in cui tu, nel secondo kernel, abbia tolto completamente il supporto per dispositivi di loop non succederà proprio niente di brutto, nel senso che quando si compila come modulo qualcosa il kernel "si segna da qualche parte " che c'è "qualcuno" che sa fare quel mestiere e che, nel momento di necessità, andrà a prenderlo... Se tu escludi il supporto, anche nel momento di necessità, lui (il kernel) negerà il servizio, pur essendo presente il modulo... Solo che lui (sempre il kernel ) non lo sa!!!

Tutta questa spatafiata per dire che non c'è problema a ricompilare (a fare esperimenti su) il kernel per quanto riguarda i moduli, abilita quelli che vuoi, ti occuperanno solo spazio su disco (forse un Mega )

Le uniche cose da tenere in considerazione sono:

- Il compilatore che hai usato per i moduli deve essere lo stesso che usi con il kernel nel quale vuoi caricare i suddetti moduli

- Alcune flags del kernel, tipo SMP PREEMPT ecc, non possono essere presenti in una parte e nell'altra no;

- Alcune flags di ottimizzazione utilizzate nel processo di compilazione devono essere le stesse (tipo -march=prescott -O3 -fomit-frame-pointer, è solo un esempio)

- Penso di aver detto tutto

Spero!!!

Bye

[urka58]

Ora il punto è l'operazione di copiatura dei moduli in una differente directory , quando va effettuta ?
il sistema all'avvio in che directory va a cercare i moduli?
passando da un kernel 2.4 a un 2.6 tale operazione va efettuata o no ?i moduli non sono differenti da versione a versione ?

Nel momento in cui impartisci il comando "make modules_install" i moduli caricabili vengono copiati in /lib/modules/x.x.xx/ (x.x.xx sta per la release del kernel: tipo quello che restituisce il comando "uname -r" ad esempio 2.6.18).
Questa è anche la directory dove vengono cercati i moduli del kernel in memoria quando richiesto.
Quindi, compilando i moduli di release diverse non si corre il rischio di sovrascrivere la directory /lib/modules/x.x.xx/. Se viceversa si ricompila con opzioni diverse la stessa release ed al tempo stesso si vuole poter continuare ad usare la configurazione già installata bisogna in fase di compilazione, subito dopo avere configurato il kernel (make xconfig, o tuo metodo preferito) modificare il Makefile nella top directory di linux-x.x.xx all'occorrenza
di "EXTRAVERSION=" inserendo qualcosa tipo "-special" o "-nospecial" in modo che in fase di installazione venga creata una directory /lib/modules/x.x.xx-special senza sovrascrivere la directory dei moduli del kernel della stessa release.
Forse non è tanto chiaro... casomai chiedi
Ciao