LKN: Aggiornare il Kernel: differenze tra le versioni
S3v (discussione | contributi) (ricreata) |
m (riformattazione) |
||
| Riga 1: | Riga 1: | ||
{{Template:LKN}} | {{Template:LKN}} | ||
__TOC__ | __TOC__ | ||
Inevitabilmente capita: avete un kernel personalizzato, funziona perfettamente tranne per una piccola cosa che è stata sistemata nel più recente rilascio (''release'') dagli sviluppatori del kernel. Oppure un problema di sicurezza è stato trovato, e una nuova release stabile del kernel è stata pubblicata. In entrambi i casi, siete davanti al problema di aggiornare il kernel ma non volete perdere tutto il tempo e la fatica spesa nella creazione di quella perfetta configurazione. | |||
Questo capitolo mostra come è facile aggiornare il kernel da una vecchia versione, mantenendo tutte le opzioni di configurazione della precedente. | |||
Questo capitolo mostra come è facile aggiornare il kernel da una vecchia versione, mantenendo tutte le opzioni di configurazione della precedente | |||
Anzitutto, fate il backup del file ''.config'' nella directory dei sorgenti del kernel. Avete speso del tempo e fatica per crearlo, e dovrebbe essere salvato nel caso qualcosa vada storto provando ad aggiornare. | |||
<pre> | <pre> | ||
$ cd ~/linux/linux-2.6.17.11 | |||
$ cp .config ../good_config | |||
</pre> | </pre> | ||
Solo cinque semplici passi sono necessari per aggiornare il kernel da uno precedentemente preparato: | Solo cinque semplici passi sono necessari per aggiornare il kernel da uno precedentemente preparato: | ||
# Ottenere il nuovo codice sorgente. | |||
# Applicare le modifiche al vecchio albero sorgente per portarlo al nuovo livello. | |||
# Riconfigurare il kernel basato sulla configurazione precedente. | |||
# Compilare il nuovo kernel. | |||
# Installare il nuovo kernel. | |||
Gli ultimi due passi funzionano come descritto prima, per cui discuteremo solo i primi tre punti in questo capitolo. | Gli ultimi due passi funzionano come descritto prima, per cui discuteremo solo i primi tre punti in questo capitolo. | ||
In questo capitolo, presumeremo che si sia compilato con successo un kernel 2.6.17.9, e lo si voglia aggiornare alla | In questo capitolo, presumeremo che si sia compilato con successo un kernel 2.6.17.9, e lo si voglia aggiornare alla release 2.6.17.11. | ||
== Download del nuovo sorgente == | == Download del nuovo sorgente == | ||
Gli sviluppatori del kernel Linux comprendono che gli utenti non desiderano scaricarsi l'intero codice sorgente del kernel per ogni aggiornamento. Sarebbe uno spreco di banda e tempo. Per questo offrono una patch che può aggiornare un kernel più vecchio a uno più recente.<sup>*</sup> | |||
Gli sviluppatori del kernel Linux comprendono che gli utenti non desiderano scaricarsi l'intero codice sorgente del kernel per ogni aggiornamento. Sarebbe uno spreco di banda e tempo. | |||
Sulla pagina principale del sito web di ''kernel.org'', ricorderete che è presente una lista delle versioni correnti di kernel che sono disponibili per il download, come mostrato in [[:Immagine:Kernel.org.png|Figura 6-1]]. | Sulla pagina principale del sito web di ''kernel.org'', ricorderete che è presente una lista delle versioni correnti di kernel che sono disponibili per il download, come mostrato in [[:Immagine:Kernel.org.png|Figura 6-1]]. | ||
| Riga 38: | Riga 30: | ||
Precedentemente, avete usato il link indicato dalla F per scaricare l'intero sorgente del kernel. Comunque, se premete sul nome della release del kernel, scaricherà invece un file di patch, come mostrato in [[:Immagine:Kernel.org_patch.png|Figura 6-2]]. | Precedentemente, avete usato il link indicato dalla F per scaricare l'intero sorgente del kernel. Comunque, se premete sul nome della release del kernel, scaricherà invece un file di patch, come mostrato in [[:Immagine:Kernel.org_patch.png|Figura 6-2]]. | ||
[[Immagine:Kernel.org_patch.png|center|500px|thumb|''Figure 6-2: Scaricamento di una patch da Kernel.org.'']] | [[Immagine:Kernel.org_patch.png|center|500px|thumb|''Figure 6-2: Scaricamento di una patch da Kernel.org.'']] | ||
Questo è ciò che vogliamo quando aggiorniamo. Ma dobbiamo capire quale patch scaricare. | |||
<small>Nota ('''<sup>*</sup>'''): si chiama ''patch'' perché il programma ''patch'' prende il file e la applica all'albero originale, creando il nuovo albero. Il file patch contiene una rappresentazione delle modifiche che sono necessarie alla compilazione dei nuovi file, sulla base dei vecchi. I file patch sono leggibili, e contengono una lista di linee che sono da rimuovere e da aggiungere, con alcuni contesti nel file che mostrano dove le modifiche vanno eseguite.</small> | |||
== Quale patch applicare a quale versione? == | == Quale patch applicare a quale versione? == | ||
Una patch del kernel aggiornerà il codice sorgente solo da una versione specifica ad un'altra versione specifica. Ecco come differenti patch possono essere applicate: | |||
Una patch del kernel aggiornerà il codice sorgente solo da una specifica | * Le patch stabili (''stable'') per il kernel si applicano sulla versione base del kernel. Ciò significa che la patch 2.6.17.10 si applicherà solo alla release del kernel 2.6.17. La patch del kernel 2.6.17.10 non si applicherà al kernel 2.6.17.9 o a qualsiasi altra release. | ||
* Le patch del kernel di base (''base'') si applicano solo alle versioni di base del kernel precedenti. Ciò significa che la patch 2.6.18 si applicherà alla versione 2.6.17 del kernel. Non si applicherà all'ultima release 2.6.17.y del kernel, o a qualsiasi altra release. | |||
* Le patch stabili per il kernel si applicano sulla versione base del kernel. Ciò significa che la patch 2.6.17.10 si applicherà solo alla | * Le patch incrementali (''incremental'') aggiornano da una specifica release a quella successiva. Questo permette agli sviluppatori di non dover retrocedere i loro kernel e poi aggiornarli, solo per cambiare dalla più recente release stabile a quella successiva (ricordatevi che le patch della release stabile sono solo per la base del kernel, non la release stabile precedente). Quando possibile, è raccomandabile che usiate le patch incrementali per rendere la vostra vita più semplice. | ||
* Le patch del kernel di base si applicano solo alle versioni di base del kernel precedenti. Ciò significa che la patch 2.6.18 si applicherà alla versione 2.6.17 del kernel. Non si applicherà all'ultima release 2.6.17.y, o a qualsiasi altra release. | |||
* Le patch incrementali aggiornano da una specifica release a quella successiva. Questo permette agli sviluppatori di non dover retrocedere i loro kernel e poi aggiornarli, solo per cambiare dalla più recente release stabile a quella successiva (ricordatevi che le patch della release stabile sono solo per la base del kernel, non la release stabile precedente). Quando possibile, è raccomandabile che usiate le patch incrementali per rendere la vostra vita più semplice. | |||
== Trovare la patch == | == Trovare la patch == | ||
Dal momento che noi vogliamo passare dalla release del kernel 2.6.17.9 alla 2.6.17.11, dobbiamo scaricare due differenti patch. Abbiamo bisogno di una per passare dalla 2.6.17.9 alla 2.6.17.10 e poi di una per passare dalla 2.6.17.10 alla 2.6.17.11.<sup>*</sup> | |||
Le patch stabili e di base si trovano nella stessa struttura di directory come gli alberi sorgenti principali. Tutte le patch incrementali possono esser trovate ad un livello più basso, nella directory ''incr''. Così, per trovare la patch che va da 2.6.17.9 a 2.6.17.10, guarderemo nella directory ''/pub/linux/kernel/v2.6/incr'' per trovare i file di cui abbiamo bisogno:<sup>+</sup> | |||
<pre> | |||
$ ~/linux | |||
$ lftp ftp.kernel.org/pub/linux/kernel/v2.6/incr | |||
cd ok, cwd=/pub/linux/kernel/v2.6/incr | |||
lftp ftp.kernel.org:/pub/linux/kernel/v2.6/incr> ls *2.6.17.9*.bz2 | |||
-rw-rw-r-- 1 536 536 2872 Aug 22 19:23 patch-2.6.17.9-10. | |||
bz2 | |||
lftp ftp.kernel.org:/pub/linux/kernel/v2.6/incr> get patch-2.6.17.9-10.bz2 | |||
2872 bytes transferred | |||
lftp ftp.kernel.org:/pub/linux/kernel/v2.6/incr> get patch-2.6.17.10-11.bz2 | |||
7901 bytes transferred | |||
lftp ftp.kernel.org:/pub/linux/kernel/v2.6/incr> exit | |||
$ ls -F | |||
good_config linux-2.6.17.9/ patch-2.6.17.10-11.bz2 patch-2.6.17.9-10.bz2 | |||
</pre> | |||
<small> | |||
Nota ('''<sup>*</sup>'''): se dovete aggiornare più di due versioni è raccomandabile, come modo per risparmiare passaggi, retrocedere e poi avanzare. In questo caso, potevamo andare indietro dalla 2.6.17.9 alla 2.6.17 e poi avanti dalla 2.6.17 alla 2.6.17.11 . | |||
< | Nota ('''<sup>+</sup>'''): in questo esempio usiamo il buon programma FTP ''lftp'' per scaricare le patch. Qualsiasi programma FTP o web browser può venir usato per scaricare gli stessi files. La cosa importante qui è mostrare dove si trovano questi files. | ||
</small> | |||
</ | |||
== Applicare la patch == | == Applicare la patch == | ||
Dal momento che le patch che abbiamo scaricato sono compresse, la prima cosa da fare è decomprimerle con il comando ''bzip2'': | Dal momento che le patch che abbiamo scaricato sono compresse, la prima cosa da fare è decomprimerle con il comando ''bzip2'': | ||
<pre> | <pre> | ||
$ bzip2 -dv patch-2.6.17.9-10.bz2 | |||
patch-2.6.17.9-10.bz2: done | |||
$ bzip2 -dv patch-2.6.17.10-11.bz2 | |||
patch-2.6.17.10-11.bz2: done | |||
$ ls -F | |||
good_config linux-2.6.17.9/ patch-2.6.17.10-11 patch-2.6.17.9-10 | |||
</pre> | </pre> | ||
Ora dobbiamo applicare le patch alla directory del kernel. Andate nella directory: | Ora dobbiamo applicare le patch alla directory del kernel. Andate nella directory: | ||
<pre>$ cd linux-2.6.17.9</pre> | |||
Lanciate il programma ''patch'' per applicare la prima patch spostando l'albero sorgente dalla versione 2.6.17.9 alla 2.6.17.10: | Lanciate il programma ''patch'' per applicare la prima patch spostando l'albero sorgente dalla versione 2.6.17.9 alla 2.6.17.10: | ||
<pre> | <pre> | ||
$ patch -p1 < ../patch-2.6.17.9-10 | |||
patching file Makefile | patching file Makefile | ||
patching file block/elevator.c | patching file block/elevator.c | ||
| Riga 123: | Riga 97: | ||
</pre> | </pre> | ||
Si verifichi che veramente la patch ha funzionato correttamente e che non ci siano errori o avvisi in output dal programma patch. | Si verifichi che veramente la patch ha funzionato correttamente e che non ci siano errori o avvisi in output dal programma patch. È anche una buona idea guardare nel ''Makefile'' la versione del kernel: | ||
<pre> | <pre> | ||
$ head -n 5 Makefile | $ head -n 5 Makefile | ||
| Riga 135: | Riga 108: | ||
Ora che il kernel è alla release 2.6.17.10, fate le stesse cose di prima, e applicate la patch per portarlo al livello 2.6.17.11: | Ora che il kernel è alla release 2.6.17.10, fate le stesse cose di prima, e applicate la patch per portarlo al livello 2.6.17.11: | ||
<pre> | <pre> | ||
$ patch -p1 < ../patch-2.6.17.10-11 | $ patch -p1 < ../patch-2.6.17.10-11 | ||
| Riga 172: | Riga 144: | ||
Ancora una volta verificate che non ci siano errori e guardate il ''Makefile'': | Ancora una volta verificate che non ci siano errori e guardate il ''Makefile'': | ||
<pre> | <pre> | ||
$ head -n 5 Makefile | $ head -n 5 Makefile | ||
| Riga 183: | Riga 154: | ||
Ora che il codice sorgente è aggiornato con successo alla versione che desiderate avere, è una buona idea tornare indietro e cambiare il nome della directory per riferirsi alla versione del kernel in modo da evitare confusione in seguito: | Ora che il codice sorgente è aggiornato con successo alla versione che desiderate avere, è una buona idea tornare indietro e cambiare il nome della directory per riferirsi alla versione del kernel in modo da evitare confusione in seguito: | ||
<pre> | <pre> | ||
$ cd .. | $ cd .. | ||
| Riga 192: | Riga 162: | ||
== Riconfigurare il kernel == | == Riconfigurare il kernel == | ||
Precedentemente, abbiamo usato i metodi ''make menuconfig'' oppure ''gconfig'' o ''xconfig'' per cambiare differenti opzioni di configurazione. Ma una volta che avete una configurazione funzionante, l'unica cosa necessaria è aggiornarla con qualsiasi nuova opzione che è stata aggiunta al kernel dall'ultima release. Per fare ciò, si devono usare le opzioni ''make oldconfig'' e ''make silentoldconfig''. | |||
''make oldconfig'' prende la configurazione del kernel corrente nel file ''.config'', e lo aggiorna sulla base del nuovo kernel. Per far ciò, stampa tutte le domande di configurazione, e fornisce loro una risposta se l'opzione è già gestita nel file di configurazione. Se c'è una nuova opzione, il programma si ferma e chiede all'utente a cosa il nuovo valore deve essere impostato. Dopo aver risposto, il programma continua finché l'intera configurazione del kernel è finita. | |||
''make silentoldconfig'' funziona esattamente nello stesso modo di ''oldconfig'', ma non stampa niente sullo schermo, a meno che necessiti di chiedere una domanda su una opzione della nuova configurazione. | |||
''make silentoldconfig'' funziona esattamente nello stesso modo di ''oldconfig'', ma non stampa niente sullo schermo, a meno che | |||
Solitamente, quando si aggiorna tra differenti versioni delle release stabili, nessuna nuova opzione di configurazione viene aggiunta, dal momento che si suppone essere una serie di kernel stabile. Se questo succede, non ci sono nuove domande che necessitano una risposta per la configurazione del kernel, perciò il programma continua con successo senza alcun bisogno di interventi dell'utente. Un esempio di questo è mostrato aggiornando dalla release 2.6.17.9 alla 2.6.17.11: | |||
<pre> | <pre> | ||
$ cd linux-2.6.17.11 | $ cd linux-2.6.17.11 | ||
| Riga 210: | Riga 178: | ||
</pre> | </pre> | ||
Il seguente esempio mostra cosa succede quando una nuova opzione del kernel | Il seguente esempio mostra cosa succede quando una nuova opzione del kernel arriva in una nuova release. L'opzione del kernel per abilitare il ''Mutex debugging'' è una nuova opzione per alcune release. Ecco l'output: | ||
<pre> | <pre> | ||
$ make silentoldconfig | $ make silentoldconfig | ||
| Riga 236: | Riga 203: | ||
Il programma di configurazione si ferma a questa opzione e chiede all'utente di scegliere una opzione. Premere y, e il programma continua: | Il programma di configurazione si ferma a questa opzione e chiede all'utente di scegliere una opzione. Premere y, e il programma continua: | ||
<pre> | <pre> | ||
Spinlock debugging (DEBUG_SPINLOCK) [Y/n/?] y | Spinlock debugging (DEBUG_SPINLOCK) [Y/n/?] y | ||
| Riga 259: | Riga 225: | ||
</pre> | </pre> | ||
In questo modo aggiornare la configurazione del kernel per una nuova è semplice come usare una opzione differente a ''make''. Con questo metodo non si ha bisogno di usare | In questo modo aggiornare la configurazione del kernel per una nuova è semplice come usare una opzione differente a ''make''. Con questo metodo non si ha bisogno di usare programmi di configurazione grafici o testuali per qualsiasi aggiornamento del kernel. | ||
== È possibile automatizzare tutto? == | == È possibile automatizzare tutto? == | ||
L'intero processo di scaricamento del file di patch appropriato, la sua decompressione e applicazione sembra essere maturo per l'automatizzazione. Gli sviluppatori del kernel essendo tipi a cui piace automatizzare operazioni ripetitive, hanno creato il programma ''ketchup'' per gestire tutto automaticamente. Si veda l'[[LKN: Programmi Utili|appendice A]] per ulteriori dettagli su come funziona questo programma e come usarlo. | |||
L'intero processo di scaricamento del file di patch appropriato, la sua decompressione e applicazione sembra essere maturo per l'automatizzazione. Gli sviluppatori del kernel essendo tipi a cui piace automatizzare operazioni ripetitive, hanno creato il programma ''ketchup'' per gestire tutto automaticamente. Si veda l'appendice A per ulteriori dettagli su come questo programma | |||
Versione delle 13:57, 1 mag 2016
| Linux Kernel in a Nutshell |
|
Sommario |
|
Inevitabilmente capita: avete un kernel personalizzato, funziona perfettamente tranne per una piccola cosa che è stata sistemata nel più recente rilascio (release) dagli sviluppatori del kernel. Oppure un problema di sicurezza è stato trovato, e una nuova release stabile del kernel è stata pubblicata. In entrambi i casi, siete davanti al problema di aggiornare il kernel ma non volete perdere tutto il tempo e la fatica spesa nella creazione di quella perfetta configurazione.
Questo capitolo mostra come è facile aggiornare il kernel da una vecchia versione, mantenendo tutte le opzioni di configurazione della precedente.
Anzitutto, fate il backup del file .config nella directory dei sorgenti del kernel. Avete speso del tempo e fatica per crearlo, e dovrebbe essere salvato nel caso qualcosa vada storto provando ad aggiornare.
$ cd ~/linux/linux-2.6.17.11 $ cp .config ../good_config
Solo cinque semplici passi sono necessari per aggiornare il kernel da uno precedentemente preparato:
- Ottenere il nuovo codice sorgente.
- Applicare le modifiche al vecchio albero sorgente per portarlo al nuovo livello.
- Riconfigurare il kernel basato sulla configurazione precedente.
- Compilare il nuovo kernel.
- Installare il nuovo kernel.
Gli ultimi due passi funzionano come descritto prima, per cui discuteremo solo i primi tre punti in questo capitolo.
In questo capitolo, presumeremo che si sia compilato con successo un kernel 2.6.17.9, e lo si voglia aggiornare alla release 2.6.17.11.
Download del nuovo sorgente
Gli sviluppatori del kernel Linux comprendono che gli utenti non desiderano scaricarsi l'intero codice sorgente del kernel per ogni aggiornamento. Sarebbe uno spreco di banda e tempo. Per questo offrono una patch che può aggiornare un kernel più vecchio a uno più recente.*
Sulla pagina principale del sito web di kernel.org, ricorderete che è presente una lista delle versioni correnti di kernel che sono disponibili per il download, come mostrato in Figura 6-1.
Precedentemente, avete usato il link indicato dalla F per scaricare l'intero sorgente del kernel. Comunque, se premete sul nome della release del kernel, scaricherà invece un file di patch, come mostrato in Figura 6-2.
Questo è ciò che vogliamo quando aggiorniamo. Ma dobbiamo capire quale patch scaricare.
Nota (*): si chiama patch perché il programma patch prende il file e la applica all'albero originale, creando il nuovo albero. Il file patch contiene una rappresentazione delle modifiche che sono necessarie alla compilazione dei nuovi file, sulla base dei vecchi. I file patch sono leggibili, e contengono una lista di linee che sono da rimuovere e da aggiungere, con alcuni contesti nel file che mostrano dove le modifiche vanno eseguite.
Quale patch applicare a quale versione?
Una patch del kernel aggiornerà il codice sorgente solo da una versione specifica ad un'altra versione specifica. Ecco come differenti patch possono essere applicate:
- Le patch stabili (stable) per il kernel si applicano sulla versione base del kernel. Ciò significa che la patch 2.6.17.10 si applicherà solo alla release del kernel 2.6.17. La patch del kernel 2.6.17.10 non si applicherà al kernel 2.6.17.9 o a qualsiasi altra release.
- Le patch del kernel di base (base) si applicano solo alle versioni di base del kernel precedenti. Ciò significa che la patch 2.6.18 si applicherà alla versione 2.6.17 del kernel. Non si applicherà all'ultima release 2.6.17.y del kernel, o a qualsiasi altra release.
- Le patch incrementali (incremental) aggiornano da una specifica release a quella successiva. Questo permette agli sviluppatori di non dover retrocedere i loro kernel e poi aggiornarli, solo per cambiare dalla più recente release stabile a quella successiva (ricordatevi che le patch della release stabile sono solo per la base del kernel, non la release stabile precedente). Quando possibile, è raccomandabile che usiate le patch incrementali per rendere la vostra vita più semplice.
Trovare la patch
Dal momento che noi vogliamo passare dalla release del kernel 2.6.17.9 alla 2.6.17.11, dobbiamo scaricare due differenti patch. Abbiamo bisogno di una per passare dalla 2.6.17.9 alla 2.6.17.10 e poi di una per passare dalla 2.6.17.10 alla 2.6.17.11.*
Le patch stabili e di base si trovano nella stessa struttura di directory come gli alberi sorgenti principali. Tutte le patch incrementali possono esser trovate ad un livello più basso, nella directory incr. Così, per trovare la patch che va da 2.6.17.9 a 2.6.17.10, guarderemo nella directory /pub/linux/kernel/v2.6/incr per trovare i file di cui abbiamo bisogno:+
$ ~/linux $ lftp ftp.kernel.org/pub/linux/kernel/v2.6/incr cd ok, cwd=/pub/linux/kernel/v2.6/incr lftp ftp.kernel.org:/pub/linux/kernel/v2.6/incr> ls *2.6.17.9*.bz2 -rw-rw-r-- 1 536 536 2872 Aug 22 19:23 patch-2.6.17.9-10. bz2 lftp ftp.kernel.org:/pub/linux/kernel/v2.6/incr> get patch-2.6.17.9-10.bz2 2872 bytes transferred lftp ftp.kernel.org:/pub/linux/kernel/v2.6/incr> get patch-2.6.17.10-11.bz2 7901 bytes transferred lftp ftp.kernel.org:/pub/linux/kernel/v2.6/incr> exit $ ls -F good_config linux-2.6.17.9/ patch-2.6.17.10-11.bz2 patch-2.6.17.9-10.bz2
Nota (*): se dovete aggiornare più di due versioni è raccomandabile, come modo per risparmiare passaggi, retrocedere e poi avanzare. In questo caso, potevamo andare indietro dalla 2.6.17.9 alla 2.6.17 e poi avanti dalla 2.6.17 alla 2.6.17.11 .
Nota (+): in questo esempio usiamo il buon programma FTP lftp per scaricare le patch. Qualsiasi programma FTP o web browser può venir usato per scaricare gli stessi files. La cosa importante qui è mostrare dove si trovano questi files.
Applicare la patch
Dal momento che le patch che abbiamo scaricato sono compresse, la prima cosa da fare è decomprimerle con il comando bzip2:
$ bzip2 -dv patch-2.6.17.9-10.bz2 patch-2.6.17.9-10.bz2: done $ bzip2 -dv patch-2.6.17.10-11.bz2 patch-2.6.17.10-11.bz2: done $ ls -F good_config linux-2.6.17.9/ patch-2.6.17.10-11 patch-2.6.17.9-10
Ora dobbiamo applicare le patch alla directory del kernel. Andate nella directory:
$ cd linux-2.6.17.9
Lanciate il programma patch per applicare la prima patch spostando l'albero sorgente dalla versione 2.6.17.9 alla 2.6.17.10:
$ patch -p1 < ../patch-2.6.17.9-10 patching file Makefile patching file block/elevator.c patching file fs/udf/super.c patching file fs/udf/truncate.c patching file include/net/sctp/sctp.h patching file include/net/sctp/sm.h patching file net/sctp/sm_make_chunk.c patching file net/sctp/sm_statefuns.c patching file net/sctp/socket.c
Si verifichi che veramente la patch ha funzionato correttamente e che non ci siano errori o avvisi in output dal programma patch. È anche una buona idea guardare nel Makefile la versione del kernel:
$ head -n 5 Makefile VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 17 EXTRAVERSION = .10 NAME=Crazed Snow-Weasel
Ora che il kernel è alla release 2.6.17.10, fate le stesse cose di prima, e applicate la patch per portarlo al livello 2.6.17.11:
$ patch -p1 < ../patch-2.6.17.10-11 patching file Makefile patching file arch/ia64/kernel/sys_ia64.c patching file arch/sparc/kernel/sys_sparc.c patching file arch/sparc64/kernel/sys_sparc.c patching file drivers/char/tpm/tpm_tis.c patching file drivers/ieee1394/ohci1394.c patching file drivers/md/dm-mpath.c patching file drivers/md/raid1.c patching file drivers/net/sky2.c patching file drivers/pci/quirks.c patching file drivers/serial/Kconfig patching file fs/befs/linuxvfs.c patching file fs/ext3/super.c patching file include/asm-generic/mman.h patching file include/asm-ia64/mman.h patching file include/asm-sparc/mman.h patching file include/asm-sparc64/mman.h patching file kernel/timer.c patching file lib/spinlock_debug.c patching file mm/mmap.c patching file mm/swapfile.c patching file net/bridge/netfilter/ebt_ulog.c patching file net/core/dst.c patching file net/core/rtnetlink.c patching file net/ipv4/fib_semantics.c patching file net/ipv4/netfilter/arp_tables.c patching file net/ipv4/netfilter/ip_tables.c patching file net/ipv4/netfilter/ipt_ULOG.c patching file net/ipv4/route.c patching file net/ipx/af_ipx.c patching file net/netfilter/nfnetlink_log.c
Ancora una volta verificate che non ci siano errori e guardate il Makefile:
$ head -n 5 Makefile VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 17 EXTRAVERSION = .11 NAME=Crazed Snow-Weasel
Ora che il codice sorgente è aggiornato con successo alla versione che desiderate avere, è una buona idea tornare indietro e cambiare il nome della directory per riferirsi alla versione del kernel in modo da evitare confusione in seguito:
$ cd .. $ mv linux-2.6.17.9 linux-2.6.17.11 $ ls -F good_config linux-2.6.17.11/ patch-2.6.17.10-11 patch-2.6.17.9-10
Riconfigurare il kernel
Precedentemente, abbiamo usato i metodi make menuconfig oppure gconfig o xconfig per cambiare differenti opzioni di configurazione. Ma una volta che avete una configurazione funzionante, l'unica cosa necessaria è aggiornarla con qualsiasi nuova opzione che è stata aggiunta al kernel dall'ultima release. Per fare ciò, si devono usare le opzioni make oldconfig e make silentoldconfig.
make oldconfig prende la configurazione del kernel corrente nel file .config, e lo aggiorna sulla base del nuovo kernel. Per far ciò, stampa tutte le domande di configurazione, e fornisce loro una risposta se l'opzione è già gestita nel file di configurazione. Se c'è una nuova opzione, il programma si ferma e chiede all'utente a cosa il nuovo valore deve essere impostato. Dopo aver risposto, il programma continua finché l'intera configurazione del kernel è finita.
make silentoldconfig funziona esattamente nello stesso modo di oldconfig, ma non stampa niente sullo schermo, a meno che necessiti di chiedere una domanda su una opzione della nuova configurazione.
Solitamente, quando si aggiorna tra differenti versioni delle release stabili, nessuna nuova opzione di configurazione viene aggiunta, dal momento che si suppone essere una serie di kernel stabile. Se questo succede, non ci sono nuove domande che necessitano una risposta per la configurazione del kernel, perciò il programma continua con successo senza alcun bisogno di interventi dell'utente. Un esempio di questo è mostrato aggiornando dalla release 2.6.17.9 alla 2.6.17.11:
$ cd linux-2.6.17.11 $ make silentoldconfig scripts/kconfig/conf -s arch/i386/Kconfig # # using defaults found in .config #
Il seguente esempio mostra cosa succede quando una nuova opzione del kernel arriva in una nuova release. L'opzione del kernel per abilitare il Mutex debugging è una nuova opzione per alcune release. Ecco l'output:
$ make silentoldconfig scripts/kconfig/conf -s arch/i386/Kconfig # # using defaults found in .config # * * Restart config... * * * Kernel hacking * Show timing information on printks (PRINTK_TIME) [Y/n/?] y Magic SysRq key (MAGIC_SYSRQ) [Y/n/?] y Kernel debugging (DEBUG_KERNEL) [Y/n/?] y Kernel log buffer size (16 => 64KB, 17 => 128KB) (LOG_BUF_SHIFT) [16] 16 Detect Soft Lockups (DETECT_SOFTLOCKUP) [Y/n/?] y Collect scheduler statistics (SCHEDSTATS) [N/y/?] n Debug slab memory allocations (DEBUG_SLAB) [Y/n/?] y Memory leak debugging (DEBUG_SLAB_LEAK) [Y/n] y Mutex debugging, deadlock detection (DEBUG_MUTEXES) [N/y/?] (NEW) y
Il programma di configurazione si ferma a questa opzione e chiede all'utente di scegliere una opzione. Premere y, e il programma continua:
Spinlock debugging (DEBUG_SPINLOCK) [Y/n/?] y Sleep-inside-spinlock checking (DEBUG_SPINLOCK_SLEEP) [Y/n/?] y kobject debugging (DEBUG_KOBJECT) [N/y/?] n Highmem debugging (DEBUG_HIGHMEM) [N/y/?] n Compile the kernel with debug info (DEBUG_INFO) [N/y/?] n Debug Filesystem (DEBUG_FS) [Y/?] y Debug VM (DEBUG_VM) [N/y/?] n Compile the kernel with frame pointers (FRAME_POINTER) [N/y/?] n Compile the kernel with frame unwind information (UNWIND_INFO) [N/y/?] n Force gcc to inline functions marked 'inline' (FORCED_INLINING) [N/y/?] n torture tests for RCU (RCU_TORTURE_TEST) [N/m/y/?] n Check for stack overflows (DEBUG_STACKOVERFLOW) [N/y/?] n Stack utilization instrumentation (DEBUG_STACK_USAGE) [N/y/?] n Stack backtraces per line (STACK_BACKTRACE_COLS) [2] 2 * * Page alloc debug is incompatible with Software Suspend on i386 * Write protect kernel read-only data structures (DEBUG_RODATA) [N/y/?] n Use 4Kb for kernel stacks instead of 8Kb (4KSTACKS) [N/y/?] n
In questo modo aggiornare la configurazione del kernel per una nuova è semplice come usare una opzione differente a make. Con questo metodo non si ha bisogno di usare programmi di configurazione grafici o testuali per qualsiasi aggiornamento del kernel.
È possibile automatizzare tutto?
L'intero processo di scaricamento del file di patch appropriato, la sua decompressione e applicazione sembra essere maturo per l'automatizzazione. Gli sviluppatori del kernel essendo tipi a cui piace automatizzare operazioni ripetitive, hanno creato il programma ketchup per gestire tutto automaticamente. Si veda l'appendice A per ulteriori dettagli su come funziona questo programma e come usarlo.
This is an indipendent translation of the book Linux Kernel in a Nutshell by Greg Kroah-Hartman. This translation (like the original work) is available under the terms of Creative Commons Attribution-ShareAlike 2.5.