Se ambas as ranhuras de arranque do ZimaOS falharem e a consola apresentar erros de montagem de overlay, falhas na leitura do superbloco ou erros de E/S do NVMe, não comece por reconstruir o conjunto de armazenamento. Primeiro, determine se a falha está no dispositivo de arranque ou nos discos de dados separados.
Neste caso de junho de 2026, os diagnósticos só de leitura mostraram erros repetidos de suporte no NVMe de arranque, enquanto o grande conjunto de dados Btrfs estava em discos separados. O utilizador substituiu a unidade de arranque, reinstalou o ZimaOS e confirmou mais tarde que o conjunto de dados continuava lá.
Separe Primeiro o Dispositivo de Arranque do Conjunto de Dados
O resultado da shell de recuperação no tópico mostrava um NVMe de aproximadamente 119 GB contendo as partições de arranque/dados do ZimaOS e um conjunto Btrfs separado com vários discos. Essa distinção alterou o plano de recuperação: a falha do NVMe de arranque não significava automaticamente que o conjunto de armazenamento tivesse falhado.
Comece com comandos só de leitura:
lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
blkid
cat /proc/cmdlineAnote os nomes exatos dos dispositivos antes de executar qualquer comando que tenha como alvo um disco ou uma partição.
Verifique os Registos do Kernel à Procura de Erros Reais de E/S
O caso original continha mensagens repetidas de critical medium error, Buffer I/O error, falhas de montagem EXT4 e erros de NVMe no dispositivo de arranque. Essas mensagens são evidências muito mais fortes de uma falha de armazenamento do que um erro genérico no ecrã de arranque.
dmesg -T | grep -Ei 'nvme|I/O error|Buffer I/O|EXT4|superblock|reset|timeout|critical|media'Se os erros apontarem consistentemente para o NVMe de arranque, enquanto os discos de dados não apresentam falhas, mantenha a investigação centrada no caminho de arranque.
Um Resultado SMART “PASSED” Não Anula os Erros de Suporte
No tópico, o resumo de integridade SMART do NVMe ainda indicava PASSED, mas os contadores detalhados mostravam 76 erros de suporte/integridade de dados e o kernel já registava leituras falhadas. A verificação do sistema de ficheiros só de leitura também foi interrompida devido a blocos ilegíveis.
Utilize dados detalhados de integridade, como smartctl -x /dev/nvmeXn1 ou nvme smart-log /dev/nvmeXn1, depois de confirmar o nome correto do dispositivo. Não trate a única palavra de estado geral como se fosse todo o diagnóstico.
Comece por Verificações do Sistema de Ficheiros Só de Leitura
A comunidade utilizou e2fsck -fn na partição overlay EXT4 afetada, para que o sistema de ficheiros pudesse ser inspecionado sem escrever correções. Mesmo essa verificação só de leitura encontrou blocos ilegíveis, reforçando o diagnóstico de falha de hardware.
Nunca execute fsck no modo de escrita num sistema de ficheiros montado e não adivinhe os nomes das partições. Se o SSD de arranque estiver a falhar fisicamente, tentativas repetidas de escrita podem dificultar a recuperação.
Porque Podem Falhar Tanto a Ranhura A como a Ranhura B
O ZimaOS utiliza ranhuras de sistema A/B para recuperação, conforme documentado no guia de recuperação do sistema do ZimaOS. No entanto, ambas as opções de arranque continuam a depender de componentes de armazenamento partilhados e em bom estado no dispositivo de arranque. Por isso, um overlay ou NVMe de arranque com falhas pode impedir que ambas as ranhuras concluam o arranque.
Quando a Substituição é a Opção Mais Segura
Depois de o caso original apresentar erros de suporte no kernel, contadores detalhados de erros de suporte no SMART e blocos ilegíveis no sistema de ficheiros do NVMe de arranque, a comunidade recomendou tratar esse SSD como não fiável, em vez de tentar repará-lo no local. O utilizador substituiu-o e reinstalou o ZimaOS com sucesso.
Durante a reinstalação, mantenha os discos de dados claramente identificados e evite inicializar ou recriar um conjunto existente. O guia de resolução de problemas de instalação do ZimaOS ajuda na parte da instalação no dispositivo de arranque, enquanto o guia de recuperação do armazenamento após a reinstalação reforça a regra essencial: não recrie um conjunto que já contenha os seus dados.
Em Resumo
Neste caso, o erro do kernel foi causado por uma falha do NVMe de arranque, não sendo prova de que o conjunto de dados separado tivesse sido destruído. Faça o diagnóstico em modo só de leitura, confirme qual é o dispositivo que apresenta os erros de E/S e não altere os discos de dados. O utilizador original substituiu a unidade de arranque avariada, reinstalou o ZimaOS e confirmou que o conjunto de dados existente tinha sobrevivido.
