delucidazioni ricompilazione Kernel + Moduli + Headers

[ocman]

Ciao a tutti.
Questi giorni sto facendo varii tentativi di ricompilazione del kernel presente nella slackware 12.2, il 2.6.27.7-smp-huge utilizzando la configurazione corrispondente.

Avrò compiltato una decina di kernel, sempre dagli stessi sorgenti puliti con "make mrproper", ma con configurazioni di volta in volta diverse, con i seguenti obiettivi: mettere in sicurezza il mio sistema con opzioni tipo heap randomization ecc, mettere come built-in i driver del mio hardware, migliorare le prestazioni kernel/cpu > come obiettivo futuro di un kernel con caricamento moduli disabilitato, ma per questo si vedrà.

Di frequente quindi mi trovo a cambiare i LINK SIMBOLICI della directory /boot ed a rilanciare lilo.

PROBLEMA: non capisco perchè tornando ad utilizzare kernel che PRIMA erano completamente FUNZIONANTI dopo aver provato altri kernel appena compilati, riceva in console un'infinità di WARNINGS riguardanti ARCHITETTURA CPU, MODULI AUDIO e chi più ne ha più ne metta, DRIVER ATI che prima con quel kernel andavano e ora manco si compilano...., fstab che non monta più tutte la partizioni.

premesse: uso sempre lo stesso kernel, come detto all'inizio, non mi interessa l'ultimo, le funzionalità che uso sono minime.
le compilazioni che faccio vanno sempre a buon fine, faccio sempre: make mrproper, copio config che mi inter. , make xconfig, salvo, make, make modules, make install_modules, copio i files generati, system.map, config, e bzimage.

prima di aprire sto topic ho spulciato un pò questo forum e ho trovato i seguenti messaggi che mi interessavano:
il mitico conraid ha scritto:

"Il problema è che in "teoria" dovresti avere gli header con cui sono state compilate le glibc. E poi molti header vengono creati durante la compilazione, quindi non ce l'hai prima. Ma volendo dopo puoi installarti quelli del kernel appena compilato"

nuitari ha scritto:
Non è un bene fare un kernel monolitico, per una serie di motivi. Il primo e fondamentale è che gli script di sistema e gli applicativi si aspettano di trovare dei moduli ed alcuni potrebbero benissimo rifiutarsi di funzionare se vengono delusi.
Il secono è che determinati driver (come quello d'emulazione scsi ad esempio) è meglio avviarli ad OS caricato per evitare di dover passare 10.000 parametri al kernel dal bootloader.

phobos3576
Hai configurato correttamente il "sound support" nel kernel?
Ricordati che bisogna abilitare ALSA e disabilitare OSS; è necessario inoltre abilitare l'emulazione OSS attraverso lo stesso ALSA.
Un altro aspetto importante è che molto spesso il sound support funziona correttamente solo quando è compilato come modulo; ciò vale anche per i driver della scheda audio.
Per quanto riguarda le varie librerie ALSA da installare a parte, bisogna tenere presente che il kernel 2.6.23.8 utilizza alsa-driver-1.0.15; può anche darsi che tu stia usando delle librerie troppo vecchie.

Bart ha scritto:
l'unico problema è che al boot ho dei fatal relativi a dei moduli che non trova (ho eliminato il loro supporto). Ora volevo chiedervi se per eliminare questi "fatal" l'unica soluzione fosse rieditare /etc/rc.d/rc.modules o se esistevano altre vie. Mi sembra di ricordare di aver letto altri suggerimenti in passato ma non li trovo più nel forum. Consigli?
quella più pulita è creare ad hoc il file /etc/rc.d/rc.modules-2.6.22.2 ; io ho un rc.modules per ogni kernel che ho

Come detto nel titolo vorrei delle delucidazioni, perciò, su cosa dover/poter fare dopo la prima/dopo la compilazione di un kernel dagli stesso sorgenti per non ottenere tutti questi fastidiosi problemi, che anche altre persone hanno incontrato da quello che ho visto.

Inoltre cosa e DOVE sono questi HEADERS e quando servono?
come me li porto dietro se molti vengono creati durante la compilazione come diceva conraid????
ci sono dei pacchetti che possono aiutarmi a ripulire la distro nel cambiare da un kernel all'altro??

Parlando invece di moduli:
da quel che ho capito slackware non mi sembra affatto flessibile su questo campo, nel senso che è legata alla configurazione di pat che usa molti moduli e presume che alcuni come quelli audio siano presenti, CORREGGETEMI SE SBAGLIO.

ringrazio in anticipo per il prezioso supporto.
henry

[414N]

PROBLEMA: non capisco perchè tornando ad utilizzare kernel che PRIMA erano completamente FUNZIONANTI dopo aver provato altri kernel appena compilati, riceva in console un'infinità di WARNINGS riguardanti ARCHITETTURA CPU, MODULI AUDIO e chi più ne ha più ne metta, DRIVER ATI che prima con quel kernel andavano e ora manco si compilano...., fstab che non monta più tutte la partizioni.

Semplice: compilando un nuovo kernel, compili anche nuovi moduli (o ne rimuovi, se ti indirizzi verso un kernel monolitico).
RIcevi quegli errori perché, nella directory /lib/modules/<versione kernel>/ non esistono più alcuni moduli oppure sono stati compilati con opzioni diverse da quelle di partenza, che il vecchio kernel non riconosce più come proprie.
Per ovviare a questo, ti basta specificare in fase di configurazione del kernel, una tag "Local version" (trovi l'opzione nella categoria "General setup" usando menuconfig). Io di solito uso "-custom" (nel caso facessi più prove, dovresti ogni volta usare una local version diversa). In questo modo, i moduli che andrai a compilare finiranno sotto /lib/modules/<versione-kernel>-custom/, non andando a cozzare contro quelli della versione del kernel "standard".

premesse: uso sempre lo stesso kernel, come detto all'inizio, non mi interessa l'ultimo, le funzionalità che uso sono minime.
le compilazioni che faccio vanno sempre a buon fine, faccio sempre: make mrproper, copio config che mi inter. , make xconfig, salvo, make, make modules, make install_modules, copio i files generati, system.map, config, e bzimage.

Beh, qualche comando puoi anche risparmiartelo... Per compilare il kernel, ti bastano

Codice: Seleziona tutto

make && make modules_install

Inoltre cosa e DOVE sono questi HEADERS e quando servono?
come me li porto dietro se molti vengono creati durante la compilazione come diceva conraid????
ci sono dei pacchetti che possono aiutarmi a ripulire la distro nel cambiare da un kernel all'altro??

Gli header files sono file sorgenti contenenti definizioni di costanti, istruzioni per il preprocessore (anche riguardanti la compilazione condizionale di certe parti di codice), prototipi di funzioni etc.
Ogni file sorgente include un certo di numero di header per non stare a riscrivere 20000 volte le stesse righe di definizioni delle costanti, delle funzioni che si chiameranno etc. Durante la fase di configurazione del kernel, alcune di queste costanti vengono create/modificate.
Se non hai i kernel-headers (il pacchetto Slackware dovrebbe chiamarsi così, se non ricordo male), non puoi ricompilarti il kernel.

Parlando invece di moduli:
da quel che ho capito slackware non mi sembra affatto flessibile su questo campo, nel senso che è legata alla configurazione di pat che usa molti moduli e presume che alcuni come quelli audio siano presenti, CORREGGETEMI SE SBAGLIO.

Qui non so risponderti di preciso. C'è da dire, però, che se Slackware non è tanto flessibile, lo diventa con una martellata o due
Se uno script pretende di caricare delle componenti come moduli mentre tu le hai selezionate built-in nel kernel, nulla ti vieta di andare a modificare lo script incriminato per "riportarlo alla retta via", magari imponendo il caricamento di tali moduli sotto determinate condizioni.
Per esempio, supponendo uno script che pretenda a tutti i costi di caricare 2 moduli:

Codice: Seleziona tutto

/sbin/modprobe modulo1
/sbin/modprobe modulo2

puoi fare in modo che, se il kernel attualmente in esecuzione è un tuo kernel personalizzato con tag "-custom", tali moduli non vengano caricati:

Codice: Seleziona tutto

if ! [ `uname -r | grep custom` ]  # Se la versione del kernel non contiene la tag custom ...
  /sbin/modprobe modulo1           # ... carico i 2 moduli
  /sbin/modprobe modulo2
fi

[ocman]

Per ovviare a questo, ti basta specificare in fase di configurazione del kernel, una tag "Local version" (trovi l'opzione nella categoria "General setup" usando menuconfig). Io di solito uso "-custom" (nel caso facessi più prove, dovresti ogni volta usare una local version diversa). In questo modo, i moduli che andrai a compilare finiranno sotto /lib/modules/<versione-kernel>-custom/, non andando a cozzare contro quelli della versione del kernel "standard".

non sapevo di questa cosa....se è così è veramente molto comoda

grazie mille per la dritta!

beh allora da questo deduco che poi potrei, volendo modificare l'rc.modules a mio piacimento....magari col nome rc.<versione-kernel>-custom e linkarlo a rc.modules....c'è da dire però che leggendo i commendi dei files della directory etc/rc.d ho visto che il file che fa il GROSSO DEL LAVORO. è RC.M che si occupa di verificare le dipendenze e caricare i moduli, magari in auto....mi sa che dovrò intervenire anche su questo...

e come hai detto tu posso chiedere che se trovo la tag CUSTOM non siano caricati.....beh direi ottimo.

ok tornando sugli headers. da quello che hai detto tu, 414N, penso non mi diano problemi, nel senso che quelli sono forntiti in un paccchetto, e per la prima compilazione vanno bene.....ma il problema in slackware, e penso anche in tutte le altre distro, sorge dopo la compilazione del kernel, per esempio al momento della RICOMPILAZIONE dei drivers VIDEO. io da newbie posso pensare che magari alcuni di questi siano stati creati, cambiati o rimossi......è così? come rimediare? come me li porto dietro se servono per la compilazione di qualcosa da far girare con quel kernel....?

[414N]

beh allora da questo deduco che poi potrei, volendo modificare l'rc.modules a mio piacimento....magari col nome rc.<versione-kernel>-custom e linkarlo a rc.modules....c'è da dire però che leggendo i commendi dei files della directory etc/rc.d ho visto che il file che fa il GROSSO DEL LAVORO. è RC.M che si occupa di verificare le dipendenze e caricare i moduli, magari in auto....mi sa che dovrò intervenire anche su questo...

Io rc.M non lo toccherei. Tutto quel che fa è far partire alcuni demoni. Rivolgerei piuttosto l'attenzione a rc.modules.
Ricordati, inoltre, che se vuoi usare impostazioni personalizzate per l'avvio, il file rc.local è fatto apposta. Viene richiamato in automatico da rc.M (in fase di avvio) se presenta il bit eseguibile (x).

ok tornando sugli headers. da quello che hai detto tu, 414N, penso non mi diano problemi, nel senso che quelli sono forntiti in un paccchetto, e per la prima compilazione vanno bene.....ma il problema in slackware, e penso anche in tutte le altre distro, sorge dopo la compilazione del kernel, per esempio al momento della RICOMPILAZIONE dei drivers VIDEO. io da newbie posso pensare che magari alcuni di questi siano stati creati, cambiati o rimossi......è così? come rimediare? come me li porto dietro se servono per la compilazione di qualcosa da far girare con quel kernel....?

C'è un target apposito per make:

Codice: Seleziona tutto

make prepare

Ricrea tutti gli header necessari alla compilazione dei moduli a partire dal file .config presente nella directory dei sorgenti del kernel. Questo può essere leggermente problematico, specie se hai compilato un kernel con opzioni diverse da quello di default all'interno della stessa directory di sorgenti.
Infatti, nel caso tu decidessi di compilare un modulo per il kernel standard della Slackware (ammesso che tu l'abbia tenuto) scegliendolo all'avvio, questo probabilmente fallirebbe anche dopo aver lanciato "make prepare", per via del fatto che il file .config presente nella directory dei sorgenti del kernel contiene le tue opzioni personalizzate, non più quelle standard di partenza.
Per recuperare il file config del kernel attualmente in esecuzione, prova a lanciare

Codice: Seleziona tutto

zcat /proc/config.gz

Funzionerà solo se nel kernel attualmente in esecuzione hai attivato il supporto a /proc/config.gz (nel menù General Setup --> "Kernel .config support" e "Enable access to .config through /proc/config.gz"). Nel caso funzionasse, potresti aggiungere una riga in rc.local (e renderlo eseguibile con chmod +x /etc/rc.d/rc.local), la quale non fa altro che salvare il contenuto di /proc/config.gz in /usr/src/linux/.config ad ogni avvio, in questo modo:

Codice: Seleziona tutto

zcat /proc/config.gz > /usr/src/linux/.config

Così facendo, ogni qualvolta volessi laciare "make prepare" da un qualsiasi kernel (con supporto a /proc/config.gz, mi raccomando), esso andrà sempre a leggere un file di configurazione che rispecchia la configurazione del kernel attualmente in esecuzione.

[ocman]

ok!!!
non sapevo nemmeno di make prepare.....anche questo può aiutare molto (lo uso fra il make e il make modules, giusto?)

In linea generale quindi quando vado a ricompilare moduli a POSTERIORI di un kernel devo sempre avere la /usr/src/linux pulita, con la CONFIGURAZIONE del kernel che sto usando per compilare il modulo/driver.
è molto interessante anche la tua procedura per automatizzare la copia di .config.....vedrò di utilizzarla...

ps: il supporto per /proc/config.gz lo attivo sempre ora . mi è già successo più volte di non ritrovarmi più la config quando mi serviva

grazie ancora

[Blallo]

non usare make e make modules...
per compilare fai così:
ti fai la configurazione (make oldconfig, make xconfig o make menuconfig a seconda di cosa ti piace più usare)
dopodichè dai un bel make -j3 (o j5 se hai un dual core) (l'opzione j aumenta il numero di porcessi in parallelo quindi velocizzi un po la compilazione...io ci metto 15 minuti )
dopodichè dai solo un make modules_install
dopo ti copi il System.map, l'immagine del kernel e configuri lilo.

[ocman]

ti ringrazio jimmy_page

l'opzione -jN la utilizzo anche io da tempo. confermo che è molto più rapida.
parlandoci chiaro: mi garantite perciò che il comando make modules_install si occupa sia della creazione che della installazione dei moduli??

il dubbio è me è sorto in quanto nel wiki relativo alla ricompilazione del kernel prima viene usato e poi no.....quindi a scanso di equivoci io lo mettevo.
ovviamente mi sono detto vado a leggere nella documentazione ufficiale e qui troviamo

- If you configured any of the parts of the kernel as `modules', you
will also have to do "make modules_install".

io però sinceramente non penso di usare make oldconfig....la versione del kernel è la stessa. infatti:

If you want to carry your existing configuration to a
new version with minimal work, use "make oldconfig", which will
only ask you for the answers to new questions.

[enzo.bak]

Beh, qualche comando puoi anche risparmiartelo... Per compilare il kernel, ti bastano

make && make modules_install

Oppure, più "pigramente" (in perfetto stile Slackware), io faccio:

make && make modules_install install

Che automaticamente copia i files necessari ed aggiorna lilo.

[ocman]

oggi finalmente ho messo in pratica quanto suggerito da 414N!!

tutto funziona a meraviglia e addirittura ho un modulo dei driver della vga compilato per ogni kernel!!!
il che vuol dire che lo devo compilare solo la prima volta che avvio con quel kernel e poi rimane nella sua bella directory /lib/modules/miokernel/

[conraid]

Per rispondere brevemente a qualche cosa che ho letto in questa discussione

- rc.modules personalizzato si chiama rc.modules.local e viene caricato per primo, guardati gli script di avvio. Così non devi nemmeno ogni volta starlo a ricreare o rinominare
Ma normalmente, anche "grazie a udev, non dovresti nemmeno aver bisogno di questo files. Se invece ti accorgi che qualche modulo non viene caricato correttamente all'avvio lo inserisci qui.

- come ti hanno detto per compilare basta make && make modules_install
Nel kernel 2.6 make compila anche i moduli, se ci sono

- io ti sconsiglio di dare make install, anche perché ti cambia i link simbolici ed altro. Sposta i 3 file a mano (config, System.map e bzImage... naturalmente dandogli nomi personalizzati), configurati lilo e lancialo
Sempre meglio avere il kernel originale di Slackware per possibili errori

- gli headers servono per compilare alcuni programmi ed i moduli del kernel, ma solitamente questi attingono direttamente dai sorgenti "lavorati". Lascia i kernel-headers di Pat, a meno che non sai quel che fai.
Se compili un kernel, dopo lascia anche i sorgenti "lavorati" senza cancellarli. Come detto possono servire per compilarti altri moduli, etc...

- make prepare ti serve solamente se non hai i sorgenti lavorati e vuoi compilarti moduli esterni (nvidia, etc...) Non c'entra niente con make, make modules_install, etc... Quindi non devi farlo ne prima, ne dopo, ne nel mezzo. Lo fai solamente se vuoi ricompilare qualche modulo esterno e non hai più la directory dei sorgenti da cui hai compilato il kernel stesso

- che un modulo esterno devi compilarlo solo una volta (a meno che non ricompili un kernel) mi sembra normale, prima come facevi?

[ocman]

- make prepare ti serve solamente se non hai i sorgenti lavorati e vuoi compilarti moduli esterni (nvidia, etc...) Non c'entra niente con make, make modules_install, etc... Quindi non devi farlo ne prima, ne dopo, ne nel mezzo. Lo fai solamente se vuoi ricompilare qualche modulo esterno e non hai più la directory dei sorgenti da cui hai compilato il kernel stesso

ok conraid, sei stato chiarissimo.
d'ora in poi procedo in questo modo. se devo ricompilare qualcosa, visto che mantenere i sorgenti lavorati corrisponenti è dura, farò un make prepare, prima spostando la configurazione.

comunque questa mattina sto già testano varie cose e tutto sempra andare a gonfie vele.....

che un modulo esterno devi compilarlo solo una volta (a meno che non ricompili un kernel) mi sembra normale, prima come facevi?

prima praticamente ricompilavo il modulo, o meglio tentavo di ricompilarlo, ogni volta che cambiavo kernel da caricare con lilo. , siccome avevo la stessa directory dei moduli.
comunque direi problema RISOLTO!

grazie a tutti per la vostra disponibilità, a presto

[conraid]

d'ora in poi procedo in questo modo. se devo ricompilare qualcosa, visto che mantenere i sorgenti lavorati corrisponenti è dura, farò un make prepare, prima spostando la configurazione.

perché è dura? ti manca spazio?

[ocman]

...no
Il linea teorica dovrei ricreare una directory /usr/src/directory_sorgenti per ogni ricompilazione e poi quando vado ad fare un modulo o una compilazione di altro genere linkarla a /usr/src/linux....
è fattibile, ma fin quando si tratta dello stessa versione del kernel penso di non farlo, preferisco usare il make prepare.
Seguirò di sicuro il tuo suggerimento quando avrò versioni diverse, perchè in questo caso è quasi dovuta come operazione.

[conraid]

...no
Il linea teorica dovrei ricreare una directory /usr/src/directory_sorgenti per ogni ricompilazione e poi quando vado ad fare un modulo o una compilazione di altro genere linkarla a /usr/src/linux....
è fattibile, ma fin quando si tratta dello stessa versione del kernel penso di non farlo, preferisco usare il make prepare.
Seguirò di sicuro il tuo suggerimento quando avrò versioni diverse, perchè in questo caso è quasi dovuta come operazione.

Non ti seguo.
Se tu compili un kernel hai già quella dir, e quando compili un modulo va già a pescare da li
Non preoccuparti del "link simbolico" /usr/src/linux, a meno di moduli particolari la maggioranza cerca in /lib/modules/`uname -r`/build che come puoi vedere è un link alla directory (la directory lasciala usare ai traduttori di windows) dei sorgenti.

Poi fai come credi, ma sinceramente ho capito poco quel che hai detto, perché da quel che ho capito è contraddittorio, se hai un solo kernel compilato da te che ti costa avere la directory dei sorgenti?
make prepare lo fai se i manca spazio e devi cancellarla o se usi kernel compilato altrove

[Dak]

Per ovviare a questo, ti basta specificare in fase di configurazione del kernel, una tag "Local version" (trovi l'opzione nella categoria "General setup" usando menuconfig). Io di solito uso "-custom" (nel caso facessi più prove, dovresti ogni volta usare una local version diversa). In questo modo, i moduli che andrai a compilare finiranno sotto /lib/modules/<versione-kernel>-custom/, non andando a cozzare contro quelli della versione del kernel "standard".

Io, probabilmente in modo scorretto, per ottenere lo stesso risultato, modifico il parametro Extraversion nel Makefile dei sorgenti.