LKN: Aggiornare il Kernel

Linux Kernel in a Nutshell

Sommario

Parte I
Compilare il kernel
  1. Introduzione
  2. Requisiti
  3. Procurarsi i sorgenti
  4. Configurazione e compilazione
  5. Installazione e avvio
  6. Aggiornare il kernel
Parte II
Personalizzazioni principali
  1. Personalizzare un kernel
  2. Ricette per configurare un kernel
Parte III
Guide di riferimento per il kernel
  1. Guida di riferimento dei parametri di boot del kernel - parte1
  2. Guida di riferimento dei parametri di boot del kernel - parte2
  3. Guida di riferimento dei parametri di compilazione del kernel
  4. Guida di riferimento delle opzioni di configurazione del kernel - parte1
  5. Guida di riferimento delle opzioni di configurazione del kernel - parte2
Parte IV
Informazioni aggiuntive
  1. Programmi utili
  2. Bibliografia

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:

  1. Ottenere il nuovo codice sorgente.
  2. Applicare le modifiche al vecchio albero sorgente per portarlo al nuovo livello.
  3. Riconfigurare il kernel basato sulla configurazione precedente.
  4. Compilare il nuovo kernel.
  5. 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.

 
Figura 6-1: Il sito ufficiale Kernel.org.

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.

 
Figure 6-2: Scaricamento di una patch da Kernel.org.

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.



Capitolo originale