Um painel do ZimaOS pode ser apresentado no navegador enquanto ainda faltam dados importantes do backend. Neste caso da comunidade, de fevereiro de 2026, o utilizador conseguia ver a interface gráfica após um reinício, mas as aplicações instaladas não apareciam, as informações do sistema estavam em branco e a licença Plus aparecia temporariamente como inativa.
O sistema era um NAS personalizado com o ZimaOS 1.5.4, um HBA LSI e dez discos. Reinstalar o ZimaOS não tinha resolvido o comportamento recorrente. A solução acabou por surgir ao isolar o hardware de armazenamento, em vez de se concentrar nos avisos relativos à NVIDIA e ao Wi-Fi visíveis nos registos de arranque.
Porque é que a interface gráfica podia carregar sem aplicações nem informações do sistema
Um membro da comunidade observou que o frontend podia carregar enquanto o backend principal zimaos.service terminava repetidamente e era reiniciado pelo systemd. Isso correspondia aos sintomas visíveis: a estrutura da página aparecia, mas os dados das aplicações, as informações do sistema e o estado da licença não estavam disponíveis até o backend estabilizar.
Os mesmos registos continham erros do NVML numa máquina sem GPU NVIDIA e erros de Wi-Fi numa máquina sem adaptador Wi-Fi. O diagnóstico da comunidade foi que estas mensagens não eram a causa principal neste caso. O sinal mais importante era a falha repetida do serviço principal do ZimaOS.
Este foi um caso do ZimaOS 1.5.4
O relatório foi feito no ZimaOS 1.5.4, depois de uma atualização a partir do 1.5.3. Não assuma que o mesmo comportamento de arranque ou as mesmas mensagens de registo se aplicam sem alterações a versões posteriores. A documentação atual do ZimaOS apresenta versões mais recentes, por isso utilize esta página como um padrão de resolução de problemas e não como uma afirmação sobre um erro atual.
Para obter informações sobre as versões atuais, consulte ZimaOS.
Isole a camada de armazenamento antes de reinstalar novamente
A máquina original tinha dez discos, incluindo oito unidades ligadas através de um HBA LSI. O primeiro teste útil consistiu em reduzir o conjunto de hardware e arrancar com menos discos ligados.
Depois de remover as oito unidades ligadas ao HBA, o sistema iniciou muito mais rapidamente. O utilizador voltou então a ligar os discos de forma metódica e descobriu que uma unidade Seagate IronWolf de 8 TB reproduzia o ciclo de arranque, mesmo quando ligada sozinha através de outro percurso SATA. Com esse disco removido, o ZimaOS voltou a arrancar em aproximadamente dois minutos no ambiente do utilizador.
Este é o resultado mais significativo da discussão: a unidade problemática era um fator desencadeador reproduzível naquele sistema específico. Isto não demonstra que todas as unidades IronWolf, discos NTFS, HBAs ou discos de grande capacidade provoquem falhas de arranque do ZimaOS.
Uma unidade pode parecer normal num teste rápido e, ainda assim, desencadear o problema
O utilizador ligou a unidade suspeita a um computador Windows através de uma caixa USB 3.0 e executou os diagnósticos da Seagate. O teste curto não revelou uma falha evidente, o que tornou o caso mais complexo do que um simples diagnóstico de disco avariado.
Uma captura de ecrã dos detalhes SMART mostrava mais de 35 000 horas de funcionamento, enquanto vários dos contadores clássicos de falhas apresentados no teste permaneciam a zero.
Uma interpretação posterior da comunidade também assinalou um pequeno número de erros CRC Ultra DMA e advertiu que testar através de USB não equivale a testar a unidade no percurso SATA ou HBA original. Estas observações são pistas úteis, mas resultaram da análise da comunidade e não de um diagnóstico de hardware da IceWhale.
Um processo prático de resolução de problemas baseado neste caso
- Confirme se o navegador está a mostrar apenas um painel parcial ou se toda a máquina está inacessível.
- Verifique se o backend principal do ZimaOS está a falhar repetidamente, em vez de presumir que todas as linhas de aviso são causais.
- Desligue a máquina antes de alterar as ligações dos discos.
- Reduza o sistema ao conjunto mínimo de armazenamento necessário para arrancar.
- Se a interface gráfica ficar estável, volte a ligar os discos adicionais gradualmente e reproduza a falha de forma metódica.
- Teste uma unidade suspeita noutra porta ou através de outro percurso de controlador, quando for viável.
- Faça uma cópia de segurança dos dados importantes antes de executar diagnósticos prolongados aos discos ou substituir hardware de armazenamento.
A discussão da comunidade incluía comandos de shell para inspecionar serviços, registos, dispositivos de bloco e dados SMART. Como esses comandos não foram fornecidos nem confirmados por uma conta da equipa da IceWhale nesta discussão, não são reproduzidos aqui como instruções oficiais do ZimaOS.
Porque é que a licença Plus parecia inativa
Neste caso, o estado inativo da Plus surgiu juntamente com a ausência das aplicações e das informações do sistema, enquanto o backend estava a falhar. Quando o sistema arrancou normalmente sem a unidade desencadeadora, esses sintomas da interface gráfica parcial desapareceram. Por isso, a discussão considera a apresentação da licença um sintoma de um arranque incompleto do backend, e não uma indicação de que o direito Plus do utilizador tivesse sido efetivamente removido.
Perguntas frequentes sobre a interface gráfica parcial do ZimaOS
Os erros da NVIDIA e do Wi-Fi são sempre a causa de um ciclo de arranque do ZimaOS?
Não. Neste caso, a máquina não tinha esses dispositivos, mas o fator desencadeador reproduzível era um dispositivo de armazenamento. Não diagnostique um ciclo de reinícios com base numa única linha de aviso.
Reinstalar o ZimaOS resolveu o problema?
Não. O utilizador tinha reinstalado o sistema várias vezes. Foi o isolamento do hardware que permitiu restringir o problema a uma unidade específica de 8 TB.
O SMART mostrou imediatamente que a unidade estava avariada?
Não. O teste curto do Windows parecia normal e vários contadores SMART comuns de falhas estavam a zero. A principal evidência foi o facto de ligar esta unidade desencadear repetidamente o ciclo de arranque, enquanto removê-la restaurava o comportamento normal de arranque.
Isto prova que o ZimaOS 1.5.4 não consegue lidar com muitos discos ou com um HBA LSI?
Não. O sistema arrancou com os outros discos depois de a unidade suspeita ser removida. A discussão não estabelece uma incompatibilidade geral com HBAs ou com uma determinada quantidade de discos.
