在 SLES 15 上設定 DM-Multipath 以實現可靠的 SAN 路徑
準備 SCSI SAN 路徑,啟用 multipathd,檢查 SUSE 的硬體預設設置,並在不猜測陣列設定的情況下驗證穩定的設備映射。
如果 SUSE Linux Enterprise 報告 Zypper 被其他進程鎖定,請先讓所有正在進行的軟體更新、YaST 軟體包操作或自動維護任務完成。在停止任何操作之前,請檢查哪個軟體包管理進程正在執行該任務。如果沒有軟體包操作正在運行,但鎖定仍然存在,請調查鎖定狀態,不要盲目刪除鎖定檔案;然後重試 Zypper。使用其他方式建立的軟體包鎖定zypper addlock是不同的問題,需要不同的修復方法。
Zypper 及其底層套件管理工具可防止套件事務發生重疊變更。刷新、修補程式、安裝、YaST 軟體任務或計畫更新都可能暫時阻止第二個交易。這種鎖定機制是一種協調機制:如果在 RPM 或 Zypper 仍在更改套件時移除鎖定,可能會導致套件資料庫或系統處於不一致狀態。
已驗證的差異:進程鎖會阻止並發的軟體包操作;軟體包鎖會阻止指定軟體包被選中進行安裝、升級或卸載。 SUSE 文件將軟體包鎖描述為一項獨立的功能。 SUSE的 RPM 打包指南解釋了 Zypper 軟體包鎖。如果錯誤訊息指向其他進程或提示軟體套件管理器繁忙,請先執行以下進程檢查。如果錯誤訊息提示某個特定軟體包被鎖定或排除,請執行sudo zypper locks並查看列出的軟體包規則。
如果剛開始更新、安裝或儲存庫刷新,請稍等幾分鐘。在伺服器上,請先諮詢管理員或維護自動化負責人;後台修補作業可能不會顯示終端。
ps -eo pid,ppid,etime,stat,cmd | grep -E '[z]ypper|[r]pm|packagekit|YaST|yast'
尋找實際存在的 Zypper、RPM、YaST 或 PackageKit 任務,並記錄其進程 ID (PID)、運行時間和命令。 grep 表達式會避免符合 Zypper 和 RPM 的搜尋指令本身。進程清單只是一個快照,如果結果不清晰,請稍等片刻後重複執行。以下範例僅為範例終端視圖,並非來自真實機器的報表。

尚未確定的是:看到進程並不一定意味著它卡住了。軟體包事務可能正在下載元數據,或正在等待儲存或儲存庫。不要僅僅因為命令沒有反應就終止它。如果它正在運行,請讓它完成,然後再重新執行最初的 Zypper 命令。
桌面安裝可能使用 PackageKit,而託管伺服器可能透過 systemd 定時器或 SUSE Manager 執行計劃更新。請僅檢查主機上存在的服務:
systemctl status packagekit
systemctl list-timers --all
如果 PackageKit 不存在,systemd 會報告找不到該單元;但這並不表示 Zypper 已損壞。如果它處於活動狀態,請檢查其最近的日誌條目,並在考慮停止之前確認沒有正在進行的安裝或更新:
sudo journalctl -u packagekit --since "30 minutes ago"
當已確認的 PackageKit 作業已完成,但其服務仍處於活動狀態並封鎖 Zypper 時,請與負責管理更新的人員或自動化流程進行協調。在適合停止該服務的主機上,使用 `zypper stop` 指令sudo systemctl stop packagekit,然後使用 `zypper stop` 指令進行驗證systemctl status packagekit。請勿透過停用服務或停止無關的更新計時器來解決問題。名稱和更新計劃取決於系統已安裝的元件和管理策略。

過期的鎖定檔案可能出現在會話中斷、系統重新啟動或管理任務失敗之後,但僅憑鎖定檔案的存在並不能確定具體原因。 SUSE 的使用者文件並未針對所有 SLES 版本和配置提供通用的鎖定檔案刪除指南。請避免使用諸如 `--lock-file` 之類的命令rm來修改猜測的路徑,也不要kill -9對未知進程 ID (PID) 執行此操作。鎖定檔案可以在事務進行期間被重新建立或替換,刪除鎖定檔案並不會停止擁有該事務的進程。
重新檢查進程列表,查看相關服務日誌,並確保沒有正在進行的軟體包操作。如果發現過期的 PID 檔案或鎖定路徑,請先驗證其擁有者,並參考您所使用的 SLES 服務包的文件步驟或支援指南進行變更。對於生產系統,請擷取完整的錯誤訊息和日誌,並遵循您所在組織的 SUSE 支援流程。此時,本機細節至關重要:錯誤文字、SLES 服務包、已安裝的桌面工具以及管理代理程式都可能影響正確的復原操作。
競爭操作完成後,刷新儲存庫元資料:
sudo zypper refresh
成功刷新後,Zypper 可以存取其程式碼庫,且進程鎖不再阻止該命令執行。如果您最初的任務是修補系統,請在套用變更之前預覽建議的變更:
sudo zypper patch --dry-run
查看輸出中的軟體包和操作。試運行是計劃檢查,不會安裝列出的更新。當提案預計發布且您的維護窗口允許時,運行該命令sudo zypper patch。 SUSE 的 SLES 15 SP7 文件涵蓋了命令列軟體管理,包括軟體的安裝和卸載;命令行為和可用選項可能因版本而異。請參閱SLES 15 SP7 軟體管理文件和SUSE 的 Zypper 參考文件。


zypper locks當明確鎖定指定包時使用;不要透過移除包規則來清除正在執行的交易。sudo zypper refresh當操作完成且未出現鎖定錯誤,且目標命令可以執行時,問題即已解決。對於補丁程序,請sudo zypper patch --dry-run在應用任何操作之前檢查並確認其建議的操作。如果鎖定再次出現,請記錄確切的錯誤訊息、進程清單、相關服務狀態、最近的日誌輸出以及 SLES 版本,然後調查重新取得鎖定的進程或管理工具,而不是重複刪除鎖定狀態。
準備 SCSI SAN 路徑,啟用 multipathd,檢查 SUSE 的硬體預設設置,並在不猜測陣列設定的情況下驗證穩定的設備映射。
找到持有 Zypper 包鎖的進程,區分進程衝突和包鎖,並在不盲目刪除鎖定檔案的情況下重試更新。
註冊 SLE HA,引導 SLES 15 個節點,然後在依賴故障轉移之前新增隔離、仲裁和測試服務資源。
將 Zypper 刷新錯誤追溯到 SUSE、RMT 或第三方端點,然後應用正確的伺服器端或快取修復程序,同時不停用必要的更新。
透過檢查資料和元資料使用情況、安全地擴展池以及防止重複中斷來解決 SUSE LVM 精簡池空間錯誤。
確定 Btrfs 是否故意設定為唯讀、空間不足或在發生錯誤後保護數據,然後選擇適合該原因的恢復路徑。
準備鏡像通道,建立啟動金鑰,並在沒有直接網路存取的情況下引導 SLES 15 用戶端,同時保持管理員簽到所需的連線。
修復 YaST 透過 SSH 啟動 XIO 時出現的錯誤,驗證 X11 轉送和 xauth,並在不需要遠端視窗時切換到 ncurses 介面。
找到更新前的 Btrfs 快照,以唯讀方式測試它,並使用 Snapper 實現永久恢復,同時了解哪些資料保留在根回滾之外。
Send SLES system logs to a remote rsyslog collector over authenticated TLS, with certificate checks, outage buffering, and delivery tests.