安装 CentOS 8 却抓不到磁盘，原来是磁盘数组卡的问题啊！
鸟哥在 2019 年底到 2020 年初，都在搞 CMAQ 空气品质模式的升级，因为从 v5.2.1 升级到 v5.3 有很多的有趣的机制可以玩， 而且，据说仿真的结果还会更准确～所以，鸟哥花费了好多的心力在处理这些东西。而在 2020 年初，CMAQ 官网更推出 v5.3.1 这一版， 这个版次解决了一些次要的 bugs，据说速度还更快了！因此，鸟哥就想要更改成这个版本。
而在 2019 年的 9 月间， CentOS 终于将 RHEL8 的版本追上来了，发布了 CentOS 8 这一版本，鸟哥想想，既然要升级整个环境， 当然是连 OS 都升级算了！连同所有的 library 也通通升级好了！所以，就将原本的 v5.3 版本，先备份，然后将硬件重装。 灌完之后，将所有的操作系统相关调整、前驱模块编译、主程序编译等等，通通搞一遍～花了几个礼拜，好不容易搞定了， 丢主程序进去跑跑～结果...吓死我了！跑出来的性能，我说的不是模式准确度的性能评估，而是电脑运算的性能， 发现到 CentOS 8 的性能比起 CentOS 7 快了很多，比起 CentOS 6 更是多到爆炸！
举个例子，我们都知道 scp 拷贝数据时，会通过加解密来处理。而为了加速，目前的 CPU 都有 aes 这个硬件加解密机制～ 可以加快整体的运算速度！同样使用 aes 这个加密机制，在 CentOS 6 对 CentOS 6 之间，用 scp 拷贝， 而且拷贝的数据放在 /dev/shm 底下，避免被磁盘性能所干扰～结果，发现到大致如下的速率 (使用硬件几乎相同的机器， 只安装不同的系统，同时使用 10G 网络环境下的情境)
因为我们的计算需要跨不同主机，而且就是通过 ssh 机制，因此，很需要高速的传输性能！过去以为 10G 就好了，没想到， 竟然会卡在操作系统的性能上面！相当讶异啊！鸟哥不知道是不是不同的 OS 之间的性能调整机制不同所致， 但是鸟哥的系统，大多会使用同一组性能调整参数～所以，直觉上，这似乎就是软件版本与内核版本的效果差异所至啊！
根据与鸟哥一同参与模式开发的伙伴，鸟哥跟他说了这个情况后，他也将他们机房内的主机系统，从 CentOS 6 改换到 CentOS 8， 然后重新编译同一个模式程序，有趣的是，他的模式运算时间，从 CentOS6 的 10 小时，变成 CentOS 8 的 5 小时左右！ 足足快了一倍！硬件与模式都没变喔！ (当然，模式版本没变，但是编译自然是不一样！)。
对我们这种习惯『系统建置好，模式能跑！能跑出正确的结果，那就好了啦！』的模式操作者来说，过去要处理模式运算性能， 就是钱砸下去～换成新的硬件，然后多颗 CPU 去跑就对了！然后我们为了要兼容于过去的机制，通常会偷懒选择与过去相同的操作系统， 这样可以不用重新编译，直接通过 NFS 挂载后，该硬件就可以开始跑模式！不用重新编译！这下子发现到，不对不对！ 需要与时俱进才对！
由于鸟哥在另一处服务的地方还有另一组机器，里面的运算主机足足有 7 台是旧式的 CentOS 6，这样不行！该换成新系统了！ 于是，就在这个连假期间，就是最近儿童节、清明节的时刻，自己一个人躲在机房，慢慢的重新安装系统啰！
既然升级到 CentOS 8 的性能提升这么明显，自然是需要升级才对！于是鸟哥先在主控系统上面设计好 PXE 的网络开机与网络安装机制， 这一部主控系统并没有需要运算，因此暂时没有要升级！可能要找下个假期来处理几部主控系统与 storage 系统～目前还是先处理运算主机才好。 鸟哥以为使用网络开机、网络安装，安装 GUI 环境，然后转为 multi-user 环境，设置好网络， 7 部主机同时处理， 基本上，也不会花费太多时间吧！没想到惨剧来了～
处理第一部主机果然很快，那部主机使用了 Intel 主板内置的 RAID1 功能，在 Linux 上面就是以 software RAID 机制来处理， 安装也快速～整理也快速～没问题！等到顺利安装后，开始第二部系统的整理。
第 2 到第 7 部系统，全部是 ASUS 的机架式主机系统，而且使用了还算可以的 LSI RAID 芯片，里面也是使用 RAID1 这个机制， 可以避免系统被恶搞到死翘翘～只是...很怪异～安装程序就是抓不到它！查了查，这个 RAID card 在 lspci 里面出现的信息为：
[root@nodes ~]# lspci | grep -i raid
04:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic MegaRAID SAS 2008 [Falcon] (rev 03)
这个 raid card 的 driver 使用的是 megaraid_sas 这个模块，查了查 CentOS 8.1 的安装光盘里面，确实是有这个模块的存在的！ 那为什么找不到呢？终于找到这几篇：
原来很多人都有同样的困扰，那就是这个还很常被使用的磁盘数组，已经不被 CentOS 8.1 的官方支持列表中持续存在， 也就是，CentOS 8.1 缺省不支持这硬件啦！但是很有趣喔！其实 megaraid_sas 的代码里面，是有支持这张硬件的！ 只是在编译的时候，被官方缺省移除了...很要命！那怎办？重新安装好新版驱动程序就好！在这里下载前辈们的努力成果：
根据论坛的说明，你可能需要使用一个 USB 制作 DUD 的开机片，然后通过这个开机片加载内核模块，也就是 kmod-megaraid_sas 这个软件， 问题是，我有多部主机要安装，而且我人在机房～花了大概半个小时找到上面几篇文章 (用小手机找到)，然后...我主要是通过网络安装系统， 然后，我手边没有任何可用的 USB，因为就单单一个人在啊！那怎办？
将上述的论坛文章看了多次，基本上的情况是这样的：
简单的说，就是 (1)让安装进程拥有更新的 megaraid_sas 驱动程序，以及 (2)让新的系统拥有正确的 megaraid_sas 驱动！这两个缺一不可！ 因为没有 (1) 就无法安装，而没有 (2) 就不能让新的系统开机！呵呵呵呵！累死～
首先，通过网络开机的环境，正常进入到安装画面后，按下 [ctrl]+[alt]+[F2] 来进入到文本界面的流程中。 接下来，确认你的网络是正确的～然后，你可以通过 scp 或者是 wget 的方式来抓取正确的文件。如果是在你可以掌握的环境中， 使用 scp 应该是比较好的方式：
[anaconda root@localhost /]# wget http://192.168.19.254/kmod-megaraid_sas-07.707.50.00-1.el8_0.elrepo.x86_64.rpm [anaconda root@localhost /]# rpm -ivh --nodeps kmod-megaraid_sas-07.707.50.00-1.el8_0.elrepo.x86_64.rpm [anaconda root@localhost /]# cd /lib/modules/4.18.xxxx/kernel/drivers/scsi/megaraid [anaconda root@localhost /]# mv megaraid_sas.ko.xz megaraid_sas.ko.xz.old [anaconda root@localhost /]# depmod -a
安装 kmod 的过程中，会有点小问题，先略过不要理会！不过，这时因为同时存在两个 megaraid_sas 的驱动程序，缺省的情境下， 安装进程会主动抓原有的模块，因此，你得要先去更改或移除原有的模块，并且重新侦测模块相依性， 这才有办法处理！接下来请依据正常的方法来安装好你的系统。在磁盘分割时，按下『重新侦测系统』之后， 就会有看到你的磁盘出现啦！真开心啊！
对了！回到原本的安装画面，得要按下 [ctrl]+[alt]+[F6] 喔！
等到一切安装流程都搞定之后，画面最后显示『重新开机』时，千万不要重新开机！否则，你的新系统会无法顺利开机的。 请再次回到 tty2 的地方，然后，准备切换根目录，你可以这样做喔：
[anaconda root@localhost /]# df # 你应该会看到很多 /mnt/sysimage 的挂载！那就是根目录所在！ [anaconda root@localhost /]# rpm -ivh --root /mnt/sysimage kmod-megaraid_sas-07.707.50.00-1.el8_0.elrepo.x86_64.rpm [anaconda root@localhost /]# chroot /mnt/sysimage [anaconda root@localhost /]# depmod -a [anaconda root@localhost /]# dracut --force [anaconda root@localhost /]# exit
如此一来，你就可以拥有最新的 megaraid_sas 的支持！只是，未来如果跨越新版本，你可能需要先安装新版 megaraid_sas 的驱动程序才好！ 例如鸟哥范本中安装的是 CentOS 8.0 的版本，事实上，鸟哥在之前的系统，安装的则是 CentOS 8.1 的版本喔！ 这次的范本是在虚拟机里面仿真给大家看的！毕竟自己的印象微弱，得用实际的案例来处理较佳！
