當 SLES Btrfs 檔案系統變成唯讀時:重新掛載前請先診斷
確定 Btrfs 是否故意設定為唯讀、空間不足或在發生錯誤後保護數據,然後選擇適合該原因的恢復路徑。
在啟用了 Snapper 且根檔案系統為 Btrfs 的標準 SUSE Linux Enterprise Server (SLES) 系統上,最安全的復原方法是啟動失敗更新之前所建立的快照,在唯讀狀態下進行測試,然後執行復原指令sudo snapper rollback。這將從測試狀態建立一個新的可寫根分割區;它不會回滾每個磁碟、子磁碟區或應用程式資料庫。
目前的 SLES 15 SP7 管理指南仍然採用這種啟動和測試工作流程。在執行此操作之前,請確認機器符合 SUSE 支援的回溯佈局,並確定失敗的 Zypper 或 YaST 交易的預快照。
否。可引導系統回滾僅適用於預設 Snapperroot配置中的快照。 SUSE 文件支援預設的根子磁碟區配置,即單一根裝置上的 Btrfs 檔案系統以及已安裝的可用開機載入程式。回滾操作會更改子卷的內容/;其他子卷不會被更改。在典型的 SLES 佈局中,諸如/var`/ usr / local/bin`、` /srv/ usr/local/bin`、`/usr/ local/bin` 和 `/usr/local/bin` 之類的路徑通常位於快照之外。因此,即使系統軟體套件已回滾,資料庫或服務仍可能保留快照後寫入的資料。/opt/usr/local/home
在執行回滾作業之前,請務必備份或驗證重要的應用程式資料。此外,如果您變更了預設的 Btrfs 子磁碟區佈局或使用了多裝置根目錄,也請避免執行此操作:SLES 15 SP7 文件中記錄的可啟動回溯要求不涵蓋這些設定。請在繼續操作之前閱讀 SUSE 的Snapper 恢復要求。
使用 Snapper 設定根檔案系統,並比較交易的執行前/執行後快照對。在啟用了 Btrfs 根快照的典型 SLES 系統中,Zypper 和 YaST 會在套件操作前後建立快照。執行前快照表示該操作之前的根狀態;執行後快照表示該操作執行後的狀態,包括部分失敗的交易。
sudo snapper list-configs。尋找名為 . 的配置root。findmnt -no FSTYPE /。對於此可引導回滾過程,它應該會報告btrfs。然後運行sudo btrfs filesystem show /並確認根檔案系統報告Total devices 1。sudo snapper -c root list -t pre-post。將日期和描述與失敗的更新進行配對。在Pre #列中記錄編號,而不是配對的事務對Post #。PRE和替換POST為您機器上顯示的數字:sudo snapper -c root status PRE..POST
sudo snapper -c root diff PRE..POST
這些命令會列出已變更的路徑和檔案差異。快照編號、日期、軟體包說明和輸出因主機而異;請勿從螢幕截圖複製範例編號。如果沒有出現相關的快照對,請檢查 Snapper 是否已啟用,以及清理策略是否已刪除該快照。 Snapper 無法事後重新建立遺失的快照。

重新啟動並使用引導程式的快照條目。在 SLES 系統中,選擇「啟動」Start Bootloader from a read-only snapshot,然後選擇失敗事務發生前不久的快照。啟動選單會以日期和描述標記項目,描述可能包括zypp(zypper)YaST 操作。選擇您記錄的更新前快照;不要因為更新後快照的描述更容易識別就選擇它。
登入並測試故障的服務或應用程式。在此測試期間,快照的根檔案為唯讀,因此僅此一次啟動不會變更預設根目錄。如果快照錯誤或系統仍然發生故障,請重新啟動並嘗試另一個快照,或使用救援系統。請勿僅為了使選單選項永久生效而強制回滾。

僅在舊快照啟動並通過所有檢查後才執行回滾操作。從該只讀快照執行以下命令:
sudo snapper rollback
然後重新啟動並選擇正常的預設啟動項目:
sudo reboot
Snapper 會保留回滾前系統狀態的快照,並基於該快照建立新的讀寫根目錄。在文件中記錄的從快照啟動工作流程中,您無需將舊快照編號傳遞給此命令。最終結果是一個新的預設根目錄,而不是將只讀快照本身轉換為可寫入目錄。快照稍後可能會被清理規則刪除,因此在將舊的回滾快照用作長期存檔之前,請先複製所有必需的檔案。

啟動預設入口點,並檢查實際的恢復情況,而不僅僅是命令是否執行完畢。確認內核和軟體包狀態是否符合預期,查看故障服務的狀態和日誌,並執行一個簡單的應用程式層級檢查。然後檢查 Snapper 的新狀態:
sudo snapper -c root list
對於普通的軟體包更新,這通常足以確認機器從新的根目錄啟動。如果失敗的操作是服務包遷移,則應遵循 SUSE 的回溯後檢查步驟:刷新並檢查軟體倉庫,然後檢查註冊:
sudo zypper ref -fs
sudo zypper lr
sudo SUSEConnect --status
軟體倉庫應與您恢復到的服務包相匹配,並且已安裝的產品應已註冊。如果註冊未恢復,請依照 SUSE 的SLES 15 SP7 服務包回溯流程文件中的sudo SUSEConnect --rollback步驟進行修復。此註冊命令專門用於遷移恢復;請勿將其用於常規軟體包更新。

如果此主機使用transactional-update(例如,交易型 SLE Micro 系統),請遵循該產品的步驟,而不是套用傳統的 SLES 指令序列。該產品的文檔中提供了sudo transactional-update rollback SNAPSHOT_NUMBER從運行系統中選擇快照的方法,以及在當前根目錄損壞時使用單獨的啟動只讀快照工作流程。請參閱 SUSE 的交易更新回滾說明。
確定 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.
使用 RAM、交換空間、核心和 Zypper 日誌來識別真實的記憶體壓力,保護軟體包狀態,並選擇更安全的 SLES 升級重試。
啟用 Debian 透過 SSH 進行的無人值守安全性更新,保留預設軟體套件來源,並透過 systemd 和 APT 日誌驗證計畫運作。
比較郵件投遞選項,在 Ubuntu 上配置 smartd,並驗證磁碟健康警告是否到達您的收件匣。
透過檢查 systemd-resolved、在需要時修復 resolv.conf 以及驗證上游 DNS 和應用程式解析,恢復 Debian 12 上的 DNS 查找。
讓 Ubuntu 偵測到你的顯示器或電視作為音訊輸出設備,在聲音設定中選擇它,如果缺少 HDMI,請檢查連接或 PipeWire 設備清單。