This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)(Learn how and when to remove this template message)
This section contains instructions, advice, or how-to content. (August 2020)
On many Unix-like systems, the boot process generates a particularly dense stream of kernel messages. Many administrative issues pertain to whether a desired hardware device is successfully enumerated during the boot process, so the diagnostic process for a failed device often begins by inspecting the dmesg output from the kernel identification message to the point where the boot process concludes. Since this buffer can be overwritten by a flood of messages in subsequent operation, many Unix-like distributions store a post-boot copy of the message buffer at /var/log/dmesg or similar secure system location.
It is also common to manually consult the current dmesg buffer after hot-plugging devices, particularly USB devices (especially thumb drives), to determine whether the device has been recognized, the data rate of the port involved (USB 2 and USB 3.0 plugs sit side by side and are hard to distinguish on many systems), what driver has been assigned, and where the device is made visible in the file system. Many distributions attempt to display device-recognition messages on the desktop, often through a taskbar pop-up, but this is not always reliable or the information presented is incomplete. (Furthermore, to be notified on the desktop, the hot-plugged device must be permitted by the system's security policy.)
Many dmesg lines in a traditional system begin with a device name followed by a colon, followed by some detailed text. Often these come in clusters, with the same device showing up on multiple lines in succession. Each cluster is usually associated with a single device enumeration, by one particular device driver (or device facility) associated with the device name.
Each such driver or facility emits diagnostic information in its own chosen format, and generally includes all of the most important technical details, in a dense and arcane notation. The manual page associated with the device driver will sometimes document the message format. For example, device name da0 (SCSI direct access 0) is a commonly seen device name associated with USB thumb drives. man da at the command line—without the trailing number—will bring up documentation for this driver class on many systems. Even if the precise format of the lines written to the system buffer are not described here, the parameters of interest are usually defined, though you might need to further peruse related manual pages (listed at the bottom of a traditional man page) for a complete overview spanning various hardware abstraction layers.
When initially booted, a computer system loads its kernel into memory. At this stage device drivers present in the kernel are set up to drive relevant hardware. Such drivers, as well as other elements within the kernel, may produce output ("messages") reporting both the presence of modules and the values of any parameters adopted. (It may be possible to specify boot parameters which control the level of detail in the messages.) The booting process typically happens at a speed where individual messages scroll off the top of the screen before an operator can read/digest them. (Some keyboard keys may pause the screen output.) The dmesg command allows the review of such messages in a controlled manner after the system has started.
Even after the system has fully booted, the kernel may occasionally produce further diagnostic messages. Common examples of when this might happen are when I/O devices encounter errors, or USB devices are hot-plugged. dmesg provides a mechanism to review these messages at a later time. When first produced they will be directed to the system console: if the console is in use then these messages may be confused with or quickly overwritten by the output of user programs.
The output of dmesg can amount to many complete screens. For this reason, this output is normally reviewed using standard text-manipulation tools such as more, tail, less or grep. The output is often captured in a permanent system logfile via a logging daemon, such as syslog.
- lspci, detailed information about all PCI buses and devices in the system
- lsusb, detailed information about USB ports and devices
- uname prints the name, version and other details about the current machine and the operating system
- List of Unix commands
- udev — Linux device manager, with some control over device visibility
- DMESG(8) (Research Unix 8th ed.). Bell Labs. 1985. Retrieved 2020-02-10.
- Gareth Anderson (15 April 2006). "GNU/Linux Command-Line Tools Summary" (PDF). www.tldp.org. The Linux Documentation Project. p. 32. Archived from the original (PDF) on 23 November 2016. Retrieved 29 May 2017.
- Mendel Cooper (5 April 2012). "Advanced Bash-Scripting Guide" (PDF). www.tldp.org. The Linux Documentation Project. p. 329. Archived from the original (PDF) on 18 May 2017. Retrieved 29 May 2017.