The dmesg command is often used to determine whether specific device drivers, for network interfaces and mass storage devices, have been correctly loaded at boot time.
While its functions have largely been taken over by the syslog daemon (syslogd), dmesg provides a useful record of error and status messages printed by the kernel.
When the system boots, several status messages of log level kern.notice will be recorded, and can be subsequently retrieved by using dmesg:
May 15 14:23:16 austin genunix: [ID 540533 kern.notice] SunOS Release 5.9 Version Generic_112233-01 64-bit May 15 14:23:16 austin genunix: [ID 784649 kern.notice] Copyright 1983-2000 Sun Microsystems, Inc. All rights reserved. May 15 14:23:16 austin genunix: [ID 678236 kern.info] Ethernet address = 0:3:ba:4:a4:e8 May 15 14:23:16 austin unix: [ID 389951 kern.info] mem = 131072K (0x8000000) May 15 14:23:16 austin unix: [ID 930857 kern.info] avail mem = 121085952
Here, we can see that a 64-bit kernel has been loaded successfully, for SunOS 5.9 (Solaris 9). Sun’s copyright banner is also recorded, along with the Ethernet address of the primary network interface card (0:3:ba:4:a4:e8), the amount of installed RAM, and the amount of currently available RAM after the kernel has been loaded.
Before the kernel begins loading device drivers, it performs an integrity check to determine if any naming conflicts exist. If a conflict is found, it is logged for future reference and action:
May 15 14:23:16 austin genunix: [ID 723599 kern.warning] WARNING: Driver alias "cal" conflicts with an existing driver name or alias.
Here, we can see that the device driver alias “cal” has been used more than once, giving rise to a naming conflict. Next, details about the system architecture and its main bus type are displayed:
May 15 14:23:16 austin rootnex: [ID 466748 kern.info] root nexus = Sun Blade 100 (UltraSPARC-IIe) May 15 14:23:16 austin rootnex: [ID 349649 kern.info] pcipsy0 at root: UPA 0x1f 0x0 May 15 14:23:16 austin genunix: [ID 936769 kern.info] pcipsy0 is /pci@1f,0 May 15 14:23:16 austin pcipsy: [ID 370704 kern.info] PCI-device: pmu@3, pmubus0 May 15 14:23:16 austin pcipsy: [ID 370704 kern.info] PCI-device: ppm@0, grppm0 May 15 14:23:16 austin genunix: [ID 936769 kern.info] grppm0 is /pci@1f,0/pmu@3/ppm@0
Here, we can see that the system is a Sun Blade 100, and that its PCI bus architecture has been correctly identified. The next stage involves identifying the hard drives attached to the system, as follows:
May 15 14:23:27 austin pcipsy: [ID 370704 kern.info] PCI-device: ide@d, uata0 May 15 14:23:27 austin genunix: [ID 936769 kern.info] uata0 is /pci@1f,0/ide@d May 15 14:23:28 austin uata: [ID 114370 kern.info] dad0 at pci10b9,52290 May 15 14:23:28 austin uata: [ID 347839 kern.info] target 0 lun 0 May 15 14:23:28 austin genunix: [ID 936769 kern.info] dad0 is /pci@1f,0/ide@d/dad@0,0 May 15 14:23:28 austin dada: [ID 365881 kern.info] <<ST315320A cyl 29649 alt 2 hd 16 sec 63>> May 15 14:23:29 austin swapgeneric: [ID 308332 kern.info] root on /pci@1f,0/ide@d/disk@0,0:a fstype ufs
The IDE hard drive installed on the system has been correctly detected (/pci@1f,0/ide@d/dad@0,0), and has the label “ST315320A cyl 29649 alt 2 hd 16 sec 63.” In addition, the file system type has been identified as native UFS.
The status of every device on the system is logged during device driver loading, so it’s possible to use the dmesg command to determine whether drivers have been correctly loaded. In the following entry, the FDDI interface cannot be activated because it is not correctly installed:
May 15 14:26:38 austin smt: [ID 272566 kern.notice] smt0: nf FDDI driver is not active. Initialization of this driver cannot be completed.