當 SLES Btrfs 檔案系統變成唯讀時:重新掛載前請先診斷
確定 Btrfs 是否故意設定為唯讀、空間不足或在發生錯誤後保護數據,然後選擇適合該原因的恢復路徑。
如果 YaST 透過XIO: fatal IO error 11 (Resource temporarily unavailable)SSH 退出,請先嘗試 SUSE 文件中提供的 Qt 解決方法:QT_XCB_GL_INTEGRATION=none yast.ssh。對於已安裝的 SLES 系統和特定的 YaST 模組,請在模組名稱前使用相同的變量,例如QT_XCB_GL_INTEGRATION=none yast2 disk。如果無法開啟任何圖形應用程序,請先修復 X11 轉送:使用 連接ssh -X,檢查遠端 shell 是否具有DISPLAY值,並確認伺服器已啟用 X11 轉送。
SUSE 的 SLES 15 SP7 部署指南詳細記錄了這種 XIO 故障,並提供了 Qt 的解決方法和 ncurses 的替代方案。該部分內容出現在遠端安裝的上下文中,因此請將其作為針對 YaST over SSH 故障的修復方案;它並不能證明所有 YaST 啟動失敗的原因都相同。以下檢查可以將此情況與本機 X 伺服器缺失、SSH 轉送停用或 X 驗證問題區分開來。
X11 轉送透過 SSH 將遠端應用程式的視窗流量傳送到本機上的 X 伺服器。因此,本機電腦需要運行 X 伺服器,且 SSH 用戶端必須請求轉送。在 X11 桌面上,開啟一個新的終端並如下連接:
ssh -X admin@server.example.com
請將帳戶和主機名稱替換為您自己的帳戶和主機名稱。登入後,執行:
echo "$DISPLAY"
類似這樣的值localhost:10.0表示 SSH 設定了轉發顯示。這只是一個範例,並非固定值:顯示編號可能會有所不同。如果輸出為空,請登出並重新連接-X。如果仍然為空,請檢查客戶端 SSH 設定和下一節中的伺服器設定。請勿手動將其DISPLAY設為猜測的值;SSH 會為會話建立一個代理顯示。

如果您在 Windows 系統上使用 PuTTY,請在會話的「連線」>「SSH」>「X11」設定中啟用 X11 轉發,並確保本機 X 伺服器正在執行。 SUSE 的部署指南中明確指出了這項要求。即使 SSH 登入成功,如果本機沒有 X 伺服器,遠端主機也無法顯示視窗。
在 SLES 主機上,管理員可以檢查 SSH 守護程式配置:
sudo grep -i '^X11Forwarding' /etc/ssh/sshd_config
command -v xauth
有效的伺服器策略必須允許 X11 轉發,並且xauth必須可用於身份驗證交接。 SUSE 文件X11Forwarding Yes中將其作為伺服器端設置,並指出 SSH 會DISPLAY在客戶端連線時設定遠端伺服器-X。簡單的grep配置可能會遺漏設定檔或條件區塊中的設定Match;如果輸出結果與實際行為相衝突,請讓 SSH 管理員檢查有效配置,而不是新增重複的行。

如果進行了更改sshd_config,請在重新載入守護程序之前驗證該檔案:
sudo sshd -t
sudo systemctl reload sshd
請務必以管理員身份執行這些命令。測試新會話時,請保持現有 SSH 會話打開,以免配置錯誤導致您無法存取。測試完成後,斷開連線並重新連線;轉送設定在 SSH 會話啟動時進行協商。請勿在伺服器上開啟 TCP 連接埠 6000 或將xhost +其用作捷徑。 SSH 轉送旨在對 X 流量進行隧道傳輸並管理其身份驗證;直接存取 X 可能會顯示內容暴露給其他電腦。
如果DISPLAY已設定且另一個轉送的 X 應用程式打開,但 YaST 出現上述 XIO 錯誤,請嘗試針對該次啟動使用文件中記錄的環境變數覆寫:
QT_XCB_GL_INTEGRATION=none yast.ssh
對於常規安裝的系統,請啟動所需的模組,而不是假設安裝助手程式已存在。例如,SUSE 對此模組表單有詳細說明:
QT_XCB_GL_INTEGRATION=none yast2 disk

此變數僅適用於其後的命令;它不會永久更改 Qt 設定或 SSH 策略。 SUSEyast.ssh的安裝系統使用此指令,而已安裝的 SLES 主機通常會使用此指令啟動 YaST 模組yast2。如果其他模組發生故障,請將 `<module_name>` 替換為其文件中記錄的模組名稱disk。請勿將此環境變數設定視為解決空白DISPLAY或用戶端缺少 X 伺服器問題的方案。
如果您只需要完成管理操作而不需要圖形窗口,請在 SSH 終端機中使用 YaST 的 ncurses 介面。關於磁碟模組,請參閱 SUSE 文件:
yast2 disk --ncurses
您也可以明確地為該模組請求 ncurses 後端:
YUI_PREFERRED_BACKEND=ncurses yast2 disk

文字介面完全避免了 X11 轉發,通常是遠端伺服器最簡單的選擇。它仍然是 YaST,仍然會更改系統配置;在確認更改之前,請仔細檢查磁碟、分割區、防火牆和網路配置。對於 SLES 安裝系統,SUSE 表示,當本地 X 伺服器不可用時,YaST 會提供一個 ncurses 介面。
使用 SSH 開啟新的會話ssh -X,確認會話echo "$DISPLAY"不為空,然後使用對應的指令啟動 YaST。成功表示 YaST 視窗出現在本機桌面上,或者如果您選擇了 ncurses 後端,則 ncurses 模組會在終端機中開啟。如果轉送正常,但在 Qt 覆蓋後仍然存在相同的 XIO 錯誤,請捕獲完整的終端錯誤訊息,並查看 SLES 發行說明或 SUSE 支援知識庫,以查找特定於該版本的問題;僅憑錯誤片段無法識別無關的 Qt 或 YaST 缺陷。
-X— X11 轉送的客戶端選項,包括不受信任和受信任之間的差異-Y。確定 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 設備清單。