La guía original de resolución de problemas es valiosa porque comienza por debajo de la interfaz de CasaOS. Cuando una unidad, NIC, tarjeta PCIe o dispositivo USB se comporta de forma extraña, la primera pregunta es si el sistema Linux subyacente puede ver el hardware en absoluto.
El límite importante de 2026 es la arquitectura del sistema operativo. La guía de 2023 presupone que CasaOS se ejecuta en una instalación normal de Linux basada en Debian/Ubuntu. Los comandos de diagnóstico de solo lectura siguen siendo útiles, pero las instrucciones para instalar paquetes y modificar el sistema anfitrión de las guías habituales de Debian no deben copiarse en ZimaOS.
Usa dmidecode para consultar la información de la BIOS y la placa
dmidecode lee datos SMBIOS/DMI como:
- proveedor y versión de la BIOS;
- fecha de lanzamiento;
- identificadores del sistema/placa;
- información de la memoria;
- capacidades del firmware, como UEFI.
Esto resulta útil para comparar un problema específico del hardware con una actualización de la BIOS o para confirmar exactamente qué revisión de la placa está en funcionamiento.
Usa lspci para confirmar que el hardware PCIe está enumerado
lspci enumera los dispositivos que detecta el subsistema PCI: GPU, controladores SATA, adaptadores NVMe, NIC, tarjetas de captura y otro hardware de expansión.
Si una NIC PCIe nueva nunca aparece en lspci, el problema está por debajo de Docker/CasaOS. Comprueba el encaje, la alimentación, la configuración del firmware, el uso compartido de líneas y la compatibilidad del hardware antes de instalar software de aplicaciones.
Usa lsusb para identificar dispositivos USB
lsusb muestra los ID de proveedor/producto USB. Esos ID son especialmente útiles para diagnosticar adaptadores Wi‑Fi, dispositivos Coral TPU, puentes de almacenamiento USB, coordinadores Zigbee y otros periféricos que pueden tener varias revisiones de hardware bajo un mismo nombre comercial.
Usa dmesg para consultar los mensajes del controlador y del hardware durante el arranque
dmesg puede mostrar:
- vinculación de controladores del kernel;
- fallos de carga del firmware;
- eventos de desconexión/reconexión USB;
- errores de E/S de almacenamiento;
- cambios en el enlace de la NIC;
- errores de PCIe/AER.
Filtra o captura solo las secciones relevantes en lugar de publicar miles de líneas de arranque no relacionadas.
Usa lsblk para distinguir entre «disco no detectado» y «disco no montado»
lsblk muestra discos, particiones, relaciones entre sistemas de archivos y puntos de montaje. Una unidad presente en lsblk pero ausente de la interfaz de Archivos de CasaOS es un fallo distinto al de una unidad que falta por completo en Linux.
Prefiere el descubrimiento de solo lectura antes que los comandos de reparación
La Parte 1 original es más sólida cuando enseña a observar. Comandos como dmidecode, lspci, lsusb, dmesg, y lsblk puede determinar la capa del problema sin modificar el almacenamiento ni los paquetes.
Hazlo antes de reformatear discos, reinstalar controladores, cambiar propietarios de forma recursiva o reconstruir Docker.
CasaOS y ZimaOS requieren reglas distintas para modificar el host
CasaOS normalmente se ejecuta en un host Linux general donde apt puede estar disponible. ZimaOS se basa en Buildroot y las directrices actuales de la CLI de IceWhale indican que la mayoría de las carpetas del sistema siguen siendo de solo lectura incluso como root.
Usa los límites actuales de la CLI de ZimaOS cuando el mismo hardware ejecute ZimaOS.
Diagnostica desde el hardware hacia arriba
Un orden útil es:
- la BIOS/el firmware detecta el hardware;
- la enumeración del bus de Linux lo detecta;
- un controlador del kernel se vincula;
- el sistema operativo crea una interfaz o dispositivo de bloques utilizable;
- CasaOS/ZimaOS lo muestra en la interfaz;
- Docker/las aplicaciones reciben el dispositivo o la ruta.
Saltar directamente a la sexta capa hace que muchos problemas de hardware parezcan errores de las aplicaciones.
Usa blkid para identificar el tipo de sistema de archivos y el UUID
La Parte 1 de la fuente también utiliza blkid después lsblk. Esto responde a otra pregunta: ¿qué firma de sistema de archivos o miembro de LVM contiene realmente la partición y qué UUID/PARTUUID la identifica?
Esto resulta útil cuando un disco aparece en Linux, pero un gestor de montaje o almacenamiento no reconoce el sistema de archivos esperado. Registra la salida antes de reformatear nada.
Guarda las pruebas del hardware antes de cambiar los controladores o el almacenamiento
Para elaborar un informe de soporte reproducible, recopila la salida de los comandos relevantes junto con:
- modelo de la placa y versión de la BIOS;
- versión del sistema operativo;
- modelo del dispositivo y su ID PCI/USB;
- qué cambió inmediatamente antes de que surgiera el problema;
- si el hardware aparece en la BIOS, Linux y la interfaz de CasaOS/ZimaOS.
Esto permite distinguir entre un controlador faltante, un cable defectuoso, un sistema de archivos no compatible o un problema de asignación del contenedor.
Preguntas frecuentes sobre la resolución de problemas de hardware en Linux
¿Qué debería ejecutar primero para una tarjeta PCIe desconocida?
lspci es la comprobación de solo lectura más rápida para verificar que el subsistema PCI lo detecta.
¿Qué es más útil para obtener los ID de proveedor y producto USB?
lsusb.
¿Puedo aplicar en ZimaOS las suposiciones de la guía sobre los paquetes de Debian?
No. Conserva los conceptos de diagnóstico, pero sigue las reglas específicas de extensiones y controladores de ZimaOS.
