安裝 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 的版本喔！ 這次的範本是在虛擬機裡面模擬給大家看的！畢竟自己的印象微弱，得用實際的案例來處理較佳！
