SLES啟動模組載入失敗：尋找驅動程式並修復

如果 SLES 在啟動過程中顯示“啟動載入核心模組失敗”，請先檢查systemd-modules-load.service日誌以確定失敗的模組。如果該模組是已過時的可選條目，請從其配置中移除該請求；如果該模組是必需的，請修復驅動程式或核心不匹配的問題，而不是停用該服務。

本流程適用於 SUSE Linux Enterprise Server (SLES) 15，並以 SLES 15 SP7 管理文件為參考。命令應在本機控制台或具有sudo存取權限的有效 SSH 會話中執行。

在更改任何內容之前，請先了解此訊息的含義。

核心模組是可單獨載入的驅動程式或核心功能。啟動期間，systemd-modules-load.service系統會處理載入特定模組的請求，包括在modules-load.d設定檔中定義的模組。即使伺服器的其他部分仍在運行，如果載入請求失敗，也可能導致該服務中斷。

SUSE 指出，大多數驅動程式會在偵測到硬體時自動載入。通常無需手動列出模組列表，因此模組條目過時的可能性很高——但僅憑啟動資訊無法確定。請保留控制台存取權限，並在條件允許的情況下建立系統快照或配置備份，切勿僅為了消除警告而卸載儲存、網路或叢集驅動程式。有關支援的型號，請參閱 SUSE核心模組管理指南。

步驟 1：讀取服務狀態及其啟動日誌

首先檢查 systemd 狀態。 systemdsystemd是負責啟動服務並報告其狀態的服務管理器。

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

此-b標誌限制journalctl為目前啟動，並-u選擇此服務。請查看最後一行「失敗結果」上方的錯誤訊息，例如「找不到模組」、無效選項或權限/簽名錯誤。記錄準確的模組名稱和錯誤文字。不要假設以下範例中指定的模組存在於您的伺服器上。

如果服務日誌無法得出結論，請檢查內核訊息以獲取更多詳細資訊：

sudo journalctl -k -b --no-pager

如果電腦無法建立可用的登錄，請嘗試從 GRUB 啟動一個較舊的核心（如果有），或使用 SLES 救援介質。切勿在未經測試的遠端會話中編輯啟動關鍵模組。 SUSE 在其journalctl 管理章節中提供了有關日誌過濾器的文件。

步驟 2：找到請求它的啟動配置

假設期刊名稱為「模組名稱」example_driver。將該佔位符替換為實際的模組名稱，然後搜尋模組列表：

sudo grep -Rns --include='*.conf' 'example_driver' \
  /etc/modules-load.d /run/modules-load.d \
  /usr/lib/modules-load.d 2>/dev/null

每個符合的記錄都會告訴你哪個檔案在啟動時請求該模組。管理員的本機設定通常位於 `/etc/systemd/config/systemd` 目錄下/etc/modules-load.d/，而軟體套件的設定檔可能位於 `/etc/systemd/config/systemd` 目錄下/usr/lib/modules-load.d/。具有相同基本名稱的本機文件優先於供應商文件，如 SUSE 的systemd 設定指南中所述。如果搜尋未找到任何結果，則應檢查cat /proc/cmdline啟動時模組請求，並驗證失敗名稱是否已正確複製。

開啟符合的文件，並確定硬體或應用程式是否仍需要該條目。為已移除的舊設備請求的模組與儲存控制器驅動程式或叢集監視程式不同。

步驟 3：測試模組，然後套用對應的修復方法

檢查目前運行的核心以及相應的驅動程式是否可用。modprobe載入核心模組並解析依賴關係；其-n選項會執行空運行，但不插入任何內容。

uname -r
modinfo example_driver
sudo modprobe -n -v example_driver

再次強調，請替換example_driver。空運行有助於識別查找或配置問題，但並不能證明驅動程式能夠在您的硬體上成功初始化或透過安全啟動簽名檢查。 SUSE 建議使用空運行modprobe而不是直接insmod加載；空運行標誌的詳細資訊請參閱modprobe 手冊。

如果一個過時的可選入口指向一個缺少的模組

備份本地特定文件，並僅註解掉過時的行。例如，如果/etc/modules-load.d/example.conf這是已確認的來源：

sudo cp -a /etc/modules-load.d/example.conf \
  /etc/modules-load.d/example.conf.bak
sudoedit /etc/modules-load.d/example.conf

將單一example_driver條目變更為# example_driver，儲存，並保持其他模組請求不變。如果來源是位於下的軟體包文件/usr/lib，請勿直接編輯該軟體包文件；請使用經過審核的本地覆蓋或更正軟體包的配置。如果相應的設備是必需的，切勿僅因為modinfo報告缺少該模組而刪除該模組請求。

如果缺少必需模組或模組不相容

請勿註解掉相關代碼。確認驅動程式包支援uname -r已安裝的 SLES 服務包的輸出。 「找不到模組」訊息可能表示相符的驅動程式未安裝，或在核心更新後未重新建置。 「無效的模組格式」訊息則表示有相容性問題；核心日誌可以進一步縮小問題範圍。請依照 SUSE 或硬體供應商的說明恢復或重新安裝受支援的匹配驅動程式。避免.ko從其他核心複製任意檔案。

如果模組存在但其依賴索引明顯過時，則為當前核心重建該索引並重試試運行：

sudo depmod -a "$(uname -r)"
sudo modprobe -n -v example_driver

此步驟不會安裝缺少的驅動程式。如果在安全啟動系統中看到「所需金鑰不可用」或模組簽署被拒絕的提示，請按照 SUSE 的可信任金鑰註冊和驅動程式簽署工作流程進行操作；不要將停用安全啟動作為通用解決方法。 SUSE 在其安全啟動部署指南中解釋了第三方驅動程式的限制。

步驟 4：確認下次啟動是否順利。

更正配置或恢復驅動程式後，請重試載入程式並檢查其狀態。僅在確認所有剩餘條目均正確後才執行此操作；重新啟動將再次嘗試配置的載入。

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

如果設備運作成功，請安排受控重新啟動（需具備控制台存取權限），並再次執行狀態和日誌指令。當服務在新啟動後不再出現故障，且依賴該模組的任何必要硬體或軟體仍然正常運作時，即可確認修復成功。如果錯誤再次出現，請將新日誌與舊日誌進行比較：可能還有其他列出的模組也出現故障。請保留備份，直到檢查通過為止；不要systemd-modules-load.service僅為了抑制啟動訊息而進行屏蔽。