A fonte parece ser um problema de configuração do btop, mas na realidade mistura dois ambientes de execução diferentes. O ZimaOS tem um painel de desempenho btop integrado desde a v1.3.3. Separadamente, os utilizadores podem instalar um contentor btop a partir da App Store. Um contentor vê normalmente o seu próprio espaço de nomes de rede, enquanto o btop do anfitrião consegue ver as interfaces expostas ao anfitrião.
Essa distinção explica por que motivo um participante conseguia alternar entre eth0, eth1, virbr0, docker0e várias veth interfaces, enquanto o btop do autor da publicação original apenas disponibilizava lo e eth0. O tópico continuava sem terminar com uma reparação confirmada para a configuração exata do autor da publicação.
O próprio ZimaOS estava a utilizar a interface 10GbE
O btop foi adicionado como painel de desempenho integrado do ZimaOS
A IceWhale introduziu o painel btop integrado no ZimaOS 1.3.3. Por isso, os utilizadores atuais não devem presumir que precisam de instalar um contentor btop separado apenas para obter uma monitorização básica do sistema.
Consulte o limite funcional oficial do btop integrado.
Um exemplo de btop no anfitrião mostrou várias interfaces físicas e virtuais
Um btop no Docker vê apenas o espaço de nomes de rede que lhe é atribuído
As respostas da comunidade explicaram que um contentor btop da App Store pode ver apenas a rede do próprio contentor. Esse é o comportamento normal do Docker: a aplicação não consegue monitorizar interfaces do anfitrião que não estejam expostas no respetivo espaço de nomes.
Alterar o seletor de interfaces do btop não pode criar uma interface inexistente
Selecionar a rede do anfitrião do Docker fez a aplicação da fonte falhar ou parar
O autor da publicação original afirmou que mudar o contentor btop da App Store para a rede do anfitrião não resolveu o problema, porque o btop deixou de funcionar. Também considerou adicionar SYS_PTRACE ou SYS_ADMIN.
O tópico não valida essas alterações de privilégios, pelo que não devem ser recomendadas apenas para disponibilizar um painel de estatísticas.
O binário btop do anfitrião existia, mas a fonte indicava que não funcionava
O tópico não contém uma correção final confirmada
Nenhuma resposta de um funcionário da IceWhale na fonte estabelece se o btop integrado do autor da publicação estava corrompido, era afetado por uma instalação manual anterior ou estava a deparar-se com um erro separado da versão 1.6.1.
Uma abordagem atual mais segura
- Utilize primeiro o painel btop integrado do ZimaOS.
- Confirme que a NIC existe com as ferramentas de rede atuais do anfitrião.
- Se utilizar um monitor num contentor, compreenda o respetivo espaço de nomes de rede.
- Evite aumentar privilégios para privilegiado/SYS_ADMIN apenas para obter métricas.
- Se o btop integrado falhar, recolha a versão atual e o erro direto da CLI, em vez de reinstalar repetidamente um segundo pacote btop.
A página preta do btop e a eth1 em falta são dois sintomas distintos
No início do tópico, o autor original disse que o btop do painel integrado abria com o ecrã preto. Mais tarde, concentrou-se num btop da App Store/contentor que funcionava, mas apresentava apenas lo e eth0. Esses problemas não devem ser reduzidos a uma única causa.
Uma falha do painel integrado pode envolver a sessão btop/ttyd do anfitrião, enquanto a ausência de interfaces do anfitrião dentro de um monitor Docker é uma consequência esperada do isolamento do espaço de nomes.
Uma porta do btop alta ou variável não é automaticamente a causa principal
O ZimaOS inicia algumas ferramentas de terminal através de sessões Web. Ver um erro de porta ou de ligação no navegador não prova que a NIC física esteja mal configurada. Execute primeiro o comando no anfitrião diretamente e registe o erro exato.
Mais privilégios no contentor não são uma solução de monitorização gratuita
Adicionar SYS_ADMIN, o acesso amplo a dispositivos ou o modo totalmente privilegiado podem expor muito mais do anfitrião do que aquilo de que o btop necessita. Até mesmo network_mode: host altera o modelo de isolamento do contentor.
Para a telemetria do sistema, é preferível um monitor integrado no anfitrião que funcione a conceder a um contentor da App Store privilégios próximos dos do anfitrião apenas para enumerar todas as interfaces.
Verifique a eth1 no anfitrião antes de culpar o btop
Verifique a página de rede atual do ZimaOS ou os comandos de rede do anfitrião e confirme que a interface 10GbE está ativa, tem o endereço esperado e transporta tráfego. A fonte fez isto com sucesso: o próprio ZimaOS apresentou e utilizou eth1.
Se a rede do anfitrião detetar a interface, mas apenas o contentor não a detetar, o limite está no ambiente de monitorização — não no controlador da NIC.
Trate um btop integrado avariado no ZimaOS atual como uma nova regressão
A fonte usava a versão 1.6.1, enquanto a versão atual do ZimaOS é a 1.7.1. Se o painel integrado continuar hoje a aparecer preto, registe a versão atual, a arquitetura da CPU, a saída direta btop a saída, o erro da consola/sessão do navegador e se a recuperação/reinstalação altera o problema. Não assuma que o tópico de abril de 2026 já explica uma falha atual.
Perguntas frequentes sobre a rede do btop
O btop consegue selecionar a eth1 se a eth1 não estiver visível no respetivo espaço de nomes?
Não. O seletor alterna apenas entre as interfaces que o processo em execução consegue ver.
Outro utilizador confirmou que o btop integrado conseguia ver a eth1?
Sim. O James relatou ter alternado entre as interfaces eth0, eth1, libvirt, Docker e veth no btop do anfitrião.
A fonte confirmou uma correção segura dos privilégios do Docker?
Não. Foram discutidas a rede do anfitrião e capacidades adicionais, mas não foi verificada nenhuma configuração final funcional.
