Códigos de diagnóstico POST de UEFI: guía completa y práctica

Cuando un ordenador o servidor se enciende, lo primero que entra en juego no es el sistema operativo, sino el firmware, es decir, ese pequeño bloque de código que vive en la placa base y que decide si el equipo está listo para arrancar. En equipos modernos, ese papel lo suele desempeñar UEFI, heredero del clásico BIOS, y uno de sus trabajos esenciales es ejecutar el POST (Power-On Self Test), una batería de comprobaciones que, si algo va mal, genera códigos de error, pitidos y mensajes que a menudo suenan a “chino” si no sabes interpretarlos.

Los códigos POST de UEFI son la pista clave para saber qué está fallando: desde un módulo de RAM con problemas hasta una tarjeta gráfica mal colocada, un disco duro dañado o un error de comunicación con el controlador de gestión (BMC, IMM, SP, etc.). Entender qué significan, cómo se registran y qué acciones recomienda cada fabricante (Lenovo, IBM, Dell, Oracle, etc.) es fundamental tanto para técnicos como para usuarios avanzados que quieren diagnosticar su equipo sin perderse en tecnicismos innecesarios.

Qué son UEFI y POST y qué papel juegan al arrancar un equipo

UEFI (Unified Extensible Firmware Interface) es el estándar que ha venido a sustituir al BIOS tradicional en la mayoría de ordenadores y servidores actuales. A diferencia del BIOS clásico, que trabajaba en modo de 16 bits y estaba fuertemente ligado a la ROM de la placa, UEFI puede residir en cualquier memoria no volátil y se ejecuta en modo protegido de 32 o 64 bits, lo que le permite ofrecer más funciones, mejor rendimiento y opciones avanzadas de seguridad.

POST (Power-On Self Test) es la “revisión médica” que el firmware hace al hardware nada más encender el equipo. En esa fase se detectan y se inicializan elementos como el procesador, la memoria RAM, el chipset, la tarjeta gráfica, el teclado, las unidades de disco y otros dispositivos esenciales. Si todo está correcto, el firmware pasa el control al cargador del sistema operativo; si no, genera códigos de error, mensajes en pantalla y patrones de sonidos (pitidos) para indicar qué parte ha fallado.

En el POST se realizan pruebas muy concretas: se comprueba la CPU, se verifica el propio firmware, se lee la configuración guardada en la memoria CMOS, se inicializa el temporizador del sistema (reloj interno), el controlador DMA, se chequean la RAM y la caché, se cargan los módulos del firmware adicionales y se detectan y configuran los periféricos básicos como teclado y dispositivos de almacenamiento.

Si el POST encuentra una anomalía leve, intenta continuar con el arranque, pero en cuanto detecta un error crítico (por ejemplo, que no hay RAM usable, la tarjeta gráfica no responde o la CPU falla), se detiene y muestra alguna de estas señales: un mensaje en pantalla si el subsistema de vídeo funciona, una secuencia de pitidos con un patrón específico y/o códigos POST enviados a puertos internos o registrados en el controlador de gestión del sistema.

Cuando todo está correcto y no hay ningún fallo detectable, muchos firmwares emiten un único pitido corto que, de forma tradicional, se ha interpretado como la confirmación de que el POST ha terminado sin problemas y el equipo va a entregar el control al sistema operativo.

Códigos de diagnóstico POST de UEFI en servidores (IMM, SP, BMC, etc.)

En muchos servidores modernos, los códigos de diagnóstico POST de UEFI no se quedan sólo en mensajes de pantalla o pitidos, sino que se registran de forma detallada en los módulos de gestión integrados. Lenovo, por ejemplo, guarda estos códigos en el registro de sucesos del IMM; otros fabricantes emplean controladores llamados SP o BMC accesibles por interfaces como Oracle ILOM o similares.

Cuando se produce un suceso de POST, las guías de los fabricantes suelen incluir un campo denominado “Respuesta del usuario”. Ahí se describen, paso a paso, las acciones recomendadas para tratar de resolver el problema. La idea es seguir las indicaciones en el orden propuesto y, si después de completar todos los pasos el error persiste, ponerse en contacto con el soporte técnico correspondiente (Lenovo Support, IBM Support, etc.).

Los manuales de UEFI/POST de servidores recopilan listados extensos de códigos de error acompañados de descripciones y posibles causas. Por ejemplo, pueden indicar si el error está relacionado con el subsistema de memoria, el bus PCIe, el controlador de entrada/salida IOH, problemas térmicos, discos duros SAS/SATA, fallos de batería CMOS, errores de contraseña, etc.

Una parte importante del diagnóstico consiste en revisar el registro de eventos del SP o IMM. Allí se pueden encontrar mensajes más detallados que los que salen en pantalla, a menudo con información adicional: puerto o ranura afectada, tipo exacto de error del bus, módulo de memoria implicado, umbrales térmicos superados, e incluso historiales de errores repetitivos que ayudan a identificar componentes intermitentes o a punto de fallar.

En algunos casos, un error POST puede requerir un simple reinicio del controlador de gestión. Por ejemplo, ciertos fallos internos de comunicación entre el firmware principal (BIOS/UEFI) y el SP/BMC pueden generar avisos como “BMC Not Responding”, y la solución recomendada puede ser reiniciar el SP o, si no se resuelve, escalar el caso a soporte para descartar un fallo físico en la placa o en el propio módulo de gestión.

Ejemplos de mensajes POST habituales en servidores UEFI

En entornos de servidor es frecuente encontrar errores asociados al IOH durante el último arranque. Mensajes del estilo “Uncorrectable Error Detected on Last Boot: IOH(0) Protocol Error”, “IOH(0) QPI [x] Error”, “PCI-E [x] Error”, “ESI Error”, “Thermal Error”, “Miscellaneous Error” o “VT-d Error” indican problemas detectados en el concentrador de entrada/salida o en los enlaces que gestiona.

En todos estos casos, la recomendación típica es revisar la función de gestión de fallos y el registro de eventos del SP en Oracle ILOM u otra consola equivalente para obtener más detalles. Dichos registros suelen especificar si se trata de un fallo puntual, de una condición térmica, de un error de enlace QPI, de un problema en un puerto PCIe concreto o de un conflicto con las funciones de virtualización de E/S (VT-d).

Otro mensaje habitual es “Hard disk error” asociado a fallos de SAS o SATA. El firmware suele indicar que se ha producido un error en una unidad de disco y aconseja revisar el log del SP para ver qué bahía, puerto o LUN está dando el problema, así como comprobar el estado de los discos en la controladora correspondiente.

Mensajes como “Bad PBR sig” apuntan a problemas con la tabla de particiones del disco. En estos casos, la causa suele ser una tabla de particiones inexistente o corrupta en la unidad. La solución pasa por re-crear las tablas de particiones con herramientas adecuadas (por ejemplo, las utilidades de formateo de Oracle Solaris o fdisk en Linux) y reinstalar el sistema si es necesario.

En el subsistema de memoria aparecen errores del tipo “RAM R/W test failed”, que indican que la prueba de lectura/escritura de la RAM durante el POST ha fallado. Nuevamente, se recomienda revisar el registro de sucesos del SP para localizar el banco o módulo concreto afectado, y después proceder a la comprobación física de los módulos de memoria (recolocarlos, probarlos de uno en uno o reemplazarlos).

También son relativamente comunes los avisos relacionados con la batería y la configuración de CMOS, tales como “CMOS Battery Low” o errores genéricos de CMOS. Estos mensajes señalan que la batería encargada de alimentar la memoria CMOS —donde se guarda la hora, la fecha y parte de la configuración— está agotada o fallando, y que es conveniente revisar el evento en el SP y, normalmente, sustituir la pila.

En el apartado de seguridad aparecen mensajes como “Password check failed” cuando la verificación de la contraseña configurada en el firmware no supera el control. En un entorno administrado, estos eventos también quedan registrados en el SP/IMM para trazar intentos fallidos de acceso a la configuración del sistema.

Significado de los pitidos POST en BIOS Award y AMI

Además de los códigos en pantalla o en los registros, muchos BIOS siguen utilizando patrones de pitidos para indicar errores, algo especialmente útil cuando el sistema no llega a inicializar el vídeo. La combinación de pitidos cortos y largos permite identificar si el problema está en la RAM, el procesador, el teclado, la gráfica o el propio BIOS.

En sistemas con Award BIOS modernos, los pitidos suelen centrarse en problemas de vídeo. Así, un pitido largo seguido de dos pitidos cortos indica un error en la tarjeta gráfica o en uno de los dispositivos de vídeo; la recomendación es comprobar que la tarjeta está bien asentada en su ranura (PCIe, AGP en equipos antiguos) y probar otra si es posible. Otros patrones suelen apuntar a errores de memoria.

En la tabla de Award BIOS también se detallan combinaciones como un pitido corto (arranque correcto), dos cortos (problema de CMOS solucionable reiniciando la configuración retirando la pila o moviendo el jumper adecuado), un pitido largo y uno corto (problemas en placa base o RAM), un largo y tres cortos (teclado), y así sucesivamente, con recomendaciones que van desde recolocar módulos hasta sustituir componentes.

Los BIOS AMI disponen de una tabla algo más extensa de pitidos numerados. Por ejemplo, un pitido apunta a error de actualización de memoria, dos a error de paridad, tres a fallos en los primeros 64 KB de RAM, cuatro a temporizador del sistema no funcional, cinco al procesador, seis a la puerta A20, ocho a errores de lectura/escritura en la RAM de vídeo, nueve a suma de comprobación de ROM incorrecta, diez a problemas en el registro de cierre de CMOS y once a fallos en la caché.

La forma de actuar suele ser similar en la mayoría de casos: recolocar módulos, probar con otro componente o, si el problema apunta a placa base o BIOS, enviarla a reparar o actualizar el chip de firmware. Muchos manuales recomiendan también usar gomas de borrar suaves para limpiar los contactos de los módulos de RAM o de las tarjetas gráficas cuando la sospecha es un mal contacto por suciedad u oxidación.

En la práctica, se pueden distinguir dos “familias” de pitidos bastante fáciles de reconocer: los continuos, cortos o largos y repetitivos, suelen señalar problemas de RAM o de fuente de alimentación; mientras que secuencias melódicas no repetitivas tienden a indicar fallos de tarjeta gráfica u otros dispositivos concretos. Entender ese patrón ayuda a ir directo al componente sospechoso.