Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to troubleshoot Linux hardware. The content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Linux servers run critical business applications in many different kinds of infrastructure, including physical machines, virtualization, private clouds, public clouds, and hybrid clouds. It is important for Linux system administrators to understand how to manage Linux hardware infrastructure (including software-defined features related to network, storage, and Linux containers) and multiple tools on Linux servers.

It may take some time to troubleshoot and resolve hardware-related issues on Linux. Even experienced system administrators sometimes spend hours resolving mysterious hardware and software differences.

The following tips will make it faster and easier for you to troubleshoot hardware in Linux. Many different things can cause problems with Linux hardware. Before you start diagnosing them, it is wise to understand the most common problems and where they are most likely to be found.

Quickly diagnose devices, modules, and drivers

The first step in troubleshooting is usually to display a list of hardware installed on the Linux server. You can use list commands such as lspci, lsblk, lscpu, and lsscsi to get detailed information about the hardware. For example, this is the output of the lsblk command:

# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 50G 0 disk ├─ xvda1 202:1 0 1M 0 part └─ xvda2 202:2 0 50G 0 part / xvdb 202:16 0 20G 0 disk └─ xvdb1 202:17 0 20G 0 part

If these listing commands do not show any errors, use an initialization system, such as systemd, to see how the Linux server works. Systemd is the most popular initialization system, which is used to start user space and control multiple system processes. For example, this is the output of the systemctl status command:

# systemctl status ● bastion.f347.internal State: running Jobs: 0 queued Failed: 0 units Since: Wed 2018-11-28 01:29:05 UTC 2 days ago CGroup: / ├─ 1 / usr/lib/systemd/systemd-- switched-root-- system-- deserialize 21 ├─ kubepods.slice │ ├─ kubepods-pod3881728a_f2af_11e8_af77_06af52f87498.slice │ │ │ └─ 23860 / opt/bridge/bin/bridge-- public-dir=/opt/bridge / static-config=/var/console-config/console-c │ │ └─ docker-a4433f0d523c7e5bc772ee4db1861e4fa56c4e63a2d48f6bc831458c2ce9fd2d.scope │ │ └─ 23639 / usr/bin/pod....

Go deep into the various logs

Using dmesg, you can find errors and warnings in the latest kernel messages. For example, this is the output of the dmesg | more command:

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

You can also view all Linux system logs in the / var/log/messages file, where you can find errors related to specific problems. When you make changes to the hardware (such as installing additional disks or adding Ethernet network cards), it is worthwhile to monitor messages in real time through the tail command. For example, this is the output of the tail-f / var/log/messages command:

# tail-f / var/log/messages Dec 1 13:20:33 bastion dnsmasq [30201]: using nameserver 127.0.0.1.53 for domain in-addr.arpa Dec 1 13:20:33 bastion dnsmasq [30201]: using nameserver 127.0.0.1inclusive 53 for domain cluster.local Dec 1 13:21:03 bastion dnsmasq [30201]: setting upstream servers from DBus Dec 1 13:21:03 bastion dnsmasq [30201]: using nameserver 192.199.0.2y53 Dec 1 13:21:03 bastion Dnsmasq [30201]: using nameserver 127.0.0.1#53 for domain in-addr.arpa Dec 1 13:21:03 bastion dnsmasq [30201]: using nameserver 127.0.0.1#53 for domain cluster.local Dec 1 13:21:33 bastion dnsmasq [30201]: setting upstream servers from DBus Dec 1 13:21:33 bastion dnsmasq [30201]: using nameserver 192.199.0.2#53 Dec 1 13:21:33 bastion dnsmasq [30201]: using nameserver 127.0.0.1#53 for domain In-addr.arpa Dec 1 13:21:33 bastion dnsmasq [30201]: using nameserver 127.0.0.1#53 for domain cluster.local

Analyze network function

You may have thousands of cloud native applications that serve your business in a complex network environment, including virtualization, multi-cloud, and hybrid clouds. This means that, as part of troubleshooting, you should analyze whether the network connection is working properly. Useful commands to figure out the network functions in the Linux server include: ip addr, traceroute, nslookup, dig, ping, and so on. For example, this is the output of the ip addr show command:

# ip addr show 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 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: eth0: mtu 9001 qdisc mq state UP group default qlen 1000 link/ether 06:af:52: F8:74:98 brd ff:ff:ff:ff:ff:ff inet 192.199.0.169/24 brd 192.199.0.255 scope global noprefixroute dynamic eth0 valid_lft 3096sec preferred_lft 3096sec inet6 fe80::4af:52ff:fef8:7498/64 scope link valid_lft forever preferred_lft forever 3: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:67:fb:1a:a2 brd ff:ff:ff:ff:ff : ff inet 172.17.0.1/16 scope global docker0 valid_lft forever preferred_lft forever inet6 fe80::42:67ff:fefb:1aa2/64 scope link valid_lft forever preferred_lft forever....

Summary

Troubleshooting Linux hardware requires a great deal of knowledge, including how to use powerful command-line tools and finding system logging. You should also know how to diagnose kernel space, where you can find the root causes of many hardware problems. Keep in mind that hardware problems in Linux can come from many different sources, including devices, modules, drivers, BIOS, networks, and even plain old hardware failures.

On how to carry out Linux hardware troubleshooting to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.