GHES support bundle 上傳被拒絕怎麼辦？先升到指定 patch

先核對版本與失敗的命令#

先在 appliance 上執行版本檢查。GitHub 文件說明 ghe-version 會印出 GitHub Enterprise Server 的版本、平台與 build：

1
ssh -p 122 admin@HOSTNAME -- 'ghe-version'

再記下失敗時實際使用的命令：

這一步的重點是確認「版本門檻」而不是重複嘗試同一個上傳命令。support bundle 內含診斷與經過清理的日誌，GitHub 文件也說明它與較小的 diagnostics file 是不同資料層級。

2026-08-18 起適用的最低 patch#

GitHub 目前在 Enterprise Server 文件列出的最低版本如下；同一版本線使用更高的 patch 也符合這個門檻：

不要只把「3.21」當成已符合要求。這次檢查的是完整的 patch 版本，例如 3.21.2 仍低於文件列出的 3.21.3。如果 appliance 已在不受這份文件涵蓋的舊版本線，應先確認該版本線的支援狀態與升級路徑，而不是自行猜一個 patch number。

升級後再做一次最小驗證#

升級完成並確認管理主控台服務正常後，建議依序留下下面幾項證據：

1. 重新執行 ghe-version，保存版本、平台與 build 輸出。
2. 確認叢集或 geo-replication 的每個必要節點都完成相容的升級。
3. 依 GitHub Support 指示產生 standard 或 extended bundle。
4. 確認 appliance 能透過 TCP 443 連到支援 bundle 的上傳端點，再進行上傳。
5. 把 ticket reference、產生時間、版本與 bundle 檔名記在維運紀錄，不要只留下「重新執行成功」。

單機環境可以先用官方文件的標準命令產生檔案：

1
ssh -p 122 admin@HOSTNAME -- 'ghe-support-bundle -o' > support-bundle.tgz

如果是叢集，改用 ghe-cluster-support-bundle；如果 Support 要求八天內的歷史日誌，才依文件使用 extended bundle 的 -x 選項。這些命令的選擇取決於環境與 ticket 要求，不要把單機範例直接套到叢集。

無法立即升級時怎麼處理？#

GitHub 文件給的處理方向很明確：如果無法在 8 月 18 日前升到要求的 patch、但仍需要上傳 support bundle，應聯絡 GitHub Enterprise Server Support 取得指示。現在已經過了這個日期，更不適合透過修改命令參數、重試上傳或把 bundle 放到非官方位置來繞過限制。

如果 Support 只需要先看環境摘要，可以依文件使用 ghe-diagnostics 產生較小的 diagnostics file：

1
ssh -p 122 admin@HOSTNAME -- 'ghe-diagnostics' > diagnostics.txt

這份檔案仍應依 Support 指示提供，不能自行把它當成完整 bundle 的等價物。support bundle 和 diagnostics file 的內容、大小與用途不同；尤其是需要歷史日誌或叢集資料時，最後仍可能必須完成正式升級。

結論：把 patch 檢查放進支援流程#

這次變更最容易被忽略的地方，是它發生在故障排查的最後一段：系統本身可能仍能運作，但當 Support 要求 bundle 時，舊 appliance 才暴露出版本門檻。日後建立 GHES 維運清單時，至少把 ghe-version、目前版本線的最新 patch、叢集節點狀態與支援上傳路徑一起記錄，避免等到事故發生才發現診斷資料送不出去。

常見問題#