La fuente parece un problema de configuración de btop, pero en realidad mezcla dos entornos de ejecución diferentes. ZimaOS cuenta con un panel de rendimiento btop integrado desde la versión v1.3.3. Por separado, los usuarios pueden instalar un contenedor btop desde una App Store. Normalmente, un contenedor ve su propio espacio de nombres de red, mientras que el btop del host puede ver las interfaces expuestas al host.
Esa distinción explica por qué un participante podía alternar entre eth0, eth1, virbr0, docker0y varias interfaces veth interfaces, mientras que el btop del autor original solo ofrecía lo y eth0. El hilo aún no terminó con una reparación confirmada para la configuración exacta del autor.
ZimaOS estaba utilizando la interfaz 10GbE
btop se añadió como panel de rendimiento integrado de ZimaOS
IceWhale introdujo el panel btop integrado en ZimaOS 1.3.3. Por lo tanto, los usuarios actuales no deberían suponer que necesitan instalar un contenedor btop independiente solo para obtener una supervisión básica del sistema.
Consulta el límite funcional oficial del btop integrado.
Un ejemplo de btop del host mostró varias interfaces físicas y virtuales
Un btop de Docker solo ve el espacio de nombres de red que se le proporciona
Las respuestas de la comunidad explicaron que un contenedor btop de la App Store puede ver únicamente su propia red de contenedor. Ese es el comportamiento normal de Docker: la aplicación no puede supervisar interfaces del host que no estén expuestas en su espacio de nombres.
Cambiar el selector de interfaces de btop no puede crear una interfaz inexistente
Seleccionar la red del host de Docker provocó que la aplicación de origen se bloqueara o dejara de funcionar
El autor original dijo que cambiar el contenedor btop de la App Store a la red del host no resolvió el problema porque btop dejó de funcionar. También consideró añadir SYS_PTRACE o SYS_ADMIN.
El hilo no valida esos cambios de privilegios, por lo que no deberían recomendarse simplemente para mostrar un panel de estadísticas.
El binario btop del host existía, pero la fuente indicaba que no funcionaba
El hilo no contiene una solución final confirmada
Ninguna respuesta del personal de IceWhale en la fuente establece si el btop integrado del autor estaba dañado, afectado por una instalación manual anterior o presentaba un error independiente de la versión 1.6.1.
Un enfoque actual más seguro
- Usa primero el panel de btop integrado de ZimaOS.
- Confirma que la NIC exista mediante las herramientas de red actuales del host.
- Si utilizas un monitor en un contenedor, comprende su espacio de nombres de red.
- Evita aumentar los privilegios a privileged/SYS_ADMIN únicamente para obtener métricas.
- Si el btop integrado falla, recopila la versión actual y el error directo de la CLI en lugar de reinstalar repetidamente un segundo paquete de btop.
La página de btop negra y la ausencia de eth1 son dos síntomas distintos
Al principio del hilo, el autor original dijo que el btop del panel integrado se abría con la pantalla negra. Más tarde se centró en un btop de App Store/contenedor que se ejecutaba, pero solo mostraba lo y eth0. Esas dos situaciones no deben atribuirse a una sola causa.
Un panel integrado que falla puede implicar la sesión de btop/ttyd del host, mientras que la ausencia de interfaces del host dentro de un monitor Docker es una consecuencia esperada del aislamiento del espacio de nombres.
Un puerto de btop alto o cambiante no es automáticamente la causa raíz
ZimaOS inicia algunas herramientas de tipo terminal mediante sesiones web. Ver un error de puerto o de conexión en el navegador no demuestra que la NIC física esté mal configurada. Ejecuta primero el comando directamente en el host y captura el error exacto.
Más privilegios para el contenedor no son una solución de monitorización gratuita
Añadir SYS_ADMIN, un acceso amplio a dispositivos o el modo completamente privilegiado pueden exponer mucho más del host de lo que btop necesita. Incluso network_mode: host cambia el modelo de aislamiento del contenedor.
Para la telemetría del sistema, es preferible un monitor integrado en el host que conceder privilegios cercanos a los del host a un contenedor de App Store solo para que pueda enumerar todas las interfaces.
Verifica eth1 en el host antes de culpar a btop
Comprueba la página de red actual de ZimaOS o los comandos de red del host y confirma que la interfaz 10GbE esté activa, tenga la dirección esperada y transmita tráfico. La fuente lo hizo correctamente: el propio ZimaOS mostraba y utilizaba eth1.
Si la red del host ve la interfaz, pero el contenedor no, el límite está en el entorno de monitorización, no en el controlador de la NIC.
Trata un btop integrado averiado en el ZimaOS actual como una nueva regresión
La fuente usaba la versión 1.6.1, mientras que la versión actual de ZimaOS es la 1.7.1. Si el panel integrado sigue apareciendo negro hoy, registra la versión actual, la arquitectura de la CPU, la btop la salida, el error de la consola o sesión del navegador y si la recuperación o reinstalación lo cambia. No asumas que el hilo de abril de 2026 ya explica un fallo actual.
Preguntas frecuentes sobre la red de btop
¿Puede btop seleccionar eth1 si eth1 no es visible en su espacio de nombres?
No. El selector solo recorre las interfaces que el proceso en ejecución puede ver.
¿Otro usuario confirmó que el btop integrado podía ver eth1?
Sí. James informó que pasó por las interfaces eth0, eth1, libvirt, Docker y veth en el btop del host.
¿La fuente confirmó una solución segura para los privilegios de Docker?
No. Se habló de la red del host y de capacidades adicionales, pero no se verificó ninguna configuración final funcional.
