這段地基平常被跳過，是因為多數人是在一台早就裝好的機器上開始管理 dotfile。但只要你換到全新環境——開一台 VM、租一台雲端主機、拿到一台空機器——就會直接撞上這層：安裝程式問你十幾個選項該怎麼選、裝完發現連 sudo 都沒有、想從本機連進去卻還沒有 SSH key。這些都不在編號模組的範圍，卻是跑 模組八的 bootstrap script 之前必須先過的關。

本系列的內容來自一次完整的 VM 實測：在 Apple Silicon 的 UTM 上從 archboot（Arch 的獨立網路安裝環境 ISO）裝 Arch Linux ARM、跑 dotfile 的 install.sh、一路把 Hyprland 桌面拉起來。實測中每個卡關點都被記錄下來，這裡把它們蒸餾成可重用的判讀與決策，不綁特定發行版或虛擬化軟體。

在學習路徑中的位置

模組零的操作順序指引 列出從 OS 安裝到桌面就緒的完整依賴鏈，但只把「安裝作業系統」標成一步。本系列是那一步的展開：安裝程式每個選項背後的取捨、裝完之後的驗證、以及連入機器的幾種路徑。

文章

機器裝好、能連入之後若出問題（連不上、終端機亂、程式行為怪），除錯與診斷自成一組，見同層的 Linux 除錯與診斷。

依情境的讀法

主線那幾篇照「安裝 → 驗證 → 連入 → 可除錯 → 無人值守」的順序，是「從零開一台新機器、到讓它自己跑活」的完整路線，但不是每個讀者都從零開始：

• 接手一台別人已裝好的機器：OS 已經在，從 最小安裝後的工具驗證與補足 切入，確認它缺不缺你流程要的工具。
• 雲端主機初始化：雲端主機多半已附 OS image、已有 sudo 與注入的 key，適用的是 外部連入、SSH key 與無 key 的 bootstrap 路徑 跟 可除錯的 bootstrap，前兩篇的 ISO 安裝可略過。
• bootstrap 失敗來 debug：直接讀 可除錯的 bootstrap，它也涵蓋「腳本不是你寫的、只想 debug 一次失敗」的情況。
• 讓機器無人值守跑活：機器已能連入操作，只想設好讓它在你離開後自己跑長任務或 agent，直接讀 讓機器跑無人值守的長任務。
• 遇到問題要除錯：機器已在跑但出狀況（連不上、終端機亂、程式行為怪），進 Linux 除錯與診斷，從 診斷心法 建立判讀紀律，再依症狀分流。
• 裝好後想讓它自己顧：服務跑起來後，主動確認這台有沒有在監控自己的服務死活（systemctl show sshd -p OnFailure），沒有就從最簡單的 OnFailure + ntfy 建起——遠端機器至少把 sshd 掛上，掛了就失聯。見 服務掛了怎麼自動知道。

跟其他模組的交叉引用

• 模組八：Bootstrap script 設計——本系列是它的前置；bootstrap 假設套件清單完整、機器可連入，本系列補「在那之前」。
• 模組五：Hyprland VM 測試——本系列的 VM 安裝是它的下游前置；裝好機器才能測 Hyprland。
• 模組七：日誌判讀與診斷工具——「可除錯的 bootstrap」與它呼應：前者談怎麼產生可診斷的 log，後者談怎麼讀。
• Linux 除錯與診斷——本系列裝好、連入之後的下游；出問題時的判讀紀律與情境分流。
• Linux 工具選單——安裝與除錯要用的工具（CLI / 圖形桌面 / 遠端）有哪些選擇、推薦用哪些。
• Infra 心智模型：拿到雲端帳號的第一天——雲端主機的機器初始化是本系列的上游情境；被指派 infra 工作、拿到一台雲端主機後，先過本系列的 OS 連入與 bootstrap 前置，再進 infra 的資源管理。

這篇給每個關鍵選項一條判斷軸，而不是一份「照著點」的步驟。底下用一次具體的安裝當作貫穿例子：在 Apple Silicon 的 UTM 上用 archboot ISO 裝 Arch Linux ARM，目標是一台演練 dotfile 部署的測試 VM。例子是具體的，但判斷軸跨發行版通用——locale、分割、bootloader 這些抉擇在多數 Linux 安裝程式裡都會以類似形式出現。

怎麼建立 VM、燒錄並開機到安裝程式，是跟環境綁定的前置——UTM、VirtualBox、實體機各不相同——不在這條判讀軸的範圍；這篇從「安裝程式已經跑起來、開始問你選項」接手，給的是每個選項的判斷軸，不逐頁帶某個安裝程式的選單怎麼點。底下的指令與選單名稱以 archboot / Arch 呈現，換 Ubuntu（Subiquity 安裝程式）或 Fedora 時，選項的判斷軸一樣成立，但選單長相、套件組名稱、指令會不同。

系統語系與時間

系統語系決定的是錯誤訊息、log、系統工具輸出用哪種語言，不是你日常打字的語言。這兩件事容易混為一談。日常輸入中文是桌面層的字型與輸入法問題，跟系統 locale 無關；系統 locale 影響的是當某個服務崩潰、你在 journalctl 裡讀它吐出來的那行訊息時，那行字是英文還是被翻譯過。

把系統 locale 留在 en_US.UTF-8 的理由是可搜尋性。當你把一段錯誤訊息貼到搜尋引擎或問別人，英文訊息能對上絕大多數的文件、issue、Stack Overflow 答案；翻譯過的訊息往往一個結果都搜不到。這條判斷軸對伺服器、開發機、任何你預期會除錯的機器都成立。會選非英文 locale 的情境通常是給終端使用者的桌面，且該使用者不除錯——那是另一種機器。

時區的選擇影響 log 的時間戳跟排程任務的觸發時刻，挑你所在地即可。另一個相關的決策是「硬體時鐘存 UTC 還是本地時間」：選 UTC。Linux 慣例是硬體時鐘存 UTC、顯示時再換算成時區，這樣跨時區搬機器、或 NTP 校時都不會錯亂。會需要存本地時間的唯一常見情境是跟 Windows 雙開——Windows 預設把硬體時鐘當本地時間——而 VM 或純 Linux 機器沒有這個包袱。

網路

安裝階段的網路設定要回答兩個層次：當下能不能連、以及這份設定會不會帶進裝好的系統。第一層通常很直覺——選到對的網卡、用 DHCP 讓它自動拿 IP。虛擬機的 NAT 網路會自動發 IP，所以選 DHCP、不要手動設 static，省去算網段的麻煩。

第二層是真正會咬人的地方：安裝程式裡設好的網路，不保證會出現在重開機後的系統裡。這是 VM 裝 Linux 常見的斷網點——安裝時明明能上網裝套件，重開機後卻連不出去，因為安裝環境的網路設定沒被複製到目標系統。判讀方式是裝好首次開機後立刻驗證：看網卡有沒有拿到 IP、能不能解析一個域名。

1ip -brief a          # 網卡有沒有 IP、狀態是不是 UP
2ping -c 3 archlinux.org   # 解析成功就證明對外連線 + DNS 都通

DNS 能把域名解析成 IP，本身就證明對外連線是通的（DNS 查詢就是一次網路往返），所以這條 ping 即使對方不回 ICMP 也已經給了答案。在前述的 archboot 例子裡，網路設定確實有被複製進目標系統並由 systemd-networkd 接手，重開機後免再手動設——但這是該安裝程式的行為，不能假設每個安裝程式都這樣。把「首次開機驗網路」當成固定動作，比預設它一定會通安全。

套件鏡像

鏡像源決定你從哪裡下載套件，挑地理上接近的那個。基礎系統加上一套桌面動輒上 GB，選對岸的鏡像跟選同城的鏡像，下載時間差好幾倍。安裝程式給的鏡像清單通常按國家排，往下捲找你所在地區的；找不到完全同國的，就退而求其次選同區域、且穩定的大型鏡像。

這個選擇的另一個作用是順帶確認你裝的是哪個發行版分支。前述例子的鏡像清單全是 archlinuxarm.org，這證實了 archboot 的 aarch64 ISO 裝出來的是 Arch Linux ARM（ARM 移植版），而不是 x86 的 Arch——同一條安裝路徑產出的是哪個分支，鏡像來源會洩漏給你看。

磁碟分割

磁碟分割是整個安裝裡選項最多、也最不可逆的一段，但判斷軸只有一條：這台機器需不需要在分區層面做隔離。需要隔離的情境——多系統共存、加密、資料與系統分離以便重灌不丟資料——每多一個，分割就多一層結構。不需要的情境，多切一刀都只是增加「一邊爆一邊空」的風險。下面逐項拆解，但它們服務的是同一個判斷。

自動分割 vs 手動分割

自動分割（清空整碟、安裝程式幫你建標準佈局）適用於整碟專屬、沒有要保留任何既有資料的機器。測試 VM 的磁碟是全新的、整碟給這個系統用，自動分割沒有任何代價，還省去手動算 EFI 大小、root 大小、對齊、格式化、掛載這一連串容易錯的步驟。

手動分割的價值在你需要非標準佈局時才浮現：多系統共用某個分區、要留一塊不格式化的資料區、要套 LVM 或 LUKS。這些是真實主力機與伺服器會遇到的需求，但對一台「目標是驗證 dotfile 部署」的 VM 是純雜訊——它們屬於另一個主題，不該混進這次的安裝。判讀訊號很簡單：你說得出一個具體的隔離需求，才手動分割；說不出來，自動分割就是對的。

分區識別方式（PARTUUID）

分區識別方式決定 fstab（開機時決定哪個分區掛到哪的設定檔）跟 bootloader 怎麼指涉每個分區，在 GPT（現代 UEFI 機器的分區表格式）磁碟上選 PARTUUID。這個選擇的後果是「重開機後系統找不找得到自己的分區」。PARTUUID 綁在分區本身、跨重開機穩定，而且重新格式化檔案系統也不會變；相對地，檔案系統層級的 UUID 一重格就變，會讓 fstab 失效，而 /dev/vda1 那種 kernel 名稱會隨偵測順序浮動，最不穩。穩定性的排序是 PARTUUID 優於 FSUUID 優於 kernel 名稱，GPT 磁碟用最穩的那個（這三種識別方式的細節見 分區識別卡）。

EFI 分區的掛載點與大小

EFI 系統分區（ESP）放開機載入器與 kernel，掛載點的選擇取決於這台機器是不是單一作業系統。把 ESP 掛在 /boot（單系統佈局）讓 kernel 跟開機檔住在同一個分區、維護最單純；把 ESP 掛在 /efi、kernel 另放（多系統佈局）是為了多個 OS 共用同一個 ESP 才需要的結構。單系統的機器選多系統佈局，只是憑空多一層目錄。

ESP 大小在單系統佈局下要算進 kernel 與 initramfs（開機初期把真正的 root 掛起來之前、用來載入驅動的小型臨時根檔系統）。一個 kernel 加上它的 initramfs（含 fallback）大約一兩百 MB，再加上 FAT32 ESP 約 260 MiB 的實務下限，512 MiB 是在下限之上留餘裕。會需要更大的情境是你要同時保留多個 kernel 版本——但單 kernel 的 VM 用不到，給太大只是浪費。

Swap

Swap 是記憶體不足時的安全墊，大小取決於這台機器的記憶體壓力型態，不是一個固定公式。對一台只有 4 GB RAM、且要在上面從原始碼編譯套件的 VM，編譯瞬間的記憶體尖峰很容易把實體記憶體吃爆、觸發 OOM 把進程殺掉。給 2 GB swap 當緩衝，擋住這種尖峰、避免安裝跑到一半被中斷。

swap 分區的磁碟成本不是一次付清的。mkswap 只寫一個 header，實際沒被換出的頁不會佔用宿主磁碟空間（在稀疏配置的虛擬磁碟上尤其明顯），用到才寫。所以「為了保險多給一點 swap」的代價，比直覺以為的小。判讀軸是看工作負載：會編譯、會跑吃記憶體的服務、RAM 又緊，就給足 swap；純文書、RAM 寬裕，小一點或不給都行。

swap 還有形態的選擇，這裡用分區 swap 是因為在安裝程式階段一併切好最省事，不代表它比另兩種好。swapfile（一個檔案，事後可隨時調大小或移除）避開了「分割最不可逆」的痛點；zram（壓縮記憶體 swap，不碰磁碟）對低 RAM 加編譯尖峰正是設計情境，現代發行版很多預設用它。換句話說，2 GB 這個量是看編譯尖峰定的，而「切成分區」只是配合安裝當下一次到位——若你跳過安裝期的 swap、事後用 swapfile 或 zram 補，是等價的可逆路徑。

檔案系統

檔案系統的選擇是在「簡單可靠」與「進階功能」之間取捨，預設往簡單那邊靠。ext4 簡單、穩、在各平台行為一致、修復工具成熟，對一台只要求「可靠地存取檔案」的機器是零驚喜的選擇。btrfs 提供快照、subvolume、透明壓縮，但代價是要規劃 subvolume 佈局、還要理解它寫時複製（CoW）的一些行為差異；這些功能在你會用快照回滾的主力機上很有價值，在演練 VM 上是雜訊。xfs 同樣穩定，但對這類用途相對 ext4 沒有決定性優勢。更特定的 zfs、f2fs 不在一般 VM 的考慮範圍——zfs 在 Arch / ARM 上是非主線 kernel 的 out-of-tree 模組、授權與維護成本高，f2fs 是為快閃裝置設計、VM 用不到。

判讀軸是你會不會用到進階功能。會固定用快照回滾系統狀態——選 btrfs 並接受它的佈局複雜度；只是要一個可靠的檔案系統——ext4。快照這類能力跟下面的獨立 /home 一樣，是真實機器的儲存規劃主題，值得另外深入，但別為了「聽起來比較強」就把它的複雜度帶進一台用完即丟的機器。

獨立 /home vs 單一 root

獨立 /home 分區的價值是「重灌系統不丟個人資料」，這是主力機的需求，不是每台機器都需要。把 /home 切成獨立分區，重裝系統時可以只格式化 root、保留 /home 裡的設定與檔案。一台用完即丟的演練 VM 沒有這個需求——它的整個生命週期就是裝起來、驗證、丟掉。如果你想跨多次實驗保留狀態，VM 情境更貼切的手段是宿主層的快照或共享資料夾，而不是在 guest 裡切獨立 /home——後者解決的是「重灌 OS 保資料」，不是「保留實驗狀態」。

把空間切兩半的隱性代價是失衡風險。假設總共十幾 GB，照預設切一塊給 /、剩下給 /home，所有系統套件（桌面全套依賴都裝在 /usr、算 /）擠在前者、容易先滿，而 /home 那邊空著——典型的一邊爆一邊空。把全部空間當一個池子用的單一 root 佈局，不會人為卡死任一邊，對不需要「重灌保資料」的機器最不容易出事。

Bootloader

開機載入器決定韌體怎麼找到並載入 kernel，在虛擬機上選 GRUB 而非直接用 EFISTUB，理由是可靠性（韌體到 kernel 的整條交棒過程見 UEFI 開機鏈卡）。EFISTUB 讓 UEFI 韌體直接載入 kernel、不經過獨立的 bootloader，最精簡，但它完全依賴寫進 UEFI NVRAM（韌體用來存開機項的非揮發記憶體）的開機項。問題在於 QEMU 系的虛擬機（UTM 底層即是）對 EFI 變數的儲存有時不穩，一旦 NVRAM 裡的開機項掉了，韌體就找不到 kernel、機器開不了——這在 VM 環境是會實際踩到的坑。

GRUB 的容錯來自它（以 removable 模式安裝時）多寫了一份。除了 NVRAM 開機項，grub-install --removable 會在 ESP 的標準 fallback 路徑（aarch64 是 \EFI\BOOT\BOOTAA64.EFI）也放一份，就算 NVRAM 開機項丟了，韌體仍會從 fallback 路徑找到 GRUB；VM 環境的安裝程式通常以這個模式裝 GRUB，正是看上這層保險。它還附帶一個開機選單，當 kernel 或 initramfs 出問題時，可以進選單救援、加開機參數除錯——演練時的容錯空間大很多。

判讀軸是環境的 NVRAM 可靠度。在 NVRAM 穩定的實體機上，EFISTUB 的極簡是漂亮的選擇；在 NVRAM 可能不穩的 VM 上，可靠性優先，GRUB 的「多寫一份 fallback + 救援選單」更穩妥。GRUB 不是唯一的可靠選擇——systemd-boot 同樣是有開機選單、能裝到 fallback 路徑的獨立 bootloader，又比 GRUB 輕，在 VM / 單系統同樣站得住；這裡落在 GRUB 是因為 archboot 安裝程式預設以 removable 模式裝它，不是 GRUB 獨佔可靠性。GRUB 自己的設定檔在 VM 上用預設值即可，不需要額外的 kernel 參數。

下一步

選項選完、系統裝好、重開機進得去之後，先別急著開始用——「裝好了」跟「能用了」之間往往還缺一截：這台最小系統不一定有你需要的基本工具。最小安裝後的工具驗證與補足 就是在補那一截。

從安裝到桌面就緒的完整依賴順序，見 模組零的操作順序指引；本篇是它「安裝作業系統」那一步的展開。

這層落差最常在你跑自動化腳本時引爆。一支 bootstrap script 的第一行可能就是 sudo pacman -S ...，在一台連 sudo 都沒有的機器上，它連第一步都跨不過去。所以裝好系統後、跑任何自動化之前，先過一輪工具驗證，把缺的補上。

sudo：先有雞還是先有蛋

sudo 是最容易被假設存在、卻最常缺席的工具，而且它的缺席有一個結構性的麻煩：補它的動作本身需要 root 權限。最小安裝通常不含 sudo。某些安裝程式（如本例的 archboot）即使你勾了「把這個使用者設為管理員」，那個動作也往往只是把使用者加進 wheel 群組，並沒有真的裝上 sudo、也沒有啟用 sudoers 裡 wheel 群組的授權行。結果就是使用者「名義上是管理員」，但系統裡並沒有 sudo 這支指令。

這形成一個先有雞還是先有蛋的關卡：bootstrap script 要靠 sudo 來裝套件，但 sudo 自己得先存在。它的解法不能是「把 sudo 寫進套件清單」——那份清單正是靠 sudo 來安裝的。sudo 只能是「跑 bootstrap 之前的前置」，用 root 身分手動補上（su - 成為 root、echo > 檔案 重導向、chmod 設權限這些基礎操作不熟的話，見 安裝過程用到的基礎操作）：

1su -                                          # 切到 root（輸入 root 密碼）
2pacman -S --needed sudo                        # root 身分裝 sudo，不需要 sudo
3echo '%wheel ALL=(ALL:ALL) ALL' > /etc/sudoers.d/10-wheel   # 啟用 wheel 群組授權
4chmod 440 /etc/sudoers.d/10-wheel
5visudo -c                                      # 驗證 sudoers 語法，印 parsed OK 才安全
6exit

切回一般使用者後用 sudo -v 確認——能輸入密碼、沒報「不在 sudoers 檔」就成。這一步揭示一條通則：凡是 bootstrap 自身要依賴的工具，都不能由 bootstrap 來裝，必須當成前置先備好。sudo 是這類前置最典型的一個。

上面的指令以 Arch 的 pacman 為例。Fedora 用 dnf、Debian/Ubuntu 用 apt；而 Debian 系的桌面與伺服器映像多半預設就裝了 sudo、也設好了授權，這個缺口主要出現在刻意精簡的 minimal 安裝。換句話說「sudo 是前置」這條判讀軸跨發行版成立，但「你這台到底缺不缺」要靠驗證、不是假設。

which：腳本裡的隱形地雷

which 是另一個最小系統常缺、卻被腳本大量引用的指令，它的缺席會以一種隱晦的方式讓腳本出錯。很多腳本用 $(which zsh) 之類的寫法取一支程式的完整路徑；在沒有 which 的系統上，這個命令替換會吐出空字串，而下游拿到空字串的指令可能不會立刻報「找不到 which」，而是報一個看似無關的錯。實測中就遇過 chsh -s "$(which zsh)" 因為 which 不存在而變成 chsh -s ""，最後報的是 chsh: shell must be a full path name——錯誤訊息完全沒提到真正的元兇。

正確的做法是用 command -v 取代 which。command -v 是 POSIX 規範的 shell 內建，不依賴任何外部套件，在最小系統上一定存在。

1command -v zsh        # 印出 /usr/bin/zsh；找不到則回傳非零、不印東西

這條判讀對你自己寫的腳本是「把 which 全換成 command -v」，對別人的腳本是「在缺 which 的系統上，先補 which 套件或改腳本」。它跟 sudo 的差別在於：which 的缺席會悄悄製造一個誤導性的下游錯誤，而不是當場大聲報錯，所以更值得在驗證階段主動排掉。

其他常缺的工具

除了 sudo 與 which，最小系統還常缺幾類在自動化裡會用到的工具，各有各的補法。它們不像 sudo 是硬前置，但缺了會在特定步驟卡住。

rsync 的缺席要特別點出，因為它常被當成理所當然的傳輸工具。最小系統沒有它時，第一次把檔案弄進機器可以用兩邊都有的 tar 搭配 SSH 過渡：

1tar czf - --exclude '.git' . | ssh user@host 'mkdir -p ~/dest && tar xzf - -C ~/dest'

這條的好處是不依賴目標機有 rsync；缺點是它每次都傳全部、沒有 rsync 的增量。在反覆同步的工作流裡，值得早點把 rsync 補進套件清單換取增量傳輸。

ca-certificates 最容易在下一步咬人。最小系統可能沒有 CA 信任根，這時任何 HTTPS 連線——包括下一篇主推的「公開 repo 用 HTTPS clone」——會在 TLS 憑證驗證直接失敗，而錯誤訊息常指向 SSL handshake 而非「缺信任根」，容易誤判成網路問題。打算走 HTTPS 取得 dotfile 的機器，先確認 ca-certificates 在。git 與 curl 同理：它們是 bootstrap 取得程式碼的基本工具，下面的驗證迴圈也會檢查，最小系統若沒有要一併補。

剩下兩項的缺席各有觸發時機。hostname 只在腳本明確呼叫它取主機名時才會浮現缺失，而用 hostnamectl 或直接讀 /etc/hostname 可以繞過，所以它常被當成「補了省事、不補也有替代」的軟缺口。編譯工具鏈則是在你要從原始碼或社群套件庫編譯時才需要——純跑預編譯套件的機器可以不裝，但只要你的 dotfile 流程會編譯任何東西（例如從社群套件庫裝桌面元件），它就得進清單。

系統性的驗證

裝好系統後先跑一輪集中驗證、把缺口一次盤出來，比等腳本跑到一半才逐一踩雷省事。驗證的對象是「你接下來的流程會用到、但最小系統可能沒有」的工具。

1for cmd in sudo git curl rsync tar zsh; do
2  if command -v "$cmd" >/dev/null 2>&1; then
3    echo "OK   $cmd"
4  else
5    echo "缺   $cmd"
6  fi
7done

這段刻意用 command -v 來檢查（而不是 which），因為要檢查的對象之一正是「外部工具在不在」，用一個一定存在的內建來檢查才不會自己先掛掉。盤出來的缺口分兩類處理：bootstrap 自身依賴的（如 sudo）當前置手動補；其餘的（如 rsync、編譯工具）進套件清單，交給 bootstrap 一起裝。

跟 Bootstrap 套件清單的界線

這篇的驗證跟 模組八的 bootstrap script 設計 是兩件互補的事，界線在「假設」上。bootstrap script 的套件清單假設一個前提：機器已經有能力執行安裝（有 sudo、有 package manager、清單裡的東西都能被裝上）。這篇處理的正是那個前提成立之前的階段——最小系統到底有沒有滿足那些假設，缺的補上，讓 bootstrap 的假設變成事實。

換句話說，套件清單回答「這台機器最終要有哪些套件」，工具驗證回答「這台機器現在夠不夠資格開始跑那份清單」。把兩者分清楚，才不會把 sudo 這種前置誤塞進靠 sudo 安裝的清單裡。

下一步

工具補齊、機器有能力執行安裝之後，你還困在一個地方：擠在機器的主控台手打。怎麼從舒適的本機終端機操作它，以及還沒有 SSH key 時怎麼把 dotfile 弄進去，外部連入、SSH key 與無 key 的 bootstrap 路徑 處理這兩件事。

第一步：分「連不到」還是「連得到但被拒」

錯誤訊息本身就能分層，不用猜：

• 訊息提到主機名解不出、連線逾時、retrieving file 失敗 → 連不到，往網路 / DNS / mirror 查。
• 訊息提到 database lock、signature、trust、conflicting、partial → 連得到、封包也拿到了，是套件管理器的狀態問題。

判準是問一句：「它到底有沒有成功連上 mirror？」有連上才談得到簽章、相依、db 狀態；連都沒連上，那些都還輪不到。剛裝好的最小系統最常見的是前者——網路設定還沒到位。

連不到那層：從實體介面往上查到域名

網路不通有好幾層，從最底層往上逐層確認，哪一層斷了一目了然。這條鏈跟最小安裝後的驗證裡的網路檢查同源，這裡聚焦在「抓套件失敗」這個症狀上：

1ip -brief a              # 1. 有沒有拿到 IP？介面 UP 且有位址
2ping -c1 8.8.8.8         # 2. IP 層對外通不通？（直接打 IP、跳過 DNS）
3getent hosts archlinux.org   # 3. 域名解得出來嗎？
4timedatectl              # 4. 時間對嗎？（影響下一層的簽章驗證）

第 2 步通、第 3 步不通 = DNS 問題，這是最小安裝最典型的落點：IP 層明明通（ping 8.8.8.8 有回應），但域名解不出來，因為 /etc/resolv.conf 還沒設 nameserver。這時 pacman 會卡在解析 mirror 主機名。修法是給系統一個 resolver——臨時可直接寫 /etc/resolv.conf（nameserver 1.1.1.1）。先看它是什麼（ls -l /etc/resolv.conf）：啟用了 systemd-resolved 或 NetworkManager 的系統上它是那些服務管理的 symlink，手寫會被覆蓋，治本要透過該網路管理服務設定 DNS；裸 Arch 最小安裝若沒啟用這些服務，它通常就是一個普通檔案，手寫即持久生效。

mirror 逾時 / 抓不到：DNS 通了、但某個 mirror 慢或掛了。換 /etc/pacman.d/mirrorlist 到地理近且快的鏡像（實測不同 mirror 速度可差數倍）。這也接回安裝選項判讀裡選 mirror 的決策——裝機當下選錯 mirror，這裡就會慢。

連得到但被拒那層：pacman 自己的狀態

連上 mirror、封包也拿到了卻失敗，問題在 pacman 的本地狀態或簽章驗證。這幾種各有明確徵兆與修法：

database lock：上次沒清乾淨的殘留

error: failed to init transaction (unable to lock database)。pacman 用 /var/lib/pacman/db.lck 這個鎖檔保證同時只有一個 pacman 在動資料庫；上次 pacman 被中斷（斷電、Ctrl+C、當掉）沒清掉鎖檔就會殘留。先確認真的沒有 pacman 在跑（pgrep -x pacman），確認沒有再刪鎖檔：

1pgrep -x pacman && echo "有 pacman 在跑、別刪" || sudo rm /var/lib/pacman/db.lck

先查再刪這個順序重要——盲刪鎖檔時如果真的有另一個 pacman 在跑，兩個同時寫資料庫會弄壞它。

簽章 / keyring 過期：十之八九是時間不對

invalid or corrupted package (PGP signature) 或 signature is unknown trust。pacman 驗證每個套件的 GPG 簽章，驗證失敗最常見的根因是系統時間不對——這正是第一步要 timedatectl 的原因。時間差太多（新裝的 VM、主機板電池沒電的老機器）會讓「簽章的有效期」判斷錯誤，明明有效的簽章被判過期。先校時：

1sudo timedatectl set-ntp true     # 開 NTP 自動校時（SSH 進最小系統無 polkit 互動代理、裸跑會被拒，要 sudo）

時間對了還失敗，才是 keyring 本身的問題（archlinux-keyring 太舊）：sudo pacman -Sy archlinux-keyring 更新 keyring，必要時 sudo pacman-key --refresh-keys。順序是先校時再動 keyring，因為時間不對時連 keyring 都更新不了。

partial upgrade：只同步不升級造成的相依斷裂

conflicting dependencies 或裝完某個套件後系統行為異常。根因是在 rolling 發行版上只做了 pacman -Sy（同步資料庫）就裝新套件，卻沒 -u（升級既有套件）——新套件依賴新版函式庫，但系統還是舊的，相依對不上。Arch 只支援 full upgrade：一律 pacman -Syu，永遠不要單獨 -Sy 之後裝東西。這條規則救掉這一整類故障。

stale db 404：裝機當下的資料庫已經過期

error: failed retrieving file '...' 404，而且換好幾個 mirror 都一樣。這是 rolling 發行版特有的時序陷阱：Arch 的 mirror 不保留舊版檔案，你裝機時 ISO 內建的套件資料庫指向的檔名，可能幾天內就被輪替掉了——資料庫說有這個檔、mirror 上已經沒有。修法跟上一條同源：pacman -Syu 先把資料庫同步到最新，檔名對上了就抓得到。這也是為什麼「一律 -Syu」是 Arch 的鐵律，而不只是建議。

判讀總表

下一步

• 這幾步用到的網路驗證，完整版在最小安裝後的工具驗證與補足。
• 裝機時選 mirror / locale / 時區的決策，見Linux 安裝選項判讀。
• 跨發行版時「這個套件名 / 這個旗標在別的發行版叫什麼」的差異判讀，見平台與發行版差異的判讀地圖。
• 套件抓下來了、但 bootstrap 腳本本身失敗要 debug，見可除錯的 bootstrap。
• 系統跑起來後才出的套件問題（AUR 建置失敗、-bin 包 soname 斷裂等），屬除錯範疇，見Linux 除錯與診斷。

拆包生態：裝了本體不等於裝了功能

發行版為了控制依賴體積，會把一個應用的核心跟功能模組拆成多個套件，預設只裝核心。這個設計讓「安裝成功」跟「功能可用」變成兩件事，而缺件的症狀往往是靜默的：

• VLC 的解碼器是獨立 plugin：Arch 的 vlc 本體開得起來、UI 完整，播 H.264 影片卻回報 Codec 'h264' is not supported——解碼能力在 vlc-plugin-ffmpeg（或整組 vlc-plugins-all）。judgment 訊號是「應用正常啟動、特定格式失敗」，權威來源是應用自己的 log（vlc --verbose=2）。
• pipewire 的 session manager 是獨立套件：pipewire 常被依賴鏈拉進來，但沒有 wireplumber 就沒有人建立音訊 graph——daemon 在跑、wpctl status 的 Sinks 段是空的、所有應用無聲且不報錯。補 wireplumber + pipewire-pulse（多數 GUI 應用走 PulseAudio API）後輸出裝置立即出現。
• optional dependency 不會自動安裝：套件宣告的 optdepends 是「裝了會多什麼功能」的提示、不是安裝動作。影片縮圖、壓縮格式支援、硬體加速常落在這層，pacman -Qi <pkg> 的 Optional Deps 段列出哪些沒裝。

判讀原則：GUI 應用「開得起來但某個功能不動」時，先查發行版有沒有把那個功能拆成獨立套件，再懷疑設定或相容性。

首跑同意對話框：程式在等使用者決策

不少 GUI 應用第一次啟動會彈出需要使用者決策的對話框，最典型的是 VLC 的「Privacy and Network Access Policy」：

VLC 聲明自己不蒐集、不傳輸任何個人資料，但它能自動向第三方網路服務抓取播放清單裡媒體的中繼資料（封面圖、曲名、演出者）——這個行為等於把「你在播哪些檔案」暴露給第三方服務，所以 VLC 開發者要求使用者明示同意（Allow metadata network access 勾選框、預設勾選）後才允許自動連網。

這個對話框的判讀是用途導向：拿 VLC 播本機影片、看下載的影片檔，中繼資料抓取沒有用處、取消勾選讓播放器完全離線工作；拿它管理音樂庫、想要自動補封面跟曲目資訊，才需要同意。同意與否都能在偏好設定（Privacy / Network Interaction）事後改。

首跑對話框對自動化流程有一層額外影響：無人值守安裝驗證時，應用會停在對話框等輸入、腳本側只看到「程式起了但沒繼續」。VLC 把這兩個決策記在 ~/.config/vlc/vlcrc 的 qt-privacy-ask 與 metadata-network-access 兩個鍵——首跑後檔案才生成，而且 VLC 退出時會整檔重寫（幾千行的完整設定 dump），把它納入 dotfile 版控會持續產生無意義的 diff，比較合理的處理是讓首跑對話框留給人、或在自動化腳本裡預先寫入只含這兩鍵的最小 vlcrc。

同型的首跑決策也出現在瀏覽器（預設瀏覽器詢問、錯誤回報同意）跟大型 GUI 應用（遙測同意）。它們的共通判讀：對話框問的是「要不要讓程式自動連外 / 回傳資料」，答案取決於這台機器的用途與隱私要求，安裝驗證流程要把「首跑會有互動」納入預期、不是當成故障。

播放驗證鏈：三個權威位置

「有沒有真的在播」的驗證不靠肉眼跟喇叭，三個權威位置各管一段：

把「管線通不通」跟「應用會不會播」拆開驗證能大幅縮短歸因：先用本機音檔 pw-play <file> 打通音訊路徑（stream 出現 [active] 代表 guest 側無誤），再測應用層；應用層失敗就跟管線無關，往解碼器、DRM、應用 log 查。串流再多拆一層：先用無 DRM 的串流（一般影音網站）確立網路串流基線，DRM 內容（Spotify、Netflix 類）的失敗才能歸因到 DRM 層——DRM 在非 x86_64 架構的可用性判讀見 平台與發行版差異的判讀地圖 的套件存在性段。

VM 特有：硬體解碼回退

在 VM 裡播放影片，第一次開檔常會閃一個錯誤對話框（failed to create video output）然後正常播放——這是硬體解碼回退的痕跡：播放器預設先嘗試硬體加速解碼（VDPAU / VAAPI），虛擬 GPU（如 virtio-gpu）沒有視訊解碼能力，嘗試失敗後回退軟體解碼重建輸出。log 上的特徵是一次性的 decoder error 加上之後穩定的 avcodec decoder 軟體解碼行；實體機器有 GPU 解碼時不會出現。VM 裡想要乾淨啟動，在播放器偏好設定停用 hardware-accelerated decoding 即可——這是機器特性設定，適合留在該機器本機、不進共用 dotfile。

下一步路由

• 套件在這個平台 / 架構存不存在、名字叫什麼：平台與發行版差異的判讀地圖
• 音訊、行程、服務狀態的權威判讀：Linux 除錯與診斷
• GUI 應用清單怎麼進 bootstrap：模組八：Bootstrap script 設計