企业官网建设流程全解析

前段时间接手一台 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 三种典型故障现象，对应三个不同根因

我把这次以及之前几次遇到的现场整理成三类，你可以对号入座：

第一类和第二类的区别特别容易被忽略——前者是安装介质的问题，后者是目标系统的问题。我见过有人明明系统装完了，重启进不去，就以为是驱动没装，回头又去折腾安装盘，白折腾了一晚上。

1.3 为什么 openEuler 上更容易撞到这类问题

说句实在话，这不是 openEuler 独有的毛病。Dell 官方给 Linux 的驱动盘（DUD，Driver Update Disk）和 rpm 包，主要针对 RHEL、SLES 这几条线做认证。openEuler 虽然用户态体系高度接近 RHEL 8（同样是 anaconda 安装器、dracut、rpm/dnf 包管理），但它用的是自己的内核版本号，比如5.10.0-153.xx.x，DKMS 编译第三方驱动时偶尔会因为内核 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/model

lspci -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 下用 perccli：

perccli64 /c0 add vd type=raid5 drives=252:0-3 perccli64 /c0/vall show

注意：卷没建就上操作系统，看到的一定是一堆单盘。这不是驱动问题，是配置问题，别把时间浪费在找驱动上。

2.2 挑对安装镜像和启动方式

openEuler 22.03 LTS 目前有 SP1/SP2/SP3 几个小版本，内核版本号各不相同。如果你已经确认这台机器的卡在某个内核版本下是能认的，就优先用那个版本，别盲追最新。另外镜像要选x86_64的完整版（everything 或 DVD 版），不要选网络安装的 netinst 版本——网络版体积小，内含的驱动模块更少，反而更容易出问题。

启动方式这块有两个坑：

• BIOS 还是 UEFI：15G 服务器上 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 if=dd.iso of=/dev/sdb bs=1M status=progress conv=fsync # 或者不解压，直接把 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 配置并重建 initramfs：

cat > /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-all

force_drivers这个参数特别有用，它的语义是"这几个模块必须在挂载根之前就加载"，正好对上我们的需求。很多人只写了add_drivers，结果模块是打进去了，但加载时机排在根挂载之后，照样起不来。

再加一道保险，把驱动的加载顺序提到内核命令行最前面：

grubby --update-kernel=ALL --args="rd.driver.pre=megaraid_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.dd=hd:/dev/sdb1:/dd.iso

其中/dev/sdb1是 U 盘分区，/dd.iso是文件路径。如果驱动盘是刻成光盘放进光驱，那就写inst.dd=cdrom。

加载成功后，安装器界面上会多出一行提示，说明驱动已经就位，这时候再去点"安装位置"，虚拟磁盘就能看到了。有一点要提醒：驱动盘里的 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，让它重新生成依赖关系表。

想让它在内核升级后自动跟着重建，就得靠 DKMS：

dnf 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 status

dkms status显示installed才算成功。如果编译报错，八成是内核源码包没装全，或者 openEuler 的内核 API 和驱动源码不匹配，需要打个小补丁。这种时候我的建议是先在 RHEL 8 同版本上编译一遍看看能不能过，能过就是 openEuler 内核差异的问题，定位起来快得多。

注意：在内核升级还没验证通过之前，务必把内核版本锁住，否则dnf update一不小心升上去，第三方驱动没跟上，机器直接起不来。锁的方法：

dnf install -y python3-dnf-plugin-versionlock dnf versionlock add kernel kernel-core kernel-modules

4. 一次完整的实操记录：从认不到盘到稳定运行

前面讲的是方法论，这一段把那次 R750 的完整过程按时间线记下来，包括每一步的验证动作和我当时的判断依据。

4.1 现场环境与初始状态

机器是 PowerEdge R750，双路，PERC H750，四块 960G SSD 做了 RAID5，系统目标 openEuler 22.03 LTS SP3，UEFI 启动，Secure Boot 初始开启。第一次装的时候，安装器能起来，但"安装位置"页面显示"未找到磁盘"。

切到 tty2 排查：

dmesg | grep -i -E "megaraid|sas|raid" | head -30 lspci -nn | grep -i raid

lspci能看到 RAID 控制器，说明 PCI 层面没问题；dmesg里完全没有 megaraid 的初始化日志，lsmod里也没有这个模块。结论是安装介质的内核没有加载这个驱动。这就是典型的第一类故障。

4.2 安装阶段加载驱动盘的关键动作

我回到启动菜单，按e，在linuxefi行尾追加了inst.dd，然后 Ctrl+X 引导。Anaconda 弹出了设备选择界面，我选了 U 盘分区，它自动扫描到了驱动盘并提示加载成功。

加载完之后，回到 tty2 再看一次：

lsmod | grep megaraid lsblk

这次lsmod里有megaraid_sas，lsblk也能看到一个约 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 配置并重建 initramfs：

cat > /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-kernel=ALL --args="rd.driver.pre=megaraid_sas" grubby --info=ALL | grep -o "rd.driver.pre=[a-z_]*"

第三件，检查/etc/fstab。这一步被很多人忽略：如果 fstab 里写的是/dev/sda2这种内核设备名，RAID 卡的驱动加载顺序一变，设备名就可能漂移，导致系统起不来或者挂错分区。稳妥做法是全部换成 UUID：

blkid # 把形如 UUID=xxxx 的标识替换进 /etc/fstab

同时顺手在/etc/default/grub里给内核命令行加上rd.auto=1之类的稳妥参数（视发行版而定），改完记得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 用的是 NetworkManager，nmcli con mod加nmcli con up就能配静态 IP），因为后面更新驱动、装 perccli 都可能需要网络。别等到要用了才发现机器没网，又得摸黑去机房插网线。

5. 常见问题排查速查表与避坑经验

这套东西我在不同项目里反复做过好几遍，遇到的问题高度重合。下面这张表基本覆盖了九成现场状况，建议装机前先扫一眼。

5.1 症状-原因-处置对照表

5.2 我踩过的几个真坑

第一个坑是把"找不到磁盘"直接判定成"缺驱动"。实际上那次安装介质里是有模块的，只是没加载。正确的第一步永远是在 tty2 里看lsmod和dmesg，先分清是"没有模块"还是"没加载模块"，这一个动作能省下几个小时。

第二个坑是 Secure Boot。当时我在 rescue 环境里手动modprobe第三方驱动，一直报错，日志里那句Key was rejected by service藏在几百行输出里，差点没看见。后来先把 Secure Boot 关了才继续往下走。要点是：装机阶段的排障，先把所有可能干扰的因素（Secure Boot、iommu、第三方内核参数）清干净，确认基础路径通了再逐个加回来。

第三个坑是 fstab 用设备名。系统装完第一次重启是正常的，第二次又起不来了，原因是那次内核参数改动导致枚举顺序变了，/dev/sda变成了/dev/sdb，fstab 直接找不到根。改成 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 卡上的机器都是这么配的。