前段时间接手一台 Dell PowerEdge R750配置单上写着 PERC H750 阵列卡系统要求换成 openEuler 22.03 LTS SP3。装机那天我以为半小时能收工结果卡在安装界面未找到可用磁盘上整整一下午。Dell PERC H750 RAID 卡在 openEuler 下的驱动不适配表面看是个缺驱动的小问题实际牵扯到内核自带模块、安装介质 initramfs、驱动盘加载、DKMS 编译、Secure Boot 签名、固件版本五六层东西。这篇就把我这次从装不上到装得上、从装得上到跑得稳的全过程摊开讲一遍包括中间踩的坑、误判的方向、以及最后验证硬件 RAID 真正生效的方法。如果你手上的机器是 Dell 14G/15G 服务器R640、R740、R750、R650 这些卡是 PERC H750、H755、H740P 这一挂装的又是 openEuler、麒麟、统信或者别的国产化发行版那这篇基本能照着抄。1. 先把问题定性所谓驱动不适配到底是哪一层不适配很多人一上来就问哪里有 H750 的 Linux 驱动下载这个问法本身就偏了。在 Linux 世界里驱动不适配至少有三种完全不同的含义对应的处置手段也完全不一样先定性再动手能省掉大量无用功。1.1 PERC H750 在 Linux 里的驱动归属PERC H750 是 Dell 15G 服务器上的主流硬件 RAID 卡芯片方案来自 Broadcom 的 MegaRAID 家族在 Linux 内核里对应的驱动模块名是megaraid_sas。这一点非常关键它不是一块需要厂商单独提供闭源驱动的怪卡主流内核里本来就带着它的代码。openEuler 22.03 LTS 基于 5.10 系列内核megaraid_sas是编译进内核包里的/lib/modules/$(uname -r)/kernel/drivers/scsi/megaraid/下面能找到对应的.ko.xz文件。那为什么还会装不上因为内核里有这个模块和系统启动时能用上这个模块是两件事。你的根文件系统如果放在这块卡做的 RAID 卷上那么系统在挂载根之前就必须先加载megaraid_sas而这个加载动作是由 initramfs初始化内存盘完成的。如果 initramfs 里没有打包这个模块内核跑到挂载根的那一步就会干瞪眼最后丢出一句dracut: no root device或者一串 timeout。判断方法很简单在任意能进系统的环境下敲modinfo megaraid_sas ls -l /lib/modules/$(uname -r)/kernel/drivers/scsi/megaraid/如果modinfo有输出说明模块存在问题在没被用上如果报Module not found那才是真的缺模块得走厂商驱动那条路。这两种情况的处置完全不同别混着搞。1.2 三种典型故障现象对应三个不同根因我把这次以及之前几次遇到的现场整理成三类你可以对号入座故障现象真实根因判断依据安装界面里没有可用磁盘连一个块设备都看不到安装介质的内核/initramfs 里没有可用驱动或卡处于非 RAID 模式切到 tty2 敲lsmod、lsblk、dmesg全无 RAID 相关记录装完重启卡在 dracut timeout提示找不到根设备模块存在但没被打进 initramfs或驱动加载顺序排在根挂载之后用安装盘进 rescuechroot后lsinitrd查不到 megaraid_sas系统能进能看到磁盘但只能看到单块盘、容量不对或性能异常卡被切成了 HBA/直通模式或者 RAID 卷根本没建perccli64 /c0 show看 Personality 字段lsblk看设备数量第一类和第二类的区别特别容易被忽略——前者是安装介质的问题后者是目标系统的问题。我见过有人明明系统装完了重启进不去就以为是驱动没装回头又去折腾安装盘白折腾了一晚上。1.3 为什么 openEuler 上更容易撞到这类问题说句实在话这不是 openEuler 独有的毛病。Dell 官方给 Linux 的驱动盘DUDDriver Update Disk和 rpm 包主要针对 RHEL、SLES 这几条线做认证。openEuler 虽然用户态体系高度接近 RHEL 8同样是 anaconda 安装器、dracut、rpm/dnf 包管理但它用的是自己的内核版本号比如5.10.0-153.xx.xDKMS 编译第三方驱动时偶尔会因为内核 API 微调而过不去。所以现象是RHEL 8 上顺顺利利的驱动盘在 openEuler 上能加载但装完起不来或者 RPM 装上了depmod一跑报符号缺失。另外一点是固件。PERC H750 的固件版本如果和内核驱动的适配矩阵对不上轻则功能受限比如 RAID6 的某些模式不支持重则直接认不到盘。Dell 的 15G 服务器出厂的阵列卡固件往往不是最新而新固件又经常要求较新的驱动版本两头卡着。提示动手之前先把卡固件版本和内核驱动版本两个数字都记下来后面所有对比判断都要用。固件版本用perccli64 /c0 show看驱动版本用modinfo megaraid_sas | grep -i version看。2. 开工前必须做的准备工作把适配问题提前解决装机现场最忌讳边装边想。我在办公室先把下面这些事做完了到机房只花了四十分钟就把系统装上。准备工作做扎实能砍掉一大半现场时间。2.1 先确认卡的身份和当前工作模式第一步不是找驱动是确认硬件本身没问题、模式没搞错。把机器通电进阵列卡的管理界面15G 服务器开机时按 F2 进 BIOS或者用 iDRAC 的虚拟控制台或者在能跑命令的环境里执行lspci -nn | grep -i -E raid|sas|broadcom|lsilogic lspci -k -s 03:00.0 # 换成上面查到的实际槽位 cat /sys/block/sda/device/modellspci -nn输出的方括号里会有一串形如1000:xxxx的 ID这就是 PCI 厂商 ID:设备 ID。把设备 ID 记下来去对照内核源码里megaraid_sas的 ID 表就能确认这个内核到底认不认你这块卡。lspci -k会告诉你当前这个 PCI 设备绑定到了哪个驱动上如果显示Kernel driver in use: megaraid_sas说明驱动路径是通的如果显示vfio-pci或干脆没有Kernel driver in use那一行那就是没绑定上。还有一种情况要特别留意部分型号的 PERC 卡在较新固件下可以切换成 HBA 直通模式Dell 叫 eHBA 或者 non-RAID切了之后走的驱动就变成mpt3sas了不再是megaraid_sas。这时候你在系统里看到的是一堆物理单盘而不是一个 RAID 卷。有人遇到装完只有单盘、容量也不对一通 modprobe 折腾不下来最后发现是卡的模式被切了。如果你还没建 RAID 卷先建。在卡的 BIOS 界面里创建虚拟磁盘或者在 Linux 下用 perccliperccli64 /c0 add vd typeraid5 drives252:0-3 perccli64 /c0/vall show注意卷没建就上操作系统看到的一定是一堆单盘。这不是驱动问题是配置问题别把时间浪费在找驱动上。2.2 挑对安装镜像和启动方式openEuler 22.03 LTS 目前有 SP1/SP2/SP3 几个小版本内核版本号各不相同。如果你已经确认这台机器的卡在某个内核版本下是能认的就优先用那个版本别盲追最新。另外镜像要选x86_64的完整版everything 或 DVD 版不要选网络安装的 netinst 版本——网络版体积小内含的驱动模块更少反而更容易出问题。启动方式这块有两个坑BIOS 还是 UEFI15G 服务器上 PERC 系列阵列卡基本只提供 UEFI 驱动没有传统 Option ROM。所以系统必须按 UEFI 模式装启动顺序里把包含阵列卡的那一项排前面。Secure Boot默认开着的话第三方签名的内核模块会加载失败dmesg里会出现Key was rejected by service之类的字样。装机阶段建议先关掉装完确认一切正常以后再决定要不要开回去并做签名。这两条我在现场见过太多人栽进去尤其是 Secure Boot报错信息很隐晦看着像驱动问题其实是签名问题。2.3 提前把驱动盘和 rpm 包准备好Dell 官网按服务器型号查驱动找到 SAS RAID 控制器对应条目选择 RHEL 8.x 版本一般能拿到两样东西一个是驱动程序更新盘镜像通常叫dd.iso或者 DUD一个是驱动 rpm 包或源码包。openEuler 的用户态和 RHEL 8 高度接近这两个东西多数情况下可以直接用。driver disk 我习惯这么处理# 写到一个 U 盘上注意确认设备名别写错盘 dd ifdd.iso of/dev/sdb bs1M statusprogress convfsync # 或者不解压直接把 dd.iso 拷到另一个 U 盘的普通分区根目录 cp dd.iso /run/media/u盘挂载点/两种方式对应两种加载写法下面会讲。除了驱动盘顺手把 rpm 包也拷一份到 U 盘上装完系统之后大概率还要用。还有一件事别忘把服务器的 iDRAC 里的固件版本也对一遍如果阵列卡固件明显落后于驱动适配矩阵的要求先在 iDRAC 的 Lifecycle Controller 里把卡固件升上去再装系统。固件升级顺序错了后面会反复返工。3. 三条救场路线从最省事到最彻底确认完硬件和准备工作接下来就是选路线。我把可行的方案按复杂度排成三条能走第一就别走第二能走第二就别走第三。3.1 路线一让内核自带的模块正常发挥作用绝大多数情况的真相是——驱动本来就够用只是没被正确搬进 initramfs。这条路线不装任何第三方东西纯用系统自带能力。先进安装器的 rescue 模式或者用安装盘启动后切到 tty2确认模块到底在不在lsmod | grep -i megaraid modinfo megaraid_sas | head -20如果模块存在但没加载手动modprobe megaraid_sas然后看磁盘有没有出现modprobe megaraid_sas lsblk cat /proc/partitions dmesg | grep -i -E megaraid|sas设备出现了说明路子对了。接下来要做的就是把开机自动加载这件事固化下来。做法是在目标系统里加一个 dracut 配置并重建 initramfscat /etc/dracut.conf.d/99-megaraid.conf EOF add_drivers megaraid_sas force_drivers megaraid_sas EOF # 重建当前内核的 initramfs dracut -f /boot/initramfs-$(uname -r).img $(uname -r) # 或者图省事全部内核一起重建 dracut -f --regenerate-allforce_drivers这个参数特别有用它的语义是这几个模块必须在挂载根之前就加载正好对上我们的需求。很多人只写了add_drivers结果模块是打进去了但加载时机排在根挂载之后照样起不来。再加一道保险把驱动的加载顺序提到内核命令行最前面grubby --update-kernelALL --argsrd.driver.premegaraid_sas cat /boot/grub2/grub.cfg | grep rd.driver.pre改完之后一定要验证 initramfs 里真的有这个模块lsinitrd /boot/initramfs-$(uname -r).img | grep megaraid有输出才算成功没有就回去看配置文件的写法别靠猜。3.2 路线二安装阶段用驱动盘救场如果内核里确实没有对应驱动或者安装器根本没带那就得在安装阶段把驱动喂进去。openEuler 用的是 anaconda 安装器支持inst.dd这个内核参数用法和 RHEL 完全一样这是它比很多人想象中好用的地方。在安装启动菜单上选中启动项按e编辑内核命令行在linuxefi那一行末尾追加inst.dd不要给值就这么光着写。这样 anaconda 会主动问你驱动盘在哪个设备上你在界面上选 U 盘对应的分区就行比背设备名靠谱得多。如果你的 U 盘上放的是dd.iso文件而不是写入的设备就写成inst.ddhd:/dev/sdb1:/dd.iso其中/dev/sdb1是 U 盘分区/dd.iso是文件路径。如果驱动盘是刻成光盘放进光驱那就写inst.ddcdrom。加载成功后安装器界面上会多出一行提示说明驱动已经就位这时候再去点安装位置虚拟磁盘就能看到了。有一点要提醒驱动盘里的 rpm 通常会被自动装进目标系统并且在生成目标系统 initramfs 时把驱动带上。但这一步不是百分之百成功——我在一次 SP3 的安装里就遇到过驱动盘加载了、安装也走完了、重启却起不来原因是目标系统的 initramfs 重建阶段模块被过滤掉了。所以装完之后别急着庆祝先按 3.1 的方法手工再确认一遍 initramfs 内容和 grub 参数。3.3 路线三第三方驱动 DKMS硬扛内核升级如果自带模块版本太老功能上缺东西比如某些 RAID 模式不支持、性能明显不对那就得用厂商提供的驱动 rpm 或源码包覆盖掉内核自带版本。这里的关键是怎么覆盖和怎么在升级内核之后不翻车。Linux 加载模块时是按目录优先级找的。用modinfo -n megaraid_sas能看到当前实际用的是哪个路径下的文件modinfo -n megaraid_sas # 例如输出 /lib/modules/5.10.0-153.x86_64/extra/megaraid_sas.ko.xz只要第三方模块落在extra/或updates/这类目录里就会优先于内核自带的kernel/目录被加载。装完驱动后别忘了跑一遍depmod -a让它重新生成依赖关系表。想让它在内核升级后自动跟着重建就得靠 DKMSdnf install -y dkms kernel-devel kernel-headers gcc make elfutils-libelf-devel # 用 RPM 方式装 rpm -ivh dell-megaraid_sas-*.rpm # 或者用源码方式交给 DKMS 管理 dkms add -m megaraid_sas -v 版本号 dkms build -m megaraid_sas -v 版本号 dkms install -m megaraid_sas -v 版本号 dkms statusdkms status显示installed才算成功。如果编译报错八成是内核源码包没装全或者 openEuler 的内核 API 和驱动源码不匹配需要打个小补丁。这种时候我的建议是先在 RHEL 8 同版本上编译一遍看看能不能过能过就是 openEuler 内核差异的问题定位起来快得多。注意在内核升级还没验证通过之前务必把内核版本锁住否则dnf update一不小心升上去第三方驱动没跟上机器直接起不来。锁的方法dnf install -y python3-dnf-plugin-versionlock dnf versionlock add kernel kernel-core kernel-modules4. 一次完整的实操记录从认不到盘到稳定运行前面讲的是方法论这一段把那次 R750 的完整过程按时间线记下来包括每一步的验证动作和我当时的判断依据。4.1 现场环境与初始状态机器是 PowerEdge R750双路PERC H750四块 960G SSD 做了 RAID5系统目标 openEuler 22.03 LTS SP3UEFI 启动Secure Boot 初始开启。第一次装的时候安装器能起来但安装位置页面显示未找到磁盘。切到 tty2 排查dmesg | grep -i -E megaraid|sas|raid | head -30 lspci -nn | grep -i raidlspci能看到 RAID 控制器说明 PCI 层面没问题dmesg里完全没有 megaraid 的初始化日志lsmod里也没有这个模块。结论是安装介质的内核没有加载这个驱动。这就是典型的第一类故障。4.2 安装阶段加载驱动盘的关键动作我回到启动菜单按e在linuxefi行尾追加了inst.dd然后 CtrlX 引导。Anaconda 弹出了设备选择界面我选了 U 盘分区它自动扫描到了驱动盘并提示加载成功。加载完之后回到 tty2 再看一次lsmod | grep megaraid lsblk这次lsmod里有megaraid_saslsblk也能看到一个约 2.6T 的块设备四块 960G 做 RAID5 之后扣除校验的容量实际显示会比标称小一些这是正常的。继续回到图形界面磁盘出现了分区、装系统一气呵成。提示RAID5 的可用容量算法是 (N-1) × 单盘容量四块 960G 大约是 2.88T 标称实际格式化后会更小。看到容量比物理盘总和小别慌那是校验位占的。4.3 装完之后必须补的三件事系统装完第一次重启我在机房里盯着结果是卡在 dracut 的 shell 里提示找不到根设备。这就是前面说的第二类故障——安装阶段驱动进去了但没有被正确带进目标系统的 initramfs。当时的处置是拿安装盘启动进 rescue 模式把根挂上再 chroot 进去修# rescue 模式下先确认分区布局 lsblk fdisk -l /dev/sda # 挂载根和必要的伪文件系统 mount /dev/mapper/openeuler-root /mnt/sysroot mount /dev/sda1 /mnt/sysroot/boot/efi mount -t proc proc /mnt/sysroot/proc mount -t sysfs sys /mnt/sysroot/sys mount -o bind /dev /mnt/sysroot/dev chroot /mnt/sysroot进去之后三件事一件都不能省。第一件写 dracut 配置并重建 initramfscat /etc/dracut.conf.d/99-megaraid.conf EOF add_drivers megaraid_sas force_drivers megaraid_sas EOF dracut -f /boot/initramfs-$(uname -r).img $(uname -r) lsinitrd /boot/initramfs-$(uname -r).img | grep megaraid第二件加内核启动参数grubby --update-kernelALL --argsrd.driver.premegaraid_sas grubby --infoALL | grep -o rd.driver.pre[a-z_]*第三件检查/etc/fstab。这一步被很多人忽略如果 fstab 里写的是/dev/sda2这种内核设备名RAID 卡的驱动加载顺序一变设备名就可能漂移导致系统起不来或者挂错分区。稳妥做法是全部换成 UUIDblkid # 把形如 UUIDxxxx 的标识替换进 /etc/fstab同时顺手在/etc/default/grub里给内核命令行加上rd.auto1之类的稳妥参数视发行版而定改完记得grub2-mkconfig -o /boot/efi/EFI/openeuler/grub.cfg。UEFI 系统里 grub 配置的路径和 BIOS 模式不同写错地方改了等于没改。4.4 验证 RAID 真的在起作用系统能起来不代表万事大吉。我见过系统起来了但是只认到一块单盘的情况用户以为在跑 RAID实际是单盘裸奔硬盘坏了数据就没了。验证要做三层。第一层看块设备的型号cat /sys/block/sda/device/model lsblk -o NAME,SIZE,TYPE,MODEL,MOUNTPOINT如果 model 显示的是类似PERC H750的字样说明你看到的是阵列卡虚拟出来的卷而不是物理磁盘如果显示的是具体硬盘型号那就是直通了。第二层看卡的配置# 安装 perccli 工具包后 rpm -ivh perccli-*.rpm /opt/MegaRAID/perccli/perccli64 /c0 show /opt/MegaRAID/perccli/perccli64 /c0/vall show/c0/vall show会列出所有虚拟磁盘能看到 RAID 级别、状态Optl 表示 Optimal、关联的物理盘和对应的操作系统设备名。这里如果看到状态是Dgrd降级或者Pdgd部分降级赶紧处理别拖。第三层看内核日志dmesg | grep -i -E megaraid|vd|virtual disk journalctl -k -b | grep -i megaraid正常的话能看到虚拟磁盘被识别的记录以及驱动的版本号。把版本号和 Dell 适配矩阵里要求的版本对一下确认没有偏差。注意装完系统之后顺手把网卡配一下openEuler 用的是 NetworkManagernmcli con mod加nmcli con up就能配静态 IP因为后面更新驱动、装 perccli 都可能需要网络。别等到要用了才发现机器没网又得摸黑去机房插网线。5. 常见问题排查速查表与避坑经验这套东西我在不同项目里反复做过好几遍遇到的问题高度重合。下面这张表基本覆盖了九成现场状况建议装机前先扫一眼。5.1 症状-原因-处置对照表症状大概率原因排查命令处置方式安装器里找不到任何磁盘安装介质 initramfs 缺模块切 tty2lsmod、dmesg启动参数加inst.dd加载驱动盘装完重启卡 dracut timeout目标系统 initramfs 缺模块或加载顺序不对rescue 模式下lsinitrd加 dracut 配置重建 initramfs加rd.driver.pre只能看到单块盘、容量不对卡处于 HBA 直通模式或没建 RAID 卷perccli64 /c0 show看 Personality建虚拟磁盘或切回 RAID 模式模块加载失败日志有 Key was rejectedSecure Boot 拦截未签名模块dmesggrep -i -E key内核升级后系统起不来第三方驱动没跟着重建dkms status装 DKMS 或重装驱动未验证前锁内核版本磁盘读写性能明显偏低缓存策略降级、电池/CacheVault 故障perccli64 /c0 show看写策略检查电池状态修复后调回 WriteBack系统能起但挂载点错乱fstab 用设备名而非 UUIDblkid、cat /etc/fstab全部改成 UUID 挂载5.2 我踩过的几个真坑第一个坑是把找不到磁盘直接判定成缺驱动。实际上那次安装介质里是有模块的只是没加载。正确的第一步永远是在 tty2 里看lsmod和dmesg先分清是没有模块还是没加载模块这一个动作能省下几个小时。第二个坑是 Secure Boot。当时我在 rescue 环境里手动modprobe第三方驱动一直报错日志里那句Key was rejected by service藏在几百行输出里差点没看见。后来先把 Secure Boot 关了才继续往下走。要点是装机阶段的排障先把所有可能干扰的因素Secure Boot、iommu、第三方内核参数清干净确认基础路径通了再逐个加回来。第三个坑是 fstab 用设备名。系统装完第一次重启是正常的第二次又起不来了原因是那次内核参数改动导致枚举顺序变了/dev/sda变成了/dev/sdbfstab 直接找不到根。改成 UUID 之后再没出过这个问题。这个经验放在任何有 RAID 卡的机器上都适用。第四个坑关于密码救援。有同事的机器因为 initramfs 改坏了进不去想用网上常见的rd.break进单用户模式修折腾半天没搞明白。这里的区别要讲清楚rd.break和单用户模式主要用于修改用户态配置典型场景是忘记 root 密码它把你带到的位置已经过了挂载根这一关而 initramfs 本身的损坏发生在更早的阶段rd.break帮不上忙。这时候正确的姿势是从安装介质进 rescue 模式chroot 进去重建 initramfs。两件事别搞混。第五个坑是升级内核。验证通过之后我图省事跑了一次dnf update内核跟着升了一级第三方驱动没跟上重启直接黑屏。后来老老实实装了python3-dnf-plugin-versionlock把 kernel 相关包锁住等驱动适配确认之后再解锁。5.3 PERC H750 日常运维的几条硬经验驱动跑通只是开始这套卡日常运维还有几个点值得盯。缓存策略与电池状态。阵列卡的写缓存默认是 WriteBack性能好但依赖电池或者 CacheVault 模块保护。一旦电池老化或者 CacheVault 报错卡的策略会自动降到 WriteThrough写入性能会掉一大截表现出来就是系统没动过怎么突然这么慢。定期执行/opt/MegaRAID/perccli/perccli64 /c0 show /opt/MegaRAID/perccli/perccli64 /c0/bbu show all看电池状态和当前写策略发现异常尽早换电池或模块。固件版本统一管理。同一批机器如果阵列卡固件版本不一致出了问题很难横向对比。建议在装机之前用 iDRAC 的 Lifecycle Controller 把同批机器的固件刷到同一版本刷完再装系统。反过来的顺序会让你反复返工。驱动版本与内核版本的对应关系要记录。我习惯在/etc/motd或者一份运维文档里记下这台机器的内核版本、驱动版本、固件版本三个数字下次出问题一查就知道是不是版本不匹配导致的。升级前先做快照。改 dracut 配置、改 grub 参数这类动作做完之后一定要验证到能起来为止。有条件的话先在测试机上走一遍完整的改配置-重建 initramfs-重启流程确认没问题再上生产。6. 这件事的影响范围比一台服务器大得多一开始我也以为这就是一次性的适配工作做完就完了。但连着几个项目做下来发现Dell PERC H750 在 openEuler 下驱动不适配这件事背后指向的是一类普遍问题值得单独说清楚。从硬件范围看受影响的远不止 H750 一块卡。整个 MegaRAID 家族——H740P、H750、H755、H330、H730P——走的是同一套megaraid_sas驱动路径遭遇的问题和处置思路完全一致。部分卡支持 eHBA 模式又牵扯到mpt3sas那又是另一个分支。所以这套方法你学一次基本能覆盖 Dell 14G 到 16G 主流机型的阵列卡。从软件范围看openEuler 只是国产化替代这条线上的一个典型代表。同样基于 anaconda dracut 体系的其他发行版遇到的情况高度相似。反过来说这套排障思路先定性是哪一层不适配再决定是否引入第三方驱动最后用 DKMS 和版本锁兜底是可以跨发行版复用的。从使用场景看这个问题最容易在三种场合集中爆发一是新机器首次装机介质和固件都是出厂状态二是在线扩容或者换卡之后驱动路径变了三是批量升级内核之后第三方驱动没跟上。第三种最具破坏性因为它往往是在系统跑得好好的时候突然砸下来而且影响的是整批机器而不是一台。我个人在实际操作中的体会是这类驱动不适配问题八成以上不是真的缺驱动而是驱动没被正确加载或者加载时机不对。所以遇到现象先别急着找驱动包先在出问题的环境里把lspci -nn、lsmod、dmesg、modinfo、lsinitrd这五个命令跑一遍把问题定到具体哪一层再决定动手方向。养成这个习惯之后我在现场的平均排障时间从半天缩短到一两个小时。另外一个小技巧把 dracut 的force_drivers和 grub 的rd.driver.pre两个参数一起用上相当于给根设备挂载加了双保险比只配一个稳得多我后面所有 RAID 卡上的机器都是这么配的。