Primeiro, distinga um bloqueio completo do anfitrião de uma falha de rede
A máquina indicada perdeu o acesso à rede, o ping, os contentores, a resposta da consola local e a saída de vídeo. Esse alcance é mais amplo do que uma falha de SMB, Docker ou da placa de rede e é consistente com um bloqueio completo do anfitrião que exige um ciclo de alimentação.
Se um servidor desaparecer remotamente, verifique a consola local e o ecrã antes de comprar uma placa de rede de substituição. Uma consola responsiva direciona a investigação para a rede; uma consola bloqueada e um ecrã sem imagem direcionam-na para o kernel, o firmware, a alimentação, o armazenamento ou o hardware.
Registe a hora exata do evento e se a máquina reiniciou sozinha ou permaneceu ligada, mas sem responder. Essas observações determinam qual o intervalo do arranque anterior e quais os dados de monitorização externa que podem ser comparados.
Recolher evidências do arranque anterior antes de alterar variáveis
A primeira recolha útil no tópico foi journalctl -b -1, incluindo mensagens do kernel e de alta prioridade do arranque que terminou no bloqueio. Posteriormente, a equipa do ZimaOS solicitou as últimas 500 entradas do arranque anterior e o registo persistente para análise privada.
Reveja os registos para verificar se contêm informações pessoais antes de os publicar. Neste caso, o registo persistente estava ativado, mas parou abruptamente à hora da falha observada, sem pânico, eliminação por falta de memória (OOM), reposição da GPU, erro de armazenamento, evento térmico, bloqueio do watchdog ou encerramento normal.
Um registo final vazio não prova que nada tenha falhado. Mostra que o anfitrião parou antes de o mecanismo de registo local disponível registar uma causa. Repetir o mesmo comando de registo após cada bloqueio silencioso idêntico acrescenta pouco, a menos que o método de captura seja alterado.
Os testes à GPU e ao Frigate não identificaram uma solução
O sistema utilizava os gráficos Intel i915 e o Frigate VAAPI, pelo que o autor desativou primeiro a aceleração por GPU. O anfitrião continuou a bloquear. Parar completamente o Frigate produziu, numa ocasião, um intervalo mais longo, mas os testes posteriores não estabeleceram que o Frigate fosse a causa.
O autor também tentou desativar o i915, o que tornou outras cargas de trabalho inutilizáveis, e o sistema acabou por voltar a bloquear. Esse resultado exclui «desativar o i915» como solução eficaz neste caso.
A comparação com o OpenMediaVault foi significativa: o mesmo hardware e a mesma configuração do Frigate tinham permanecido estáveis nesse sistema. Isto levanta suspeitas sobre uma interação específica do kernel ou do controlador do ZimaOS, mas, por si só, não identifica qual foi o componente que falhou.
As Sugestões de IOMMU, VFIO e LPM SATA Foram Excluídas como Soluções
O ZimaOS incluía inicialmente intel_iommu=on e vfio_iommu_type1.allow_unsafe_interrupts=1. Um membro da equipa pediu ao autor para remover ambos. A linha de comandos ativa confirmou a sua ausência, mas a máquina bloqueou novamente.
O autor testou então libata.force=nolpm porque os discos de dados utilizavam um adaptador M.2 para SATA. Na manhã seguinte ocorreu outro bloqueio. Por conseguinte, o tópico não sustenta nenhuma das alterações de parâmetros de arranque como solução.
Estes testes também mostram por que motivo as atualizações podem invalidar uma experiência: uma atualização tinha substituído o ficheiro personalizado da linha de comandos. Verifique sempre a linha de comandos de arranque ativa antes de interpretar o tempo de atividade e altere uma variável de cada vez através da janela de falha estabelecida.
O Journal Persistente, o pstore e o Reencaminhamento Remoto Atingiram os Seus Limites
O kernel incluía pstore e deteção de bloqueios rígidos/suaves, e o watchdog NMI estava ativo. No entanto, /sys/fs/pstore permaneceu vazio após as falhas, enquanto não foi reservado qualquer kernel de falha para o kdump.
O netconsole iniciado no arranque analisou a configuração, mas arrancou antes de eth0 existia e desativava-se. Um journalctl-o reencaminhador para UDP alcançou uma segunda máquina Linux, mas também parou sem uma causa final quando o anfitrião bloqueou.
Esse resultado é útil: o reencaminhamento em espaço do utilizador não consegue enviar mensagens depois de o agendador ou a pilha de rede parar, nem consegue criar um aviso do kernel que nunca foi emitido. Neste momento, um kernel de depuração do fabricante ou uma instrumentação direcionada será mais útil do que outra captura idêntica em espaço do utilizador.
ZimaOS 1.7.1 Alterou os Componentes Suspeitos, mas Ainda Não Foi Validado
Um segundo utilizador do ZimaBoard 2 relatou falhas repetidas do Python e de outros processos perto de um bloqueio total. A equipa do ZimaOS afirmou ter removido a dependência Crudini do zimaos-welcome, reduziu a frequência dos pedidos de recursos desse serviço e planeou as alterações para uma versão de teste.
A equipa esclareceu posteriormente que o problema do Crudini era apenas um fator desencadeador e que a causa efetiva da falha do sistema continuava sob investigação. No ZimaOS 1.7.1, também reverteu a versão do Docker Engine para melhorar o arranque dos contentores e reduzir a probabilidade de bloqueio das mensagens do intermediário DBus.
A publicação final pergunta se outro utilizador está estável na versão 1.7.1; não fornece o resultado de disponibilidade necessário. Não descreva a versão 1.7.1 como uma correção confirmada dos bloqueios até que a condição de falha original permaneça estável para além do intervalo anterior.
Escalar com os testes já excluídos
Um bom pacote de suporte inclui o modelo do hardware, as versões do ZimaOS e do kernel, o controlador de armazenamento, as cargas de trabalho, as horas dos bloqueios, os parâmetros de arranque ativos, os registos do arranque anterior e uma lista dos testes controlados com os respetivos resultados.
Indique explicitamente que a aceleração por GPU, o isolamento do Frigate, a remoção dos parâmetros IOMMU/VFIO, a desativação do i915, as alterações ao SATA LPM, os registos persistentes, o pstore e o registo remoto no espaço do utilizador não produziram uma reparação confirmada neste caso específico.
Se outro sistema operativo permanecer estável com a mesma carga de trabalho enquanto o ZimaOS continua a bloquear, preserve essa comparação e solicite uma compilação direcionada ou uma investigação do fabricante. Quando a fiabilidade é operacionalmente crítica, regressar ao ambiente estável é um limite de paragem válido, em vez de continuar a acumular parâmetros não verificados indefinidamente.
Perguntas frequentes
O Frigate ou o Intel VAAPI causaram os bloqueios do ZimaOS?
O tópico não o comprovou. Os bloqueios continuaram depois de a aceleração por GPU ter sido desativada e após mais testes de isolamento do i915.
A remoção dos parâmetros IOMMU e VFIO corrigiu os bloqueios?
Não. A linha de comandos ativa confirmou que ambos foram removidos e o anfitrião bloqueou novamente.
O ZimaOS 1.7.1 corrige os bloqueios completos do sistema?
A versão alterou o Crudini, zimaos-welcome, o Docker Engine e o comportamento relacionado com o DBus, mas o tópico termina antes de um resultado de estabilidade confirmar a recuperação.
