如何在不破壞依賴關係的情況下將 Debian 12 遷移到 Testing 版本
將 Debian 12 Bookworm 系統移轉到 Debian Testing,減少依賴項的意外情況。了解支援的 Bookworm 到 Trixie 遷移路徑、APT 檢查、模擬和復原保障措施。
範例場景: Maya 維護一台用於開發的 Debian 12 Bookworm 工作站。她想要使用 Debian Testing 中的新軟體包,但又不能接受 APT 軟體包集未完全升級的情況。最穩健的方法是先升級到目前支援的穩定版本,然後再將乾淨的穩定係統切換到目前的 Testing 版本。此範例僅說明一種謹慎的操作步驟;它並非實際升級的指南,也不能保證每台機器的軟體包計劃都相同。
截至 2026 年 10 月 6 日,Debian 將 Debian 13 “Trixie” 標記為穩定版,將 Debian 14 “Forky” 標記為測試版。 Debian 的測試版升級指南建議從目前的穩定版升級到測試版;指南警告稱,從較舊的穩定版升級可能會導致意外錯誤。對於 Bookworm 安裝,這表示在將軟體來源變更為 Forky 之前,需要先按照官方的 Bookworm 到 Trixie 升級指南進行操作。由於 Debian 發布新的穩定版時,測試版的代號也會發生變化,因此請在升級當天再次查看版本頁面。
APT 使用系統上配置的軟體包索引和發布套件來解決依賴關係。如果您將舊版本直接指向 Testing 目錄,APT 可能會在一次操作中對核心程式庫、核心、桌面環境、韌體和第三方軟體包提出更改建議。模擬可以發現有問題的方案,但無法使不受支援的初始配置變得安全。
測試版是一個不斷變化的系統。軟體套件在滿足歸檔標準後會從不穩定版遷移到穩定版,但仍可能出現暫時的依賴關係缺失和迴歸問題。此外,Debian 不會像穩定版那樣為測試版提供永久的安全支援。這種方式可以減少不必要的軟體包衝突,但無法讓測試版像穩定版一樣可靠,也無法完全避免未來的所有問題。
Maya 首先確認這是 Debian 系統本身,並記錄目前系統狀態。在進行任何編輯之前,她會閱讀當前版本詳情和軟體倉庫檔案:
cat /etc/os-release
cat /etc/debian_version
apt-cache policy
dpkg --audit
apt-get check
apt-mark showhold
她會檢查/etc/apt/sources.list`<path>` 中的每個文件,以及 `<path>`和/etc/apt/sources.list.d/`<path>` 中的 APT 首選項。目標是在升級過程中出現混亂之前,識別出供應商倉庫、本地建置的軟體包、已鎖定的版本和已保留的軟體包。如果`<path>` 報告軟體套件配置未完成或依賴項損壞,Maya 會先在 Bookworm 中修復該問題,而不是直接在其上疊加發行版變更。/etc/apt/preferences/etc/apt/preferences.d/dpkg --auditapt-get check
在修改軟體包原始碼之前,Maya 會建立經過測試的個人資料和重要配置備份,包括應用程式資料庫和服務資料(如適用)。完整的磁碟映像或虛擬機器快照讓她能夠恢復作業系統;而單獨的使用者目錄副本則無法做到這一點。她還會確保自己擁有本地控制台存取權限、可啟動的恢復媒體、足夠的可用空間/以及/var穩定/boot的網路連線。
如果機器是遠端的,她會安排停機時間,並在條件允許的情況下使用外部控制台。重新啟動網路或取代 SSH 元件的軟體包升級可能會導致遠端會話中斷。對於重要的伺服器,Maya 會先在複製伺服器上測試整個升級流程。 Debian 的發行說明包含準備和恢復指南;每次版本升級前都應該閱讀這些說明。
Maya 遵循 Debian 13 官方發行說明中的 Bookworm 到 Trixie 升級流程,包括檢查第三方軟體包、APT 首選項、軟體包狀態和可用磁碟空間。她沒有跳過 Bookworm 支援的升級步驟,而是將所有原始檔案重寫為 Forky。 Debian 官方文件中明確記錄了從 Debian 12 到 Debian 13 的升級過程;請參考該發行版文檔,以了解適用於您系統的特定軟體包和配置提示。
機器完全升級後,她重新啟動進入Trixie系統,確認啟動正常。她檢查關鍵服務、網路存取、儲存掛載、圖形或桌面登錄,以及任何依賴韌體的硬體。這個檢查點非常重要:如果出現問題,她可以在引入測試之前診斷出單一版本過渡過程中存在的問題。
在 Trixie 系統運作正常後,Maya 會保存其 APT 原始檔和首選項檔的副本。她會暫時停用第三方軟體倉庫以及 Trixie 特有的反向移植或更新條目。如果沒有明確的版本鎖定策略,混合使用穩定版、測試版和不穩定版軟體套件可能會導致庫不匹配和依賴衝突。來自 Debian 以外供應商的 Forky 軟體包可能尚未存在;她會檢查每個供應商的兼容性信息,而不是想當然地認為 Trixie 軟體倉庫就適用。
在目前安裝中,原始檔案可能使用較舊的單行格式或 deb822.sources格式。請編輯目前使用的格式,並確保在測試升級開始時,bookworm沒有活動的 Debian 條目仍然指向該格式。trixie
在這個特定日期的範例中,Forky 是目前的測試代號。一個類似這樣的 deb822 原始檔/etc/apt/sources.list.d/debian.sources可以使用以下結構。保留與安裝相符的元件;此範例包含通用韌體和非自由區域,但不會在每個系統上自動啟用它們。
Types: deb
URIs: https://deb.debian.org/debian
Suites: forky
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
未經檢查,請勿將此配置段複製到現有配置之上。保留系統所需的鏡像選擇和元件,並刪除或註解掉重複的 Debian 條目。testing如果打算在 Forky 穩定版發布後繼續使用,請避免使用行動別名。 Forky 的版本過渡期間會使用一個代號;套件名稱testing則跟隨未來正在測試的版本。
對於測試版,請勿盲目保留穩定版的安全性更新 URL,例如 ` <security_url> trixie-security` 或將其替換為猜測的forky-security更新套件。 Debian 的常見問題解答指出,測試版不會像穩定版那樣獲得專屬的安全更新;修復程式可能需要從不穩定版遷移,並且更新時間可能有所不同。讀者應查看目前的 Debian 測試版指南和漏洞訊息,並自行判斷該支援模式是否可接受。
原始檔編輯完成後,Maya 會刷新包元數據,並要求 APT 模擬完整升級:
sudo apt update
sudo apt -s full-upgrade
模擬是一個審核步驟,而不是應該自動接受的核准提示。 Maya 會讀取要安裝、升級、保留和移除的軟體包清單。如果提案移除了桌面元軟體包、SSH 伺服器、引導程式、網路管理器、資料庫或其他依賴的軟體包;如果移除了大量不相關的軟體包;或者如果 APT 報告了未解決的依賴關係,Maya 就會停止。她會檢查原因是否為已啟用的第三方來源、保留、鎖定、磁碟空間不足或臨時測試狀態轉換。
被暫緩發布的軟體包並非一定會失效。它可能需要進行一些依賴項更改,而保守的upgrade發布方式不會滿足這些更改。請勿僅為了使軟體包數量歸零而強制安裝庫或移除元軟體包。如果您對發布計劃仍有疑問,請等待歸檔過渡穩定後再發布,查閱相關的 Debian 軟體包錯誤報告或過渡訊息,或繼續使用穩定版。
如果模擬合理且備份是最新的,Maya 首先會執行升級,但不會刪除已安裝的軟體包:
sudo apt upgrade --without-new-pkgs
她仔細閱讀所有設定檔相關的問題,並記錄本地的變更。然後她再次進行模擬,因為軟體包計劃可能已經發生變化:
sudo apt -s full-upgrade
只有當提出的移除和新增方案合理時,她才會實際執行操作:
sudo apt full-upgrade
full-upgrade可以安裝新的依賴項並移除軟體包以完成版本切換。這就是模擬和人工審核的重要性。如果出現無法解釋的移除操作或依賴項錯誤,Maya 會停止並儲存原始輸出。它不會進行隨機的apt --fix-broken install、強制的版本選擇或手動移除庫的操作;這些操作可能會加劇不一致。首先檢查 APT 的錯誤、來源配置、保留狀態和軟體包狀態,然後在了解原因後再重試。
在軟體包解壓縮和配置過程中,請保持機器通電並連接網路。避免同時啟動其他軟體套件管理器。如果該過程中斷,請按照所觀察到的錯誤進行恢復,並在確認軟體包資料庫狀態後,再完成待處理的軟體包配置。
APT 安裝完成後,如果沒有未解決的錯誤,Maya 會檢查軟體包狀態,並在適當的時候重新啟動:
sudo dpkg --audit
sudo apt-get check
sudo apt update
sudo reboot
重新啟動後,她使用 `sudo apt-get install` 確認已安裝的版本/etc/os-release,使用 `sudo apt-get install` 檢查預期核心是否正在運行uname -r,並檢查和測試其關鍵應用程式和服務。她可以在 `sudo apt-get install`和 `sudo systemctl --failedapt-get install` 中查看最近的軟體包活動。如果系統無法啟動、網路連線無法使用或重要服務發生故障,即使 APT 運作成功也無濟於事。/var/log/apt/history.log/var/log/dpkg.log
只有在 Debian 軟體包運作正常後,她才會考慮逐一重新啟用第三方軟體來源,並且只有在供應商明確表示支援 Forky 的情況下才會這樣做。之後,她會運行apt update並模擬任何升級,然後再決定是否要接受。她會保留恢復備份,直到機器在正常使用下穩定為止。
當機器啟動進入預期的測試代號,dpkg --audit系統乾淨,apt-get check未報告任何損壞的依賴項,APT 從目標倉庫更新且無簽名或版本錯誤,並且關鍵工作負載通過自身檢查時,Maya 認為遷移完成。她還會記錄日期、原始碼更改、軟體包刪除以及任何手動配置決策,以便日後追蹤回歸問題。
如果目標只是安裝一個較新的應用程序,那麼使用穩定版並使用官方的向後移植版本、廠商支援的軟體包、容器或隔離的測試環境可能幹擾較小。但如果電腦是業務關鍵型設備、需要連接互聯網或無法快速恢復,那麼 Debian 穩定版通常是更合適的選擇。測試版適用於那些準備好監控更新、閱讀軟體套件計畫並解決臨時歸檔或依賴項問題的使用者。
將 Debian 12 Bookworm 系統移轉到 Debian Testing,減少依賴項的意外情況。了解支援的 Bookworm 到 Trixie 遷移路徑、APT 檢查、模擬和復原保障措施。
使用同步通道、引導儲存庫、啟動金鑰和經過驗證的 Salt 引導工作流程,無需 Internet 存取即可將 SLES 15 註冊到 SUSE Manager。
解決 Ubuntu 24.04 掛起後 Wi-Fi 斷開的問題:更新、檢查無線電區塊和 NetworkManager、測試省電模式、檢查日誌並驗證修復。
透過診斷 ALSA 設備並安全地調整 WirePlumber 緩衝區、取樣率和直接 ALSA 設置,修復 Ubuntu 24.04 中的劈啪聲、嗡嗡聲和失真聲音。
學習如何對自訂 SLES 15 核心模組進行簽名,將其憑證註冊到 MOK,在安全啟動下載入它,驗證結果,以及處理核心更新。
在 SLES 15 上設定 KVM,配置 libvirt 網路和存儲,建立虛擬機,啟用自動啟動,並在主機重新啟動後驗證可靠啟動。
Configure a WireGuard point-to-site VPN on Debian 12 with wg-quick, IPv4 forwarding, nftables NAT, client profiles, systemd startup, and verification.
在生產推廣之前,根據目前的 DISA STIG 對 SLES 15 進行審核,審查 OpenSCAP 的調查結果,測試補救措施,並記錄例外情況。
了解如何在 SUSE Linux Enterprise Server 上設定 SAP HANA 全域和語句記憶體限制,將 HANA 限制與 SUSE MemoryLow 進行比較,並安全地驗證每個變更。
了解 Gooroom OS 瀏覽器隔離的工作原理,準備受信任且被封鎖的 URL 策略,協調 GPMS 配置,並驗證您的建置中的設定。