有一次在机房处理一批新上架的服务器做带外管理配置的时候我在每台机器上敲了同样的命令modprobe ipmi_si。前面几台都顺顺当当到了其中一台终端直接甩出来一行字modprobe: ERROR: could not insert ipmi_si: Operation not permitted。当时我的第一反应是权限问题立刻切到root再试结果一样。仔细查了一圈才发现这台机器BIOS里开着Secure Boot内核处于锁定状态未签名的ipmi_si模块被挡在了门外。后来做技术支持这几年我发现modprobe ipmi_si报错这个事儿卡住的人不在少数而且报错现象五花八门有Operation not permitted有Required key not available有的干脆加载成功但/dev/ipmi0就是不出来。说实话这个报错本身并不复杂但难点在于信息太简短错误提示完全看不出到底是驱动问题、硬件问题还是系统安全策略问题。这篇文章我打算从原理讲起把IPMI驱动家族梳理一遍然后根据常见报错信息对号入座给你一套可以照着做的排查流程最后复盘几个我实际遇到过的现场案例希望能帮你在最短时间内定位问题。1. 先搞明白ipmi_si是干嘛的驱动家族怎么分工1.1 IPMI和BMC两分钟扫盲做服务器运维的人几乎都绕不开“带外管理”这个词。带外管理的核心是BMC芯片和它对外暴露的IPMI接口。IPMI是一种协议BMC是承载这个协议的物理硬件——一颗独立于CPU的小型处理器。只要主板通着电哪怕操作系统挂了、机器已经关机BMC都能通过网络接口继续工作。远程开关机、看温度、看风扇转速、看电压用的全是它。为什么这和你执行modprobe ipmi_si有关因为操作系统内部要访问BMC靠的不是BIOS界面也不是拉一条网线连上去用命令行——而是需要一组内核驱动替用户态程序把IPMI命令送进BMC。ipmi_si就是其中最关键的硬件适配层驱动之一。简单理解BMC是藏在服务器主板角落里的“小管家”IPMI是和小管家沟通的“普通话”而ipmi_si就是操作系统这边的一个“翻译官”。翻译官没上岗应用层喊破喉咙小管家也听不见。1.2 Linux下的IPMI驱动并不是一个文件Linux内核给IPMI准备了一整套驱动它们不是同一个文件而是分层的多个模块。很多人在这一步就开始混乱了我先把这些模块的关系捋清楚ipmi_msghandler最底层消息处理模块所有IPMI驱动都依赖它相当于IPMI驱动的“地基”。ipmi_si系统接口驱动负责访问主板上的KCS、BT、SMIC这些硬件接口是与BMC硬件通信的关键模块。ipmi_ssif走SMBus/I2C总线访问BMC的驱动一些低成本板子或特定平台会用到。ipmi_devintf用户态接口驱动它负责生成/dev/ipmi0这个设备节点用户态程序如ipmitool才能访问。ipmi_poweroff、ipmi_watchdog辅助功能模块分别处理断电控制、看门狗用的场景少一些。可以用一个不太严谨但容易记的类比ipmi_msghandler是总公司ipmi_si是外派到硬件接口上的业务员ipmi_devintf是前台接待。外部程序找前台前台交给业务员业务员跑到BMC那边谈业务。三层缺一个环节都不行。其中加载ipmi_si只解决了“和BMC硬件通信”这一层。很多新手执行modprobe ipmi_si发现没报错但一查/dev/ipmi0不存在就懵了——其实是ipmi_devintf根本没加载。所以后面验证的时候这三个模块的状态我会一起检查。1.3 什么时候会让你手动敲modprobe ipmi_si正常来说多数主流服务器发行版会在安装时自动加载IPMI驱动但实际情况总有不尽人意的地方常见的需要手动操作场景有这几种刚装完操作系统准备装ipmitool做硬件巡检结果发现/dev/ipmi0不存在这就是典型的手动加载场景。服务器上架后要配置带外管理需要先用ipmitool查看BMC当前网络配置这时发现内核没加载IPMI驱动。某个监控软件比如Zabbix、Nagios启用了IPMI监控项结果一直报“无法连接到IPMI接口”。某些品牌服务器的厂商管理代理比如Dell OMSA、HP/慧与的AMS在安装时会检查内核IPMI驱动是否就绪驱动没加载会直接导致代理服务起不来。系统升级内核后原本自动加载的模块因为签名问题被拦住需要手动处理。明白这些背景之后你再遇到modprobe ipmi_si报错就不会只盯着那一行错误发愁了——它只是链条上的一环上下游都值得排查。2. modprobe ipmi_si 报错的几种典型信息先对号入座2.1 Operation not permitted黑名单与Secure Boot谁是主谋这是大家反馈最多的报错。完整信息长这样$ modprobe ipmi_si modprobe: ERROR: could not insert ipmi_si: Operation not permitted注意这个报错本身并不会直接告诉你是哪种原因我总结下来主要有两种可能第一种是模块被加入黑名单。发行版默认或人为在/etc/modprobe.d/里写入了blacklist ipmi_si这种情况下modprobe会直接拒绝加载。排查方法很简单grep -rn blacklist /etc/modprobe.d/ /lib/modprobe.d/如果看到blacklist ipmi_si把那行注释掉或者删掉即可。但我要提醒一句有的黑名单是厂商为了规避硬件缺陷特意加的比如某些型号的主板加载ipmi_si后会导致系统卡死。删之前最好查一下这台机器的型号和已知问题。第二种是Secure Boot安全启动开启导致的内核模块锁定。现在新出的服务器、预装系统几乎默认开启Secure Boot。当内核处于锁定状态lockdown时凡是无法通过签名验证的模块都会被拒绝报错可能只是简单的Operation not permitted。要区分这两种情况得看内核日志也就是下一步要说的dmesg。2.2 Required key not available签名验证失败这个报错比Operation not permitted更直白它说明Secure Boot确实开着而且当前模块没有有效的签名。$ modprobe ipmi_si modprobe: ERROR: could not insert ipmi_si: Required key not available这里要解释一下Secure Boot的机制。简单说当Secure Boot开启时内核只会加载带有效签名的模块签名所用的密钥必须是被UEFI固件信任的。发行版自带的ipmi_si模块一般都有签名能正常加载。但如果你自己下载编译了驱动模块、用了DKMS项目或者从第三方仓库装了一个没签名的版本加载时就会撞上这个报错。从实际操作看最容易触发这个问题的场景是Ubuntu上做内核模块编译开发或者使用了一些第三方监控内核模块连带着ipmi_si的依赖也被重新编过。还有一种情况是内核升级后旧模块目录里的文件和新内核不匹配或者模块在备份目录里丢失了签名信息。遇到这个报错我的建议顺序是优先确认使用的模块是不是发行版自带的modinfo ipmi_si | grep filename看看路径是不是标准的内核模块目录。如果路径正常检查Secure Boot状态mokutil --sb-state。如果确认是自己编译的模块要么给模块签名并导入MOKMachine Owner Key要么在生产环境慎重评估后关闭Secure Boot。关于导入MOK的具体操作后面案例部分我会详细演示。2.3 Unknown symbol in module, or unknown parameter这个报错相对少见但一旦出现通常和依赖没加载或参数错误有关。$ modprobe ipmi_si modprobe: ERROR: could not insert ipmi_si: Unknown symbol in module, or unknown parameter先说依赖问题。ipmi_si依赖ipmi_msghandler正常情况下modprobe会自动加载依赖模块但如果系统里模块依赖信息出了问题比如内核升级后没执行depmod就会报此类错误。解决方式是重新生成模块依赖关系depmod -a再说参数问题。如果你在/etc/modprobe.d/里写了options ipmi_si xxxyyy但模块并不认识xxx这个参数同样会报unknown parameter。检查方式modinfo ipmi_si | grep parm看看模块真正支持的参数都有哪些再修改配置文件。另外还有一种情况是模块二进制和当前内核版本不匹配比如从另一台机器拷贝了模块文件过来。这时候重点检查uname -r和/lib/modules/$(uname -r)/路径是否一致即可。2.4 不报错但设备节点不出来最隐蔽的“伪失败”第三种情况最坑人——你执行modprobe ipmi_si没有收到任何报错但运行ipmitool mc info的时候依然提示连接失败检查/dev/ipmi0发现根本不存在。这个“伪成功”状态的本质是驱动加载了但没探测到硬件。可能的原因有几种ipmi_devintf模块没有加载导致设备节点没生成。这种情况最简单补一个modprobe ipmi_devintf再看。BIOS里BMC功能被禁用。很多品牌服务器的BIOS默认关闭了BMC相关开关需要进BIOS里打开。这台机器压根没有BMC芯片。一些低端主板、白牌机或者入门级服务器没有板载BMC无论你怎么加载驱动都不可能凭空变出/dev/ipmi0。所以遇到这种情况第一件事不是纠结驱动而是先确认硬件层面到底有没有BMC。检查方法我放在下一节详细说。3. 从看到报错到定位根因的完整排查链路3.1 第一步先看dmesg报错的第一现场很多人拿到modprobe报错第一反应是去搜索引擎搜那行字其实最快的定位方式是先看内核日志。modprobe输出的信息非常精简真正的细节全部在内核日志里。dmesg | tail -50或者用journalctljournalctl -k -n 50日志里和IPMI相关的行重点看这几类日志关键字含义ipmi_si: Trying SMBIOS-specified kcs interface at驱动在尝试按照SMBIOS表提供的地址探测接口ipmi_si: Unable to find any System Interface(s)所有接口探测失败没找到BMCipmi_si: Interface factory failed接口初始化失败可能是地址被占用或硬件异常module verification failed: signature and/or required key missingSecure Boot签名验证失败Lockdown: ...内核已进入锁定状态拒绝加载未签名模块举个例子报错Operation not permitted时dmesg里如果出现类似module verification failed的关键字那几乎可以确定是Secure Boot在拦路。如果日志里干净得什么都没有那就要优先考虑模块被黑名单拦了或者是modprobe配置出了问题。记得有一次客户报障说某台机器执行modprobe ipmi_si报错Operation not permitted我远程上去先跑dmesg一眼就看到integrity: Loading of unsigned module is restricted问题瞬间定位。而另一位同事一开始就在那儿反复检查文件权限折腾了半小时。所以dmesg永远是第一步。3.2 第二步确认硬件层面有没有BMC这颗“心脏”软件报错查完之后就该确认硬件了。在Linux下判断BMC是否存在最标准的命令是dmidecode -t 38这个命令专门查SMBIOS里的IPMI Device信息。如果输出类似下面这样说明硬件层有BMC并且接口类型、基地址都被固件登记好了Handle 0x0049, DMI type 38, 18 bytes IPMI Device Information Interface Type: KCS (Keyboard Control Style) Specification Version: 2.0 I2C Slave Address: 0x10 Base Address: 0x0000000000000CA2如果这条命令没有任何输出基本说明SMBIOS表里没有IPMI设备记录硬件层面可能压根没有BMC。不过也有例外个别主板的BIOS把BMC功能禁用后SMBIOS表里一样查不到。这种情况要重启进BIOS找到类似下面的选项IPMI BMC SupportBMC FunctionOnboard LAN或BMC LAN ConfigurationIPMI Over LAN不同品牌的BIOS命名不一样但关键词基本都带IPMI或者BMC。把这些选项改成Enabled保存重启后重新执行dmidecode -t 38一般就能看到了。另外我还要特别提醒一种情况很多虚拟化环境VMware、KVM、Hyper-V里跑的虚拟机是不存在真实BMC的。如果在虚拟机上执行dmidecode -t 38大多数时候没有任何输出除非虚拟化平台特意模拟了IPMI设备。所以在虚拟机里排查BMC硬件基本没有意义早点明确这一点能省下不少时间。3.3 第三步逐个排除模块链路硬件层面确认没问题后回到软件链路继续排查。这一步我习惯用一个“五连查”清单很快就能过滤掉大部分问题# 1. 当前内核版本 uname -r # 2. 模块文件是否存在 ls -l /lib/modules/$(uname -r)/kernel/drivers/char/ipmi/ # 3. 模块依赖信息是否正确 depmod -a # 4. 查看模块信息确认依赖和参数 modinfo ipmi_si # 5. 查看已加载状态 lsmod | grep ipmi其中modinfo ipmi_si的输出里depends:这一行很关键。正常情况下应该是ipmi_msghandler。如果depends:是空的或者特别奇怪那说明模块依赖信息损坏了用depmod -a重新生成就行。另外还要检查模块是否被lockdown或签名问题拦截这可以看dmesg里有没有相关消息。检查Secure Boot状态用mokutil --sb-state输出SecureBoot enabled表示开启。完成这五连查之后90%的问题基本都有方向了。剩下10%的场景比较诡异可能就是个别服务器品牌的固件兼容性问题这种时候建议直接看厂商的兼容性列表或者联系技术支持。3.4 一个真实排查案例的完整记录为了方便理解我把一次比较有代表性的排查过程完整记录下来。问题现象RHEL 8.6服务器执行modprobe ipmi_si报错Required key not available。排查第1步看dmesgdmesg | tail -20关键输出Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7 Loading of unsigned module is restricted; see man kernel_lockdown.7到这里基本能确定是签名问题不是硬件问题。排查第2步确认Secure Boot状态mokutil --sb-state SecureBoot enabled排查第3步确认模块来源modinfo ipmi_si | grep filename filename: /lib/modules/4.18.0-372.19.1.el8_6.x86_64/kernel/drivers/char/ipmi/ipmi_si.ko.xz顺藤摸瓜查看这个文件是否带签名test -f /lib/modules/$(uname -r)/kernel/drivers/char/ipmi/ipmi_si.ko.xz echo exists模块路径存在但dmesg说加载被限制说明文件内的签名信息不被信任。这台机器是客户之前为了某个专用驱动装的DKMS环境系统在DKMS编译过程中把部分哈希更新了导致ipmi_si的签名链断了。处理方案把发行版原始的模块文件从安装ISO对应内核版本里恢复出来然后跑depmod -a重新modprobe ipmi_si问题解决。这个案例给我们的经验是当Required key not available出现时不要一上来就想着关闭Secure Boot先检查模块文件本身是否被第三方工具或DKMS动过。生产环境里贸然关Secure Boot安全合规上往往说不过去。4. 内核参数与硬件接口类型ipmi_si也能按需定制4.1 KCS、BT、SMICBMC接口类型三兄弟ipmi_si这个驱动并不是只管一种硬件接口它同时支持三种系统接口KCS、BT、SMIC。最常见的当属KCSKeyboard Controller Style这种接口通过I/O端口或内存映射寄存器来传输IPMI消息几乎所有主流服务器都采用它。BTBlock Transfer接口主要出现在一些老型号服务器上它的特点是传输效率更高一点但复杂度也上去了。SMICServer Management Interface Chip就更老一些只在很早期的某些平台上出现过。怎么知道你的机器用的是哪种接口还是看dmidecode -t 38输出里的Interface Type一栏写得清清楚楚。如果没有明确说明绝大多数情况默认就是KCS不用纠结。搞清楚接口类型有什么用主要是在驱动探测异常时可以用参数强制指定接口类型省得让驱动去猜。4.2 让ipmi_si“听指挥”的主要参数ipmi_si支持的模块参数不算多但有几个在实际排查中很有用。用modinfo ipmi_si可以看到完整清单我重点介绍几个常用的type指定接口类型可选值kcs、bt、smic。默认情况下驱动会尝试探测所有类型如果你明确知道自己的接口是KCS可以写成typekcs减少不必要的探测步骤。ports指定I/O端口地址多个端口用逗号分隔。比如ports0xca2。addrs指定内存映射地址适合BMC寄存器走内存映射的平台。irqs指定中断号一般不用手动设置。有朋友会问如果我的BMC在SMBIOS表里登记了正确的地址是不是不用管这些参数是的。绝大多数情况下驱动会自动从SMBIOS读取接口地址不需要人为干预。什么情况下才需要手动指定我遇到过的典型场景是主板BIOS没有把BMC地址写进SMBIOS表或者工程师在BIOS里手动改过一个非标准的BMC地址导致驱动按默认探测方式找不到。这时候在/etc/modprobe.d/ipmi.conf里写options ipmi_si typekcs ports0xca2 regspacings1注意regspacings这个参数它表示寄存器之间的间隔字节数有些厂商的BMC寄存器排列不按标准来需要配合这个参数调整。具体数值得看硬件手册或厂商技术支持的建议没有把握不要乱填。4.3 模块参数与内核启动参数的正确写法关于参数的写法我见过不少搞混的情况这里单独拉出来说明。在modprobe配置里写法是options ipmi_si typekcs ports0xca2如果在GRUB内核启动参数里指定写法是ipmi_si.typekcs ipmi_si.ports0xca2两者区别在于模块参数直接写在模块名后面而内核启动参数要用模块名加类型形式。GRUB里修改的具体操作不同发行版有差异。RHEL/CentOS系列可以用grubbygrubby --update-kernelALL --argsipmi_si.typekcsUbuntu/Debian系列则是改/etc/default/grub在GRUB_CMDLINE_LINUX里加参数然后执行update-grub。还有一个值得注意的点内核启动参数和modprobe.d里的options如果同时存在并且冲突行为可能不符合预期。最保险的做法是只保留一种配置方式不要两边都写。我建议优先用modprobe.d配置因为改完以后只需要重启模块相关服务或者重新modprobe就可以生效而GRUB参数得重启机器。另外如果使用systemd系发行版改完modprobe.d后可以执行systemctl restart systemd-modules-load或者直接重新加载模块modprobe -r ipmi_si modprobe ipmi_si当然前提是模块当前没有被其他进程占用否则-r会报Module ipmi_si is in use。这种情况先停掉占用的程序比如ipmitool、监控代理再操作。5. 四个真实场景复盘覆盖大半报错现场5.1 场景一Ubuntu下自己在DKMS里编译过ipmi相关模块这个场景我在不少开发机上遇到过。用户装了一个带BMC的显卡或者网卡厂商提供了DKMS驱动安装过程中会同时把自己的IPMI相关代码也编进内核模块搜索路径。等到内核升级后模块目录里既有发行版签名模块又有DKMS生成的未签名模块modprobe一执行就报Required key not available。完整的排查命令序列# 确认当前签名状态 mokutil --sb-state # 查看错误日志 dmesg | tail -30 # 检查模块文件实际位置和签名 modinfo ipmi_si | grep filename如果确认是DKMS生成的未签名模块有两种处理办法一种是把DKMS模块移除恢复系统自带的模块。执行dkms status看看哪些DKMS包正在使用配合modinfo确认文件路径后把不对的模块文件删掉重新depmod -a。另一种是给模块做签名并导入MOK。先生成密钥对和签名证书# 生成MOK密钥 openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 365 -subj /CNMyKey/ # 签名模块 /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 MOK.priv MOK.der ipmi_si.ko然后导入MOKmokutil --import MOK.der重启后会出现MOK管理界面确认导入即可。整个过程在Ubuntu官方文档里有详细说明建议按文档操作。这种方法比简单关Secure Boot要稳妥得多既保留了系统安全机制又让模块能顺利加载。5.2 场景二某品牌服务器BIOS里默认关闭了BMC功能这个场景来自一次一线现场。同事说服务器上modprobe ipmi_si没有任何报错但是/dev/ipmi0不存在ipmitool直接报Could not open device at /dev/ipmi0。我先在机器上执行了dmesgdmesg | grep -i ipmi ipmi_si: Unable to find any System Interface(s)这行日志说明驱动加载了但搜索不到BMC接口。然后执行dmidecode -t 38结果一片空白。当时我第一判断是这块主板可能没有板载BMC。不过再一想这类品牌服务器连个入门型号都带IPMI功能不应该查不到。后来进BIOS翻了一遍发现有个叫Onboard LAN Function的选项下面的子选项里有一个IPMI Over LAN被设成Disabled同时还有一个BMC Self Test选项显示结果是BMC not responding。把IPMI Over LAN和相关BMC选项全部改成Enabled保存重启后再执行dmidecode -t 38这次能看到类似IPMI Device Information Interface Type: KCS (Keyboard Control Style) Base Address: 0x0000000000000CA2再加载模块modprobe ipmi_si modprobe ipmi_devintf ls -l /dev/ipmi0设备节点顺利出现。这个案例的教训是ipmi_si: Unable to find any System Interface(s)不一定是硬件缺失也可能是固件里把BMC关掉了。遇到这种日志先别急着下结论进BIOS确认一下BMC相关开关是最稳妥的步骤。5.3 场景三KVM虚拟机上折腾ipmi_si这是我最想帮大家避开的坑。有朋友在KVM虚拟机里执行modprobe ipmi_si报错Unable to find any System Interface(s)然后各种加参数、改地址折腾了一整天。说实话普通KVM虚拟机默认不模拟IPMI设备BMC这东西在虚拟化世界里面是一个可选的模拟外设。除非宿主机的虚拟机XML里显式配置了ipmi-bmc-sim和ipmi-bmc-extern相关的设备否则虚拟机里根本没有BMC硬件你让ipmi_si怎么工作所以遇到虚拟机环境执行modprobe ipmi_si找不到接口的情况正确的处理方式是想清楚你到底需不需要在虚拟机里看到IPMI如果是为了监控宿主机硬件健康直接在宿主机上加载驱动就行如果是为了测试IPMI客户端程序那就得先在虚拟化层把虚拟IPMI设备加上而这一步通常是由负责虚拟化平台的人来做的普通应用层面操作不了。这个案例想强调的就一点排查问题之前先确认运行环境。在虚拟机里花时间调ipmi_si参数大概率是白费力气。5.4 场景四自动加载配置写错开机后慢得要命还有一种情况不是手动modprobe ipmi_si报错而是开机自动加载IPMI模块时机器启动变得异常慢或者启动过程中直接碰到错误信息。我见过一个案例管理员在/etc/modules-load.d/ipmi.conf里写了这样一行ipmi_si.ko问题就出在这个.ko后缀上。/etc/modules-load.d/这个目录里的文件每行只需要写模块名不需要带.ko后缀也不需要写路径。带后缀反而导致systemd-modules-load服务找不到模块启动时报错。正确写法是ipmi_msghandler ipmi_si ipmi_devintf另一个常见问题是把模块参数写进了modules-load.d比如ipmi_si typekcs这同样是错的modules-load.d只负责“加载哪些模块”不负责“传给模块什么参数”。参数要放到/etc/modprobe.d/ipmi.conf里写成options ipmi_si typekcs这种文件名带后缀、参数放错文件的问题要是遇到生产环境重启整个运维团队都会紧张。其实排查起来也很直接看一眼报错时systemd日志里的服务名多半是systemd-modules-load然后用systemctl status systemd-modules-load就能看到具体的模块名和错误信息。6. 开机自动加载的正确姿势与验证清单6.1 一套稳妥的配置方案可以直接抄如果你希望服务器开机后自动加载IPMI驱动我建议按下面的方式配置。这套方案在我这边多个发行版上都验证过稳定可靠。第一步创建/etc/modprobe.d/ipmi.conf只写参数不写加载指令options ipmi_si typekcs如果服务器型号比较老BMC地址在SMBIOS表里可能没登记可以在这一行里补充端口地址options ipmi_si typekcs ports0xca2第二步创建/etc/modules-load.d/ipmi.conf按依赖顺序写入需要加载的模块ipmi_msghandler ipmi_si ipmi_devintf为什么modules-load.d里只写模块名不带参数因为模块加载器会自动在modprobe.d中查找同名模块的options配置两边分开写职责清晰也方便单独修改参数而不影响加载列表。这套方案在RHEL、Ubuntu、Debian、openSUSE上都可以直接用因为这些系统都使用systemd作为init系统。配置做完以后先不要急着重启可以在当前环境直接验证systemctl restart systemd-modules-load如果配置正确执行完后再看模块状态。6.2 加载成功后如何验证一切正常验证IPMI驱动是否正常工作我习惯按顺序跑这几条命令# 1. 确认模块加载状态 lsmod | grep ipmi预期输出应该包含ipmi_msghandler、ipmi_si、ipmi_devintf三个模块缺哪个补哪个。# 2. 确认设备节点 ls -l /dev/ipmi*正常情况下能看到/dev/ipmi0这是一个字符设备。# 3. 确认内核日志没有异常 dmesg | grep -i ipmi理想状态下能看到类似ipmi_si: Trying SMBIOS-specified kcs interface这种正常探测日志不会出现Unable to find any System Interface(s)。# 4. 用ipmitool验证BMC通信 ipmitool mc info这一步是最终验证。如果驱动链路全通命令会返回BMC的固件版本、厂商ID、设备ID等信息。如果输出报错Could not open device at /dev/ipmi0说明设备节点没生成如果返回Error getting response说明设备节点在但BMC通信链路有问题这种情况要看硬件层和BIOS配置。对于要长期监控服务器健康的场景我还会额外检查ipmitool sensor list能否正常读出传感器数据比如CPU温度、风扇转速。这一项能通说明BMC和应用层之间的数据链路整个是健康的。6.3 反面场景机器不需要IPMI怎么彻底禁用并不是所有机器都需要IPMI驱动。一些低成本的服务器或工控机没有板载BMC而ipmi_si驱动在加载时会尝试扫描多个地址这个探测过程在某些主板上会拖慢开机速度。如果你的机器确认没有BMC也不打算用IPMI那可以考虑把相关模块加入黑名单省去每次开机的探测等待。创建/etc/modprobe.d/blacklist-ipmi.confblacklist ipmi_si blacklist ipmi_ssif blacklist ipmi_devintf blacklist ipmi_msghandler这里有一个容易踩的坑只blacklist ipmi_si不blacklist ipmi_devintf在某些内核版本上也可能生效但最稳妥的做法是四个相关模块全部列出。因为这些模块之间有依赖关系只要其中一个被加载另一个就可能被联动加载最后导致黑名单形同虚设。改完配置后先别急着重启手动试试卸载当前已加载的模块modprobe -r ipmi_devintf modprobe -r ipmi_si modprobe -r ipmi_msghandler如果模块被占用了会报is in use错误那就先停掉使用IPMI的程序再试。最后说一个反向提醒如果你在机房跑着一堆有硬件监控需求的业务机器把IPMI驱动禁掉之前一定要先确认监控方案是不是完全依赖带外方式。因为很多监控软件在用IPMI通道的同时也会用SNMP或厂商专属代理走带内方式。如果把内核里的IPMI驱动直接禁了带内方式的硬件监控可能也会受影响那时候你就只能靠BMC的Web页面看了自动化监控就断了。整个过程走下来我个人最深的体会有两点。第一报错信息越短越要沉住气去看内核日志modprobe那一行字只是一个敲门声真正的房间在dmesg里。第二动手改配置前先明确一个问题这台机器到底有没有BMCSecure Boot到底关不关。把这两件事确认清楚modprobe ipmi_si报错这个事基本就解决一大半了。我在日常运维中已经把这套排查流程固定成了文档新上架的服务器第一件事就是按这个流程过一遍省了很多事后排障的时间。