在 Intel Matrix Storage(Fake RAID)下安装 Ubuntu Server 的笔记

最近需要给一个比较老旧的曙光机架式服务器(曙光天阔I410r-FY)进行重装系统配置环境,这台服务器让我比较诧异的是四个硬盘位都塞了一个 500G 的硬盘,考虑到这个机器的 CPU 和内存情况,如此大的硬盘难以利用,加上看到启动时显示的Intel Matrix Storage Manager的提示,感觉这台机器是自带 RAID 控制器的,于是想尝试组成 RAID。

根据我的理解,如果 RAID 不是在软件层面组成,那应该是对软件层面是透明的,我在启动进引导前用Intel Matrix Storage Manager将四块磁盘组成了 RAID 10,然后发现在 Linux 安装界面会有两次提示,第一次提示显示的mdadm设备询问是否启用(这里选否就卡死了以至于我没试过第二个选否会怎么样= =),第二次提示找到串行 ATA RAID 设备是否启用,最后在安装器的磁盘格式化界面显示的是:RAID10 设备/dev/md126,对这个设备进行分区、启用 LVM、安装系统、写入 GRUB,看起来一切正常,然后拔出安装 U盘,重启之后发现Intel Matrix Storage Manager闪过之后没有出现 GRUB 的引导界面,整个系统停在黑屏状态,硬盘灯全部不亮,反复多次尝试后发现并不是安装过程的问题。

询问了工作室的 SA 前辈,使用硬件 RAID 卡的服务器会对软件彻底透明,于是找了工作室一台使用硬件 RAID 的服务器看了一眼,如图,该服务器实际安装的是三块300GB 的 SAS 硬盘组成 RAID5 ,在软件层面直接显示为一个600GB 的/dev/sda:

QQ20150729-1@2x

也就是说这台机器其实不是硬件的 RAID 卡,根据前辈提示找到了这篇文章,情况比较类似,但是看过这篇文章之后似乎感觉他的解决方法麻烦, 既然有安装介质就有 liveCD,那么就可以通过 chroot 直接挂载根文件系统而不需要手动一个个挂载目录。

我的解决方案是使用安装 U盘引导直接进入 Rescue Mode,选择启动一个在 /dev/md126p1 为根目录的 shell 实质上就是 chroot 到了 /dev/mp126p1,然后:

注意root-directory参数跟的是”/”,空格,”/dev/md126″,因为使用了 LVM,/boot进行了单独分区,前一个目录参数是指定根目录,后一个目录参数是指定安装位置:

如果您选择使用(加密) LVM 导引式分区,安装程序还会创建一个单独的 /boot 分区。其他的分区,除了交换分区,都会建在 LVM 分区之内。——Debian.org

Ctrl+D 退出 shell 回到 liveCD ,reboot。这次可以正常引导了。

最初查找到的那篇文章说的原因是:

因为在raid的安装上,如果要mount到合适的/boot分区,就必须mount到/dev/md126pX这种设备上,而这些设备是没有所谓MBR的,而GRUB的安装参数则必须要放到/dev/md126上,这个小小的差异就导致了问题。

根据查找资料,这台服务器使用的是 Intel 5000V 芯片组,集成631xESB/632xESB SATA RAID Controller(外部链接: Intel 官网 datasheet),看起来这并不是纯硬件的 RAID 卡(维基百科也提到纯硬件阵列卡一般只支持 RAID 5和6)

QQ20150729-2@2x

 

后来再经过一番查找,发现这个 Intel Matrix Storage 也不是纯粹的软件 RAID ,从 ICH6R 芯片组开始加入此功能并以 R 后缀进行区分,Linux 下以 Device-mapper 方式/ DM-RAID 支持此技术(根据英特尔官网介绍,这里的 DM 包括了 dmraid 和 mdadm,维基将 DM 和Intel Matrix Storage 都划归为 Non-standard RAID levels),也就是为什么我在安装界面看到的设备名是/dev/md126。这种模式填补了硬件 RAID 和纯软件 RAID 之间的空白,是基于硬件+驱动辅助的,被称作hardware-assisted software RAID 或者Fake RAID:

基于操作系统的RAID并不总是适合于导过程。硬件RAID昂贵且是专有的。为了填补这一缺口,产生了价格便宜的“RAID控制器“,它不包含RAID控制器芯片,但只是一个带特殊的固件和控制器芯片的标准磁盘驱动器。在启动初期,RAID通过固件实现。当加载了保护模式操作系统内核如Linux或现代微软Windows系统,驱动程序接管RAID。
这些控制器被制造商描述为RAID控制器,但很少清楚地告诉购买者,RAID处理的开销是由主机的CPU承担,而不是RAID控制器本身,硬件RAID不存在这样的开销。固件控制器往往只能使用特定的几种硬盘(例如:Intel的Matrix RAID使用SATA硬盘,现代Intel ICH南桥不支持PATA和SCSI;但主板厂商在一些主板的南桥之外实现了RAID控制器)。因为在此之前,“RAID控制器“已经实现了–控制器做了处理,所以这种新技术被技术知识界称为“fake RAID” ——Arch Wiki

根据最初的那篇文章我搜索得到了最初的问题贴(国内这种 blog的文章一般就是转帖还不标出处,不过能对百度 SEO 十分友好···),问题原因应该出自 Fake RAID 组成的逻辑卷起始并不是物理上的首磁盘,引起了 grub 安装到了错误的位置上,原帖也强调“The RAID MBR is not on the first partition  /dev/md126p1, but on the base devices file  /dev/md126”,因此症状是直接没有出现 grub 引导界面(如果是挂载错误导致 grub 丢失内核文件位置,应该至少会出现 grub> 的提示符),本次的解决方法实质上就是通过修改 device.map 手动指定了第一磁盘的第一柱面(当然是将虚拟化后的 mapper 指定给了 grub,是 Fake 的)给 grub,然后指定了一个 grub 的安装位置。关于此,ArchWiki 有记载在 Fake RAID 上安装 grub 的完整流程 ,可供对比参考。

联想到前两天遇到了另一台服务器也有类似症状,使用 UEFI 引导则引导失败出现 EFI shell,关闭 UEFI 就和这台情况一样(这次这台主板太老以至于没有 UEFI 模式,省去了一部分折腾的麻烦),当时由于时间紧迫,当时的处理办法是直接取消了 RAID 将几块硬盘挂载到不同目录下虽然可以正常启动但几块 2T 大硬盘这么用实在是觉得浪费= =。装系统这种事情遇到问题还是要留出时间去解决,不解决一次真的是永远想不到是什么原因。

2条评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注