{"id":7081,"date":"2019-01-02T08:19:41","date_gmt":"2019-01-02T08:19:41","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw92\/?p=7081"},"modified":"2019-01-08T10:55:05","modified_gmt":"2019-01-08T10:55:05","slug":"troubleshooting-hardware-problems-in-linux","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw92\/index.php\/2019\/01\/02\/troubleshooting-hardware-problems-in-linux\/","title":{"rendered":"Troubleshooting hardware problems in Linux"},"content":{"rendered":"

Linux servers<\/a> run mission-critical business applications in many different types of infrastructures including physical machines, virtualization, private cloud, public cloud, and hybrid cloud. It’s important for Linux sysadmins to understand how to manage Linux hardware infrastructure\u2014including software-defined functionalities related to networking<\/a>, storage, Linux containers, and multiple tools on Linux servers.<\/p>\n

It can take some time to troubleshoot and solve hardware-related issues on Linux. Even highly experienced sysadmins sometimes spend hours working to solve mysterious hardware and software discrepancies.<\/p>\n

The following tips should make it quicker and easier to troubleshoot hardware in Linux. Many different things can cause problems with Linux hardware; before you start trying to diagnose them, it’s smart to learn about the most common issues and where you’re most likely to find them.<\/p>\n

Quick-diagnosing devices, modules, and drivers<\/h2>\n

The first step in troubleshooting usually is to display a list of the hardware installed on your Linux server. You can obtain detailed information on the hardware using ls commands such as lspci<\/a>, lsblk<\/a>, lscpu<\/a>, and lsscsi<\/a>. For example, here is output of the lsblk command:<\/p>\n

# lsblk
\nNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
\nxvda 202:0 0 50G 0 disk
\n\u251c\u2500xvda1 202:1 0 1M 0 part
\n\u2514\u2500xvda2 202:2 0 50G 0 part \/
\nxvdb 202:16 0 20G 0 disk
\n\u2514\u2500xvdb1 202:17 0 20G 0 part<\/p>\n

If the ls commands don’t reveal any errors, use init processes (e.g., systemd) to see how the Linux server is working. systemd is the most popular init process for bootstrapping user spaces and controlling multiple system processes. For example, here is output of the systemctl status command:<\/p>\n

# systemctl status
\n\u25cf bastion.f347.internal
\nState: running
\nJobs: 0 queued
\nFailed: 0 units
\nSince: Wed 2018-11-28 01:29:05 UTC; 2 days ago
\nCGroup: \/
\n\u251c\u25001 \/usr\/lib\/systemd\/systemd –switched-root –system –deserialize 21
\n\u251c\u2500kubepods.slice
\n\u2502 \u251c\u2500kubepods-pod3881728a_f2af_11e8_af77_06af52f87498.slice
\n\u2502 \u2502 \u251c\u2500docker-88b27385f4bae77bba834fbd60a61d19026bae13d18eb147783ae27819c34967.scope
\n\u2502 \u2502 \u2502 \u2514\u250023860 \/opt\/bridge\/bin\/bridge –public-dir=\/opt\/bridge\/static –config=\/var\/console-config\/console-c
\n\u2502 \u2502 \u2514\u2500docker-a4433f0d523c7e5bc772ee4db1861e4fa56c4e63a2d48f6bc831458c2ce9fd2d.scope
\n\u2502 \u2502 \u2514\u250023639 \/usr\/bin\/pod
\n….<\/p>\n

Digging into multiple loggings<\/h2>\n

Dmesg allows you to figure out errors and warnings in the kernel’s latest messages. For example, here is output of the dmesg | more command:<\/p>\n

# dmesg | more
\n….
\n[ 1539.027419] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
\n[ 1539.042726] IPv6: ADDRCONF(NETDEV_UP): veth61f37018: link is not ready
\n[ 1539.048706] IPv6: ADDRCONF(NETDEV_CHANGE): veth61f37018: link becomes ready
\n[ 1539.055034] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
\n[ 1539.098550] device veth61f37018 entered promiscuous mode
\n[ 1541.450207] device veth61f37018 left promiscuous mode
\n[ 1542.493266] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
\n[ 9965.292788] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
\n[ 9965.449401] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
\n[ 9965.462738] IPv6: ADDRCONF(NETDEV_UP): vetheacc333c: link is not ready
\n[ 9965.468942] IPv6: ADDRCONF(NETDEV_CHANGE): vetheacc333c: link becomes ready
\n….<\/p>\n

You can also look at all Linux system logs in the \/var\/log\/messages file, which is where you’ll find errors related to specific issues. It’s worthwhile to monitor the messages via the tail command in real time when you make modifications to your hardware, such as mounting an extra disk or adding an Ethernet network interface. For example, here is output of the tail -f \/var\/log\/messages command:<\/p>\n

# tail -f \/var\/log\/messages
\nDec 1 13:20:33 bastion dnsmasq[30201]: using nameserver 127.0.0.1#53 for domain in-addr.arpa
\nDec 1 13:20:33 bastion dnsmasq[30201]: using nameserver 127.0.0.1#53 for domain cluster.local
\nDec 1 13:21:03 bastion dnsmasq[30201]: setting upstream servers from DBus
\nDec 1 13:21:03 bastion dnsmasq[30201]: using nameserver 192.199.0.2#53
\nDec 1 13:21:03 bastion dnsmasq[30201]: using nameserver 127.0.0.1#53 for domain in-addr.arpa
\nDec 1 13:21:03 bastion dnsmasq[30201]: using nameserver 127.0.0.1#53 for domain cluster.local
\nDec 1 13:21:33 bastion dnsmasq[30201]: setting upstream servers from DBus
\nDec 1 13:21:33 bastion dnsmasq[30201]: using nameserver 192.199.0.2#53
\nDec 1 13:21:33 bastion dnsmasq[30201]: using nameserver 127.0.0.1#53 for domain in-addr.arpa
\nDec 1 13:21:33 bastion dnsmasq[30201]: using nameserver 127.0.0.1#53 for domain cluster.local<\/p>\n

Analyzing networking functions<\/h2>\n

You may have hundreds of thousands of cloud-native applications to serve business services in a complex networking environment; these may include virtualization, multiple cloud, and hybrid cloud. This means you should analyze whether networking connectivity is working correctly as part of your troubleshooting. Useful commands to figure out networking functions in the Linux server include ip addr, traceroute, nslookup, dig, and ping, among others. For example, here is output of the ip addr show command:<\/p>\n

# ip addr show
\n1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
\nlink\/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
\ninet 127.0.0.1\/8 scope host lo
\nvalid_lft forever preferred_lft forever
\ninet6 ::1\/128 scope host
\nvalid_lft forever preferred_lft forever
\n2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
\nlink\/ether 06:af:52:f8:74:98 brd ff:ff:ff:ff:ff:ff
\ninet 192.199.0.169\/24 brd 192.199.0.255 scope global noprefixroute dynamic eth0
\nvalid_lft 3096sec preferred_lft 3096sec
\ninet6 fe80::4af:52ff:fef8:7498\/64 scope link
\nvalid_lft forever preferred_lft forever
\n3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
\nlink\/ether 02:42:67:fb:1a:a2 brd ff:ff:ff:ff:ff:ff
\ninet 172.17.0.1\/16 scope global docker0
\nvalid_lft forever preferred_lft forever
\ninet6 fe80::42:67ff:fefb:1aa2\/64 scope link
\nvalid_lft forever preferred_lft forever
\n….<\/p>\n

In conclusion<\/h2>\n

Troubleshooting Linux hardware requires considerable knowledge, including how to use powerful command-line tools and figure out system loggings. You should also know how to diagnose the kernel space, which is where you can find the root cause of many hardware problems. Keep in mind that hardware issues in Linux may come from many different sources, including devices, modules, drivers, BIOS, networking, and even plain old hardware malfunctions.<\/p>\n

Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Linux servers run mission-critical business applications in many different types of infrastructures including physical machines, virtualization, private cloud, public cloud, and hybrid cloud. It’s important for Linux sysadmins to understand how to manage Linux hardware infrastructure\u2014including software-defined functionalities related to networking, storage, Linux containers, and multiple tools on Linux servers. It can take some time … <\/p>\n

Continue reading “Troubleshooting hardware problems in Linux”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-7081","post","type-post","status-publish","format-standard","hentry","category-linux"],"_links":{"self":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/posts\/7081","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/comments?post=7081"}],"version-history":[{"count":1,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/posts\/7081\/revisions"}],"predecessor-version":[{"id":7413,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/posts\/7081\/revisions\/7413"}],"wp:attachment":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/media?parent=7081"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/categories?post=7081"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/tags?post=7081"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}