Gli aggiornamenti incrementali del kernel sono distribuiti come patch (NdT letteralmente
"toppe"). Per esempio, se si ha la versione 1.1.45 e si ha notizia che c'è una
"patch46.gz
" in giro, significa che si può aggiornare alla versione 1.1.46
applicando quella patch. Prima può essere una buona idea fare una copia di backup
dell'albero dei sorgenti ("make clean
" e poi "cd /usr/src; tar zcvf
old-tree.tar.gz linux
" creerà un archivio compresso).
Così, continuando con l'esempio precedente, si supponga di avere "patch46.gz
"
in /usr/src
. Si dia "cd /usr/src
" e si esegua
"zcat patch46.gz | patch -p0
" (o "patch -p0 < patch46
" se la patch
non è compressa). Si vedranno sfrecciare (o fluttuare, se il proprio sistema è abbastanza
lento) delle scritte che dicono che sta provando ad applicare dei pezzi ("hunk") e quando
ha o meno successo. Solitamente questa azione è troppo veloce per poterla leggere ed è
difficile essere sicuri se ha funzionato o meno, quindi può essere un'idea usare l'opzione
-s
, che dice a patch
di riportare solo i messaggi d'errore. Per cercare
le parti che non sono andate a buon fine, si passi in /usr/src/linux
e si cerchino
i file con estensione .rej
. Alcune versioni di patch
(versioni più vecchie
che possono essere state compilate con un filesystem inferiore) lasciano scarti con
un'estensione #
. Si può usare "find
" per la ricerca:
find . -name '*.rej' -printmostrerà nello standard output tutti i file residenti nella directory corrente e in ogni sottodirectory con estensione
.rej
.
Se tutto va a buon fine, si faccia "make clean
", "config
" e
"dep
" come descritto nelle sezioni 3 e 4.
Ci sono alcune altre opzioni per il comando patch
. Come
menzionato prima, patch -s
sopprimerà tutti messaggi tranne
quelli d'errore. Se si conservano i sorgenti del kernel in un posto
diverso da /usr/src/linux
, patch -p1
(in quella
directory) applicherà correttamente la patch. Altre opzioni di
patch
sono ben documentate nella pagina di man.
(Nota: questa sezione fa riferimento principalmente a kernel piuttosto vecchi)
Il problema più frequente che solitamente compariva quando una
patch modificava un file chiamato "config.in
" e questo non
sembrava più essere a posto, perché lo si era modificato per adattarlo
alla propria macchina. Di questo ora si tiene conto, ma si
potrebbe ancora incontrare con vecchie release. Per correggerlo, si
veda il file config.in.rej
e si veda cosa rimane della patch
originale. Le modifiche saranno tipicamente marcate con "+
"
e "-
" all'inizio di ciascuna riga. Si vedano le righe là attorno e
si ricordi se erano state impostate a "y
" o "n
". Ora
si modifichi il config.in
, e si cambi "y
" in
"n
" e "n
" in "y
" quando appropriato. Si
faccia un
patch -p0 < config.in.reje, se finisce con successo, si può continuare con la configurazione e la compilazione. Il file
config.in.rej
rimarrà, ma si può cancellarlo.
Se si incontrano ulteriori problemi, si può aver installato una patch
"fuori uso". Se patch dice "previously applied patch detected:
Assume -R?
" (rilevata una patch applicata precedentemente: assumo
-R?), probabilmente si sta provando ad applicare una patch precedente
al numero di versione corrente; se si risponde "y
" proverà a
degradare i sorgenti e molto probabilmente fallirà; sarà quindi
necessario prendere in blocco un nuovo albero dei sorgenti (poteva
non essere una cattiva idea sin dall'inizio).
Per tornare indietro di una patch, disapplicandola, si usi "patch
-R
" sulla patch originale.
La miglior cosa da fare quando le patch fanno realmente casino è di
ripartire da un albero dei sorgenti nuovo di zecca (per esempio, da
uno dei file linux-x.y.z.tar.gz
) e ricominciare.
Già dopo poche patch, i file .orig
cominciano ad
ammucchiarsi. Per esempio, un albero 1.1.51 che ho ripulito l'ultima
volta quand'era 1.1.48: rimuovendo i file .orig ho recuperato oltre
500 Kbyte.
find . -name '*.orig' -exec rm -f {} ';'se ne occuperà al vostro posto. Le versioni di
patch
che
usano #
per gli scarti usano una tilde invece di
.orig
.
Ci sono modi migliori per sbarazzarsi dei file .orig
, che
dipendono da GNU xargs
:
find . -name '*.orig' | xargs rmo il metodo "piuttosto sicuro ma un po' più prolisso":
find . -name '*.orig' -print0 | xargs --null rm --
Esistono altre patch (io le chiamo "non standard") oltre a quelle che distribuisce Linus. Se le si applica, le patch di Linus potrebbero non funzionare correttamente e si dovrà o tornare indietro, correggere i sorgenti o la patch, installare un nuovo albero dei sorgenti o una combinazione di queste cose. Ciò può divenire abbastanza frustrante, se non si vogliono modificare i sorgenti (con il rischio di ottenere pessimi risultati), si rimuovano le patch non standard prima di applicare quelle di Linus, o semplicemente si installi un nuovo albero. Poi, si può provare a vedere se le patch non standard funzionano ancora. Se non lo fanno, o si resta con il vecchio kernel, giochicchiando con la patch e i sorgenti per farli funzionare, o si aspetta (probabilmente elemosinando) che esca una nuova versione della patch.
Quanto comuni sono le patch che non sono nella distribuzione standard? Probabilmente se n'è sentito parlare. Ero avvezzo ad usare la patch noblink per le mie console virtuali perché odio il cursore lampeggiante (questa patch è, o almeno era, aggiornata frequentemente per le nuove release del kernel). Con la maggior parte dei device driver sviluppati come moduli caricabili, la frequenza di patch "non standard" è diminuita significativamente.