Obteniendo información del hardware con dmesg en Linux

En más de una ocasión he mencionado en este blog el hecho de que la información es poder, y es por ello que los logs cada día cobran más importancia... Generalmente cuando he hablado de logs, éstos han hecho referencia a eventos relacionados con ciertos servicios del sistema o con alguna conexión de red ¿Pero que pasaría si deseásemos buscar información y/o eventos relacionados con el hardware? Visitando los logs más habituales como podrían ser /var/log/syslog veremos que no siempre hay información, pues el syslog generalmente únicamente muestra los mensajes de error más críticos relacionados con el kernel, pero nada referente a errores "menores"; con lo que... ¿Donde podemos encontrar la tan ansiada información? Es aquí donde entra en juego un comando de gran relevancia y que en muchos casos es olvidado: dmesg.

Dmesg está diseñado principalmente para escribir los mensajes recibidos desde el kernel en un formato de salida legible para los humanos... El kernel es lo primero que se carga en el sistema operativo pues el núcleo que comunica el hardware con el software... Tras esto arrancaría el init (Sys V, systemd, etc...) e irían los siguientes procesos, pero el kernel siempre sería lo primero en arrancar. Obviamente dicho arranque deja ciertos mensajes grabados en un lugar llamado ring buffer, desde el cual dmesg extraería la información más adelante...
La información que se podría extraer inicialmente desde dicho buffer estaría relacionada con los mensajes generador por el kernel durante el arranque; cosa que principalmente implicaría la detección del hardware y el arranque de ciertos drivers... Pero eso no quedaría ahí... Cualquier nuevo evento relacionado con hardware como por ejemplo problemas de conexión de nuevos USBs, conexión de puertos COM, etc... También quedaría grabado dentro del buffer, siendo una valiosísima fuente de información, pues podría ayudarnos a depurar problemas de comunicación entre software y hardware.
Los mensajes del kernel se guardan en dos lugares: /var/log/kern.log y en el comando dmesg. El primero tendría todos los mensajes guardados hasta ahora, a excepción de los relacionados con la sesión actual que no se volcarían dentro de dicho fichero hasta reiniciar el sistema. La información más actual se obtendría mediante el comando dmesg, que se podría escribir sin parámetro alguno; es decir que bastaría con hacer:
dmesg
El problema del comando dmesg es que si bien plasma los eventos con bastante precisión, las fechas de dichos eventos no son mostradas de una forma demasiado amigable, pues lo muestra en un formato legible para el kernel, no para los simples mortales... Eso de por sí puede ser un problema, ya que si bien luego más adelante la información guardada en kern.log sí que muestra una fecha legible, el reiniciar el equipo simplemente para tener una fecha legible no es factible; es por eso que lo mejor es optar por un parámetro al que en mi opinión todo el mundo le saca mucho partido llamado -T (Time Stamp). Además, si habéis probado el comando "a pelo" veréis que la cantidad de mensajes mostrados es realmente abrumadora, así que lo más recomendable sería ir mostrando los mensajes progresivamente mediante la ayuda del comando less... Es por ello que el comando dmesg ideal que mezclaría precisión y legibilidad sería:
dmesg-T|less
Si en cambio deseásemos hilar más fino y quisiésemos buscar información más concreta como podrían ser eventos relacionados con los puertos serie o puertos USB, lo ideal sería combinar este comando con nuestro filtro favorito: grep. Gracias a dicho filtro podríamos buscar únicamente las líneas que tuviesen eventos relacionados con USB o con el puerto serie; este último es referenciado en Linux como ttySx.
dmesg-T|grep-i ttyS |less
A partir de aquí uno tendría que ver hasta que punto desea hilar, pero es innegable que este comando nos puede sacar de más de un problema de comunicación con el hardware, además de otros eventos derivados de éste.
Espero que os haya resultado útil.
Saludos.