2017-10-30 - By Robert Elder
This article will focus on providing an overview of various Linux commands and tips that can be used to debug hardware issues on your computer. Since this article is targeted at beginners we won't go into a lot of depth on each subject. Therefore, it's worth noting that you can do much more with each of these tools than what is described here.
Some of the topics that are introduced include: Modules, Drivers, The GRUB Bootloader, hard disk mounting, init processes, kernel logs, and various other debugging commands.
WARNING: A number of ideas discussed in this article reference commands that could lead to loss of data if you don't use them properly. If you're a beginner, please exercise caution when using any commands that make use of the bootloader, hard disk formatting, partitioning etc.
Sometimes you'll want to view a list of the hardware that is currently in your computer. Each of the following commands can be used to obtain lots of detailed information about your hardware. Each command should remind you of the 'ls' command that list files. For example, 'lspci' is used to list information about PCI devices, 'lsblk' is used to list block devices, 'lscpu' is used to list CPUs, 'lshw' lists general hardware information, 'lsusb' lists information on USB devices and 'lsscsi' lists information on SCSI devices.
lspci lsblk lscpu lshw lsusb lsscsi
Note that the output you get from the above commands will only contain your hardware if it is properly detected. There are various problems that can cause hardware to not be detected. In addition, hardware can sometimes also be misidentified as hardware from a different vendor.
Here's another variant of the 'lspci' command above that will be more verbose and print additional information including driver and module names associated with devices:
Finally, you can also use this command which prints out more information than you can probably handle:
One good reason to use this command would be to run it and pipe the results to a file where they could be sent to someone else for a bug report. This would let them review whatever details they need in order to debug a problem with someone else's hardware.
hwinfo > /tmp/my_report
If you're not using systemd, you'll see something like 'command not found'. If you are you'll probably see something like this:
The above output shows the status of a number of services that were launched through systemd.
Since your init process is the first thing that starts after you boot the kernel, it is involved with launching a number of services, some of which will interact directly with your hardware. Therefore, if you're trying to debug something that seems like a hardware issue, it's probably a good idea to examine the status of each service that was launched by your init process to make sure it is functioning properly.
You can use this command:
to show you any recent kernel diagnostic messages. Here is an example of some random messages that I see currently on my laptop (a bunch of stuff is broken that I haven't gotten around to looking into):
[ 5.004764] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC898: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:hp [ 5.004767] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 5.004768] snd_hda_codec_realtek hdaudioC0D0: hp_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 5.004769] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 [ 6.441596] iwlwifi 0000:02:00.0: L1 Disabled - LTR Enabled [ 8.006288] nvidia-modeset: Allocated GPU:0 (GPU-62bd1-7d-df-72-4250bb4) @ PCI:0000:01:00.0 [ 8.006385] nvidia-modeset: Freed GPU:0 (GPU-62bd1-7d-df-72-4250bb4) @ PCI:0000:01:00.0 [ 8.656307] vgaarb: this pci device is not a vga device [ 9.468958] [drm:intel_dp_link_training_clock_recovery [i915_bpo]] *ERROR* failed to enable link training [ 9.477564] [drm:intel_dp_start_link_train [i915_bpo]] *ERROR* failed to start channel equalization [ 9.564666] [drm:intel_dp_check_link_status [i915_bpo]] *ERROR* Failed to get link status [ 10.872948] [drm:intel_dp_link_training_clock_recovery [i915_bpo]] *ERROR* failed to enable link training [ 10.881531] [drm:intel_dp_start_link_train [i915_bpo]] *ERROR* failed to start channel equalization
These messages represent yet another source of information you can use to debug problems related to hardware. Often hardware problems that are detected by the kernel after booting up are added to the output of the dmesg command.
Boot Sequence Debugging
When your computer is booting up, a log of everything that happens is kept in /var/log/kern.log. Here is an example of stuff that I see in my kernel log right now:
Oct 22 09:18:02 ubuntu kernel: [ 0.000000] Linux version 4.4.0-97-generic (buildd@lcy01-33) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #120-Ubuntu SMP Tue Sep 19 17:38:18 UTC 2017 (Ubuntu 4.4.0-97.120-generic 4.4.87) Oct 22 09:18:02 ubuntu kernel: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-99-generic root=UUID=037c-947f-41ca-b00-f415be3e2 ro pci=nomsi Oct 22 09:18:02 ubuntu kernel: [ 0.000000] KERNEL supported cpus: Oct 22 09:18:02 ubuntu kernel: [ 0.000000] Intel GenuineIntel Oct 22 09:18:02 ubuntu kernel: [ 0.000000] AMD AuthenticAMD Oct 22 09:18:02 ubuntu kernel: [ 0.000000] Centaur CentaurHauls Oct 22 09:18:02 ubuntu kernel: [ 0.000000] x86/fpu: xstate_offset: 576, xstate_sizes: 256 Oct 22 09:18:02 ubuntu kernel: [ 0.000000] x86/fpu: xstate_offset: 960, xstate_sizes: 64 Oct 22 09:18:02 ubuntu kernel: [ 0.000000] x86/fpu: xstate_offset: 1024, xstate_sizes: 64 ... Oct 22 09:18:02 ubuntu kernel: [ 0.021723] ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20150930/psobject-227) Oct 22 09:18:02 ubuntu kernel: [ 0.021959] ACPI Exception: AE_NOT_FOUND, (SSDT:xh_rvp11) while loading table (20150930/tbxfload-193) Oct 22 09:18:02 ubuntu kernel: [ 0.031695] ACPI Error: 1 table load failures, 9 successful (20150930/tbxfload-214) Oct 22 09:18:02 ubuntu kernel: [ 0.032138] Security Framework initialized
If you ever have problems with any of your hardware devices in Linux, it's a good idea to review the contents of this log file to see if there are any error messages related to the device you're having problems with. This log is very verbose and in practice you'll often see some error messages or warnings that don't necessarily require that you do anything about them.
In addition to the kernel log, it can also be useful to change your GRUB settings so that you can see kernel messages on the screen as your computer tries to boot up. This can be done by making sure that the 'quiet' and 'splash' settings are removed from your GRUB configuration. This will be discussed in more detail later in this article.
Drivers And Modules
If you spend any amount of time debugging hardware devices on your Linux machine, you'll eventually encounter the concept of drivers and modules. The difference between drivers and modules is a bit confusing and not well defined, but I'll give a shot at describing the difference between the two:
A driver is just any piece of code that takes care of the low-level interfacing with the specific hardware device you need to interface with. Drivers may or may not need to operate in a highly privileged mode to execute special hardware-specific instructions, or they may do any number of low level operations that interact with your hard drive, keyboard, video card etc.
A Linux kernel module is a package of code that can be added and removed from the kernel at run time. Often, but not always, a Linux kernel module is actually a driver. Therefore if you're just a beginner at Linux, it's probably OK, to suggest that 'modules and drivers are the same thing'. As you learn more, you'll become more aware of their differences. Here is a discussion that talks more about the difference between Linux kernel modules and drivers.
You can use the command
to show verbose information about your devices. This output will list the kernel modules that can be used with each device, and it will also list the current driver that is in use for each device if applicable.
If you want to see all possible kernel modules that exist on your system, you can use this command:
The above command will list all modules that are available, including those that are not actually loaded.
You can also see module information viewing the contents of '/proc/modules':
If you want to see where the Linux kernel modules are stored on disk, you can check '/lib/modules'. This folder will contain folders for each version of the kernel. If your machine has been through a lot of kernel updates, then you'll probably see many folders here.
For example, here is a command that will show me all modules that were enabled with my kernel version 4.4.0-97:
find /lib/modules/4.4.0-97-generic/ | egrep "*.ko"
Note that you'll probably have to replace '4.4.0-97-generic' with something else unless you have that kernel version. Here is a sample of the output that I see from this command:
... /lib/modules/4.4.0-97-generic/kernel/lib/lz4/lz4_compress.ko /lib/modules/4.4.0-97-generic/kernel/lib/lz4/lz4hc_compress.ko /lib/modules/4.4.0-97-generic/kernel/lib/test_firmware.ko /lib/modules/4.4.0-97-generic/kernel/lib/lru_cache.ko /lib/modules/4.4.0-97-generic/kernel/lib/libcrc32c.ko /lib/modules/4.4.0-97-generic/kernel/lib/crc-itu-t.ko ...
If you want to learn information about a specific kernel module, you can use the 'modinfo' command with a module name as an argument. For example, let's learn more about a module called 'nvidiafb' that I see in the output of the 'lspci -v' command:
Here is the result I see from the above command:
filename: /lib/modules/4.4.0-97-generic/kernel/drivers/video/fbdev/nvidia/nvidiafb.ko license: GPL description: Framebuffer driver for nVidia graphics chipset author: Antonino Daplas srcversion: 258EB68CBB3428 alias: pci:v000010DEd*sv*sd*bc03sc*i* depends: vgastate,i2c-algo-bit,fb_ddc intree: Y vermagic: 4.4.0-97-generic SMP mod_unload modversions parm: flatpanel:Enables experimental flat panel support for some chipsets. (0=disabled, 1=enabled, -1=autodetect) (default=-1) (int) parm: fpdither:Enables dithering of flat panel for 6 bits panels. (0=disabled, 1=enabled, -1=autodetect) (default=-1) (int) parm: hwcur:Enables hardware cursor implementation. (0 or 1=enabled) (default=0) (int) ...
Finally, it is also useful to know that you can add and remove modules at run time using the 'modprobe' command. For more information, run:
The '/dev' directory is special in that it contains file-like representations of many devices in your system. If you run the following command:
ls -latr /dev
you will see something like the following:
... brw-rw---- 1 root disk 8, 16 Oct 28 10:31 sdb crw-rw-rw- 1 root root 1, 8 Oct 28 10:31 random crw-rw-rw- 1 root root 1, 3 Oct 28 10:31 null crw-rw-rw- 1 root root 1, 5 Oct 28 10:31 zero crw-rw-rw- 1 root root 1, 9 Oct 28 10:31 urandom crw--w---- 1 root tty 4, 31 Oct 28 10:31 tty31 crw--w---- 1 root tty 4, 30 Oct 28 10:31 tty30 crw--w---- 1 root tty 4, 60 Oct 28 10:31 tty60 crw--w---- 1 root tty 4, 6 Oct 28 10:31 tty6 crw------- 1 root root 89, 7 Oct 28 10:31 i2c-7 crw-rw-rw- 1 root root 195, 254 Oct 28 10:31 nvidia-modeset crw------- 1 root root 5, 1 Oct 28 10:32 console ...
each of these lines represents a 'file' that can be interacted with in many of the same ways as a normal file could be (with some exceptions). For example, there is a special 'device' that can be used to generate random numbers. You can read from this device just like you would read from any file with the following command:
xxd /dev/urandom | head -n 3
and the result of this command is:
00000000: efc7 1226 97e2 924d 4ceb 2d34 350a 4bf5 ...&...ML.-45.K. 00000010: 3222 cd8e 4b41 1bda 0b57 1719 f65e 59b2 2"..KA...W...^Y. 00000020: 3516 f199 a137 bb09 dc1c d1e4 8704 6f20 5....7........o
You could even use techniques like this to open your entire hard disk as a file (often as '/dev/sda' or '/dev/sdb') and write to it. However, if you do this you'll need root permissions, and you'd better know what you're doing otherwise you're likely to make your system unbootable!
Something else you should take notice of from the command above is the major and minor numbers:
crw--w---- 1 root tty 4, 60 Oct 28 10:31 tty60 crw-rw-rw- 1 root root 195, 254 Oct 28 10:31 nvidia-modeset crw------- 1 root root 5, 1 Oct 28 10:32 console
These major and minor numbers appear where you would otherwise see a number to indicate file size for a regular file. Generally, each major number identifies the driver associated with that device. One driver can control multiple devices, each of which will be assigned a different minor number. Here is a link with a few more details on major and minor numbers. Also note that the 'c' in the above output indicates that the device is a character device (and not a block device).
You can often go the other way and start with the major minor number pairs and get the device names using information located in '/sys/dev/block/' or '/sys/dev/char/' depending on whether the device is a block or character device. For example, we previously saw that on my machine the device 'console' had major number 5 and minor number 1. If I run the following command:
the result on my machine is:
MAJOR=5 MINOR=1 DEVNAME=console
which includes the original device name that was found in '/dev'.
Knowledge of these major and minor numbers is relevant in understanding how devices 'appear' in '/dev' after you plug them in. Modern Linux uses something called 'udev' to manage how devices are detected and how the actual device nodes get created and added in '/dev'. Here is a link that describes more about how udev works and what it does.
One of the commands that I use very frequently to check my IP address or connectivity is:
ip addr show
On my machine this command gives me:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether d8:38:8a:10:2f:49 brd ff:ff:ff:ff:ff:ff inet 169.254.9.73/16 brd 169.254.255.255 scope link enp3s0:avahi valid_lft forever preferred_lft forever 3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 33:2b:ff:14:99:cf brd ff:ff:ff:ff:ff:ff inet 192.168.0.165/24 brd 192.168.0.255 scope global dynamic wlp2s0 valid_lft 577314sec preferred_lft 577314sec inet6 f8e0::6333:1180:87ea:ffc1/64 scope link valid_lft forever preferred_lft forever
In the above output, the 'enp3s0' device is the ethernet network interface (where the blue internet cable thingy plugs in). Since I don't have an ethernet cable plugged in that is connected to my router, there is no IP address associated with the ethernet interface. The 'wlp2s0' device is my wireless network interface. I am currently connected to the router over WIFI though, and you can see that the router assigned my computer IP 192.168.0.165 on the local area network. The 'lo' device is the loopback interface.
There are a number of other useful things you can see from using the 'ip' command, but I won't cover them here. It should be noted that there is an older command known as 'ifconfig' that does a similar function but ifconfig is actually deprecated and you're better off using the 'ip' command which is more powerful.
Another useful command that you can use to list out all the nearby WiFi networks is:
sudo iw dev wlan0 scan
In the above command you need to replace 'wlan0' with the name of your WiFi Device. For me, I need to type:
sudo iw dev wlp2s0 scan
If you just want to see the names of the WiFi networks you can pipe the output through grep:
sudo iw dev wlan0 scan | grep SSID
The 'ping' command can be used to determine the latency and reachability between you and another computer. This can be extremely useful when debugging which piece of networking hardware is not working:
ping 127.0.0.1 # If this fails then networking on your local computer is broke ping 192.168.0.1 # If this fails then your computer isn't able to talk to your local router (assuming router IP is 192.168.0.1) ping 126.96.36.199 # If this fails your computer doesn't have any direct or indirect connection to the internet (188.8.131.52 is a Google DNS server).
Normally, the output of ping will look something like this:
PING 184.108.40.206 (220.127.116.11) 56(84) bytes of data. 64 bytes from 18.104.22.168: icmp_seq=1 ttl=59 time=25.4 ms 64 bytes from 22.214.171.124: icmp_seq=2 ttl=59 time=24.0 ms 64 bytes from 126.96.36.199: icmp_seq=3 ttl=59 time=21.5 ms 64 bytes from 188.8.131.52: icmp_seq=4 ttl=59 time=28.2 ms 64 bytes from 184.108.40.206: icmp_seq=5 ttl=59 time=16.5 ms ^C --- 220.127.116.11 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 16.568/23.182/28.257/3.946 ms
If your connection to the IP you're pinging is broke you might see something like this:
PING 18.104.22.168 (22.214.171.124) 56(84) bytes of data. From 169.254.9.73 icmp_seq=1 Destination Host Unreachable From 169.254.9.73 icmp_seq=2 Destination Host Unreachable From 169.254.9.73 icmp_seq=3 Destination Host Unreachable From 169.254.9.73 icmp_seq=4 Destination Host Unreachable From 169.254.9.73 icmp_seq=5 Destination Host Unreachable From 169.254.9.73 icmp_seq=6 Destination Host Unreachable ^C --- 126.96.36.199 ping statistics --- 7 packets transmitted, 0 received, +6 errors, 100% packet loss, time 6025ms
A great tool for determining what ports are open on your local machine (or a remote machine) is nmap:
This tool can be used to identify what ports and services are open on a particular machine. Here is a command to scan for open ports on your own computer:
and here are the results:
Starting Nmap 6.40 ( http://nmap.org ) at 2017-10-29 17:27 EDT Nmap scan report for localhost (127.0.0.1) Host is up (0.00010s latency). Not shown: 998 closed ports PORT STATE SERVICE 80/tcp open http 631/tcp open ipp Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds
The above output shows that there are only two open ports visible on a simple scan: port 80 where a web server is hosted, and port 631 where a remote printing daemon is hosted.
Another useful command is traceroute which will show you all of the computers between you and another computer over a network such as the internet. This is useful because it can tell you what hardware a message from your computer has to pass through in order to get to its destination. Here is an example of performing a traceroute to Google's DNS server:
and here are the results:
traceroute to 188.8.131.52 (184.108.40.206), 30 hops max, 60 byte packets 1 220.127.116.11 (18.104.22.168) 11.900 ms 22.214.171.124 (126.96.36.199) 11.849 ms 188.8.131.52 (184.108.40.206) 19.325 ms 2 100.66.8.230 (100.66.8.230) 14.864 ms 100.66.12.46 (100.66.12.46) 21.087 ms 100.66.8.68 (100.66.8.68) 15.428 ms 3 100.66.14.38 (100.66.14.38) 16.412 ms 100.66.11.142 (100.66.11.142) 17.507 ms 100.66.10.46 (100.66.10.46) 12.613 ms 4 100.66.6.9 (100.66.6.9) 17.466 ms 100.66.6.29 (100.66.6.29) 49.260 ms 100.66.7.141 (100.66.7.141) 17.693 ms 5 100.66.4.61 (100.66.4.61) 19.457 ms 100.66.4.19 (100.66.4.19) 19.761 ms 100.66.4.53 (100.66.4.53) 18.131 ms 6 100.65.10.65 (100.65.10.65) 0.533 ms 100.65.9.129 (100.65.9.129) 0.450 ms 100.65.11.1 (100.65.11.1) 0.387 ms 7 220.127.116.11 (18.104.22.168) 1.776 ms 22.214.171.124 (126.96.36.199) 29.803 ms 188.8.131.52 (184.108.40.206) 1.356 ms 8 220.127.116.11 (18.104.22.168) 1.301 ms 22.214.171.124 (126.96.36.199) 2.078 ms 188.8.131.52 (184.108.40.206) 17.698 ms 9 220.127.116.11 (18.104.22.168) 1.349 ms 16.498 ms 22.214.171.124 (126.96.36.199) 25.445 ms 10 188.8.131.52 (184.108.40.206) 1.407 ms 220.127.116.11 (18.104.22.168) 1.962 ms 22.214.171.124 (126.96.36.199) 1.653 ms 11 188.8.131.52 (184.108.40.206) 1.514 ms 220.127.116.11 (18.104.22.168) 1.279 ms 1.278 ms 12 * * * 13 22.214.171.124 (126.96.36.199) 1.571 ms google-public-dns-a.google.com (188.8.131.52) 1.375 ms 184.108.40.206 (220.127.116.11) 1.855 ms
A common thing to do is check if any of your hard disks are full. You can do that with the 'df' command:
Here's the result on my machine:
Filesystem 1K-blocks Used Available Use% Mounted on udev 8141388 0 8141388 0% /dev tmpfs 1633448 9672 1623776 1% /run /dev/sdb1 122940436 65279988 51392392 56% / tmpfs 8167224 71884 8095340 1% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 8167224 0 8167224 0% /sys/fs/cgroup /dev/sdc2 942078208 252939556 641260732 29% /mnt tmpfs 1633448 60 1633388 1% /run/user/1000
The above command shows how to check the amount of space used for files, but a common problem is to have older kernel version take up a lot of inodes, and in this case you can have 'disk full' errors on /boot when you try to upgrade (this happens often in Ubuntu). In these cases you might see that your disk space is well under 100% when using 'df', but you should also use:
to show inode usage. Older kernel headers will often take up many inodes but not much space since they're mostly thousands of small files that each require an inode.
Filesystem Inodes IUsed IFree IUse% Mounted on udev 2035347 553 2034794 1% /dev tmpfs 2041806 886 2040920 1% /run /dev/sda1 7815168 626440 7188728 9% / tmpfs 2041806 87 2041719 1% /dev/shm tmpfs 2041806 9 2041797 1% /run/lock tmpfs 2041806 16 2041790 1% /sys/fs/cgroup /dev/sdb2 59834368 796290 59038078 2% /mnt tmpfs 2041806 30 2041776 1% /run/user/1000
There is a program called 'fdisk' that is used for formatting and partitioning disks that I often find myself using to list out all disks and partitions even if they're not mounted. Note: Be very careful to make sure you know what you're doing when you run fdisk because you can easily re-format your disk and destroy data if you don't pay attention! Here is a non-destructive command that will list all disks and partitions:
sudo fdisk -l
Of course, as mentioned before you can use fdisk to format disks and create various types of partitions: swap, bootable, non-bootable etc.
Once you have properly formatted your hard disk and created a partition, you can use the 'mke2fs' command to create a filesystem on the partition.
If you ever find yourself trying to get an existing partition to show up automatically at boot, you'll need to know about the '/etc/fstab' file. Here is mine:
# /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda1 during installation UUID=037d5ae-97f-4ca-b00-fbe3415e2 / ext4 errors=remount-ro 0 1 UUID=c04d9c5-d2a-4fd-8e7-5d9535f3c /mnt ext4 errors=remount-ro 0 2 # swap was on /dev/sdb1 during installation UUID=fda32f0-7da-492-d4c-fefd11d46 none swap sw 0 0
This file contains information that associates the hardware automatically with a mount point during the boot process. There are various different versions of the syntax for this file that you can look up online. If you change this file, be careful to not make mistakes, otherwise you may end up causing the boot process to fail.
If you don't add an entry to '/etc/fstab' to mount a partition at boot time, you'll need to do so manually with the 'mount' command. You can also un-mount with the 'umount' command. Note that the command is spelled umount and NOT unmount.
It is possible that when you try to unmount it you'll get an error that says 'device is busy'. You can run the command
where '/path/of/mount/directory' is the directory where the partition is mounted (this directory is visible in the output of the 'df' command). After you run this command, you'll be presented with a list of applications that are using the device and causing it to be busy. Often, I'll get the 'device is busy' message when I leave a shell open in a directory that is located on the device in question.
If you ever need to find the size of files on a disk, you can use this command:
du -k /some/directory
You can also pipe this into sort to find the largest files:
du -k /some/directory | sort -n
Finally, there is also a command-line program called fsck that you can use to check for filesystem consistency.
Here is a command to check free:
and this is the result on my machine:
total used free shared buff/cache available Mem: 15951 1942 11694 80 2315 13528 Swap: 19072 0 19072
You can also check the contents of '/proc/meminfo:
and this is the result on my machine:
MemTotal: 16334452 kB MemFree: 11854128 kB MemAvailable: 13777136 kB Buffers: 514872 kB Cached: 1583972 kB SwapCached: 0 kB Active: 3021376 kB Inactive: 935736 kB ... Dirty: 236 kB Writeback: 0 kB AnonPages: 1846112 kB Mapped: 535156 kB Shmem: 87032 kB Slab: 322700 kB SReclaimable: 256268 kB SUnreclaim: 66432 kB KernelStack: 10432 kB PageTables: 46096 kB NFS_Unstable: 0 kB ... Hugepagesize: 2048 kB DirectMap4k: 264920 kB DirectMap2M: 6977536 kB DirectMap1G: 10485760 kB
The output from '/proc/meminfo' is a bit more detailed and show a number of metrics that dive deep into the performance of virtual memory on your machine.
If you want to know what CPU you have, you can do:
Here is part of the result on my machine:
processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz stepping : 3 microcode : 0x84 cpu MHz : 2154.140 cache size : 6144 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes flags : fpu vme ....... hwp_epp
Note that you'll get what looks like repeated results if you have a multi-core processor. Each result represents one of the cores.
There are a few circumstances where checking for your processor model number like this can be very useful. One such case is a situation where a piece of software was giving me an 'illegal' instruction error, but only on some EC2 instances, even when the EC2 instances where all of the same type!
Here is a command you can use to list all sound capture devices:
Here is a command you can use to list all PCI devices that contain the word 'audio':
lspci | grep -i audio
If you have alsa-utils installed you can list all devices that aplay knows about:
Another useful option is to list all Linux kernel modules that contain the letters 'snd':
lsmod | grep snd
You can often use the following command to list out your video devices:
lspci | egrep -i "3d|vga"
Although, in some cases you may have to look through the full output of 'lspci' to find your video device.
If you ever try to boot up your Linux system and you only see a black screen, the first thing you should do is try:
CTRL + ALT + F6
Running the above command will change your virtual terminal to VT 6 where you should see a prompt that will let you log in and manage the system through the command-line. By default, your graphical interface is displayed on VT 7, and by switching to any of VT 1,2,3,4,5,6 you can access a terminal session even if your graphical session is not working.
If you ever do get into one of these situations with a broken graphical session, you should probably check the log file in '/var/log/kern.log'. You should also check the logs of your XOrg server which can be in various places, usually somewhere in your home directory in a hidden directory, or possibly in '/var/log/'. See the Arch Wiki documentation on XOrg for more details.
Finally, another potential source of video problems can be related to configurations found in GRUB. For more details on this, check the next session.
Understanding what GRUB is and what it does can be very helpful when debugging hardware problems with Linux. GRUB is a bootloader which means that it runs before any part of the operating system runs. GRUB can also define various settings that can influence the way that your computer interacts with the hardware. For example, a few common settings you might want to configure yourself are the 'nomodeset', 'splash' and 'quiet' options that were mentioned above.
The 'nomodeset' option controls whether certain graphical display options (such as screen resolution, colours, etc) are handled inside the Linux kernel itself, or externally inside a video driver. Depending on whether you enable kernel mode setting or not, this can affect the functionality of any rich graphical displays. This option is important for debugging because disabling kernel mode setting may or may not lead to better results.
The 'quiet' option controls whether certain useful information about the success (or failure) of the boot process and kernel loading is printed to the screen. Here is an example of what this information looks like:
The 'splash' option controls whether you see the 'splash' screen or not. The splash screen is the part of the boot process where you might be presented with a nicely polished logo of the computer's distributor, or the OS distribution logo. Non-technical users would usually prefer this screen over seeing all the technical information that gets printed with the 'quiet' option is not present. You can read more about nomodeset, quiet and splash here. The following link will provide you with more information on how to change these boot options. Be careful! If you mess up your grub configuration, you might not be able to boot back into your OS!
In this article, we've reviewed a few commands and files that can be useful for debugging hardware-related issues in Linux. Most of what we've discussed here only scratches the surface. Most of the details and options of the commands mentioned here have been omitted to prevent this article from getting too long. Hopefully you've found some useful topics for further study!