針對 Azure Linux 虛擬機開機問題進行疑難解答，因為操作系統磁碟已滿

發行項
07/30/2024

適用於：✔️ Linux VM

在某些情況下和設定中，完整的操作系統（OS）磁碟可能會導致 Azure Linux 虛擬機（VM）開機問題。本文提供開機問題的一些原因和解決方案。

徵兆

在一般系統作業期間，如果 OS 磁碟或重要系統分割區已滿，可能會發生下列問題：

VM 意外關閉。
VM 無法成功開機。

必要條件

若要針對開機問題進行疑難解答，並完成系統修復，應符合下列需求：

建立磁碟快照集或操作某些備份和還原工具的許可權。

在本文中，數據或磁碟會改變，因此能夠將 VM 還原為先前狀態，是安全系統管理的重要元件。
已啟用和設定的開機診斷。

備妥此設定可讓您日後檢閱控制台記錄的記憶體，並與 VM 的序列控制檯介面互動。
每當需要救援 VM 時，建立 VM 的許可權。
需要交換磁碟時，建立、中斷鏈接和連結磁碟的許可權。

注意

並非所有需求都適用於下列案例。

案例 1：VM 意外關閉，無法開機

許多安全性強化做法可能會導致維護系統的困難。如果在寫入稽核記錄檔時發生錯誤，一個常見的設定會要求系統立即關閉。若要檢查此案例是否為系統關機的原因，請執行下列動作：

檢查序列主控台記錄中的系統關機訊息。

如果系統開機，「正在啟動安全性稽核服務...」訊息隨即顯示。此訊息不會指出服務已啟動。相反地，VM 會立即轉換為關機，並顯示「關閉電源」訊息。如果系統正在執行且意外關閉，序列控制台可能會顯示以「關閉電源」訊息結束的有序關機程式。請參閱下列螢幕快照作為範例：
使用 az vm repair 命令、手動復原 VM 或單一使用者模式掛接 OS 磁碟。然後，使用df命令行工具檢查磁碟使用率，並檢查包含 /var/log/audit 目錄的磁碟是否接近 100% 使用率。
使用 az vm repair 命令、手動復原 VM 或單一使用者模式存取 OS 檔案系統，並確認 /etc/audit/auditd.conf 檔案是否包含下列設定：
```
[root@linux /]# grep action /etc/audit/auditd.conf
admin_space_left_action = HALT
disk_full_action = HALT
disk_error_action = HALT
```

解決方案：暫時停用 HALT 設定

注意

如果此解決方案無法運作或不適合您的環境，請移至 [解決] 區段。

如果稽核的組態造成稽核記錄失敗的系統關機，暫時停用設定 HALT 可讓 VM 開機到完整的 OS 以進行補救。

若要修正此常見的稽核問題和其他幾個常見問題，請使用 Azure Linux 自動修復（ALAR）工具中的稽核動作，在 Azure CLI 中自動執行az vm repair擴充功能。若要手動執行相同的程式，請遵循下列步驟：

擷取OS磁碟的快照集以提供復原狀態。
使用 az vm repair 命令、手動復原 VM 或單一使用者模式來存取組態檔。
記下目前的組態，因為空間可能無法備份 VM 中的檔案。
將 /etc/audit/audit/auditd.conf 檔案中的先前設定從 HALT 變更為除了以外的SINGLE任何其他有效值。在此案例中，這些值可以是 IGNORE、 SUSPEND或 Auditd.conf 檔案之 Linux man 頁面中所列的任何其他值，這會為 VM 中使用的軟體版本提供適當的參數。
```
[root@linux /]# grep action /etc/audit/auditd.conf
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
```

如果您使用復原 VM，請遵循取消掛接和中斷連結原始虛擬硬碟中的指示，將 OS 磁碟交換回有問題的 VM，並嘗試正常開機 VM。如果您使用單一使用者模式，請結束，然後 VM 重新啟動。
VM 完全開機後，請瀏覽檔案系統，並使用和 du等df命令行工具來釋放一些空間。大約 10% 的檔案系統包含 /var/log/audit 目錄應該是良好的初始目標。

問題解決之後，請將 /etc/audit/auditd.conf 檔案中的內容還原為其原始值，然後重新啟動 VM。

案例 2：VM 磁碟在 Azure 中重設大小，但 OS 無法重設大小，且 VM 未完全開機

識別出完整磁碟且 VM 已關閉以調整 OS 磁碟大小之後，VM 可能無法成功開機。在某些散發套件上，OS 嘗試在重新啟動時自動調整根目錄（/）檔案系統的大小，此案例可能會造成混淆。如果磁碟已滿，重設大小作業可能會失敗，因為此程式需要一些可用空間來擴充文件系統。沒有可用空間可能會導致 cloud-init 失敗，然後 VM 無法完成開機。

若要識別此問題，請檢閱序列控制台中的開機記錄，並檢查是否有類似下列文字的行存在：

[   15.384699] cloud-init[1142]: OSError: [Errno 28] No space left on device
[   15.384742] cloud-init[1142]: Original exception was:
[   15.384784] cloud-init[1142]: OSError: [Errno 28] No space left on device

因為特定的 cloud-init 訊息可能不是最明顯的訊息傳回，請尋找包含 “[Errno 28] 裝置上沒有剩餘空間”文字或類似的「沒有空間」訊息的其他行。

若要解決此問題，請清除不必要的數據以釋放少量磁碟空間，然後展開文件系統。

案例 3：VM 開機，但由於服務失敗而無法存取

似乎完全開機的 VM 可能有下列問題：

開機期間發生服務問題。
Azure 代理程式可能無法使用。
VM 的連線可能會失敗。
VM 可能根據應用程式而離線。

開機期間，多個訊息，例如「[Errno 28] 裝置上未留下任何空間」或其他類型的訊息表示根文件系統已滿。

如果 VM 開機但似乎無法使用，請檢查開機診斷內的序列記錄檔以檢視開機訊息，或使用序列控制台與 VM 互動。如果空間不足，請清除不必要的數據以釋放空間或展開磁碟。

如果主控台記錄檔包含許多訊息，指出「ERROR ExtHandler /proc/net/route 不包含任何路由」，則完整OS磁碟也可能是原因，因為網路服務無法完全啟動。

解決方法

下列解決方案適用於上述任何案例。

解決方案 1：清除不必要的資料

使用 az vm repair 命令、手動復原 VM 或單一使用者模式來存取 OS 磁碟和數據分割，因為系統不會正常開機。
使用標準 Linux 工具和命令來識別大型檔案和目錄：
- du -ks /* | sort -n - 找出位置中最耗用空間的檔案或目錄。在最大的報告目錄上重複，直到發現某些大型數據為止。
- ls -altSr /var/log - 以遞增順序序列出目錄的內容，依大小排序。
- find / -size +500M -exec ls -alFh {} \; - 尋找大型個別檔案。視需要將 500M 值調整為數 MB 或 GB，以找出要剪除的最有效檔案。
拿掉任何可識別為不必要的檔案，例如舊記錄、忘記的備份和類似的檔案。
清除適當的空間量后，請將目標設為 10% 的可用磁碟，然後重新啟動系統。

解決方案 2：展開 OS 檔案系統

如果 OS 檔案系統中無法清除任何數據，建議您擴充包含重要 OS 磁碟區的磁碟。如需詳細資訊，請參閱在Linux VM上展開虛擬硬碟。

下一步

如果特定開機錯誤不是Linux開機問題，因為操作系統磁碟已滿，請參閱針對 Azure Linux 虛擬機開機錯誤進行疑難解答，以進一步進行疑難解答。

與我們連絡，以取得說明

如果您有問題或需要相關協助，請建立支援要求，或詢問 Azure community 支援。您也可以向 Azure 意見反應社群提交產品意見反應。

共用方式為