Solução da comunidade

Resolução de problemas do CasaOS no ZimaBoard e no ZimaBlade: dmidecode, lspci, lsusb, dmesg, lsblk e limites modernos

A detailed October 2023 community troubleshooting reference for ZimaBoard/ZimaBlade running CasaOS on a regular Linux distribution. It teaches BIOS, PCI, USB, kernel-log, and storage inspection using standard Linux CLI tools. Those commands remain useful on CasaOS/Debian, but package-management assumptions should not be transferred blindly to ZimaOS.

O guia de resolução de problemas original é valioso porque começa abaixo da interface do CasaOS. Quando uma unidade, NIC, placa PCIe ou dispositivo USB se comporta de forma estranha, a primeira pergunta é se o sistema Linux subjacente consegue sequer detetar o hardware.

A fronteira importante de 2026 é a arquitetura do sistema operativo. O guia de 2023 pressupõe o CasaOS a funcionar numa instalação Linux normal ao estilo Debian/Ubuntu. O ZimaOS atual é um sistema operativo appliance separado, baseado no Buildroot e com um sistema em grande parte só de leitura. Os comandos de diagnóstico só de leitura continuam a ser úteis, mas as instruções de instalação de pacotes e modificação do anfitrião dos guias Debian comuns não devem ser copiadas para o ZimaOS.

Use dmidecode para obter informações sobre a BIOS e a placa

dmidecode lê dados SMBIOS/DMI, tais como:

  • fabricante e versão da BIOS;
  • data de lançamento;
  • identificadores do sistema/placa;
  • informações sobre a memória;
  • capacidades do firmware, como UEFI.

Isto é útil para comparar um problema específico do hardware com uma atualização da BIOS ou para confirmar exatamente qual a revisão da placa em funcionamento.

Use lspci para confirmar que o hardware PCIe foi enumerado

lspci apresenta os dispositivos detetados pelo subsistema PCI: GPUs, controladores SATA, adaptadores NVMe, NICs, placas de captura e outro hardware de expansão.

Se uma NIC PCIe nova nunca aparecer em lspci, o problema está abaixo do Docker/CasaOS. Verifique o encaixe, a alimentação, as definições do firmware, a partilha de pistas e a compatibilidade do hardware antes de instalar software de aplicações.

Use lsusb para identificar dispositivos USB

lsusb apresenta os IDs de fabricante/produto USB. Esses IDs são especialmente úteis para diagnosticar adaptadores Wi-Fi, dispositivos Coral TPU, bridges de armazenamento USB, coordenadores Zigbee e outros periféricos que podem ter várias revisões de hardware com o mesmo nome comercial.

Use dmesg para obter mensagens de controladores e do hardware durante o arranque

dmesg pode apresentar:

  • associação de controladores do kernel;
  • falhas ao carregar o firmware;
  • eventos de desligação/religação USB;
  • erros de E/S de armazenamento;
  • alterações do estado da ligação da NIC;
  • erros PCIe/AER.

Filtre ou capture apenas as secções relevantes, em vez de publicar milhares de linhas de arranque sem relação.

Use lsblk para distinguir entre «Disco não detetado» e «Disco não montado»

lsblk mostra discos, partições, relações entre sistemas de ficheiros e pontos de montagem. Uma unidade presente em lsblk mas estar ausente da interface de Ficheiros do CasaOS é uma falha diferente de uma unidade totalmente ausente do Linux.

Prefira a deteção só de leitura antes dos comandos de reparação

A Parte 1 original é mais forte quando ensina a observar. Comandos como dmidecode, lspci, lsusb, dmesg, e lsblk pode determinar a camada do problema sem modificar o armazenamento ou os pacotes.

Faça isto antes de reformatar discos, reinstalar controladores, alterar recursivamente os proprietários ou reconstruir o Docker.

O CasaOS e o ZimaOS exigem regras diferentes para modificar o anfitrião

O CasaOS é normalmente executado num anfitrião Linux geral, onde apt pode estar disponível. O ZimaOS é baseado no Buildroot e as orientações atuais da CLI da IceWhale indicam que a maioria das pastas do sistema permanece apenas de leitura, mesmo como root.

Utilize os limites atuais da CLI do ZimaOS quando o mesmo hardware executar o ZimaOS.

Diagnostique do hardware para cima

Uma ordem útil é:

  1. a BIOS/firmware deteta o hardware;
  2. a enumeração do barramento Linux deteta-o;
  3. um controlador do kernel associa-se;
  4. o sistema operativo cria uma interface/dispositivo de bloco utilizável;
  5. O CasaOS/ZimaOS expõe-o na interface;
  6. O Docker/as aplicações recebem o dispositivo/caminho.

Saltar diretamente para a camada seis faz com que muitos problemas de hardware pareçam erros de aplicações.

Utilize blkid para identificar o tipo e o UUID do sistema de ficheiros

A Parte 1 da fonte também utiliza blkid depois lsblk. Isto responde a uma pergunta diferente: que assinatura de sistema de ficheiros ou membro LVM contém realmente a partição e que UUID/PARTUUID a identifica?

Isto é útil quando um disco aparece no Linux, mas um gestor de montagem ou armazenamento não reconhece o sistema de ficheiros esperado. Registe o resultado antes de reformatar o que quer que seja.

Guarde as informações de hardware antes de alterar controladores ou armazenamento

Para elaborar um relatório de suporte reproduzível, recolha o resultado dos comandos relevantes juntamente com:

  • modelo da placa e versão da BIOS;
  • versão do sistema operativo;
  • modelo do dispositivo e ID PCI/USB;
  • o que mudou imediatamente antes de surgir o problema;
  • se o hardware aparece na BIOS, no Linux e na interface do CasaOS/ZimaOS.

Isto permite distinguir entre um controlador em falta, um cabo avariado, um sistema de ficheiros não suportado ou um problema de mapeamento do contentor.

Perguntas frequentes sobre resolução de problemas de hardware Linux

O que devo executar primeiro para uma placa PCIe desconhecida?

lspci é a verificação de leitura mais rápida para confirmar que o subsistema PCI o deteta.

O que é mais útil para obter os IDs de fabricante/produto USB?

lsusb.

Posso aplicar ao ZimaOS os pressupostos do guia relativos aos pacotes Debian?

Não. Mantenha os conceitos de diagnóstico, mas siga as regras específicas do ZimaOS para extensões e controladores.