![um-patch-do-kernel-com-defeito-quebrou-o-ubuntu-no-mes-passado-e-pode-acontecer-novamente um-patch-do-kernel-com-defeito-quebrou-o-ubuntu-no-mes-passado-e-pode-acontecer-novamente](https://sempreupdate.com.br/wp-content/plugins/seox-image-magick/imagick_convert.php?width=904&height=508&format=.jpg&quality=91&imagick=/wp-content/uploads/2022/07/um-patch-do-kernel-com-defeito-quebrou-o-ubuntu-no-mes-passado-e-pode-acontecer-novamente-2-1024x576.jpg)
Muitas pessoas passaram por problemas com um patch do kernel do Ubuntu, no início do mês passado. Esse problema tornou inutilizáveis ??muitos sistemas, executando o Docker nesse tipo de sistema operacional, e provavelmente não será a última vez.
Todo o desastre pode ser rastreado até uma atualização de kernel específica da distribuição ruim para o Ubuntu 20.04, um lançamento de suporte de longo prazo (LTS) da Canonical, que começou a ser lançado em 8 de junho.
Patch do kernel quebra Ubuntu
A fonte do problema foi rapidamente isolada em sistemas Ubuntu executando o Docker com a pilha de habilitação de hardware (HWE) habilitada. Como o nome sugere, o HWE adiciona suporte para hardware mais recente enviando kernels atualizados.
Embora a ativação seja geralmente um processo manual para sistemas de servidor, é um recurso padrão em muitas imagens do Ubuntu disponíveis na nuvem. Para isso, vários usuários relataram que imagens de VM na AWS, GCP, Azure e Oracle foram afetadas. O HWE também geralmente é ativado por padrão para novas instalações de desktop.
O próprio bug desencadeou um kernel panic sempre que um contêiner do Docker foi iniciado. Alguns usuários até relataram que a atualização resultou em um bootloop, e a única cura foi reverter para um kernel de trabalho anterior durante a inicialização.
Para piorar a situação, o serviço de atualizações autônomas do Ubuntu, que é responsável por manter os sistemas corrigidos e geralmente livres de problemas, tornou essa atualização específica do kernel mais difícil de evitar.
A falha resultou de um problema com /proc/self/map_files
os sistemas de arquivos do ambiente de contêiner overlayfs
e shiftfs
que o patch do kernel pretendia corrigir. Um kernel revisado foi lançado alguns dias depois pelo Ubuntu abordando o problema.
O impacto desse patch malfeito é difícil de avaliar, mas o Ubuntu 20.04 continua sendo uma escolha popular para ambientes de produção, graças à sua vida útil de suporte relativamente longa.
Novos problemas podem surgir no futuro?
O Ubuntu até 21.04 incluiu outro sistema de arquivos relacionado a contêiner, aufs
, em seus kernels Linux específicos de distribuição; esse código do sistema de arquivos nunca foi mesclado no kernel da linha principal e foi mantido fora da árvore.
Quando os desenvolvedores do Ubuntu chegaram a fazer backport do shiftfs
patch relacionado ao Ubuntu 20.04, devido a uma cadeia de eventos, parte do código do patch foi descartado porque dependia de aufs
que não estivesse presente durante o processo de backport – mas aufs
estava de fato no kernel 5.13 usado pelo Ubuntu 20.04 HWE.
Devido a isso, e mudanças em como overlayfs
funcionava internamente, uma referência à memória já free()’d em uma estrutura de dados do kernel seria liberada, provocando um pânico. Isso aconteceria sempre que um contêiner do Docker fosse ativado.
De acordo com Webb, esse conflito foi detectado quase imediatamente e corrigido na fonte do kernel 5.15 do Ubuntu. Mas por razões que não são claras, o kernel 5.13 no Ubuntu 20.04 HWE foi esquecido e continuaria travando.
Esse problema específico já foi resolvido, e qualquer pessoa que tenha retornado apenas agora para encontrar suas VMs ou bootlooping de implantações de servidor deve reverter para um kernel anterior e atualizar seus sistemas.
Infelizmente, gremlins como esses podem ser difíceis de evitar, dada a vida útil dos lançamentos LTS da Canonical, o que levou os desenvolvedores a fazer malabarismos com vários ramos do kernel simultaneamente. O Webb aponta que é improvável que a situação fique mais fácil para os desenvolvedores do kernel do Ubuntu e pode se tornar mais difícil em pouco tempo.