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.