Se o ZimaOS parecer instalar uma atualização com sucesso, mas reiniciar com a versão antiga, trate primeiro de um problema de seleção do arranque, antes de o considerar um problema de transferência. As verificações mais úteis são a ranhura RAUC ativa, se a ranhura recentemente gravada está marcada como inválida e se outra unidade ligada contém uma instalação antiga do ZimaOS ou identificadores de sistema de ficheiros duplicados.
Um caso verificado na comunidade pareceu inicialmente uma atualização 1.6.2 falhada, mas o pacote de atualização era válido. A máquina gravou o novo sistema na ranhura alternativa, não conseguiu arrancá-lo e voltou à ranhura anterior. Um segundo NVMe com partições antigas do ZimaOS foi o fator determinante. Esta distinção é importante, porque transferir repetidamente a mesma atualização nunca resolveria o caminho de arranque.
Como reconhecer um rollback da atualização
O padrão clássico é:
- o atualizador chega ao fim;
- o dispositivo reinicia;
- o painel continua a indicar a versão antiga;
- a notificação de atualização volta a aparecer;
- a atualização offline ou uma instalação RAUC direta também parece ser concluída com sucesso.
Se o instalador apresentar um erro grave de soma de verificação ou de assinatura antes de gravar qualquer coisa, trata-se de um problema diferente. No entanto, quando a gravação é concluída e o sistema antigo regressa após o reinício, concentre-se na fase seguinte do arranque.
Passo 1: Verifique a ranhura atual do sistema
O ZimaOS utiliza duas pequenas partições de sistema, a Ranhura A e a Ranhura B, para que uma ranhura possa ser atualizada enquanto a outra permanece disponível para recuperação. O atual guia de recuperação do sistema ZimaOS documenta esta arquitetura de duas ranhuras.
No terminal, consulte o estado do RAUC e registe qual é a ranhura iniciada, qual está ativa e se a ranhura atualizada é considerada válida ou inválida. Uma ranhura que tenha sido gravada com sucesso, mas que passe a ser considerada inválida após o arranque, indica que a falha ocorre depois da instalação.
Passo 2: Ligue um monitor antes de forçar outra atualização
Um painel Web não consegue mostrar falhas de arranque iniciais que ocorram antes de a rede e a interface do ZimaOS serem iniciadas. Ligue um monitor e um teclado, reinicie e procure erros do GRUB, do sistema de ficheiros, do NVMe, de UUID ou do kernel.
Se a ranhura alternativa falhar e o sistema regressar automaticamente à ranhura antiga, fotografe o erro. Isso é muito mais útil do que outra captura de ecrã do atualizador a mostrar 100%.
Passo 3: Faça um inventário de todas as unidades ligadas capazes de arrancar
Um ponto frequentemente ignorado é um segundo SSD ou NVMe que tenha executado o ZimaOS anteriormente. Mesmo que agora pretenda utilizá-lo apenas para armazenamento, poderá ainda conter partições de arranque, UUID de sistemas de ficheiros duplicados ou um carregador de arranque antigo.
Desligue temporariamente as unidades secundárias capazes de arrancar
Desligue a máquina corretamente e deixe ligada apenas a unidade de sistema ZimaOS pretendida, além de quaisquer discos de dados que saiba que nunca tiveram outra instalação do ZimaOS. Em seguida, teste novamente a atualização.
Não apague uma unidade até confirmar o diagnóstico
Se remover uma unidade secundária específica fizer com que a nova ranhura arranque normalmente, faça uma cópia de segurança dos dados dessa unidade antes de eliminar as partições de sistema antigas. O caso verificado na fonte foi resolvido removendo o NVMe em conflito; isso não significa que todas as atualizações falhadas devam ser imediatamente seguidas por uma formatação do disco.
Passo 4: Utilize a atualização offline apenas quando esta resolver o problema certo
O atual guia de atualização offline do ZimaOS é útil quando o canal de atualização normal não consegue obter ou preparar o pacote, mas a instalação offline não resolverá um conflito de arranque causado por partições de sistema duplicadas.
Se as instalações online e offline forem ambas concluídas com sucesso, mas o sistema continuar a reverter, pare de repetir o instalador e avance para um diagnóstico mais aprofundado do arranque.
Não force a ativação de uma ranhura inválida sem compreender a falha
Pode ser tentador marcar a nova ranhura como válida ou forçá-la como ativa. Isso pode transformar um rollback automático numa máquina que já não chega ao painel. Deixe o mecanismo de fallback protegê-lo enquanto recolhe provas.
A lista de verificação de resolução de problemas do ZimaOS é uma lista mais abrangente útil quando o dispositivo não arranca de forma fiável.
Quando é razoável reinstalar o ZimaOS?
A reinstalação é adequada quando ambas as ranhuras do sistema estão danificadas, o disco do sistema tem problemas de sistema de ficheiros ou de hardware, ou não consegue restaurar uma ranhura inicializável depois de eliminar conflitos entre unidades. Não deve ser a primeira resposta a um rollback quando a ranhura antiga ainda arranca normalmente.
Antes de reinstalar, confirme que os dados do utilizador e os dados das aplicações em armazenamento separado têm cópia de segurança. Se os dados das aplicações estiverem no disco do sistema, proteja-os primeiro.
Como evitar isto num servidor com várias unidades
- Mantenha ligada apenas uma instalação de sistema ZimaOS pretendida durante as atualizações ou a migração do sistema.
- Ao reutilizar um SSD antigo com ZimaOS como armazenamento de dados, faça uma cópia de segurança e remova as partições de sistema obsoletas antes de o voltar a utilizar.
- Identifique fisicamente as unidades de sistema para que um disco de arranque antigo não seja reconectado meses mais tarde.
- Mantenha os dados das aplicações e os dados do utilizador em armazenamento dedicado, para que a reinstalação do sistema operativo seja menos disruptiva.
O guia de planeamento dos dados das aplicações ajuda a reduzir o custo de uma futura recuperação do sistema operativo.
Perguntas frequentes
Porque é que o ZimaOS diz que a atualização foi concluída com sucesso, mas continua a mostrar a versão antiga?
A atualização pode ter sido gravada com sucesso na ranhura alternativa, mas essa ranhura pode não ter conseguido arrancar. O ZimaOS pode então regressar à ranhura anterior em funcionamento.
Uma ranhura RAUC inválida significa sempre que o ficheiro de atualização está corrompido?
Não. Uma ranhura pode tornar-se inválida devido a problemas de armazenamento, sistema de ficheiros, kernel ou hardware durante o arranque, mesmo quando o pacote de atualização era válido.
Um segundo SSD com uma instalação antiga do ZimaOS pode interferir com o arranque?
Sim. O caso verificado na fonte envolvia outro NVMe com partições antigas semelhantes às do ZimaOS e identificadores em conflito. Teste removendo as unidades secundárias capazes de arrancar antes de apagar qualquer coisa.
Devo reinstalar imediatamente?
Não, se a ranhura anterior ainda arrancar. Verifique primeiro o estado das ranhuras, a saída da consola e as unidades ligadas. Reinstale depois de compreender a causa ou quando nenhuma das ranhuras for recuperável.
