Algo quebrou depois da atualização: "depois" e "por causa de" não são a mesma coisa

Você atualizou, reiniciou, alguma coisa não funciona. O primeiro reflexo é "a atualização quebrou", e às vezes é verdade. Mas antes é preciso fazer uma distinção, porque ela muda o trabalho desde o começo.

"Depois" e "por causa de"

Um reinício é o primeiro teste honesto de tudo o que foi feito desde o último reinício. Um serviço iniciado à mão e nunca colocado na inicialização, uma montagem que nunca foi escrita na configuração, uma configuração mudada em execução e nunca salva em arquivo: tudo isso está lá há meses e nada tinha sido exercitado até aquele momento. O reinício traz à tona, não causa.

Saber disso ajuda, porque "desfazer a atualização" não resolve esse tipo de problema, e justamente por não resolver, te manda horas na direção errada.

Primeiro o sintoma, depois a decisão

A pergunta real não é "como eu volto", é o que exatamente está quebrado. Existem três famílias de sintoma e elas apontam para três lugares diferentes.

A máquina não sobe de jeito nenhum. A questão é o kernel ou a camada de inicialização. O caminho de volta é o kernel anterior, e ele normalmente ainda está lá, porque as atualizações não apagam kernels antigos.

A máquina sobe mas não tem painel. Um serviço não iniciou. Veja qual e por quê; isso é quase sempre uma questão de configuração isolada, não a atualização inteira.

Tudo sobe mas algo se comporta diferente. Um componente mudou de verdade. É aqui que o instinto de voltar é mais errado: o trabalho certo é ler o que mudou.

Voltar não é de graça

Rebobinar o sistema de arquivos raiz não desfaz só a atualização, desfaz tudo desde aquele momento. Configurações mudadas no meio-tempo, chaves de acesso adicionadas, outras coisas instaladas, tudo volta. Voltar é uma decisão, não um botão.

Uma escada que começa pelo mais barato

Tente primeiro o mais estreito e, se funcionar, não encoste em mais nada:

Suba com o kernel anterior. Afeta só o kernel e deixa o resto como está.

Devolva um único pacote à versão anterior. O efeito fica limitado àquele pacote.

Rebobine o estado do sistema como um todo. O mais poderoso e o mais caro, guardado para o final.

Escreva antes de consertar

Anote o que você viu: a linha de erro, qual serviço, que horas. No dia em que volta a funcionar o motivo some, e se a mesma coisa acontecer três meses depois você não terá nada na mão.

O que o Atlas faz

O Atlas fixa o kernel em execução antes da atualização. Então, mesmo que um kernel novo seja instalado, o reinício te levanta com o antigo; passar para o novo é um passo separado e consciente. Quando você passa para o kernel novo, a guarda de inicialização entra em cena: ela confirma que o sistema subiu realmente saudável e volta sozinha para o kernel antigo se não subiu.

Antes da atualização é tirado um instantâneo do sistema de arquivos raiz. No ZFS isso é barato e voltar leva minutos; em sistemas sem ZFS o estado dos pacotes é guardado à parte, então não o sistema inteiro, mas o estado de instalação pode ser desfeito. Os últimos cinco instantâneos de antes de atualizações são mantidos e os mais antigos são limpos.

Depois que a instalação termina, roda mais uma verificação: os serviços críticos estão de pé, o acordo do cluster continua sendo mantido. Ou seja, a pergunta "quebrou alguma coisa" é feita antes de você perceber.

⚠️ O aviso acima continua valendo: rebobinar o sistema de arquivos raiz como um todo desfaz mais do que a atualização. O Atlas mantém o instantâneo pronto, mas a decisão de voltar é sua.