Old:OpenMosix: differenze tra le versioni

Vai alla navigazione Vai alla ricerca
mNessun oggetto della modifica
Riga 1: Riga 1:
''Torna all'indice: [[Linux Kernel in a Nutshell]]''
{{Debianized}}


Uno dei punti pi� delicati e difficili nella creazione della propria versione del kernel Linux � quello di determinare esattamente quali driver e quali opzioni di configurazione sono richiesti per il corretto funzionamento dalla macchina su cui viene installato.
==Introduzione==
Questo capitolo guider� il lettore attraverso questo processo di selezione e scelta dei driver corretti.
In Debian, il kernel Linux pu� essere ricompilato con il metodo standard (valido con tutte le distribuzioni, e quindi anche con Debian) oppure nel cosiddetto ''Debian-way'' (traduzione: ''metodo Debian'' o ''alla Debian'').


==Usare un kernel di una distribuzione==
Questa guida illustrer� il metodo Debian di compilare il kernel Linux. Questo metodo consiste nel creare un pacchetto Debian del kernel compilato per una sua facile installazione/disinstallazione.


Uno dei metodi pi� semplici, per determinare quali moduli siano necessari, � quello di partire dalla configurazione che viene installata dal pacchetto del kernel della distribuzione che si sta usando. � infatti molto pi� semplice determinare di quali driver si ha bisogno basandosi su quelli installati in un sistema in funzione, in cui i driver corretti sono gi� associati all'hardware in utilizzo.
==Installazione Pacchetti==


Se invece si sta personalizzando un kernel per una macchina sulla quale non � installata una distribuzione Linux, allora conviene partire dalla versione LiveCD di una distribuzione. Questo consente all'utente di far partire Linux sulla macchina in oggetto e di determinare in maniera semplice le opzioni di configurazione del kernel e che consentono il funzionamento ottimale della macchina stessa.
Avremo innanzi tutto bisogno di alcuni pacchetti di base per compilare e pacchettizzare un kernel:


===Dove si trova la configurazione del kernel?===
<pre>
# apt-get install debhelper modutils kernel-package libncurses5-dev fakeroot
</pre>
 
A questo punto � necessario installare il pacchetto Debian contenente i sorgenti del kernel. Per prima cosa, cerchiamo questo pacchetto:


Quasi tutte le distribuzioni forniscono il file di configurazione nello stesso pacchetto del kernel. Si consiglia di leggere la documentazione relativa alla distribuzione stessa per sapere dove viene installato il file di configurazione. Solitamente si trova da qualche parte in una sotto-directory di <tt>/usr/src/linux/</tt>.
<pre>
$ apt-cache search linux-source | grep ^linux-source
linux-source-2.6.8 - Linux kernel source for version 2.6.8 with Debian patches
</pre>


{{Box|Nota per Debian (NdT)|In debian il file di configurazione di ogni kernel installato si trova in <tt>/boot/</tt> ed ha come nome <tt>config-''versione''</tt>.}}
{{Box|Nota|Ogni versione di Debian (unstable, testing, stable) utilizza in genere una certa versione del kernel e specifiche versioni di altri pacchetti ad esso correlati in modo tale che l'insieme sia il pi� possibile stabile. E' quindi altamente consigliato usare la versione dei sorgenti del kernel che troveremo nei repository della nostra versione di Debian, a meno che non si sappia esattamente quello che si sta facendo.}}


Se avete difficolt� a trovare la configurazione del kernel, allora guardate nel kernel stesso. I kernel di molte distribuzioni sono compilati in modo da includere il file di configurazione dentro il filesystem <tt>/proc</tt>. Per verificare se questo � il vostro caso, digitate:
Adesso installiamo il pacchetto dei sorgenti del kernel che intendiamo installare. Notare che i sorgenti del kernel forniti con Debian sono leggermente differenti da quelli del [[kernel vanilla]] rilasciato dal team di Linus Torvalds ([http://kernel-handbook.alioth.debian.org/ch-source.html#s-changes maggiori informazioni qui]). Nel seguito prenderemo come esempio la versione 2.6.8 del kernel, sostituitela con qualsiasi altra versione vogliate usare.


<pre>
<pre>
$ ls /proc/config.gz
# apt-get install linux-source-2.6.8
/proc/config.gz
</pre>
</pre>


Se il file ''/proc/config.gz'' � presente, allora copiatelo nella directory del sorgente kernel ed estraetelo:
{{Box|Nota|Prima della versione 2.6.12 del kernel Linux, i pacchetti sorgenti e binari Debian si chiamavano rispettivamente <tt>kernel-source-x.x.x</tt> e <tt>kernel-image-x.x.x</tt> (invece dell'attuale denominazione <tt>linux-source-x.x.x</tt> e
<tt>linux-image.x.x.x</tt>). Questo perch� � previsto l'inserimento di nuovi kernel (come GNU HURD e FreeBSD) all'interno di Debian. }}
 
E' sconsigliato ricompilare il kernel come utente root, perch� questo pu� creare diversi tipi di problemi. In Debian, per policy, tutti i sorgenti sono contenuti in <tt>/usr/src</tt> (almeno quelli installati dai pacchetti Debian) e hanno come proprietario <tt>root</tt> e come gruppo proprietario <tt>src</tt>. Gli utenti del gruppo <tt>src</tt> hanno inoltre diritto di scrittura in <tt>/usr/src/*</tt>. Baster� dunque aggiungere al gruppo <tt>'''src'''</tt> l'utente che si vuole usare per la compilazione, con i seguenti comandi:


<pre>
<pre>
$ cp /proc/config.gz -/linux/
# adduser nome_vostro_utente src
$ cd -/linux
$ gzip -dv config.gz
config.gz:      74.9% - - replaced with config
</pre>
</pre>


Copiate questo file di configurazione nella vostra directory del kernel e rinominatelo in ''.config''.
dopodich� ricordate di effettuare un nuovo login, perch� fino ad allora non sarete effettivamente membri del gruppo <tt>'''src'''</tt>; in qualsiasi momento controllate la lista dei gruppi cui appartenete con il comando <tt>groups</tt>
Ora potrete utilizzare questo file come base di partenza nella personalizzazione della configurazione del kernel cos� come descritto nel [[LKN:_Configurare_e_Compilare|Capitolo 4]].


Usando questo file di configurazione si dovrebbe ottenere sempre un file immagine del kernel (un ''kernel ricompilato'', NdT) funzionante sulla propria macchina.
{{Box|Nota|Ricordate di non usare l'utente root per ricompilare il kernel (e neanche per scompattarlo) altrimenti tutti i file che verranno creati apparterranno a <tt>root:root</tt>. Se a questo punto si cercher� di compilare dall'utente normale si avranno problemi di permessi e per risolverli dovrete dare un:
Lo svantaggio di questa immagine � che verranno compilati quasi tutti i moduli e driver presenti nei sorgenti del kernel. Ci� non � quasi mai necessario per una singola macchina, quindi sarebbe meglio disabilitare tutti i driver e le opzioni non necessarie. Si raccomanda di disabilitare solo quelle opzioni che si � sicuri non serviranno, poich� ci sono parti del sistema che richiedono l'abilitazione di certe opzioni.
# chown -R root:src /usr/src/
Se, inoltre, il gruppo <tt>src</tt> non ha pi� i diritti di scrittura dovranno anch'essi essere ripristinati con:
# chmod -R g+w /usr/src/*
}}


===Determinare quali moduli siano necessari===
== Configurazione del kernel ==
Usando il file di configurazione fornito dalla vostra distribuzione il tempo richiesto per la compilazione del kernel � molto lungo poich� tutti i possibili driver vengono abilitati. Si dovrebbe cercare di abilitare solo i driver per l'hardware presente nel sistema, cos� da ridurre i tempi di compilazione del kernel. Inoltre, compilando ''staticamente'' (invece che come moduli) alcuni o tutti i driver necessari, si riduce la memoria utilizzata ed in alcune architetture si velocizza il funzionamento del sistema. Per escludere i driver dal kernel � necessario per� determinare quali moduli sono indispensabili per il funzionamento dell'hardware installato. Attraverso l'utilizzo di due esempi, cercheremo di spiegare come determinare quali driver siano indispensabili al controllo dell'hardware.


Le informazioni che mettono in relazione i dispositivi ai driver presenti nel kernel sono conservate in varie parti del sistema. Uno dei posti pi� importanti dove sono salvate queste informazioni � il filesystem virtuale ''sysfs''. All'avvio di Linux, ''sysfs'', dovrebbe essere montato dagli script di inizializzazione della vostra distribuzione nella directory ''/sys''. ''sysfs'' consente di dare un'occhiata a come le varie parti del kernel sono legate l'una a l'altra, questo lo si deduce grazie ai vari collegamenti simbolici (''symlink'' NdT) che puntano all'interno dell'intero filesystem.
=== Passi preliminari ===
Entriamo ora nella directory dei sorgenti del kernel:


In tutti gli esempi di seguito, saranno riportati i veri percorsi (''path'' NdT) di ''sysfs'' corrispondenti ad hardware specifico. La vostra macchina sar� certamente diversa, ma la posizione  relativa delle informazioni sar� la stessa. Non ci si deve allarmare se i nomi di file nel ''sysfs'' non sono i medesimi, ci� � normale e prevedibile.
<pre>
$ cd /usr/src
</pre>


Inoltre, la struttura interna del file di sistema ''sysfs'' subisce modifiche, a causa sia della riorganizzazione dei driver sia del fatto che gli sviluppatori del kernel trovano nuovi modi per meglio presentare in ''user space'' le strutture interne del kernel. A causa di questo, col tempo, alcuni dei ''symlink'', precedentemente menzionati in questo capitolo, possono non essere presenti. Tuttavia, le informazioni sono ancora tutte presenti, al massimo sono state un po' spostate.
Troveremo in questa directory (avendoli installati precedentemente) i sorgenti del kernel in un archivio tar.bz2:


====Esempio: Come determinare il driver di rete====
<pre>
$ ls
...
linux-source-2.6.8.tar.bz2
...
</pre>
 
Decomprimiamo il kernel:
 
<pre>
$ tar xvjf linux-source-2.6.8.tar.bz2
</pre>


Uno degli elementi pi� comuni ed importanti in un sistema � la scheda di rete. � essenziale capire quale driver la controlla ed attivarlo nella configurazione in maniera da consentire un corretto funzionamento delle connessioni di rete.
A fine decompressione avremo una directory linux-source-2.6.8, creiamo un link simbolico linux che punta ai sorgenti del kernel:


Primo: partendo dalle connessioni di rete si risale al device PCI
<pre>
<pre>$ ls /sys/class/net/
$ ln -s /usr/src/linux-source-2.6.8 linux
eth0  eth1  eth2  lo</pre>
</pre>


La directory ''lo'' rappresenta il dispositivo di rete loopback, ed non dipendente da nessun dispositivo di rete realmente installato. Invece si dovrebbe riservare particolare attenzione alle directory ''eth0'', ''eth1'' e ''eth2'', dato che si riferiscono a dispositivi realmente esistenti
Non � necessario creare questo link, ma una usuale convenzione farlo anche perch� risulta comodo per entrare nella directory dei sorgenti del kernel.


Per determinare di quali dispositivi ci si deve occupare, si utilizza il comando ''ifconfig'':
Ora spostiamoci nella directory e puliamo i sorgenti del kernel:


<pre>$ /sbin/ifconfig -a
<pre>
eth0 Link  encap:Ethernet  HWaddr 00:12:3F:65:7D:C2
$ cd linux
inet  addr:192.168.0.13  Bcast:192.168.0.255  Mask:255.255.255.0
$ make-kpkg clean
UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
</pre>
RX packets:2720792 errors:0 dropped:0 overruns:0 frame:0
TX packets:1815488 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:3103826486 (2960.0 Mb) TX bytes:371424066 (354.2 Mb)
Base address:0xdcc0 Memory:dfee0000-dff00000
eth1 Link  encap:UNSPEC  HWaddr 80-65-00-12-7D-C2-3F-00-00-00-00-00-00-00-00
BROADCAST MULTICAST  MTU:1500  Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth2 Link  encap:UNSPEC  HWaddr 00-02-3C-04-11-09-D2-BA-00-00-00-00-00-00-00
BROADCAST MULTICAST  MTU:1500  Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
lo Link  encap:Local Lookback
        inet addr:127.0.0.1  Mask:255.0.0.0
UP  LOOPBACK  RUNNING  MTU:16436  Metric:1
RX packets:60 errors:0 dropped:0 overruns:0 frame:0
TX packets:60 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:13409 (13.0 Kb) TX bytes:13409 (13.0 Kb)</pre>


Da questo listato si pu� riconoscere nel dispositivo di rete <tt>eth0</tt>, quello attivo e funzionante, infatti nelle righe;
Questo passaggio � inutile se � la prima volta che compilate il kernel, ma dalla seconda volta in poi diviene necessario per eliminare i file generati dalle precedenti compilazioni che potrebbero creare conflitti.


<pre>eth0 Link  encap:Ethernet  HWaddr 00:12:3F:65:7D:C2
Ora, se avete installato un kernel precompilato che abbia la stessa versione del kernel che volete ricompilare potreste usare il suo file di configurazione come base di partenza per configurare il vostro kernel. A tal scopo basta copiare il file di configurazione che st� in <tt>/boot</tt> (i file di configurazione dei kernel installati hanno come nome <code>config</code> seguito dalla versione del kernel) nella directory dei sorgenti:
inet  addr:192.168.0.13  Bcast:192.168.0.255  Mask:255.255.255.0</pre>


Questo risultato dimostra che il dispositivo Ethernet si vede assegnato un indirizzo IP valido (<tt>inet</tt>).
<pre>
$ cp /boot/config-2.6.8 .config
</pre>


Ora, dopo che abbiamo individuato il dispositivo <tt>eth0</tt> e ci siamo accertati di volerlo abilitare nel nostro nuovo kernel, dobbiamo individuare quale driver lo controlla. Ci� si realizza con una semplice procedura, che quella si seguire i link nel filesystem sysfs, basta digitare un comando di una sola riga:
C'� chi arriva anche a installare un kernel precompilato per usare semplicemente il suo file di configurazione. Se avete banda da sprecare possibile farlo. Tuttavia si pu� benissimo partire da zero senza copiare nessun file di configurazione.


<pre>$ basename `readlink /sys/class/net/eth0/device/driver/module`
=== Configurazione: <code>make menuconfig</code> ===
e1000</pre>


Il risultato mostra che il modulo <tt>e1000</tt> controlla il dispositivo di rete <tt>eth0</tt>. Il comando ''basename'' racchiude in un'unica linea di comando i seguenti passaggi:
A questo punto, per configurare il nostro kernel, non ci resta che lanciare il comando:


: 1. Individua il symlink ''/sys/class/net/eth0/device'' contenuto all'interno della directory ''/sys/device/'', la quale contiene le informazioni relative al dispositivo che controlla ''eth0''. Fate attenzione al fatto che nelle nuove versioni del kernel la directory ''/sys/class/net/eth0'' potrebbe essere un symlink.
<pre>
$ make menuconfig
</pre>


: 2. All'interno della directory che descrive il dispositivo in sysfs, c'� un symlink che punta al driver relativo a questo dispositivo. Questo symlink nominato ''driver'', pertanto si segue questo collegamento.
Vi apparir� un'interfaccia testuale dalla quale sar� possibile configurare le opzioni del kernel. ''Questo � il passaggio pi� delicato, nonch� il pi� lungo e difficile''.  


: 3. All'interno della directory che descrive il driver in sysfs, c'� un symlink che punta al modulo che si trova all'interno del driver in oggetto. Questo symlink chiamato <tt>module</tt>. Noi cerchiamo l'oggetto a cui punta questo symlink, per ottenerlo ci serviamo del comando ''readlink'', il quale produce un risultato simile a questo:
Se dovete configurare un kernel per la prima volta prendetevi almeno un'ora di tempo ed iniziate con calma, leggendo tutte le pagine dell'help in linea. Uno dei vantaggi di un kernel ricompilato la possibilit� di ottenere un kernel estremamente piccolo e leggero proprio perch� viene compilato il supporto per le sole periferiche e i soli filesystem effettivamente usati. In questo modo si ha un kernel piccolo e pochi moduli. Un kernel di questo tipo impiega anche molto meno tempo ad essere compilato. Per fare un esempio potrebbe impiegare sui 10 min. su in athlon 1000, quando un kernel debian ufficiale impiegherebbe sicuramente pi� di un'ora sulla stessa macchina. In definitiva, compilando un kernel snello, sar� possibile anche fare pi� prove ed ottimizzarlo quindi al meglio.  
:<pre>$ readlink /sys/class/net/eth0/device/driver/module </pre>
:<pre> ../../../../module/e1000</pre>


: 4. Dato che a noi interessa solo il nome del modulo e ci disinteressiamo del resto del risultato ottenuto con il comando ''readlink'', tenendo solo la parte pi� a destra del risultato. Questo � appunto ci� che il comando ''basename'' realizza. Applicandolo direttamente all'intero percorso, questo comando ci ritorna quanto segue:  
Per trovare quali moduli sono richiesti dal vostro hardware potete usare il comando '''lspci''' o meglio '''lspci -v'''. Inoltre risulta utilissimo consultare il database dei driver di Linux a [http://kmuto.jp/debian/hcl/ questo indirizzo]: inserendo semplicemente l'output di <code>lspci -n</code>, otterrete l'elenco dei moduli da compilare
: <pre>$ basename ../../../../module/e1000</pre>
: <pre>e1000</pre>


Cos� abbiamo inserito il lungo risultato del symlink, ottenuto da ''readlink'', quale parametro nel programma ''basemane'', permettendo cos� l'intero processo di essere realizzato in una sola riga.
Per approfondire la configurazione del kernel:


Ora che abbiamo identificato il nome del modulo, si dovrebbe trovare l'opzione della configurazione del kernel che lo controlla. Si pu� cercare nei vari menu di configurazione dei dispositivi di rete oppure cercare nel codice sorgente del kernel stesso per essere sicuri di avere l'opzione giusta.
* [[Esempio configurazione kernel]] nel nostro wiki, per un semplice esempio.
* [http://a2.pluto.it/a266.htm#almltitle484 Elementi della configurazione] per una descrizione pi� dettagliata delle varie voci. Questo � un capitolo della monumentale opera [http://a2.pluto.it/appunti_di_informatica_libera.htm Appunti di Informatica Libera], per la quale tutti noi siamo grati all'autore '''Daniele Giacomini'''.
* [http://kernel.xc.net/ Linux Kernel Configuration Archive]: potrete cercare le varie opzioni di configurazione di ogni versione del kernel.


<pre>
In bocca al lupo con la configurazione ;-).
$ cd ~/linux/linux-2.6.17.8
$ find -type f -name Makefile | xargs grep e1000
./drivers/net/Makefile:obj-$(CONFIG_E1000) += e1000/
./drivers/net/e1000/Makefile:obj-$(CONFIG_E1000) += e1000.o
./drivers/net/e1000/Makefile:e1000-objs := e1000_main.o e1000_hw.o e1000_ethtool.o e1000_param.o
</pre>


Si precisa che "e1000'', usato in questo esempio, deve essere sostituito con il nome del modulo che state analizzando.
Una volta finita la configurazione, uscite e salvate i cambiamenti. A questo punto il file <tt>/usr/src/linux/.config</tt> conterr� la nostra configurazione del kernel.


La cosa che ci interessa nel risultato del precedente comando ''find'' sono le righe dove compaia il termine <tt>'''CONFIG_'''</tt>. Questa � l'opzione di configurazione che il kernel deve aver attivato per poter compilare il modulo. Nell'esempio precedente l'opzione di configurazione che c'interessa � pertanto <tt>CONFIG_E1000</tt>.
{{Box|Nota|Se avete gi� ricompilato il vostro kernel e volete passare ad una versione pi� aggiornata, ma non troppo diversa (ad esempio: 2.6.8 --> 2.6.10), non conviene rifare tutta la configurazione da capo. D'altro canto non � neanche possibile usare il vecchio file di configurazione dato che nel nuovo kernel ci saranno voci in pi� e o in meno e sarebbe improponibile cercarle ad una ad una.


Adesso si dispone dell'informazione necessaria per poter configurare il kernel. Si esegue lo strumento menu di configurazione:
Basta allora copiare il vecchio file di configurazione nella directory dei sorgenti del nuovo kernel e lanciare il comando:


<pre>$ make menuconfig</pre>
$ make oldconfig


Dopodich� si prema il tasto / (slash) (che ha il compito di far partire una ricerca), e si digita l'opzione di configurazione, senza la parte di testo <tt>CONFIG_</tt>. Questo processo � mostrato nella [[:Immagine:Config_search.png|figura 7-1]].
in questo modo verranno fatte delle domande su come configurare ''le sole nuove voci'' presenti nel kernel. Se i due kernel sono troppo diversi questo metodo non conviene pi� dato che bisogna rispondere ad uno ad uno a tutte le domande sulle voci diverse. Sicuramente non conviene usarlo per il passaggio 2.4 --> 2.6.<br>
Un file config del vostro attuale kernel pu� essere trovato in <tt>/boot</tt> sotto il nome di <tt>config-2.x.x</tt>.}}


[[Immagine:Config_search.png|center|frame|''Figura 7-1. Ricerca in menuconfig.'']]
=== Alternative a <code>make menuconfig</code> ===


Il sistema di configurazione del kernel vi dir� ora esattamente dove selezionare l'opzione per abilitare questo modulo. Vedi [[:Immagine:Config_search_found.png|figura 7-2]].
Per completezza segnalo le altre interfacce grafiche che � possibile usare per configurare il kernel al posto di <code>make menuconfig</code>.


[[Immagine:Config_search_found.png|center|frame|''Figura 7-2. Risultato della ricerca in menuconfig.'']]
;<code>make xconfig</code>: per usare una interfaccia grafica '''qt''' per la configurazione.
;<code>make gconfig</code>: per usare una interfaccia grafica '''gtk''' per la configurazione.


Il primo elemento nella schermata mostra l'opzione che stavate cercando. Le informazioni mostrate dalla schermata vi dicono che, per attivare il modulo <tt>E1000</tt> nel kernel, la seguente opzione di configurazione deve essere abilitata:
Questi frontend non aggiungono niente di nuovo e sono pertanto funzionalmente equivalenti tra di loro. Per usarli sono per� necessarie le librerie di sviluppo, rispettivamente, di ''qt'' e ''gtk''.


  Device Drivers
== Compilazione del kernel ==
      Network device support
Ora � venuto il momento di cominciare la compilazione, a tal scopo useremo make-kpkg. Vediamo come utilizzare velocemente questo tool per compilare il nostro kernel personalizzato:
      [*] Network device support
          Ethernet (1000 Mbit)
      [*] Intel(R) PRO/1000 Gigabit Ethernet support


Questo modo di procedere funziona per ogni tipo di dispositivo attivo nel kernel.
<pre>
$ fakeroot make-kpkg --append-to-version -nomepersonalizzato --revision=1 kernel_image
</pre>


====Esempio: Un dispositivo USB====
Questo comando compiler� il nostro kernel e lo inserir� in un pacchetto debian in <tt>/usr/src</tt>. Il comando '''<tt>fakeroot</tt>''' viene usato semplicemente per simulare un ambiente di root per l'utente normale.


Come secondo esempio, esaminiamo ora un convertitore USB-seriale che � presente nel nostro sistema preso ad esempio. Attualmente il convertitore � collegato alla porta ''/dev/ttyUSB0'', pertanto si deve prendere in esame la sezione tty del ''sysfs''.
Diamo uno sguardo alle opzioni usate:
<pre>$ ls /sys/class/tty/ | grep USB
ttyUSB0</pre>
Potete ora eseguire una ricerca di questo dispositivo nel ''sysfs'' allo scopo di trovare il modulo che lo gestisce, utilizzando la stessa procedura mostrata nella sezione precedente:


<pre>$ basename `readlink /sys/class/tty/ttyUSB0/device/driver/module`
; <tt>--append-to-version</tt> : serve ad aggiungere un nome personalizzato al pacchetto che verr� aggiunto dopo il numero di versione, che in questo caso diventer� ''2.6.8-nomepersonalizzato''.
pl2303</pre>
Dopodich�, per poter individuare l'opzione di configurazione che si deve abilitare, si cerca nell'albero del codice sorgente del kernel:
<pre>$ cd ~/linux/linux-2.6.17.8
$ find -type f -name Makefile | xargs grep pl2303
./drivers/usb/serial/Makefile:obj-$(CONFIG_USB_SERIAL_PL2303) += pl2303.o</pre>


Si utilizzi lo strumento di configurazione del kernel, come indicato in [[:Immagine:Config_search_pl2303.png|figura 7-3]], per trovare l'opzione adeguata da abilitare relativa al settaggio dell'opzione CONFIG_USB_SERIAL_PL2303.
; <tt>--revision</tt> : permette di impostare il numero di revisione del pacchetto, normalmente viene indicato con un numero intero.  


[[Immagine:Config_search_pl2303.png|center|frame|''Figura 7-3. Ricerca di USB_SERIAL_PL2303''.]]
; <tt>kernel_image</tt> : dice a make-kpkg di compilare l'immagine del kernel creare il pacchetto debian.


Nel nostro caso il risultato � mostrato nella [[:Immagine:Config_search_pl2303_found.png|figura 7-4]].
Se ad esempio compileremo per la seconda volta lo stesso kernel, per fare solo delle modifiche minori, pu� essere utile usare lo stesso nome per --append-to-version ed usare un numero di revisione maggiore. In questo modo quando installerete il pacchetto del kernel ricompilato questo sostituir� il pacchetto precedente. Al contrario se ricompilate un secondo kernel cambiando la stringa da appendere alla versione, il pacchetto del nuovo kernel conviver� tranquillamente col precedente.


[[Immagine:Config_search_pl2303_found.png|center|frame|''Figura 7-4. Risultato della ricerca di USB_SERIAL_PL2303'']]
In realt� il comando '''make-kpkg''' accetta molti ulteriori parametri (elencher� solo i pi� importanti per gli altri leggete l'amichevole pagina di manuale aka read the friendly manual):


Ci� mostra esattamente dove trovare l'opzione <tt>USB Profilic 2303 Single Port Serial Driver</tt> che � necessaria alla corretta gestione di questo dispositivo.
; <tt>--initrd</tt> : da usare se state compilando un kernel che utilizza le immagini initrd.img (''vedi [[Debian_Kernel_Howto#Bisogna_usare_l.27initrd_oppure_no.3F|FAQ: Bisogna usare l'initrd_oppure no?]]'').
; <tt>--added-modules foo</tt> : compila dei sorgenti esterni (presenti in <tt>/usr/src/modules</tt>) insieme al kernel, potete mettere pi� nomi separati da virgole.
; <tt>--added-patches foo</tt> : aggiunge delle patch al kernel, le patch possono essere molteplici separate da virgole.
; <tt>--config</tt> : sceglie quale frontend usare per configurare il kernel (config, menuconfig, xconfig, gconfig).
; <tt>--zimage</tt> : crea una zImage per il kernel.
; <tt>--bzImage</tt> : crea una bzImage per il kernel.
; <tt>--mkimage</tt> : qui potete passare dei parametri a <code>mkinitrd</code>, ad esempio se volete creare una immagine rom: <code>genromfs -d %s -f %s</code>.
; <tt>--rootcmd foo</tt> : per passare un comando a make-kpkg ad esempio fakeroot o sudo
; <tt>CONCURRENCY_LEVEL</tt> : questa variabile e' l'omonimo di -j per make, per usarla vi basta mettere il numero intero che desiderate usare (''$ CONCURRENCY_LEVEL=4 make-kpkg --blabla ecc.ecc...'' )


====Riassunto: Alla scoperta del dispositivo====
Come ultimo parametro dovremo mettere un'azione da compiere, vediamo le principali:


Riassumendo, ecco i vari passaggi che servono per identificare il driver funzionante di un dispositivo ad esso collegato:
; <tt>clean</tt> : pulisce i sorgenti.
: 1. Trovate la corretta classe di dispositivi in ''sysfs'' relativa al dispositivo che ci interessa. I dispositivi di rete sono elencati in ''/sys/class/net'', mentre i dispositivi tty sono elencati in ''/sys/class/tty''. Gli altri vari dispositivi si trovano in altre sotto-directory di ''/sys/class'', a seconda del tipo.
; <tt>kernel_headers</tt> : questo genera un pacchetto con gli headers del kernel.
: 2. Ricercate nell'albero di ''sysfs''  il nome del modulo che controlla il dispositivo in oggetto. Lo si trova in ''/sys/class/class_name/device_name/device/driver/module'', la ricerca � agevolata se si utilizzano i comandi ''readlink'' e ''basename''.
; <tt>binary</tt> : questo genera un nuovo pacchetto deb con i sorgenti, uno con gli header, uno con la documentazione e uno con l' immagine del kernel.
:<pre>$ basename `readlink /sys/class/class_name/device_name/device/driver/module`</pre>
; <tt>buildpackage</tt> : pulisce i sorgenti e avvia "binary" (vedere sopra).
: 3. Ricercate nei file Makefile con ''find'' e ''grep'' le opzioni <tt>CONFIG_</tt> che abilitano il modulo
; <tt>build</tt> : compila solo l'immagine del kernel.
:<pre>$ find -type f -name Makefile | xargs grep ''module_name''</pre>
; <tt>modules</tt> :compila tutti moduli esterni sotto <tt>/usr/src/modules</tt> e genera un file .diff e un pacchetto sorgente.
: 4. Ricercate l'opzione trovata nel sistema di configurazione del kernel, dopodich� andate dove indicato dal menu per attivare il driver in oggetto.
; <tt>modules_config</tt> : permette di configurare i moduli esterni residenti in <tt>/usr/src/modules</tt> prima di compilarli.
; <tt>modules_image</tt> : crea i pacchetti deb dei moduli esterni residenti in <tt>/usr/src/modules</tt> senza il file .diff e senza creare un'altro pacchetto sorgente.
; <tt>modules_clean</tt> : pulisce i sorgenti dei moduli esterni presenti in <tt>/usr/src/modules</tt>.
; <tt>debian</tt> : questo crea la directory <tt>./debian</tt> utile per compilare i kernel vanilla e patcharli alla maniera debian.


====Lasciamo che il kernel ci dica ci� di cui abbiamo bisogno====
==Installazione nuovo kernel==
Dopo esserci infilati nel ''sysfs'' e aver seguito i sui symlinks per ricercare passo passo i nomi dei moduli, presentiamo un semplice script che far� per noi tutto il lavoro in un modo leggermente diverso:
Una volta finito torneremo alla riga di comando e ci sposteremo nella directory precedente (/usr/src/) dove troveremo il pacchetto .deb del kernel appena compilato:


<pre>
<pre>
#!/bin/bash
$ cd ..
#
$ ls
# find_all_modules.sh
...
#
kernel-image-2.6.8-nomepersonalizzato-386_1.Custom_i386.deb
for i in `find /sys/ -name modalias -exec cat {} \;`; do
...
    /sbin/modprobe --config /dev/null --show-depends $1 ;
done | rev | cut -f i -d '/' | rev | sort -u
</pre>
</pre>


Si pu� scaricare un file d'esempio, contenente questo script, dal sito web del libro, riportato nella sezione ''Come contattarci'' che si trova nella prefazione.
Adesso possiamo installare il pacchetto con il nostro nuovo kernel ricompilato. Diventiamo quindi root con '''su''', e digitiamo:
 
<pre>
Questo script cerca nel ''sysfs'' tutti file chiamati ''modalias''. Il file ''modalias'' contiene gli alias dei moduli e comunica al comando ''modprobe'' quali moduli debbano essere caricati per ogni dispositivo. L'alias del modulo � composto da una combinazione di: produttore del dispositivo, ID, tipo di classe ed altri identificativi univoci per il tipo di dispositivo in questione. Tutti i moduli del driver del kernel hanno una lista interna dei dispositivi che supportano, che � generata automaticamente dalla lista dei dispositivi che il driver comunica al kernel di poter supportare. Il comando ''modprobe'' ricerca tutti i dispositivi nella lista di tutti i driver e cerca di trovare una corrispondenza confrontando l'alias. Se trova una corrispondenza, allora provvede al caricamento del modulo (questa procedura � la stessa seguita dal caricamento automatico dei driver in Linux).
# dpkg -i kernel-image-2.6.8-nomepersonalizzato-386_1.Custom_i386.deb
</pre>


Lo script prevede l'arresto del programma ''modprobe'' prima di caricare il modulo, e visualizza a schermo solo le azioni che eseguirebbe. Questo ci d&agrave; una lista di tutti i moduli che sono necessari al controllo di tutti i dispositivi del sistema. Eseguendo una piccola pulizia della lista, ordinandola e selezionando i campi adeguati,  
Se abbiamo lilo dovremo configurare lilo.conf aggiungendo le righe relative al kernel. Ricordatevi che, con lilo, per rendere effettive le modifiche bisogna aggiornare il [[MBR]] (Master Boot Record) con il comando:  
otteniamo il seguente risultato:


<pre>
<pre>
$ find_all_modules.sh
# lilo -v
8139cp.ko
8139too.koo
ehci-hcd.ko
fimware_vlass.ko
i2c-i801.ko
ieee80211.ko
ieee80211_crypt.ko
ipw2200.ko
mii.ko
mmc_core.ko
pcmcia_core.ko
rsrc_nonstatic.ko
sdhci.ko
snd-hda-codec.ko
snd-hda-intel.ko
snd-page-alloc.ko
snd-pmc.ko
snd-timer.ko
snd.ko
soundcore.ko
uhci-hcd.ko
usbcore.ko
yenta_socket.ko
</pre>
</pre>


Questa la lista di tutti i moduli che sono necessari alla gestione dell'hardware della macchina.
Se abbiamo grub, invece, non ci resta altro che riavviare :D. Tuttavia per approfondire le personalizzazioni che possibile fare su grub, potete leggere l'apposita sezione della [[Guida a Grub]]:
 
* [[Guida_a_Grub#Usare_update-grub|Guida a Grub: Usare update-grub]]
 
==Installare e gestire i moduli==
 
Per compilare e creare automaticamente pacchetti .deb per moduli non presenti nei sorgenti del kernel, Debian fornisce un comodo strumento: [[Pagina di manuale di module-assistant|module-assistant]]. Per un uso interattivo baster� lanciarlo da root per installare i pacchetti, scaricare i sorgenti del modulo che interessa, compilarlo e creare un pacchetto debian.
 
Per scegliere invece quali moduli fare partire all'avvio ci sono diverse strade.
 
# Se si usa l'hotplug, questi dovrebbe caricare automaticamente al boot tutti i moduli necessari. Per evitare il caricamento di certi moduli che possono creare conflitti basta inserili in '''/etc/hotplug/blacklist'''.
# Se non si usa l'hotplug bisogna specificare manualmente quali moduli caricare all'avvio. Per far ci� baster� inserire i nomi dei moduli da caricare in '''/etc/modules''', uno per riga. Se non vi va di editare un file di testo (o non ricordate esattamente i nomi dei moduli) potrete usare '''modconf''' che permette di scegliere interattivamente quali moduli caricare all'avvio.
 
==FAQ==
===Per aggiungere un modulo devo ricompilare tutto il kernel?===
Dipende.


Lo script mostrer� probabilmente alcuni messaggi di errore che possono essere del tipo:
Se il modulo fa parte del kernel debian (cio� il suo sorgente � contenuto nel pacchetto <tt>kernel-source</tt> del kernel) allora bisogna ricompilare il kernel. Tenete presente, tuttavia, che i kernel binari debian includono gi� la maggior parte dei moduli presenti nei sorgenti del kernel. Per caricarli basta usare:


<pre>FATAL: Module pci:v00008086d00002592sv000010CFsd000012E0bc03sc00i00 not found.
  # modprobe ''nomemodulo''
FATAL: Module serio:ty01pr00id00ex00 not found.</pre>


Questo ci dice che non si trova un modulo che gestisce quel dispositivo. Questo non deve comunque interessare pi� di tanto, poich� alcuni dispositivi non hanno driver nel kernel che lavorino per loro.
Se il sorgente del modulo � invece pacchettizzato singolarmente (il nome di questi pacchetti comincia per <tt>module-source</tt>) '''non � necessario''' ricompilare il kernel.
Debian ci fornisce la comoda utility '''module-assistant''' che permette di scaricare, compilare e pacchettizzare un modulo del kernel. Basta lanciare il comando


==Determinare il modulo corretto partendo da zero==
  # m-a
Talvolta non c'� la possibilit� di avere un kernel funzionante su una macchina in modo da determinare quali moduli del kernel siano necessari per gestire l'hardware. Oppure si � aggiunto del nuovo hardware al sistema e bisogna trovare le opzioni della configurazione necessarie a farlo funzionare correttamente. Questa sezione illustrer� come determinare le opzioni di configurazione necessarie ad far funzionare l'hardware.


Il modo pi� semplice per capire quale driver controlla un nuovo dispositivo � quello di compilare come moduli tutti i driver di quel tipo disponibili nei sorgenti del kernel, e lasciare che il processo di avvio tramite ''udev'' associ il driver al dispositivo. Una volta fatto ci�, si dovrebbe essere in grado di risalire al driver necessario seguendo i passi descritti precedentemente, ed infine ricompilare il kernel abilitando il solo driver necessario.
e una interfaccia ''dialog'' ci guider� passo passo.


Se invece non si vogliono compilare tutti i driver, o questo meccanismo non funziona per qualche motivo, sar� necessario un p� pi� di lavoro per individuare il driver necessario. I passi successivi sono complessi e richiedono talvolta di dover cercare nei sorgenti del kernel. Non abbiate timore di ci�, sar� solo di aiuto a comprendere meglio l'hardware ed i sorgenti del kernel.
Si pu� usare il comando <tt>module-assistant list-avaible</tt> (o il diminutivo <tt>m-a la</tt>) per ottenere la lista completa dei moduli installabili con module-assistant. Per le altre innumerevoli opzioni potete leggere la pagina di manuale tradotta in italiano:


I passi necessari per trovare il driver corrispondente di un dispositivo cambiano a seconda del tipo di dispositivo in questione. In questo capitolo discuteremo le due tipologie  di dispositivi pi� comuni: PCI e USB. I metodi descritti qui saranno validi anche per altri tipi di dispositivi.
* [[Pagina di manuale di module-assistant]]


&Egrave; inoltre molto importante per il kernel di essere in grado di trovare tutti i filesystem presenti nel sistema, ed in particolare il filesystem di root. Approfondiremop questo aspetto successivamente in [[LKN: Personalizzare un Kernel#Root filesystem|"Root filesystem"]].
===Bisogna usare l'initrd oppure no?===
La risposta breve �: no non usatelo.


Di seguito la risposta lunga:


===Dispositivi PCI===
L'immagine initrd (ramdisk iniziale) serve per caricare dei moduli nel kernel prima che questo abbia l'accesso alla partizione di root. Quindi basta compilare questi moduli staticamente e non avremo mai bisogno di un ramdisk. Ma quali sono questi moduli che servono nelle prime fasi di avvio? Semplicemente i moduli che permettono di leggere la partizione di root, ovvero:
I dispositivi PCI si distinguono per ''vendor ID'' e ''device ID''; ogni combinazione di ''vendor ID'' e di ''device ID'' pu� richiedere un driver unico. Questa � la base per la ricerca mostrata in questa sezione.


Per questo esempio useremo un scheda di rete PCI che supporremo non funzionante con l'attuare versione del kernele in esecuzione. Questo esempio sar� diverso dalla vostra situazione, con differenti device PCI e valori ID del bus, ma i passi salienti dovrebbero essere rilevanti per ogni tipo di dispositivo PCI per il quale vogliate trovare un driver funzionante.
* il modulo del controller del proprio harddisk
* il modulo del filesystem della partizione di root


In primo luogo troviamo nel sistema il dispositivo PCI che non st� funzionando. Per ottenere una lista di tutti i dispositivi PCI usiamo il programma <code>lspci</code>. Poich� a noi interessano solo dispositivi PCI ethernet restringeremo la nostra ricerca filtrado tra i risultati solo quelli che conterranno la parola ''ethernet'' (case-insensitive):
Per un kernel ricompilato, l'initrd � generalmente inutile e rende l'avvio leggermente pi� lento. &Egrave; anche facile sbagliare se non attivate le giuste opzioni nel kernel (vedi [[#Ma se io devo usare l'initrd assolutamente?|FAQ successiva]]), in tal caso otterreste un kernel panic all'avvio. L'initrd serve soprattutto per i kernel ufficiali delle distribuzioni che devono supportare tutti i controller esistenti e una gran variet� di filesystem. Sarebbe assurdo compilare tutti questi supporti staticamente e quindi vengono inseriti come moduli nel ram disk. L'initrd � necessario anche se si vuole usare un bootsplash, ma questa � un'altra storia:
 
* [[Compilazione Kernel 2.6.11 con Bootsplash]]
* [[Kernel2.6.10 - Framebuffer - Gensplash Patch]]
 
La risposta lunga � quindi no, non usate il'initrd quando questo non sia strettamente necessario.
 
===Ma se io devo usare l'initrd assolutamente?===
Per usare l'intrd '''si deve''' compilare staticamente il supporto per l'initrd impostando le seguenti voci:


<pre>
<pre>
$ /usr/sbin/lspci | grep -i ethernet
Device Drivers  --->
06:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/
  Block devices  --->
8139C/8139C+ (rev 10)
    <*> RAM disk support
    (16)  Default number of RAM disks
    (8192) Default RAM disk size (kbytes)
    [*]  Initial RAM disk (initrd) support
</pre>
</pre>


Questo � il dispositivo che vorremmo fare funzionare.
Inoltre bisogna anche aggiungere il supporto per il filesystem usato nell'immagine del ram disk. In debian si usa di default il '''cramfs''', attivabile alla voce:
 
<pre>
File systems  --->
    Miscellaneous filesystems  --->
        <*> Compressed ROM file system support
</pre>
 
Se si vuole usare un'altro filesystem basta impostarlo in '''/etc/mkinitrd/mkinitrd.conf'''.
 
Con tali configurazioni possibile compilare il kernel con initrd aggiungendo semplicemente l'opzione <code>--initrd</code> al comando <code>make-kpkg</code>. Il pacchetto risultante conterr� degli script che creeranno l'immagine initrd in fase di installazione del pacchetto.


{{Box|Nota:|Potreste anche provare a cercare in tutta la configurazione del kernel un dispositivo che corrisponde alla stringa mostrata sopra (un dispositivo della Realtek Semiconductors con nome prodotto RTL-8139/8139C/8139C+), ma questo non funziona sempre. Per questo motivo useremo la via lunga in questo capitolo.}}
Attualmente ci sono tre tool in debian che permettono di creare l'immagine initrd:


::[[Immagine:Warning_65x68.jpg|left]] Quasi tutte le distribuzioni mettono il programma <tt>lspci</tt> in <tt>/usr/sbin/</tt>, ma alcune lo mettono in altri percorsi. Per trovare in quale posizione � stato messo digitare:
* '''<code>mkinitrd</code> ''' (fornito dal pacchetto <code>initrd-tools</code>): questo � il vecchio metodo usato fino al kernel 2.6.12.
* '''<code>update-initramfs</code> ''' (fornito dal pacchetto <code>initramfs-tools</code>): utilizzabile con kernel 2.6.13 o pi� recenti. Aggiunge tutti i controller del disco e i supporti che potrebbero servire per il boot che sono stati complati come moduli.
* '''<code>mkinitrd.yaird</code> ''' (fornito dal pacchetto <code>yaird</code>): utilizzabile con kernel 2.6.13 o pi� recenti. Analizza il sistema e aggiunge all'immagine initrd '''solo''' i moduli necessari al boot della macchina su cui si installa il kernel. Permette di ottenere una immagine molto pi� piccola del caso precedente.


::<tt>$ '''which lspci'''</tt>
Per ulteriori informazioni sui kernel debian e le immagini initrd:
::<tt>/usr/sbin/lspci</tt>


Se state usando una distribuzione che mette ''lspci'' in una altra posizione usate il percorso corretto per il vostro caso negli esempi seguenti.
* [http://kernel-handbook.alioth.debian.org/ch-initramfs.html Debian Linux Kernel Handbook: Managing the initial ramfs (initramfs) archive]


Le primi bit d'informazione che l'output di ''lspci'' ci mostra sono l'ID del bus PCI per questo dispositivo, <tt>06:04.0</tt>. Questo � il valore che useremo quando guarderemo nel ''sysfs'' per trovare pi� informazioni riguardo questo dispositivo.
=== Ma il kernel non fa il boot senza initrd! ===
Vedi FAQ precedente. L'initrd non � necessario per fare il boot. Se il sistema non parte ci� dipende da una incorretta configurazione del kernel.


Andiamo in ''sysfs'' dove tutti i dispositivi PCI sono elencati, e guardiamo i loro nomi:
'''lordnisse''' ha riportato sul forum che per avviare il suo sistema � stato necessario compilare anche il supporto per partizioni MS-DOS:


<pre>
<pre>
$ cd /sys/bus/pci/devices/
  File systems  --->
$ ls
    Partition Types --->
0000:00:00.0 0000:00:1d.0 0000:00:1e.0 0000:00:1f.3 0000:06:03.3
        [*] Advanced partition selection
0000:00:02.0 0000:00:1d.1 0000:00:1f.0 0000:06:03.0 0000:06:03.4
        [*]  PC BIOS (MSDOS partition tables) support (NEW)
0000:00:02.1 0000:00:1d.2  0000:00:1f.1 0000:06:03.1 0000:06:04.0
0000:00:1b.0 0000:00:1d.7  0000:00:1f.2 0000:06:03.2 0000:06:05.0
</pre>
</pre>


Il kernel numera i dispositivi PCI con un <tt>0000:</tt> iniziale che non viene mostrato nell'output di ''lspci''. Dunque, aggiungiamo un <tt>0000:</tt> al numero datoci da ''lspci'' e entriamo in quella directory:
=== Posso usare make-kpkg con un kernel vanilla ===
Certamente, <tt>make-kpkg</tt> pu� essere usato indifferentemente sia con i sorgenti Debian del kernel di linux che con i sorgenti del [[kernel vanilla]].
 
I sorgenti Debian sono contenuti nei pacchetti <tt>kernel-source-*</tt> (o <tt>linux-source-*</tt> per i kernel dal 2.6.12 in poi) e sono installabili come usuali pacchetti con [[APT]].
 
I sorgenti vanilla devono essere scaricati manualmente da [http://www.kernel.org www.kernel.org]. Devono essere scompattati in <code>/usr/src</code>, e per il resto la procedura di compilazione � assolutamente identica al caso di sorgenti Debian.
 
Nel caso di sorgenti vanilla, pu� essere interessante vedere l'opzione <tt>debian</tt> nella sezione [[Debian_Kernel_Howto#Compilazione_del_kernel|Compilazione del kernel]], tuttavia l'uso di tale parametro � del tutto opzionale.
 
===Errore con l'opzione <tt>--revision</tt> ===
Pu�' capitare che, ricompilando il kernel variando il valore dell'opzione <tt>--revision</tt> venga rilevato un errore simile al seguente:
<pre>
I note that you are using the --revision flag with the value
  2.
However, the ./debian/changelog file exists, and has a different value
  1.
I am confused by this discrepancy, and am halting.</pre>
 
Questo problema e' semplicemente dovuto al fatto che non si � pulito il tree dei sorgenti dopo la prima compilazione. Per ovviare basta dunque:


  $ cd 0000:06:04.0
<pre>$ make-kpkg clean</pre>


In questa directory vogliamo conoscere il valori dei file ''vendor'' e ''device''.
e rilanciare la compilazione.


===You are attempting to install a kernel image (version ''version-revision'') However, the directory /lib/modules/''version-revision'' still exists.===
Se si aggiorna il kernel ad una [[revisione]] successiva, durante l'installazione del pacchetto verr fatta la seguente domanda:
<pre>
<pre>
$ cat vendor
You are attempting to install a kernel image (version 2.6.15.4-swsusp) However, the directory /lib/modules/2.6.15.4-swsusp still exists.  If this directory
0x10ec
belongs to a previous linux-image-2.6.15.4-swsusp package, and if you have deselected some modules, or installed standalone modules packages, this could be
$ cat device
bad. However, if this directory exists because you are also installing some stand alone modules right now, and they got unpacked before I did, then this is
0x8139
pretty benign.  Unfortunately, I can not tell the difference.
 
If /lib/modules/2.6.15.4-swsusp belongs to a old install of linux-image-2.6.15.4-swsusp, then this is your last chance to abort the installation of this
kernel image (nothing has been changed yet).
 
If this directory is because of stand alone modules being installed right now, or if it does belong to an older linux-image-2.6.15.4-swsusp package but you
know what you are doing, and if you feel that this image should be installed despite this anomaly, Please answer n to the question.
 
Otherwise, I suggest you move /lib/modules/2.6.15.4-swsusp out of the way, perhaps to /lib/modules/2.6.15.4-swsusp.old or something, and then try
re-installing this image. 
 
Stop install since the kernel-image is already installed? 
</pre>
</pre>


Questi sono il ''vednor ID'' ed il ''device ID'' per questo dispositivo PCI. Il kernel usa questi valori per associare correttamente un driver ad un dispositivo.
La risposta da dare � '''<tt>No</tt>'''! L'avvertimento ci ricorda che i moduli del vecchio kernel (quello con la stessa versione ma numero di revisione diverso) verranno cancellati e sostituiti dai moduli del nuovo kernel.  


===Dispositivi USB===
Questo � il comportamento normale, infatti, nel caso non si voglia sostituire un vecchio kernel ma semplicemente installarne parallelamente uno nuovo (con la stessa identica versione) si sarebbe dovuta modificare la stringa dopo <code>--append-to-version</code> invece che quella dopo <code>--revision</code> (vedi sez. [[Debian_Kernel_Howto#Compilazione_del_kernel|Compilazione kernel]]).


===Root filesystem===
Se il kernel che si sta sostituendo � quello in esecuzione ''� necessario riavviare la macchina il prima possibile!''


== Link ==


====Controller del disco====
* [http://www.debian.org/doc/manuals/reference/ch-kernel.it.html Manuale di Riferimento Debian: Capitolo 7 - Il kernel Linux su Debian]
* [http://kernel-handbook.alioth.debian.org/index.html Debian Linux Kernel Handbook ]: ottimo documento sulla gestione dei kernel debian delle relative patch (''in inglese'').
* [http://a2.pluto.it/kernel_linux_1.htm Appunti di informatica Libera: Kernel Linux]: Il capitolo dedicato al kernel della monumentale opera di ''Daniele Giacomini'' contiene sia istruzioni generiche che istruzioni per Debian. Inoltre c'� una descrizione dettagliata della configurazione delle varie voci del kernel!
* [http://kernel.xc.net/ Linux Kernel Configuration Archive]: database che permette di ricercare tra le voci di configurazione (e le loro descrizioni) per varie versioni di kernel.


===Un aiuto dallo script===
Buon divertimento con Debian GNU/Linux!


----


----
Autore iniziale: Abortigeno
This is an indipendent translation of the book [http://www.kroah.com/lkn/ Linux Kernel in a Nutshell] by [http://www.kroah.com/log/ Greg Kroah-Hartman]. This translation (like the original work) is available under the terms of [http://creativecommons.org/licenses/by-sa/2.5/ Creative Commons Attribution-ShareAlike 2.5].
 
----
Rivisto ed esteso: [[Utente:TheNoise|~ The Noise]]


[[Categoria:Kernel]]
[[Categoria:Kernel]]
89

contributi

Menu di navigazione