針對因完整 OS 磁碟而導致的 Azure Linux 虛擬機開機問題進行疑難解答

發行項
03/27/2024

在某些情況下，完整操作系統 (操作系統) 磁碟可能會導致 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 進行補救。

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

擷取OS磁碟的快照集，以提供復原狀態。
使用 az vm repair 命令、手動復原 VM 或單一使用者模式，取得組態檔的存取權。
請記下目前的設定，因為可能無法在 VM 中備份檔案。
將 /etc/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 完全開機，請瀏覽檔案系統，並使用和等dfdu命令行工具釋出一些空間。大約 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 代理程式可能無法使用。
Connections VM 可能會失敗。
根據應用程式，VM 可能看起來離線。

在開機期間，多個訊息，例如 “[Errno 28] 裝置上沒有剩餘的空間”或其他類型的訊息，表示根文件系統已滿。

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

如果主控台記錄檔包含許多訊息，指出「錯誤 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上擴充虛擬硬碟。

後續步驟

如果特定開機錯誤不是因為完整OS磁碟而導致的Linux開機問題，請參閱針對 Azure Linux 虛擬機開機錯誤進行疑難解答，以進行進一步的疑難解答。

與我們連絡，以取得說明

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

共用方式為