[MVS]硬盘控制器NVME&&SCSI

硬盘控制器NVME&&SCSI

1. 问题现象回顾

• NVMe → SCSI：系统能正常启动。

• SCSI → NVMe：系统无法启动，卡在dracut-initqueue，提示/dev/mapper/rl-root不存在。

• 错误信息表明：systemd-cryptsetup@*.service（用于解密LVM或加密卷）和devexits脚本在等待设备存在，但超时失败。

2. 根本原因：内核启动时的设备识别顺序

Linux内核在启动时，会按顺序初始化不同的硬件子系统。对于存储设备，顺序通常是：

1. SCSI子系统 (SCSI Subsystem)

2. NVMe子系统 (NVMe Subsystem)

关键点：

• SCSI子系统 是一个非常成熟、历史悠久的通用块设备接口。它能识别并处理绝大多数类型的存储设备，包括传统的SATA、SAS、以及许多NVMe设备（特别是那些被映射为SCSI块设备的NVMe设备）。

• NVMe子系统 是专门为NVMe协议设计的，虽然性能更好，但对设备的兼容性要求更高，特别是在早期内核启动阶段，它可能无法正确识别或处理某些设备，尤其是那些在SCSI层已经被“接管”的设备。

3. 为什么“NVMe → SCSI”能工作？

当你将NVMe控制器切换为SCSI控制器时：

• 内核在启动时，会优先初始化SCSI子系统。

• SCSI子系统会识别NVMe设备（因为很多NVMe设备在SCSI层被抽象为SCSI块设备），并将其挂载为/dev/sdX（例如/dev/sda）。

• 这样，dracut或systemd在初始化时就能找到/dev/sdX，进而找到/dev/mapper/rl-root（加密卷），最终成功挂载根文件系统，系统正常启动。

4. 为什么“SCSI → NVMe”会失败？

当你将SCSI控制器切换为NVMe控制器时：

• 内核在启动时，会优先初始化NVMe子系统。

• 但此时，NVMe子系统可能尚未完全准备好，或者无法正确识别你所使用的NVMe设备（尤其是那些在SCSI层被识别的设备）。

• 结果就是，内核无法找到/dev/nvme0n1或/dev/nvme0n1p1等设备，导致dracut在初始化阶段无法找到/dev/mapper/rl-root，从而超时失败，系统无法启动。

5. 为什么/dev/mapper/rl-root不存在？

这是最关键的线索。/dev/mapper/rl-root是LVM或加密卷的设备节点。它依赖于底层的块设备（如/dev/sda1或/dev/nvme0n1p1）存在。如果内核在初始化阶段无法识别底层块设备，那么上层的LVM/加密卷自然也无法创建。

总结

系统启动时，内核需要在初始化阶段就识别并挂载根文件系统。NVMe控制器驱动在启动初期对设备的兼容性不如SCSI控制器驱动，因此当系统尝试将SCSI控制器切换为NVMe控制器时，内核无法识别底层设备，导致根文件系统无法挂载，系统无法启动。而将NVMe控制器切换为SCSI控制器时，SCSI子系统能更早、更稳定地识别设备，从而保证系统正常启动。

这个问题的根本原因在于内核启动时的设备识别顺序和驱动兼容性，而不是设备本身的问题。