Avanti Indietro Indice

5. ``Rattoppare'' il kernel

5.1 Applicare una patch

Gli aggiornamenti incrementali del kernel sono distribuiti come patch ("toppe"). Per esempio, se si ha la versione 1.1.45 e si ha notizia che c'è un `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 faccia cd in /usr/src e si faccia `zcat patch46.gz | patch -p0' (o `patch -p0 < patch46' se la patch non è compressa). Si vedranno delle cose sfrecciare (o fluttuare, se il proprio sistema è abbastanza lento) che dicono che sta provando ad applicare dei pezzi (hunk) e quando ha o meno successo. Solitamente questa azione è troppo veloce per poterla leggere e non si è troppo sicuri quando ha funzionato o meno, quindi può essere un'idea usare l'opzione -s con patch, 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 i rifiuti (reject) con un estensione #. Si può usare `find' per la ricerca:

    find .  -name '*.rej' -print
mostrerà nello standard output tutti i file residenti nella directory corrente ed in ogni sottodirectory con estensione .rej.

Se tutto va a buon fine, di faccia un `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 man.

5.2 Se qualcosa va storto

(Nota: questa sezione fa riferimento principalmente a kernel piuttosto vecchi)

Il problema più frequente che era solito comparire era quando una patch modificava un file chiamato `config.in' e questo non sembrava più essere a posto perché lo si era modificato per adattare le opzioni alla propria macchina. Di questo ora si tiene conto, 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 della riga. Si vedano le righe là attorno e si ricordi se erano stato impostate a `y' o `n'. Ora si editi il config.in, e si cambi `y' in `n' e `n' in `y' quando appropriato. Si faccia un

    patch -p0 < config.in.rej
e se finisce con successo, allora 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 (che poteva non essere una cattiva idea sin dall'inizio).

Per tornare indietro (disapplicare) di una patch, si usi `patch -R' sulla patch originale.

La miglior cosa da fare quando le patch fanno realmente casino è di partire ancora un albero dei sorgenti nuovo di zecca (per esempio, da uno dei file linux-x.y.z.tar.gz), e ricominciare.

5.3 Sbarazzarsi dei file .orig

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 mezzo mega.

    find .  -name '*.orig' -exec rm -f {} ';'
se ne occuperà al vostro posto. Le versioni di patch che usano # per i reject usano una tilde invece di .orig.

Ci sono modi migliori per sbarazzarsi dei file .orig, che dipendono da GNU xargs:

    find .  -name '*.orig' | xargs rm
o il ``abbastanza sicuro ma un po' meno prolisso'' metodo:
    find . -name '*.orig' -print0 | xargs --null rm --

5.4 Altre patch

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 la possibità di risultati pessimi), 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 avezzo 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.


Avanti Indietro Indice