Atualizações/Correções a parte do kernel são distribuídas como patches. Por exemplo, se você tem o kernel 2.4.17, e você foi avisado que ha um `patch-18.gz', isto significa que você pode atualizar sua versão para 2.4.18 aplicando o patch. É recomendado que você faça um backup do seu kernel atual (`make clean' e então `cd /usr/src; tar zcvf old-tree.tar.gz linux' ira fazer um arquivo tar compactado para você).
Então, continuando com o exemplo acima, vamos supor que você tenha `patch-18.gz' no /usr/src. cd /usr/src/linux e faça `gzip -d patch-8.gz && patch -p1 patch-8'. Você irá ver o processo dos arquivos que estão sendo aplicados os patches, e se foi aplicado corretamente ou não. Geralmente, isso é muito rápido para você conseguir ler, e você não estará totalmente certo de que funcionou ou não, por isso é melhor que você aplique o patch com a opção -s que diz ao patch para mostrar somente mensagens de erro. Procure por arquivos em /usr/src/linux com a extensão .rej, esses arquivos por algum motivo o patch nao foi aplicado corretamente. Versões antigas do patch deixam os arquivos nos quais ocorreu algum erro como a extensão ~. Você pode usar o `find' para procurar por voce: find . -name '*.rej' -print isso irá mostrar todos arquivos dentro de toda a estrutura do /usr/src/linux com a extensão .rej.
Se tudo ocorreu certo, digite `make clean', `config', e `dep' como descrito nas seções 3 e 4.
O programa patch apresenta outras opções para testar ou usar. Para mais informações: man patch ; info patch ; patch --help.
(Nota: esta seção refere-se em geral para kernels antigos)
O problema mais frequente que costumava acontecer era quando um patch modificava um arquivo chamado `config.in' e fazia coisas erradas, porque você alterava as opções de acordo com sua máquina. Isto ja foi arrumado, mas ainda pode ser encontrado em versões antigas. Para arrumar isso, olhe o arquivo config.in.rej, e veja o que restou do patch original. As alterações geralmente sao marcadas com `+' e `-' no começo da linha. Olhe as linhas do arquivo, e lembrese se ele foi aplicado com `y' ou `n'. Agora edite o arquivo config.in e troque de `y' para `n' e de `n' para `y' quando for apropriado. Digite: patch -p0 < config.in.rej e veja se tudo da certo (sem erros), então você pode continuar com a configuração e compilação. O arquivo config.in.rej irá permanecer, mas você pode apagar ele agora.
Se você encontrar mais problemas, você pode ter instalado um patch estragado. Se o patch disser `previously applied patch detected: Assume -R?', você provavelmente esta tentando aplicar um patch que já está presente no kernel, se sua resposta para a pergunta acima for `y', ele ira tentar degradar seu source, e provavelmente ira falhar. Assim, você ira precisar de um novo source.
Para retirar um patch, use `patch -R' no patch original.
A melhor coisa a fazer quando os patches realmente dão errados é iniciar de novo, com um source limpo. Descompacte o kernel novamente, e faça o processo novamente.
Depois de alguns patches, os arquivos .orig vão começar a crescer. Por exemplo, no kernel 1.1.51 que eu tinha foi somente limpo no 1.1.48. Removendo os arquivos .orig foi ganho mais de 500k de espaço.. find . -name '*.orig' -exec rm -f {} ';' esse comando irá apagar os arquivos .orig para você. Versões do patch que usam ~ para os arquivo rejeitados (defeituosos ou com algum problema depois de aplicar algum patch) use um ~ ao invez de .orig.
Há jeitos melhores de se livrar dos arquivos .orig, para isso você precisa do programa xargs: find . -name '*.orig' | xargs rm ou pelo método ``menos seguro mas um pouco mais detalhado'': find . -name '*.orig' -print0 | xargs --null rm --
Estes são outros patches (Irei chamalos de ``não-padrões'') que não são distribuídos por Linus. Se você aplicar um desses, os patches do Linus podem não funcionar corretamente e você irá ter que remover, arrumar o source ou o patch, descompactar o source do kernel novamente, ou todos items citados. Isso pode se tornar muito frustante, então se você não quer modificar o source, retire os patches não-padrões antes de aplicar patches do Linus, ou então instale-os em um novo diretório. Então, você poderá ver se os patches não-padrões ainda funcionam. Se não, você terá que ficar com um kernel velho, tentando fazer o patch ou o source funcionar, ou esperar por um novo patch.
O quanto comum são os patches que não estão no kernel padrão? Você provavelmente irá ouvir algo sobre eles. Eu costumava usar o patch noblink para meus consoles virtuais porque eu odeio cursores piscando (Este patch é (ou pelo menos era) frequentemente atualizado para cada versão nova do kernel). Mas desde que os drivers começaram a ser desenvolvidos como módulos carregaveis, a frequência de patches não padrões tem caindo significantemente.