修正 SLES 啟動時「載入核心模組失敗」的問題

SLES 啟動訊息「啟動載入核心模組失敗」通常表示systemd-modules-load.service嘗試載入至少一個核心模組但其中一個請求失敗。修復的目的不僅僅是隱藏紅色啟動訊息。一次成功的修復應該確保服務正常運行，移除過時的模組請求，保留機器實際需要的驅動程序，並確保系統在下次重新啟動後仍然有效。

本指南適用於 SUSE Linux Enterprise Server 15，並與最新的 SLES 15 SP7 管理指南保持一致。 SUSE 文件中提到，系統systemd-modules-load.service會載入以 `<module_name>` 命名的模組/etc/modules-load.d/*.conf，而大多數現代硬體模組通常會在偵測到裝置時自動載入。這種區別至關重要：如果一個過時的靜態條目指向一個已不存在的模組，刪除或更正該條目通常比強制將過時的驅動程式重新載入到系統中更安全。請參閱 SUSE針對 SLES 15 SP7 的「管理核心模組」文件。

成功的解決方案應該是什麼樣的？

在進行任何更改之前，請先明確您想要的結果。修復後：

• systemctl status systemd-modules-load.service不應再報告失敗結果。
• 日誌在全新啟動過程中不應再顯示相同的模組載入錯誤。
• 如果確實需要該模組，modprobe MODULE_NAME則應該成功，並且相關的硬體或功能應該可以正常工作。
• 如果模組已過時，則應刪除過時的請求，而不是用不相關的模組取代它。
• 如果問題與早期啟動有關，則應重建 initramfs，然後機器應該可以正常完成重新啟動。

如果這些檢查並非全部適用於您的情況，請使用與故障組件相符的檢查。例如，即使某個選用模組發生故障，伺服器也可能成功啟動。這種情況仍然值得清理，但這與缺少儲存驅動程式導致根檔案系統無法顯示的情況不同。

步驟 1：確認故障單元並記錄準確的模組錯誤訊息

不要僅根據啟動畫面上的資訊進行猜測，而是應該先從服務本身入手：

sudo systemctl status systemd-modules-load.service --no-pager

尋找模組名稱以及類似「模組不可用」Module ... not found、「No such device模組Operation not permitted不可用」或「拒絕使用不支援的模組」之類的錯誤訊息。具體的錯誤訊息決定了下一步的操作。

若狀態輸出不完整，請暫勿編輯配置。請先取得完整的啟動日誌。

步驟 2：在變更模組檔案之前，請先閱讀啟動日誌

僅查詢目前啟動時的此服務：

sudo journalctl -b -u systemd-modules-load.service --no-pager

您也可以查看模組載入相關的核心訊息：

sudo journalctl -b -k --no-pager | grep -iE 'module|modprobe|firmware|taint'

第一條命令回答了哪個靜態載入請求失敗。內核日誌可以提供更多上下文信息，例如驅動程式拒絕檢測到的設備、韌體依賴項、簽名問題或其他底層錯誤。

類似這樣的結果Module foo not found in directory /lib/modules/...通常指向配置過時、核心/軟體包不匹配，或者第三方驅動程式未針對當前核心重新編譯。No such device而另一種情況則不同：模組檔案可能存在，但目前硬體或虛擬設備可能與驅動程式預期不符。

步驟 3：找出是誰請求 SLES 載入該模組

搜尋常規靜態負載位置和 modprobe 配置：

grep -Rns --color=auto 'MODULE_NAME'   /etc/modules-load.d /run/modules-load.d /usr/lib/modules-load.d   /etc/modprobe.d /usr/lib/modprobe.d 2>/dev/null

替換MODULE_NAME為日誌中的名稱。在 SLES 15 SP7 中，本機條目/etc/modules-load.d/是管理員管理的、必須在啟動時載入的模組的標準位置，而打包條目可以存在於 下方/usr/lib/modules-load.d/。 SUSE 指出，大多數模組根本不需要手動添加 modules-load.d 條目。

然後檢查當前核心是否確實包含該模組：

uname -r
sudo modinfo MODULE_NAME
sudo modprobe MODULE_NAME

如果模組已過時

移除或停用請求該本機檔案的檔案。不要/usr/lib僅僅為了消除錯誤而刪除供應商文件，因為軟體包更新可能會恢復該文件。如果您確定某個本機/etc/modules-load.d/*.conf檔案是為已停用的硬體或舊軟體建立的，請移除該本機條目並重新測試。

如果模組應該存在，但 modinfo 找不到它

檢查正在運行的核心是否與已安裝的模組樹相符：

uname -r
ls -ld /lib/modules/$(uname -r)
rpm -q kernel-default

常見的品質檢查很簡單：/lib/modules/$(uname -r)驅動程式必須存在，並且包含當前運行核心所需的模組。如果第三方驅動程式是為舊核心編譯的，請使用供應商支援的步驟，針對目前的 SLES 核心重新安裝或重新編譯該驅動程式。切勿.ko為了modprobe查找某些內容而從其他內核版本複製檔案；內核 ABI 或簽名差異可能導致這樣做不安全或無效。

如果模組被列入黑名單

搜尋黑名單或安裝覆蓋程式：

grep -Rns --color=auto -E '^[[:space:]]*(blacklist|install)[[:space:]]+MODULE_NAME'   /etc/modprobe.d /usr/lib/modprobe.d 2>/dev/null

只有在確認添加黑名單的原因後才能移除它。黑名單可以保護系統免受衝突驅動程式的影響。 SUSE 的模組指南同時記錄了持久黑名單和 GRUB 引導時臨時黑名單，因此正確的做法可能是移除靜態載入請求，而不是移除黑名單本身。

如果 SLES 報告模組不受支援

請勿自動啟用不支援的模組載入。 SLES 會標記核心模組的支援狀態，強制載入不支援的模組可能會影響其支援性。 SUSE 在其管理指南中記錄了測試或供應商熱修復場景下的例外機制。僅當您了解其對支援的影響並且確實需要該驅動程式時才應使用此功能。您也可以在SLES 15 SP7 管理指南中找到相同的最新 SUSE 指南。

步驟 4：僅當變更影響早期啟動時才重建 initramfs

如果 initramfs 中需要使用故障模組，或者您變更了啟動關鍵驅動程式或黑名單配置（必須反映在 initramfs 中），請重新產生映像：

sudo dracut -f

SUSE 專門記錄了在驅動程式變更影響啟動後重建 initramfs 的過程。其目前的啟動流程指南解釋了何時需要將驅動程式新增至 initramfs 以及如何dracut使用它來重新產生 initramfs：SLES 15 SP7 中的啟動流程簡介。

不要dracut -f為每個可選模組錯誤都執行此操作。如果一個普通的啟動後模組只是在 `initramfs.conf` 檔案中列出/etc/modules-load.d，那麼修正該檔案可能就足夠了。只有當錯誤的配置嵌入到啟動鏡像中，或者在真正的根檔案系統完全掛載之前必須提供所需的驅動程式時，重建 initramfs 才最為重要。

在確認維修完成之前，請勿將事故視為已結案。

在確保安全的前提下，先進行一次無需重新啟動的測試：

sudo systemctl restart systemd-modules-load.service
systemctl status systemd-modules-load.service --no-pager
systemctl is-failed systemd-modules-load.service

如果現在應該加載所需的模組，請確認：

lsmod | grep -w MODULE_NAME

然後在適當的維護視窗期內重新啟動並檢查新的啟動情況：

sudo reboot

登入後：

systemctl --failed
journalctl -b -u systemd-modules-load.service --no-pager

最有力的成功訊號並非控制台訊息消失一次，而是重新啟動後沒有再次出現相同的模組錯誤，並且依賴該模組的硬體或子系統仍然正常運作。

何時改變策略

此修復方案的局限性

「啟動載入核心模組失敗」這一行只是一個症狀，而非單一缺陷。此過程旨在解決由靜態模組請求、模組缺失或不匹配、黑名單以及 initramfs 同步引起的故障。它不能取代硬體診斷、第三方驅動程式支援、安全啟動簽章工作，也不能取代根設備本身不可用時的儲存恢復。

對於生產環境的 SLES 系統，應確保可維護性：優先使用 SLES 核心自帶的模組，確保第三方驅動程式與其供應商的支援矩陣保持一致，並使用 SUSE 官方文件中記錄的機制，而不是為了清除服務故障而繞過檢查。當服務狀態、啟動日誌和相關硬體都確認問題已解決時，修復才算完成。