Atualizando o kernel do Linux, enquanto deixa o resto do sistema como está

Question

Sou um usuário do OpenBSD. Em FAQ do OpenBSD ele diz:

OpenBSD is a complete system, intended to be kept in sync. It is not a kernel plus utilities that can be upgraded separately from each other.

Quando você atualiza um sistema, você o faz de uma só vez; o kernel e o sistema base são substituídos. Em seguida, atualize seus pacotes de terceiros . Se compilar da fonte , você recompila o kernel e o inicializa. Então você reconstrói o sistema básico e, em seguida, os pacotes que você instalou. Se mais de um par de semanas / meses se passaram desde a última vez que você reconstruiu tudo, você primeiro instala um snapshot e reconstrói a partir daí (se você estiver seguindo o branch mais atual do CVS).

Ter um kernel fora de sincronia, sistema básico e / ou pacotes de terceiros é uma fonte potencial de problemas e mais ou menos desqualifica você de obter qualquer ajuda séria das listas de discussão oficiais.

Estou bem com isso. Na verdade, essa é uma das razões pelas quais eu uso o OpenBSD. Isso torna o sistema uma unidade consistente e torna mais fácil para mim formar uma visão mental dele.

Como é o Linux? A maioria dos Linuxes que eu conheço não tem um "sistema básico" no mesmo sentido que os BSDs, mas sim uma coleção de pacotes montados pelo provedor de distribuição. Outros softwares são adicionados a isso por um administrador local de tal forma que a fronteira entre o que estava lá desde o início e o que foi adicionado depois é, na melhor das hipóteses, embaçada.

O Linux (em geral) não tem um kernel strong para o acoplamento de espaço do usuário? O kernel é atualizado, tanto quanto eu sei, como qualquer outro pacote de software, e me confunde um pouco que isso é tudo é possível. Acrescente a isso o fato de que alguns até compilam kernels customizados (que são desencorajados no OpenBSD), e possuem várias versões de kernel listadas em seus menus de inicialização.

Quem ou o que garante que os vários subsistemas de um sistema Linux sejam capazes de cooperar uns com os outros, mesmo que sejam atualizados independentemente uns dos outros?

A razão pela qual estou perguntando é porque outro usuário neste site perguntou mim se a substituição do kernel em seu sistema Linux por uma versão mais nova "seria factível". Vindo do lado do OpenBSD, eu não poderia dizer que sim, isso seria garantido para não quebrar o sistema.

Eu uso o "Linux" acima como uma abreviação de "Linux distribution", kernel + utilitários.

    

Answer 1

Linus Torvalds tem uma opinião muito strong contra as mudanças no kernel, resultando em regressões do userspace (veja a pergunta " O kernel do Linux: quebrando o espaço do usuário "para detalhes).

A interface entre userspace e kernel é fornecida por chamadas do sistema. Os kernels mais recentes podem ter mais chamadas do sistema e alterações nas saídas quando essas alterações não interrompem os aplicativos existentes. Quando uma interface de chamada do sistema tem um parâmetro de sinalização, os novos kernels geralmente expõem a nova funcionalidade com um novo sinalizador de bit. Desta forma, o kernel mantém a compatibilidade retroativa com aplicativos antigos.

Quando não foi possível alterar a interface existente sem interromper o espaço do usuário, foram adicionadas chamadas de sistema adicionais que fornecem a funcionalidade estendida. É por isso que existem três versões de dup e duas versões de umount chamada do sistema.

A política de ter um espaço de usuário estável é a razão pela qual as atualizações do kernel raramente causam problemas nos aplicativos de espaço do usuário e você geralmente não espera problemas após a atualização do kernel.

No entanto, a mesma estabilidade da API não é garantida para as interfaces kernel e outros detalhes de implementação. Sysfs (em /sys ) e procsfs (em /proc/ ) expõem detalhes de implementação do kernel em configuração de tempo de execução, hardware, rede, processos etc. que são usados por aplicações de nível. É possível que essas interfaces mudem de uma maneira incompatível entre as versões do kernel, se houver uma boa razão para isso. As alterações ainda tentam minimizar as incompatibilidades, se possível, e há regras para saber como os aplicativos podem usar as interfaces de maneira menos provável de causar problemas . O impacto também é limitado porque aplicativos de baixo nível não devem usar essas interfaces.

@PeterCordes apontou se uma mudança em procfs ou sysfs quebra uma aplicação usada pelos scripts init de suas distribuições, você poderia ter um problema.

Isso depende de como seu kernel de atualizações de distribuição (suporte a longo prazo ou mainline) e, mesmo assim, os problemas são relativamente raros, já que as distribuições geralmente enviam as ferramentas atualizadas ao mesmo tempo.

< em> @StephenKitt adicionou que o userspace atualizado pode requerer uma versão mais nova do kernel, caso em que o sistema pode não ser capaz de inicializar com o kernel antigo e que notas de lançamento de distribuição mencionam isso quando apropriado.

    

Answer 2

O kernel do Linux e o espaço do usuário de uma distribuição Linux, que historicamente era dominada por ferramentas de usuários desenvolvidas pelo projeto GNU, são fracamente acoplados. Em parte isso é por design, e em parte é por necessidade.

Ao contrário dos BSDs, em que o kernel e o espaço de usuário base são projetados e mantidos juntos, o kernel do Linux e seu espaço de usuário foram desenvolvidos e mantidos por pessoas diferentes. Então, mantê-los strongmente unidos seria difícil, mesmo que a comunidade o desejasse, o que eu acho que não.

E @sebasth também faz o excelente ponto de que uma política importante do projeto do kernel Linux é que ele não deve quebrar o espaço do usuário. Que, claro, é outro fator que reforça o acoplamento fraco.

No entanto, ainda existe algum grau de acoplamento. Um kernel Linux suficientemente antigo não funcionará com distribuições modernas.

    

Answer 3

Meu entendimento é que o Linux é o kernel, e todo o resto é auxiliar. Você definitivamente pode atualizar o kernel independentemente de (muitos) pacotes instalados, pois eles são geralmente ligados a bibliotecas ao invés do próprio kernel. Geralmente, você verá apenas esse acoplamento entre as versões do kernel e os drivers de hardware (por exemplo, drivers de GPU). Alguns software só são compatíveis com certas versões do kernel, mas isso deve ser especificado na documentação individual desses programas.

É bastante comum ter dois conjuntos de pacotes do kernel instalados em um sistema - o pacote usado atualmente e o pacote previamente instalado. Ao atualizar, depois de garantir que a nova versão funcione corretamente, a mais antiga pode ser removida e você ainda tem um fallback de segurança conhecida. A Red Hat (e seus primos), por exemplo, tem package-cleanup --oldkernels --count 2 para fazer isso de forma automática.

    

Answer 4

Além de todos os bons argumentos aqui, posso acrescentar alguns pontos que ajudarão.

Já conhecemos a política de equipe do kernel e, como distribuições do Linux, tentamos manter o código-fonte do kernel o mais puro possível. Isso significa que, sempre que uma vulnerabilidade surgir, ou algo que precisa de um patch, informamos a equipe do kernel e tentamos ajudar com os patches, mas no final, a decisão final é da equipe do kernel.

Algumas distribuições adicionam patches extras mais do que outras, mas a idéia é mantê-lo como vem dos desenvolvedores do upstream. Obviamente, existem alguns programas que precisam de configuração especial do kernel, especialmente virtualização e drivers de terceiros e, geralmente, ambos são usados para trabalhar com uma versão específica do kernel ou pelo menos uma versão não muito antiga ... a razão é que eles tentam para trabalhar com os recursos mais recentes do kernel e, por causa disso, se você tentar executá-los com um kernel antigo, eles podem não ser executados adequadamente.

Um elemento extra para se ter em mente é que todas as distribuições do Linux têm uma equipe de mantenedores, pessoas que garantem que todo o software seja compatível com o sistema. É por isso que quase todas as distribuições têm uma versão estável e instável. Desenvolvedores trabalham com software "instável" e quando tudo é testado eles marcam como estável, só depois que um usuário normal pode atualizar o pacote, então se a pessoa que perguntou é um usuário normal é 90% seguro que o software está bem testado .

Então, quem é, a comunidade e, em seguida, qual deve ser a abordagem comum, precisamos que o software trabalhe em conjunto e não quebre o sistema. É por isso que tentamos seguir alguns padrões como Padrão da hierarquia do sistema de arquivos .