2026/8/24 2:40:19
FEATURED · 精选文章 
1. 这不是命令列表而是一套服务器硬件诊断思维框架“Linux 查看硬件服务器命令大全”这个标题表面看是份工具手册实则藏着一套完整的服务器硬件认知体系——它不是让你死记硬背lspci或dmidecode而是教会你当一台物理服务器摆在面前如何像老练的硬件工程师那样从系统启动那一刻起一层层剥开外壳、BIOS、固件、总线、设备驱动、内核模块这五层“皮肤”精准定位硬件状态、识别兼容瓶颈、预判故障风险。我干了十多年IDC运维和国产化替代项目亲手拆过上千台华为、浪潮、曙光、联想的2U/4U服务器也给金融、电力、政务客户做过上百次硬件级巡检。最常被问的问题不是“哪个命令能查CPU”而是“为什么lscpu显示8核但top只跑4个进程”、“smartctl报SMART警告但硬盘还在用到底该不该换”、“dmesg | grep -i error刷屏哪条才是真正致命的”——这些问题的答案从来不在命令手册里而在你对硬件栈的理解深度中。核心关键词“linux”“硬件”“服务器”三者叠加指向一个高度垂直的实战场景非虚拟化环境下的裸金属服务器硬件状态可信验证。它区别于云主机你根本看不到物理层、区别于桌面Linux硬件复杂度低、更区别于嵌入式Linux资源受限、驱动精简。这里的“硬件”特指x86_64架构下由Intel/AMD CPU、DDR4/DDR5内存、NVMe/SATA/SAS存储控制器、PCIe网卡/RAID卡、BMC/IPMI管理芯片构成的企业级服务器硬件生态。而“命令”只是探针真正的价值在于理解每个命令背后调用的内核接口如/sys/class/、/proc/、触发的硬件寄存器读取如lspci -vv访问PCI配置空间、依赖的固件信息如dmidecode解析SMBIOS表。比如lshw -class memory输出的“size: 64GiB”看似简单但背后是内核通过ACPI _CRS方法从主板DSDT表中解析出内存插槽拓扑再结合/sys/firmware/acpi/tables/中的SRAT表确认NUMA节点分布——没这层理解你永远不知道为什么numactl --hardware显示的节点数和lshw不一致。这份“大全”的真正读者不是刚装完Ubuntu的小白而是三类人第一类是正在准备华为校招单板硬件机考题的应届生他们需要把ipmitool sensor list和ipmitool fru print对应到BMC芯片的实际功能第二类是负责高清录播服务器集群交付的工程师他们得在30分钟内判断这批新到货的戴尔R750是否所有NVMe盘都已正确识别并启用PCIe AER错误报告第三类是做国产化替代的架构师他们要用lspci -k确认麒麟OS内核是否加载了海光DCU加速卡的hccp驱动而非fallback的通用pci-stub。所以下面的内容不会罗列100个命令然后戛然而止而是以“问题驱动”为线索把命令嵌入真实排障现场——当你看到cat /proc/cpuinfo | grep model name时我会告诉你为什么在海光HYGON平台这条命令可能返回空值以及如何用cpuid工具绕过内核限制直接读取CPUID寄存器。2. 硬件信息分层采集从固件层到内核层的穿透式验证服务器硬件信息不是平铺直叙的静态数据而是一个多层级、有依赖关系的动态树状结构。盲目执行lshw -short只会得到一堆碎片化输出真正有效的诊断必须遵循“自底向上”的穿透逻辑先确认固件层BMC/UEFI是否健康再验证内核是否正确枚举了总线设备最后检查驱动是否成功绑定并暴露了用户态接口。这个过程就像修车——你不会一上来就拆发动机而是先听异响BMC日志、再查仪表盘报警灯UEFI POST代码、最后才打开引擎盖lspci。下面这张表是我根据十年现场经验总结的硬件信息采集黄金路径每一步都标注了关键命令、典型输出陷阱及验证逻辑层级验证目标核心命令关键陷阱与验证逻辑实操优先级固件层BMC/IPMI是否在线、传感器是否上报、FRU信息是否完整ipmitool -I lanplus -H BMC_IP -U user -P pass sensor listipmitool -I lanplus -H BMC_IP -U user -P pass fru print陷阱sensor list返回Invalid command说明BMC固件版本过旧需升级验证逻辑对比fru print中Board Mfg Date与服务器实物标签日期若相差超2年大概率存在备件混用风险★★★★★UEFI/BIOS层启动模式Legacy/UEFI、内存频率锁定状态、PCIe ASPM节能是否禁用sudo fwupdmgr get-devicessudo dmesggrep -i efi|acpi陷阱fwupdmgr无输出不代表无固件更新需检查/usr/lib/fwupd/plugins/目录是否存在uefi_capsule插件验证逻辑dmesg中出现ACPI: EC: EC firmware version not available表示EC固件异常将导致风扇控制失效总线层PCIe拓扑是否完整、设备是否被正确识别、中断分配是否冲突lspci -tvlspci -vv -s 0000:01:00.0 | grep -A10 Interrupt|Region陷阱lspci -tv中某分支显示---[00]而非具体设备说明该PCIe插槽物理未连接或供电不足验证逻辑Region行若显示Memory at (64-bit, non-prefetchable)且addr为0表明BAR基址未被BIOS初始化需进UEFI关闭Fast Boot重置PCIe枚举★★★★☆内核层设备是否被内核探测、驱动是否加载、DMA地址空间是否映射成功lsmod | grep -E (igb|nvme|mpt3sas)dmesg | grep -i nvme|igb|mpt3陷阱lsmod显示nvme模块但dmesg无nvme 0000:01:00.0: enabling device日志说明NVMe SSD未通过PCIe链路训练验证逻辑dmesg中irq X: no longer affine to CPU Y表示中断亲和性被破坏需检查/proc/interrupts中该IRQ计数是否为0★★★★★用户态层设备是否可被应用访问、性能参数是否符合预期、健康状态是否可信smartctl -a /dev/nvme0n1ethtool -i enp1s0f0陷阱smartctl返回Read NVMe Identify Controller failed: Permission denied并非权限问题而是NVMe驱动未启用NVME_IOCTL_ADMIN_CMD能力验证逻辑ethtool -i中driver: igb但firmware-version: N/A说明网卡固件未加载需手动modprobe -r igb modprobe igb触发固件加载★★★★☆这个分层框架的价值在于帮你建立“命令-现象-根因”的映射关系。比如客户报障“服务器启动后网卡enp1s0f0消失”新手会直接ip link show老手则按此框架逐层排查先ipmitool sensor list确认BMC无“PCIe Link Down”告警固件层再lspci -tv看网卡是否出现在PCIe树中总线层接着dmesg | grep igb找驱动加载失败日志内核层最后ethtool -i enp1s0f0确认固件版本用户态层。我曾遇到一台浪潮NF5280M5lspci能看到网卡dmesg有驱动加载日志但ethtool报错“Cannot get driver information: No such device”。最终发现是UEFI中启用了“PCIe SR-IOV”而内核未编译vfio-pci模块导致网卡被VFIO驱动抢占igb无法绑定——这种跨层级的耦合问题只有穿透式验证才能暴露。2.1 固件层BMC/IPMI才是服务器真正的“黑匣子”BMCBaseboard Management Controller是独立于主CPU运行的ARM Cortex-M系列微控制器它像服务器的“副驾驶”24小时监控温度、电压、风扇转速并记录所有硬件事件。ipmitool命令之所以排在首位是因为它提供的信息具有最高权威性——它不依赖Linux内核直接与BMC通信。但很多人用ipmitool只停留在sensor list这是巨大浪费。真正有价值的三个命令组合是# 1. 获取实时传感器快照注意-I lanplus指定IPMI v2.0协议避免v1.5兼容问题 ipmitool -I lanplus -H 192.168.1.100 -U ADMIN -P admin123 sensor list | awk $4 ~ /degrees|Volts|Amps/ {printf %-20s %-10s %-10s %s\n, $1, $2, $3, $4} # 2. 解析FRUField Replaceable Unit信息这是硬件身份证 ipmitool -I lanplus -H 192.168.1.100 -U ADMIN -P admin123 fru print | grep -E Product Name|Board Mfg Date|Chassis Part Number # 3. 提取SELSystem Event Log历史告警比dmesg更早发现隐患 ipmitool -I lanplus -H 192.168.1.100 -U ADMIN -P admin123 sel list | head -20实操中最大的坑是BMC网络配置。很多工程师在服务器上执行ipmitool失败第一反应是密码错误其实90%是BMC IP未配置或与主机IP冲突。正确做法是先用ipmitool lan print检查BMC当前网络模式Static/DHCP再用ipmitool lan set 1 ipsrc static强制设为静态最后ipmitool lan set 1 ipaddr 192.168.1.100分配IP。我见过最离谱的案例某银行核心系统服务器BMC IP被误设为0.0.0.0导致所有ipmitool命令超时而dmesg里却没有任何相关报错——因为内核根本收不到BMC响应。FRU信息中的“Board Mfg Date”是判断硬件批次的关键。例如华为2288H V5服务器2019年3月前生产的主板使用Intel C622芯片组之后升级为C624。如果你在C624主板上强行刷入C622的BIOS固件ipmitool fru print会显示“Board Mfg Date”正常但dmesg会出现大量“ACPI Error: Could not resolve symbol [_SB.PCI0.SBRG.EC0._REG]”——这是ACPI表不兼容的典型症状。此时lspci一切正常lshw也无异常唯有FRU日期与BIOS版本交叉验证才能发现问题。SEL日志更是宝藏。ipmitool sel list输出的每一行都包含时间戳、事件ID、严重等级。重点关注“Critical”和“Warning”级别事件如“0x00000001: Power Supply Failure”或“0x00000002: Memory Correctable Error Rate Exceeded”。这些事件在Linux内核日志中可能被淹没但在SEL里是独立记录的。我曾用SEL日志提前两周预测了一台戴尔R740的PSU故障连续三天出现“Power Supply 1: Input Voltage Out of Range”警告而dmesg里只有零星的“ACPI: EC: event blocked”提示。更换PSU后SEL日志清零服务器再未出现宕机。2.2 UEFI/BIOS层启动参数决定硬件命运UEFI固件是硬件与操作系统之间的第一道桥梁。fwupdmgr和dmesg组合能揭示固件层面的深层问题。fwupdmgr get-devices输出中Update State字段至关重要supported表示固件支持在线升级needs-reboot表示升级已安装但需重启生效而unknown则意味着该设备固件不受fwupd管理——这在国产化场景中极为常见比如海光平台的hsa-firmware包就不在fwupd仓库中。dmesg | grep -i efi\|acpi的输出需要重点解读三类信息EFI相关EFI: EFI v2.70 by American Megatrends表明UEFI版本低于v2.50的固件可能存在NVMe启动兼容性问题ACPI相关ACPI: EC: GPE0x1F表示嵌入式控制器GPEGeneral Purpose Event中断号若此处显示GPE0x00说明EC未初始化风扇将失控SMBIOS相关SMBIOS 3.2.0 present.是DMI解码的基础dmidecode命令依赖此信息若此处报错“SMBIOS table not found”dmidecode必然失败。一个经典案例某客户采购的联想SR650服务器dmidecode -t memory始终返回空。排查发现dmesg中有ACPI: SMBIOS: Unable to map SDR table。根源是UEFI中启用了“Secure Boot”而SMBIOS表签名未被密钥信任。解决方案不是关Secure Boot生产环境不允许而是用sudo mokutil --import /path/to/mok.der导入厂商MOK密钥。这个操作必须在UEFI Shell中完成fwupdmgr无法处理——这就是为什么UEFI层验证不可跳过。2.3 总线层PCIe拓扑是硬件健康的晴雨表lspci -tv生成的树状图是诊断硬件连接问题的终极地图。它的输出格式为-[0000:00]--00.0 Intel Corporation... -01.0-[01]----00.0 NVIDIA Corporation... \-1f.0 Intel Corporation...其中[01]表示PCIe Switch下游的Bus ID。如果某分支显示---[00]说明该Slot无设备或链路未建立。此时不能只看lspci必须结合lspci -vv深挖# 定位NVMe SSD的详细配置空间 lspci -vv -s 0000:01:00.0 | grep -A20 Capabilities.*Express\|Region.*Memory\|Interrupt关键字段解读Capabilities: [100 v1] Express (v2)PCIe版本v2表示Gen2v3表示Gen3v4表示Gen4。若此处显示v1但设备标称Gen4说明链路协商失败Region 0: Memory at ... (64-bit, non-prefetchable)BAR0基址若at后为空或为00000000表明BIOS未分配内存空间Interrupt: pin A, routed to IRQ 42中断号若pin A但IRQ 42在/proc/interrupts中计数为0说明中断未被路由。我处理过一个华为2488H V5的案例lspci -tv显示NVMe卡在[02]分支但lspci -vv中Region 0地址为00000000。进UEFI发现“PCIe Speed”被设为“Auto”而该卡要求强制“Gen3”。改为Gen3后lspci -vv立即显示正确BAR地址dmesg出现nvme 0000:02:00.0: pci_enable_device succeeded。这证明PCIe链路训练失败根源在UEFI配置而非硬件损坏。3. 核心硬件专项诊断CPU/内存/存储/网络的深度解剖当分层验证确认硬件栈基本健康后就要进入专项诊断。这里没有“万能命令”每个子系统都有其独特的信息源和验证逻辑。CPU信息不能只看lscpu内存健康不能只信free -h存储可靠性不能只靠df -h网络性能不能只测ping。下面以真实排障场景为线索拆解四大核心部件的诊断方法论。3.1 CPU超越lscpu的微架构真相lscpu输出的“CPU(s): 32”、“Thread(s) per core: 2”看似清晰但它掩盖了CPU微架构的关键细节。真正影响性能的是CPU Family/Modellscpu | grep CPU family\|ModelIntel CPU中Family6表示Core系列Model85表示Cascade LakeModel106表示Ice LakeCache Topologylscpu | grep cache仅显示L3大小但L2/L1 cache per core、cache line size64字节才是影响NUMA亲和性的关键Microcode Versiongrep microcode /proc/cpuinfo微码版本决定硬件级漏洞修复如Spectre/Meltdown。更深层的验证需用cpuid工具直接读取CPUID寄存器# 安装cpuidUbuntu/Debian sudo apt install cpuid # 查询CPU型号字符串比lscpu更准确 cpuid | grep Processor Name String # 检查是否支持AVX-512对AI推理至关重要 cpuid | grep AVX-512一个血泪教训某AI训练集群采购了标称“Intel Xeon Gold 6248R”的CPUlscpu显示32核但cpuid | grep Processor Name String返回“Intel(R) Xeon(R) Gold 6248”少了“R”。经查证“R”后缀表示支持AVX-512_VNNI指令集而普通6248不支持。模型训练速度因此下降40%。lscpu无法区分这种后缀差异唯有cpuid或dmidecode -t processor中的“Version”字段才能确认。NUMA拓扑是另一个雷区。numactl --hardware输出的node 0 size: 128GB可能误导你认为内存均匀分布。必须用lstopo -v需安装hwloc查看物理拓扑# 生成带缓存层级的NUMA图 lstopo -v --no-io | grep -A10 Package L#0输出中L3#0 (38400KB)表示Package 0的L3缓存大小Core L#0 (P#0)表示物理核心0。若lscpu显示32线程但lstopo只显示16个Core L#*说明启用了超线程但BIOS中“Hyper-Threading”被禁用——lscpu的“Thread(s) per core: 2”是内核假设值实际以lstopo为准。3.2 内存dmidecode与edac-util的双重验证free -h只告诉你“可用内存”dmidecode -t memory才告诉你“物理内存真相”。后者输出包含Size: 64 GB单条内存容量Type: DDR4内存类型Speed: 2666 MT/s标称频率Configured Clock Speed: 2133 MT/s实际运行频率BIOS降频Manufacturer: Samsung颗粒厂商影响兼容性。但dmidecode无法检测内存错误。这时edac-utilError Detection and Correction是救命稻草# 安装edac-utilsCentOS/RHEL sudo yum install edac-utils # 查看内存控制器错误计数 sudo edac-util -v # 清除错误计数谨慎仅用于测试 sudo edac-util -cedac-util -v输出中csrow0的ce_countCorrectable Errors和ue_countUncorrectable Errors是关键指标。ce_count 0表示ECC已纠正单比特错误属正常ue_count 0则意味双比特错误内存条必须更换。我曾在一个政务云项目中edac-util显示ue_count3但dmesg无任何报错。原因是内核参数loglevel3屏蔽了ECC错误日志。修改/etc/default/grub中GRUB_CMDLINE_LINUXloglevel7并update-grub后dmesg | grep -i memory error立即刷屏——这证明edac-util比dmesg更底层、更可靠。3.3 存储NVMe的smartctl与SATA的hdparm分野存储诊断必须区分接口协议。NVMe设备用smartctl -a /dev/nvme0n1SATA设备用smartctl -a /dev/sda而SAS设备需smartctl -d satscsi -a /dev/sg0。混淆接口会导致命令失败。smartctl输出中NVMe特有的字段Available Spare: 100%备用块剩余率低于10%需预警Media and Data Integrity Errors: 0介质完整性错误非零值表示NAND闪存损坏Critical Warning: 0x00十六进制警告码0x10表示温度过高0x08表示备用块耗尽。SATA设备则关注Reallocated_Sector_Ct重映射扇区数0表示硬盘开始坏道UDMA_CRC_Error_CountCRC校验错误高值说明数据线接触不良。一个典型误区用hdparm -I /dev/sda查SATA硬盘信息。hdparm只能读取IDENTIFY DEVICE数据而smartctl能读取SMART日志。某次巡检hdparm显示硬盘“Model Number: ST4000NM0035”一切正常但smartctl -a /dev/sda | grep Reallocated_Sector_Ct返回123。更换硬盘后业务数据库IO延迟从2ms降至0.3ms——hdparm的“正常”只是假象。3.4 网络ethtool的隐藏参数与lspci的驱动绑定ethtool -i enp1s0f0显示的driver: ixgbe只是表象lspci -k -s 0000:01:00.0才能看到驱动绑定真相lspci -k -s 0000:01:00.0 # 输出 # Kernel driver in use: ixgbe # Kernel modules: ixgbe, ixgbevf若Kernel driver in use为空说明驱动未加载若显示vfio-pci则网卡被VFIO接管ethtool将失效。ethtool的隐藏参数-Sstatistics是性能诊断核心# 查看网卡硬件计数器 ethtool -S enp1s0f0 | grep -E (rx_packets|tx_packets|rx_errors|tx_errors)rx_errors非零值需深挖rx_length_errors表示帧长错误网线质量问题rx_crc_errors表示CRC校验失败电磁干扰rx_missed_errors表示内核来不及处理中断风暴。我曾定位到一台服务器rx_missed_errors每秒增长1000根源是irqbalance服务未运行所有网卡中断都压在CPU0上。systemctl start irqbalance后该计数归零。4. 实战排障从“服务器变慢”到定位PCIe AER错误的全流程现在让我们把所有知识串联起来还原一次真实的排障全过程。场景某高清录播服务器集群中一台华为2288H V5在持续推流72小时后视频卡顿率从0.1%飙升至15%top显示CPU使用率仅40%iostat -x 1显示%util为95%但iotop找不到高IO进程。这不是教科书式故障而是典型的硬件级隐性故障。4.1 第一步固件层快速扫描5分钟# 登录BMC检查传感器 ipmitool -I lanplus -H 192.168.10.50 -U ADMIN -P admin123 sensor list | grep -E Temp|Fan|Voltage # 发现CPU Temp稳定在72°CFan1转速8000RPM正常但PSU1 Status显示Presence detected而非OK # 立即执行SEL日志提取 ipmitool -I lanplus -H 192.168.10.50 -U ADMIN -P admin123 sel list | grep -i psu\|power # 输出00000001: Power Supply 1: Input Voltage Out of Range过去24小时出现12次结论PSU1输入电压不稳但BMC未触发关机属于亚健康状态。4.2 第二步总线层深度透视10分钟# 查看PCIe拓扑 lspci -tv # 发现NVMe SSD分支为[02]但lspci -vv -s 0000:02:00.0中Region 0地址异常 # 进一步检查AERAdvanced Error Reporting lspci -vv -s 0000:02:00.0 | grep -A10 AER # 输出 # Capabilities: [100 v1] Express (v2) Root Port (ARI) # ... # Capabilities: [148 v1] Advanced Error Reporting # UESta: DLP ErrMask RlvtErrMask- ... # UESta: 0x00000000 # Uncorrectable Error Status # CESta: 0x00000000 # Correctable Error Status # 但dmesg | grep -i aer无输出说明AER未启用此时想起UEFI中“PCIe Advanced Error Reporting”默认关闭。进UEFI开启后dmesg立即刷屏pcieport 0000:00:1c.0: AER: Uncorrectable error received: 0000:02:00.0 nvme 0000:02:00.0: PCIe Bus Error: severityUncorrectable, typePhysical Layer4.3 第三步存储层精准打击15分钟# 检查NVMe健康 smartctl -a /dev/nvme0n1 | grep -E (Available Spare|Media.*Errors|Critical Warning) # 输出 # Available Spare: 95% # Media and Data Integrity Errors: 12 # Critical Warning: 0x00 # 但Media and Data Integrity Errors已非零需查详细日志 smartctl -l devstat /dev/nvme0n1 # 发现Data Units Read计数停滞Host Read Commands持续增长——说明读请求堆积 # 此时执行PCIe重置 echo 1 | sudo tee /sys/bus/pci/devices/0000:02:00.0/remove echo 1 | sudo tee /sys/bus/pci/rescan # 重置后dmesg出现nvme 0000:02:00.0: pci_enable_device succeeded卡顿消失4.4 第四步根因闭环与预防10分钟根因是PSU1电压不稳导致PCIe链路训练失败AER错误被累积最终NVMe控制器进入降速模式。预防措施更换PSU1硬件级在UEFI中启用“AER”和“PCIe Relaxed Ordering”部署aer-inject工具定期注入AER错误测试链路健壮性编写脚本每5分钟执行dmesg | grep -q AER systemctl restart nvme实现自动恢复。这个案例证明所谓“命令大全”本质是构建一套硬件故障的因果链推理能力。lspci、smartctl、dmesg不是孤立工具而是同一张硬件健康图谱的不同切片。5. 常见问题与独家避坑指南那些文档里不会写的实战技巧在上千次硬件诊断中我总结出21个高频问题及其独创解法。这些不是百度能搜到的“标准答案”而是踩坑后用血泪换来的经验。5.1 “dmidecode无输出”——不是权限问题是SMBIOS表损坏现象sudo dmidecode -t system返回空dmesg | grep SMBIOS显示“SMBIOS table not found”。错误解法网上教程说加--no-sysfs参数。正确解法# 尝试从/dev/mem直接读取需root sudo dd if/dev/mem bs1 skip786432 count65536 2/dev/null | strings | grep -A5 DMI # 若仍无输出用flashrom备份BIOS用UEFITool查找SMBIOS表位置 # 最终方案联系厂商获取SMBIOS表修复补丁华为提供bios_smbios_fix.sh原理SMBIOS表位于BIOS ROM的固定偏移处通常0xC0000dmidecode默认从/sys/firmware/acpi/tables/读取若该路径损坏则需绕过内核直接读ROM。5.2 “lspci看不到GPU”——不是没插是PCIe Slot被UEFI禁用现象NVIDIA A100显卡插入PCIe x16 Slotlspci无识别dmesg无相关日志。避坑技巧进UEFI找到“PCIe Configuration” → “Slot 1” → “Link Speed”从“Auto”改为“Gen4”关闭“Above 4G Decoding”该选项在某些主板上会阻止GPU BAR空间分配执行sudo setpci -s 0000:00:00.0 3e.b1强制PCIe根端口重新枚举需setpci工具。5.3 “smartctl报Permission Denied”——NVMe驱动能力缺失现象sudo smartctl -a /dev/nvme0n1返回“Read NVMe Identify Controller failed: Permission denied”。独家解法# 检查内核是否启用NVMe管理命令 zcat /proc/config.gz | grep CONFIG_NVME_ADMIN_CMD # 若为n需重新编译内核或加载模块 sudo modprobe -r nvme sudo modprobe nvme default_ps_max_latency_us0 # 关键设置default_ps_max_latency_us0禁用PCIe电源状态切换5.4 “ethtool显示Link Down但网线正常”——BMC劫持了PHY现象ethtool enp1s0f0显示“Link detected: no”但网线直连交换机指示灯亮。真相华为服务器BMC默认启用“Shared LAN”将网卡PHY控制权交给BMC。解决# 通过BMC命令释放PHY ipmitool -I lanplus -H BMC_IP -U ADMIN -P admin123 raw 0x30 0x70 0x01 0x00 # 或在UEFI中禁用“BMC Shared LAN”5.5 “ipmitool连接超时”——不是网络问题是BMC固件Bug现象BMC IP可达ping通但ipmit
Linux服务器硬件诊断思维框架：从固件到内核的穿透式验证
1. 这不是命令列表而是一套服务器硬件诊断思维框架“Linux 查看硬件服务器命令大全”这个标题表面看是份工具手册实则藏着一套完整的服务器硬件认知体系——它不是让你死记硬背lspci或dmidecode而是教会你当一台物理服务器摆在面前如何像老练的硬件工程师那样从系统启动那一刻起一层层剥开外壳、BIOS、固件、总线、设备驱动、内核模块这五层“皮肤”精准定位硬件状态、识别兼容瓶颈、预判故障风险。我干了十多年IDC运维和国产化替代项目亲手拆过上千台华为、浪潮、曙光、联想的2U/4U服务器也给金融、电力、政务客户做过上百次硬件级巡检。最常被问的问题不是“哪个命令能查CPU”而是“为什么lscpu显示8核但top只跑4个进程”、“smartctl报SMART警告但硬盘还在用到底该不该换”、“dmesg | grep -i error刷屏哪条才是真正致命的”——这些问题的答案从来不在命令手册里而在你对硬件栈的理解深度中。核心关键词“linux”“硬件”“服务器”三者叠加指向一个高度垂直的实战场景非虚拟化环境下的裸金属服务器硬件状态可信验证。它区别于云主机你根本看不到物理层、区别于桌面Linux硬件复杂度低、更区别于嵌入式Linux资源受限、驱动精简。这里的“硬件”特指x86_64架构下由Intel/AMD CPU、DDR4/DDR5内存、NVMe/SATA/SAS存储控制器、PCIe网卡/RAID卡、BMC/IPMI管理芯片构成的企业级服务器硬件生态。而“命令”只是探针真正的价值在于理解每个命令背后调用的内核接口如/sys/class/、/proc/、触发的硬件寄存器读取如lspci -vv访问PCI配置空间、依赖的固件信息如dmidecode解析SMBIOS表。比如lshw -class memory输出的“size: 64GiB”看似简单但背后是内核通过ACPI _CRS方法从主板DSDT表中解析出内存插槽拓扑再结合/sys/firmware/acpi/tables/中的SRAT表确认NUMA节点分布——没这层理解你永远不知道为什么numactl --hardware显示的节点数和lshw不一致。这份“大全”的真正读者不是刚装完Ubuntu的小白而是三类人第一类是正在准备华为校招单板硬件机考题的应届生他们需要把ipmitool sensor list和ipmitool fru print对应到BMC芯片的实际功能第二类是负责高清录播服务器集群交付的工程师他们得在30分钟内判断这批新到货的戴尔R750是否所有NVMe盘都已正确识别并启用PCIe AER错误报告第三类是做国产化替代的架构师他们要用lspci -k确认麒麟OS内核是否加载了海光DCU加速卡的hccp驱动而非fallback的通用pci-stub。所以下面的内容不会罗列100个命令然后戛然而止而是以“问题驱动”为线索把命令嵌入真实排障现场——当你看到cat /proc/cpuinfo | grep model name时我会告诉你为什么在海光HYGON平台这条命令可能返回空值以及如何用cpuid工具绕过内核限制直接读取CPUID寄存器。2. 硬件信息分层采集从固件层到内核层的穿透式验证服务器硬件信息不是平铺直叙的静态数据而是一个多层级、有依赖关系的动态树状结构。盲目执行lshw -short只会得到一堆碎片化输出真正有效的诊断必须遵循“自底向上”的穿透逻辑先确认固件层BMC/UEFI是否健康再验证内核是否正确枚举了总线设备最后检查驱动是否成功绑定并暴露了用户态接口。这个过程就像修车——你不会一上来就拆发动机而是先听异响BMC日志、再查仪表盘报警灯UEFI POST代码、最后才打开引擎盖lspci。下面这张表是我根据十年现场经验总结的硬件信息采集黄金路径每一步都标注了关键命令、典型输出陷阱及验证逻辑层级验证目标核心命令关键陷阱与验证逻辑实操优先级固件层BMC/IPMI是否在线、传感器是否上报、FRU信息是否完整ipmitool -I lanplus -H BMC_IP -U user -P pass sensor listipmitool -I lanplus -H BMC_IP -U user -P pass fru print陷阱sensor list返回Invalid command说明BMC固件版本过旧需升级验证逻辑对比fru print中Board Mfg Date与服务器实物标签日期若相差超2年大概率存在备件混用风险★★★★★UEFI/BIOS层启动模式Legacy/UEFI、内存频率锁定状态、PCIe ASPM节能是否禁用sudo fwupdmgr get-devicessudo dmesggrep -i efi|acpi陷阱fwupdmgr无输出不代表无固件更新需检查/usr/lib/fwupd/plugins/目录是否存在uefi_capsule插件验证逻辑dmesg中出现ACPI: EC: EC firmware version not available表示EC固件异常将导致风扇控制失效总线层PCIe拓扑是否完整、设备是否被正确识别、中断分配是否冲突lspci -tvlspci -vv -s 0000:01:00.0 | grep -A10 Interrupt|Region陷阱lspci -tv中某分支显示---[00]而非具体设备说明该PCIe插槽物理未连接或供电不足验证逻辑Region行若显示Memory at (64-bit, non-prefetchable)且addr为0表明BAR基址未被BIOS初始化需进UEFI关闭Fast Boot重置PCIe枚举★★★★☆内核层设备是否被内核探测、驱动是否加载、DMA地址空间是否映射成功lsmod | grep -E (igb|nvme|mpt3sas)dmesg | grep -i nvme|igb|mpt3陷阱lsmod显示nvme模块但dmesg无nvme 0000:01:00.0: enabling device日志说明NVMe SSD未通过PCIe链路训练验证逻辑dmesg中irq X: no longer affine to CPU Y表示中断亲和性被破坏需检查/proc/interrupts中该IRQ计数是否为0★★★★★用户态层设备是否可被应用访问、性能参数是否符合预期、健康状态是否可信smartctl -a /dev/nvme0n1ethtool -i enp1s0f0陷阱smartctl返回Read NVMe Identify Controller failed: Permission denied并非权限问题而是NVMe驱动未启用NVME_IOCTL_ADMIN_CMD能力验证逻辑ethtool -i中driver: igb但firmware-version: N/A说明网卡固件未加载需手动modprobe -r igb modprobe igb触发固件加载★★★★☆这个分层框架的价值在于帮你建立“命令-现象-根因”的映射关系。比如客户报障“服务器启动后网卡enp1s0f0消失”新手会直接ip link show老手则按此框架逐层排查先ipmitool sensor list确认BMC无“PCIe Link Down”告警固件层再lspci -tv看网卡是否出现在PCIe树中总线层接着dmesg | grep igb找驱动加载失败日志内核层最后ethtool -i enp1s0f0确认固件版本用户态层。我曾遇到一台浪潮NF5280M5lspci能看到网卡dmesg有驱动加载日志但ethtool报错“Cannot get driver information: No such device”。最终发现是UEFI中启用了“PCIe SR-IOV”而内核未编译vfio-pci模块导致网卡被VFIO驱动抢占igb无法绑定——这种跨层级的耦合问题只有穿透式验证才能暴露。2.1 固件层BMC/IPMI才是服务器真正的“黑匣子”BMCBaseboard Management Controller是独立于主CPU运行的ARM Cortex-M系列微控制器它像服务器的“副驾驶”24小时监控温度、电压、风扇转速并记录所有硬件事件。ipmitool命令之所以排在首位是因为它提供的信息具有最高权威性——它不依赖Linux内核直接与BMC通信。但很多人用ipmitool只停留在sensor list这是巨大浪费。真正有价值的三个命令组合是# 1. 获取实时传感器快照注意-I lanplus指定IPMI v2.0协议避免v1.5兼容问题 ipmitool -I lanplus -H 192.168.1.100 -U ADMIN -P admin123 sensor list | awk $4 ~ /degrees|Volts|Amps/ {printf %-20s %-10s %-10s %s\n, $1, $2, $3, $4} # 2. 解析FRUField Replaceable Unit信息这是硬件身份证 ipmitool -I lanplus -H 192.168.1.100 -U ADMIN -P admin123 fru print | grep -E Product Name|Board Mfg Date|Chassis Part Number # 3. 提取SELSystem Event Log历史告警比dmesg更早发现隐患 ipmitool -I lanplus -H 192.168.1.100 -U ADMIN -P admin123 sel list | head -20实操中最大的坑是BMC网络配置。很多工程师在服务器上执行ipmitool失败第一反应是密码错误其实90%是BMC IP未配置或与主机IP冲突。正确做法是先用ipmitool lan print检查BMC当前网络模式Static/DHCP再用ipmitool lan set 1 ipsrc static强制设为静态最后ipmitool lan set 1 ipaddr 192.168.1.100分配IP。我见过最离谱的案例某银行核心系统服务器BMC IP被误设为0.0.0.0导致所有ipmitool命令超时而dmesg里却没有任何相关报错——因为内核根本收不到BMC响应。FRU信息中的“Board Mfg Date”是判断硬件批次的关键。例如华为2288H V5服务器2019年3月前生产的主板使用Intel C622芯片组之后升级为C624。如果你在C624主板上强行刷入C622的BIOS固件ipmitool fru print会显示“Board Mfg Date”正常但dmesg会出现大量“ACPI Error: Could not resolve symbol [_SB.PCI0.SBRG.EC0._REG]”——这是ACPI表不兼容的典型症状。此时lspci一切正常lshw也无异常唯有FRU日期与BIOS版本交叉验证才能发现问题。SEL日志更是宝藏。ipmitool sel list输出的每一行都包含时间戳、事件ID、严重等级。重点关注“Critical”和“Warning”级别事件如“0x00000001: Power Supply Failure”或“0x00000002: Memory Correctable Error Rate Exceeded”。这些事件在Linux内核日志中可能被淹没但在SEL里是独立记录的。我曾用SEL日志提前两周预测了一台戴尔R740的PSU故障连续三天出现“Power Supply 1: Input Voltage Out of Range”警告而dmesg里只有零星的“ACPI: EC: event blocked”提示。更换PSU后SEL日志清零服务器再未出现宕机。2.2 UEFI/BIOS层启动参数决定硬件命运UEFI固件是硬件与操作系统之间的第一道桥梁。fwupdmgr和dmesg组合能揭示固件层面的深层问题。fwupdmgr get-devices输出中Update State字段至关重要supported表示固件支持在线升级needs-reboot表示升级已安装但需重启生效而unknown则意味着该设备固件不受fwupd管理——这在国产化场景中极为常见比如海光平台的hsa-firmware包就不在fwupd仓库中。dmesg | grep -i efi\|acpi的输出需要重点解读三类信息EFI相关EFI: EFI v2.70 by American Megatrends表明UEFI版本低于v2.50的固件可能存在NVMe启动兼容性问题ACPI相关ACPI: EC: GPE0x1F表示嵌入式控制器GPEGeneral Purpose Event中断号若此处显示GPE0x00说明EC未初始化风扇将失控SMBIOS相关SMBIOS 3.2.0 present.是DMI解码的基础dmidecode命令依赖此信息若此处报错“SMBIOS table not found”dmidecode必然失败。一个经典案例某客户采购的联想SR650服务器dmidecode -t memory始终返回空。排查发现dmesg中有ACPI: SMBIOS: Unable to map SDR table。根源是UEFI中启用了“Secure Boot”而SMBIOS表签名未被密钥信任。解决方案不是关Secure Boot生产环境不允许而是用sudo mokutil --import /path/to/mok.der导入厂商MOK密钥。这个操作必须在UEFI Shell中完成fwupdmgr无法处理——这就是为什么UEFI层验证不可跳过。2.3 总线层PCIe拓扑是硬件健康的晴雨表lspci -tv生成的树状图是诊断硬件连接问题的终极地图。它的输出格式为-[0000:00]--00.0 Intel Corporation... -01.0-[01]----00.0 NVIDIA Corporation... \-1f.0 Intel Corporation...其中[01]表示PCIe Switch下游的Bus ID。如果某分支显示---[00]说明该Slot无设备或链路未建立。此时不能只看lspci必须结合lspci -vv深挖# 定位NVMe SSD的详细配置空间 lspci -vv -s 0000:01:00.0 | grep -A20 Capabilities.*Express\|Region.*Memory\|Interrupt关键字段解读Capabilities: [100 v1] Express (v2)PCIe版本v2表示Gen2v3表示Gen3v4表示Gen4。若此处显示v1但设备标称Gen4说明链路协商失败Region 0: Memory at ... (64-bit, non-prefetchable)BAR0基址若at后为空或为00000000表明BIOS未分配内存空间Interrupt: pin A, routed to IRQ 42中断号若pin A但IRQ 42在/proc/interrupts中计数为0说明中断未被路由。我处理过一个华为2488H V5的案例lspci -tv显示NVMe卡在[02]分支但lspci -vv中Region 0地址为00000000。进UEFI发现“PCIe Speed”被设为“Auto”而该卡要求强制“Gen3”。改为Gen3后lspci -vv立即显示正确BAR地址dmesg出现nvme 0000:02:00.0: pci_enable_device succeeded。这证明PCIe链路训练失败根源在UEFI配置而非硬件损坏。3. 核心硬件专项诊断CPU/内存/存储/网络的深度解剖当分层验证确认硬件栈基本健康后就要进入专项诊断。这里没有“万能命令”每个子系统都有其独特的信息源和验证逻辑。CPU信息不能只看lscpu内存健康不能只信free -h存储可靠性不能只靠df -h网络性能不能只测ping。下面以真实排障场景为线索拆解四大核心部件的诊断方法论。3.1 CPU超越lscpu的微架构真相lscpu输出的“CPU(s): 32”、“Thread(s) per core: 2”看似清晰但它掩盖了CPU微架构的关键细节。真正影响性能的是CPU Family/Modellscpu | grep CPU family\|ModelIntel CPU中Family6表示Core系列Model85表示Cascade LakeModel106表示Ice LakeCache Topologylscpu | grep cache仅显示L3大小但L2/L1 cache per core、cache line size64字节才是影响NUMA亲和性的关键Microcode Versiongrep microcode /proc/cpuinfo微码版本决定硬件级漏洞修复如Spectre/Meltdown。更深层的验证需用cpuid工具直接读取CPUID寄存器# 安装cpuidUbuntu/Debian sudo apt install cpuid # 查询CPU型号字符串比lscpu更准确 cpuid | grep Processor Name String # 检查是否支持AVX-512对AI推理至关重要 cpuid | grep AVX-512一个血泪教训某AI训练集群采购了标称“Intel Xeon Gold 6248R”的CPUlscpu显示32核但cpuid | grep Processor Name String返回“Intel(R) Xeon(R) Gold 6248”少了“R”。经查证“R”后缀表示支持AVX-512_VNNI指令集而普通6248不支持。模型训练速度因此下降40%。lscpu无法区分这种后缀差异唯有cpuid或dmidecode -t processor中的“Version”字段才能确认。NUMA拓扑是另一个雷区。numactl --hardware输出的node 0 size: 128GB可能误导你认为内存均匀分布。必须用lstopo -v需安装hwloc查看物理拓扑# 生成带缓存层级的NUMA图 lstopo -v --no-io | grep -A10 Package L#0输出中L3#0 (38400KB)表示Package 0的L3缓存大小Core L#0 (P#0)表示物理核心0。若lscpu显示32线程但lstopo只显示16个Core L#*说明启用了超线程但BIOS中“Hyper-Threading”被禁用——lscpu的“Thread(s) per core: 2”是内核假设值实际以lstopo为准。3.2 内存dmidecode与edac-util的双重验证free -h只告诉你“可用内存”dmidecode -t memory才告诉你“物理内存真相”。后者输出包含Size: 64 GB单条内存容量Type: DDR4内存类型Speed: 2666 MT/s标称频率Configured Clock Speed: 2133 MT/s实际运行频率BIOS降频Manufacturer: Samsung颗粒厂商影响兼容性。但dmidecode无法检测内存错误。这时edac-utilError Detection and Correction是救命稻草# 安装edac-utilsCentOS/RHEL sudo yum install edac-utils # 查看内存控制器错误计数 sudo edac-util -v # 清除错误计数谨慎仅用于测试 sudo edac-util -cedac-util -v输出中csrow0的ce_countCorrectable Errors和ue_countUncorrectable Errors是关键指标。ce_count 0表示ECC已纠正单比特错误属正常ue_count 0则意味双比特错误内存条必须更换。我曾在一个政务云项目中edac-util显示ue_count3但dmesg无任何报错。原因是内核参数loglevel3屏蔽了ECC错误日志。修改/etc/default/grub中GRUB_CMDLINE_LINUXloglevel7并update-grub后dmesg | grep -i memory error立即刷屏——这证明edac-util比dmesg更底层、更可靠。3.3 存储NVMe的smartctl与SATA的hdparm分野存储诊断必须区分接口协议。NVMe设备用smartctl -a /dev/nvme0n1SATA设备用smartctl -a /dev/sda而SAS设备需smartctl -d satscsi -a /dev/sg0。混淆接口会导致命令失败。smartctl输出中NVMe特有的字段Available Spare: 100%备用块剩余率低于10%需预警Media and Data Integrity Errors: 0介质完整性错误非零值表示NAND闪存损坏Critical Warning: 0x00十六进制警告码0x10表示温度过高0x08表示备用块耗尽。SATA设备则关注Reallocated_Sector_Ct重映射扇区数0表示硬盘开始坏道UDMA_CRC_Error_CountCRC校验错误高值说明数据线接触不良。一个典型误区用hdparm -I /dev/sda查SATA硬盘信息。hdparm只能读取IDENTIFY DEVICE数据而smartctl能读取SMART日志。某次巡检hdparm显示硬盘“Model Number: ST4000NM0035”一切正常但smartctl -a /dev/sda | grep Reallocated_Sector_Ct返回123。更换硬盘后业务数据库IO延迟从2ms降至0.3ms——hdparm的“正常”只是假象。3.4 网络ethtool的隐藏参数与lspci的驱动绑定ethtool -i enp1s0f0显示的driver: ixgbe只是表象lspci -k -s 0000:01:00.0才能看到驱动绑定真相lspci -k -s 0000:01:00.0 # 输出 # Kernel driver in use: ixgbe # Kernel modules: ixgbe, ixgbevf若Kernel driver in use为空说明驱动未加载若显示vfio-pci则网卡被VFIO接管ethtool将失效。ethtool的隐藏参数-Sstatistics是性能诊断核心# 查看网卡硬件计数器 ethtool -S enp1s0f0 | grep -E (rx_packets|tx_packets|rx_errors|tx_errors)rx_errors非零值需深挖rx_length_errors表示帧长错误网线质量问题rx_crc_errors表示CRC校验失败电磁干扰rx_missed_errors表示内核来不及处理中断风暴。我曾定位到一台服务器rx_missed_errors每秒增长1000根源是irqbalance服务未运行所有网卡中断都压在CPU0上。systemctl start irqbalance后该计数归零。4. 实战排障从“服务器变慢”到定位PCIe AER错误的全流程现在让我们把所有知识串联起来还原一次真实的排障全过程。场景某高清录播服务器集群中一台华为2288H V5在持续推流72小时后视频卡顿率从0.1%飙升至15%top显示CPU使用率仅40%iostat -x 1显示%util为95%但iotop找不到高IO进程。这不是教科书式故障而是典型的硬件级隐性故障。4.1 第一步固件层快速扫描5分钟# 登录BMC检查传感器 ipmitool -I lanplus -H 192.168.10.50 -U ADMIN -P admin123 sensor list | grep -E Temp|Fan|Voltage # 发现CPU Temp稳定在72°CFan1转速8000RPM正常但PSU1 Status显示Presence detected而非OK # 立即执行SEL日志提取 ipmitool -I lanplus -H 192.168.10.50 -U ADMIN -P admin123 sel list | grep -i psu\|power # 输出00000001: Power Supply 1: Input Voltage Out of Range过去24小时出现12次结论PSU1输入电压不稳但BMC未触发关机属于亚健康状态。4.2 第二步总线层深度透视10分钟# 查看PCIe拓扑 lspci -tv # 发现NVMe SSD分支为[02]但lspci -vv -s 0000:02:00.0中Region 0地址异常 # 进一步检查AERAdvanced Error Reporting lspci -vv -s 0000:02:00.0 | grep -A10 AER # 输出 # Capabilities: [100 v1] Express (v2) Root Port (ARI) # ... # Capabilities: [148 v1] Advanced Error Reporting # UESta: DLP ErrMask RlvtErrMask- ... # UESta: 0x00000000 # Uncorrectable Error Status # CESta: 0x00000000 # Correctable Error Status # 但dmesg | grep -i aer无输出说明AER未启用此时想起UEFI中“PCIe Advanced Error Reporting”默认关闭。进UEFI开启后dmesg立即刷屏pcieport 0000:00:1c.0: AER: Uncorrectable error received: 0000:02:00.0 nvme 0000:02:00.0: PCIe Bus Error: severityUncorrectable, typePhysical Layer4.3 第三步存储层精准打击15分钟# 检查NVMe健康 smartctl -a /dev/nvme0n1 | grep -E (Available Spare|Media.*Errors|Critical Warning) # 输出 # Available Spare: 95% # Media and Data Integrity Errors: 12 # Critical Warning: 0x00 # 但Media and Data Integrity Errors已非零需查详细日志 smartctl -l devstat /dev/nvme0n1 # 发现Data Units Read计数停滞Host Read Commands持续增长——说明读请求堆积 # 此时执行PCIe重置 echo 1 | sudo tee /sys/bus/pci/devices/0000:02:00.0/remove echo 1 | sudo tee /sys/bus/pci/rescan # 重置后dmesg出现nvme 0000:02:00.0: pci_enable_device succeeded卡顿消失4.4 第四步根因闭环与预防10分钟根因是PSU1电压不稳导致PCIe链路训练失败AER错误被累积最终NVMe控制器进入降速模式。预防措施更换PSU1硬件级在UEFI中启用“AER”和“PCIe Relaxed Ordering”部署aer-inject工具定期注入AER错误测试链路健壮性编写脚本每5分钟执行dmesg | grep -q AER systemctl restart nvme实现自动恢复。这个案例证明所谓“命令大全”本质是构建一套硬件故障的因果链推理能力。lspci、smartctl、dmesg不是孤立工具而是同一张硬件健康图谱的不同切片。5. 常见问题与独家避坑指南那些文档里不会写的实战技巧在上千次硬件诊断中我总结出21个高频问题及其独创解法。这些不是百度能搜到的“标准答案”而是踩坑后用血泪换来的经验。5.1 “dmidecode无输出”——不是权限问题是SMBIOS表损坏现象sudo dmidecode -t system返回空dmesg | grep SMBIOS显示“SMBIOS table not found”。错误解法网上教程说加--no-sysfs参数。正确解法# 尝试从/dev/mem直接读取需root sudo dd if/dev/mem bs1 skip786432 count65536 2/dev/null | strings | grep -A5 DMI # 若仍无输出用flashrom备份BIOS用UEFITool查找SMBIOS表位置 # 最终方案联系厂商获取SMBIOS表修复补丁华为提供bios_smbios_fix.sh原理SMBIOS表位于BIOS ROM的固定偏移处通常0xC0000dmidecode默认从/sys/firmware/acpi/tables/读取若该路径损坏则需绕过内核直接读ROM。5.2 “lspci看不到GPU”——不是没插是PCIe Slot被UEFI禁用现象NVIDIA A100显卡插入PCIe x16 Slotlspci无识别dmesg无相关日志。避坑技巧进UEFI找到“PCIe Configuration” → “Slot 1” → “Link Speed”从“Auto”改为“Gen4”关闭“Above 4G Decoding”该选项在某些主板上会阻止GPU BAR空间分配执行sudo setpci -s 0000:00:00.0 3e.b1强制PCIe根端口重新枚举需setpci工具。5.3 “smartctl报Permission Denied”——NVMe驱动能力缺失现象sudo smartctl -a /dev/nvme0n1返回“Read NVMe Identify Controller failed: Permission denied”。独家解法# 检查内核是否启用NVMe管理命令 zcat /proc/config.gz | grep CONFIG_NVME_ADMIN_CMD # 若为n需重新编译内核或加载模块 sudo modprobe -r nvme sudo modprobe nvme default_ps_max_latency_us0 # 关键设置default_ps_max_latency_us0禁用PCIe电源状态切换5.4 “ethtool显示Link Down但网线正常”——BMC劫持了PHY现象ethtool enp1s0f0显示“Link detected: no”但网线直连交换机指示灯亮。真相华为服务器BMC默认启用“Shared LAN”将网卡PHY控制权交给BMC。解决# 通过BMC命令释放PHY ipmitool -I lanplus -H BMC_IP -U ADMIN -P admin123 raw 0x30 0x70 0x01 0x00 # 或在UEFI中禁用“BMC Shared LAN”5.5 “ipmitool连接超时”——不是网络问题是BMC固件Bug现象BMC IP可达ping通但ipmit 
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
