成為 root：su -

su - 讓你從一般使用者切換成 root（系統管理員），整個 session 都以 root 身分操作。這個系列用到它，是因為在還沒有 sudo 的最小系統上，要裝 sudo、改系統設定，得先成為 root——而成為 root 的方式就是 su -，輸入 root 密碼後進入 root 的 shell。

那個 - 決定你載入哪一套環境。su - 啟動一個 login shell（模擬從頭登入、會跑完整的登入環境初始化），載入 root 自己的完整環境——把 PATH（shell 搜尋指令的目錄清單）換成 root 的（會包含 /usr/sbin 這類放管理工具的目錄）、工作目錄切到 root 的家。su（不加 -）則不啟動 login shell，環境多半沿用你呼叫時的、可能少掉那些管理工具目錄，於是有些管理指令會因為不在 PATH 裡而「找不到」，明明你已經是 root。所以要做系統管理，習慣用 su -。

su - 跟 sudo 解決的是不同情境。sudo 是「以 root 身分跑單一一條指令」，跑完就回到你自己；su - 是「整段都當 root」。這個系列先用 su - 是因為 sudo 還沒裝——一旦 sudo 裝好、wheel 群組（慣例上被授權可用 sudo 的群組）的授權設好，後面就改用 sudo <指令>，不再整段切 root。做完 root 的事，打 exit 回到原本的使用者。

用 nano 改設定檔

nano 是一個對照 vi 更直覺的文字編輯器，安裝過程改 locale.gen、hostname、sudoers 這些設定檔時會用到它。它的好處是所有快捷鍵都列在畫面最下面兩行，不必背。

那兩行裡的 ^ 符號代表 Ctrl 鍵。^O 就是 Ctrl+O、^X 就是 Ctrl+X。這個系列用到的幾個：

把這幾個串起來就是一次典型的設定檔編輯。以這個系列裡「解開 locale.gen 某一行的註解」為例：按 Ctrl+W 搜 en_US.UTF-8 UTF-8 跳到那行、用 Backspace 刪掉行首的 #、按 Ctrl+O 再 Enter 存檔、按 Ctrl+X 離開。改 hostname 則是 Ctrl+K 剪掉預設那行、打上新主機名、Ctrl+O、Ctrl+X。Ctrl+K 加 Ctrl+U 合起來就是「剪下再貼上」，是搬移整行的常見組合。

檔名與指令的大小寫

Linux 把大小寫當成不同的字元，這對檔名跟指令都成立。Setup 跟 setup 是兩個不同的東西、Documents 跟 documents 是兩個不同的資料夾、打 Sudo 不會執行到 sudo。這條規則貫穿整個系列：執行 archboot 的安裝程式是 setup（全小寫），啟動 Hyprland 桌面的指令是 Hyprland（首字母大寫），兩者差一個字母的大小寫就是不同的目標。

這對從 macOS 或 Windows 過來的人尤其常見，因為那兩個系統的預設檔案系統不分大小寫——在 Mac 上 File.txt 跟 file.txt 指向同一個檔，到了 Linux 就是兩個檔。同一個專案在 Mac 上跑得好好的，搬到 Linux 卻出現「檔案找不到」，常常就是某處大小寫對不上、而 Mac 的不分大小寫把問題藏了起來。

判讀方式很簡單：在 Linux 上，指令、檔名、路徑一律照原樣的大小寫打。錯誤訊息 command not found 或 No such file or directory 在你確定東西明明就在時，先懷疑大小寫。

shell 的幾個符號

這個系列的指令裡出現了幾個 shell 符號，它們是 shell 本身的語法、不是某個程式的參數，認得它們才讀得懂那些指令在做什麼。

> 跟 >> 是重導向，把本來會印到畫面的輸出改寫進檔案。> 覆蓋、>> 追加。系列裡 echo '%wheel ALL=(ALL:ALL) ALL' > /etc/sudoers.d/10-wheel 就是把那行文字寫進一個新檔，而設 authorized_keys 時用 >> 是為了追加、不洗掉既有的 key。

|（管線）把左邊指令的輸出，直接餵給右邊指令當輸入。傳 dotfile 進 VM 的 tar czf - . | ssh host 'tar xzf -' 就是把 tar 打包的資料流，不落地直接透過 ssh 送到對面解開。

&& 串接兩條指令，而且只有左邊成功才跑右邊。cd ~/dotfiles && ./scripts/install.sh 的意思是「先切到目錄，切成功了才跑腳本」——如果目錄不存在、cd 失敗，後面的腳本就不會在錯的目錄下執行。

$(...) 是命令替換，把括號裡指令的輸出，當成值填進當下這條指令。chsh -s "$(command -v zsh)" 會先跑 command -v zsh 得到 /usr/bin/zsh，再把這個路徑填給 chsh。理解這個語法，也才看得懂 工具驗證篇 講的 which 地雷：當 which 不存在、$(which zsh) 算出空字串，整條指令就拿到一個空值。

跟重導向相關的還有一個經典陷阱：sudo echo '內容' > /etc/某個-root-檔 會失敗。原因是重導向 > 由你的 shell 以你的身分執行，不是被 sudo 提權的那條指令——被提權的只有 echo，真正寫檔的還是你，而你沒權限寫那個 root 檔。解法是 echo '內容' | sudo tee /etc/某個-root-檔：tee 把流進它的 stdin 寫進檔案，而 tee 才是被 sudo 提權的那支，所以寫得進去。這個系列補 sudoers 檔時用的就是這個寫法。

權限對某些檔是硬要求，所以系列裡出現了 chmod。chmod 改檔案權限，那串數字是八進位的權限碼，三位分別代表擁有者/群組/其他人；每一位是讀（4）+ 寫（2）+ 執行（1）的和，所以 7 是全權、6 是可讀寫、4 是只讀、0 是無權。系列裡的 chmod 440（擁有者與群組可讀、其他人無權，給 sudoers 檔）、chmod 600（只有擁有者可讀寫，給私鑰）、chmod 700（只有擁有者全權，給 .ssh 目錄）就是這樣算出來的。這些檔對權限有要求——sudoers 必須是 440、私鑰必須只有自己讀得到，否則對應的工具會拒絕使用它們，所以那幾個 chmod 不是裝飾、是讓 sudo 跟 ssh 願意接受那些檔的條件。

下一步

認得這些基礎操作之後，就可以從 安裝選項判讀 開始走完整的安裝流程，過程中再遇到這幾個操作就不會卡。

這篇給每個關鍵選項一條判斷軸，而不是一份「照著點」的步驟。底下用一次具體的安裝當作貫穿例子：在 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 除錯與診斷。

這篇處理三件事：把 sshd 跑起來並從本機連入、設 SSH key 達到免密碼、以及一個容易被卡住的情境——你還沒有 SSH key 時，怎麼把 dotfile 弄進機器、跑完基礎安裝。

啟用 sshd 並從本機連入

讓機器能被 SSH 連入只需要兩步：裝 SSH 伺服器、啟動它的服務。

1pacman -S openssh             # 剛裝好的系統套件資料庫是新的，-S 不必先 -Sy
2systemctl enable --now sshd   # enable 開機自啟、--now 立刻啟動

指令以 Arch 為例。換發行版時套件管理器不同（Fedora dnf、Debian/Ubuntu apt），服務名也可能不同——Debian 系的 OpenSSH 服務叫 ssh 不是 sshd，那邊要 systemctl enable --now ssh。

從本機連的時候用一般使用者、不要用 root：

1ssh user@<機器 IP>            # IP 來自機器上的 ip -brief a

用一般使用者是因為多數發行版的 sshd 預設擋 root 密碼登入（PermitRootLogin prohibit-password）——root 只能用 key、不能用密碼。這個預設是好的安全姿態，順著它走、用你裝系統時建的一般使用者連即可。連進去之後，後續所有需要長指令、需要貼上的操作都在這個 session 裡做，不再回主控台手打。

這裡啟用 sshd 是為了 bootstrap 期間從本機連入操作，跟 操作順序指引 後段把 sshd 當「桌面就緒後的常駐遠端救援通道」是兩個不同的時間點與目的——同一個 systemctl enable sshd 動作，這裡是為了「現在好操作」，那裡是為了「之後好救援」。

SSH key 免密碼

每次連線都打密碼很快會變成阻力，尤其當你要反覆同步檔案或跑自動化時。SSH key 讓本機免密碼連入，做法是生一把金鑰、把公鑰放進機器、本機用私鑰認證。

生 key 時建議生一把專用的、不要佔用本機的預設金鑰槽，並在 SSH 設定裡給它一個好記的別名：

1ssh-keygen -t ed25519 -f ~/.ssh/vm_arch -N "" -C "vm_arch host->target"
2# 在 ~/.ssh/config 加一段別名：
3#   Host vm
4#       HostName <機器 IP>
5#       User <你的使用者>
6#       IdentityFile ~/.ssh/vm_arch
7#       IdentitiesOnly yes

專用 key 的好處是它的權限範圍清楚——這把只給這台機器用，跟你其他身分的金鑰互不牽連。設好別名後，ssh vm 就免密碼連入，後面的 rsync、scp 也跟著免密碼。

把公鑰放進機器有兩條路。標準工具是 ssh-copy-id，它會在本機跑、要你輸入一次目標機的密碼。另一條省一次切換的路是：當你已經用密碼連進機器、且這個 session 在真終端機裡（貼上可用），直接把公鑰內容貼進機器的 authorized_keys：

1mkdir -p ~/.ssh && chmod 700 ~/.ssh
2echo "ssh-ed25519 AAAA... 你的公鑰內容" >> ~/.ssh/authorized_keys
3chmod 600 ~/.ssh/authorized_keys

兩條路等價，選哪條看你當下在哪——還沒連上就用 ssh-copy-id，已經連上就直接貼，少一次切換。

還沒有 SSH key 時，怎麼把 dotfile 弄進去

設 SSH key 是讓「之後」連線變方便，但 bootstrap 的第一步——把 dotfile repo 弄進機器——並不一定需要 key。常見的卡點是把「clone repo」跟「有 SSH key」綁在一起，但 clone 有不需要 key 的路徑。怎麼把 dotfile 弄進去，取決於這份 dotfile 放在哪。

repo 是公開的（在 GitHub 之類）：用 HTTPS clone，公開 repo 的唯讀 clone 不需要任何認證。

1git clone https://github.com/<帳號>/dotfiles ~/dotfiles
2cd ~/dotfiles && ./scripts/install.sh

這是最直接的路——機器只要能上網就能拉到 dotfile，完全繞過 key 的問題。clone URL 裡的帳號要對；用錯帳號（例如把 email handle 當成 GitHub 帳號）會 clone 失敗或抓到別的 repo，這類筆誤在只看 README 範例時很容易漏掉。SSH key 在這個情境只有「之後要從機器 push 回去」才需要，純粹跑部署用不到。

repo 是私有的、但機器能上網：機器可以直接 clone，用 GitHub Personal Access Token（PAT）走 HTTPS——這是私有 repo 免 SSH key 的標準解。clone 時把 PAT 當密碼填進認證，機器就拉得到，一樣不必在它上面設 SSH key。

repo 還沒推到任何遠端、或機器離線：從本機把檔案傳進去。如果本機到機器的 SSH 已經能用（即使只是密碼登入），用 tar over SSH 一次傳進去（跟 scp -r 等價，差別只在 tar 能一次打包、又好控制要不要帶 .git）：

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

這條只需要兩邊都有的 ssh 跟 tar，不依賴目標機有 rsync。從 macOS 傳的時候要關掉 AppleDouble 中繼檔，否則會夾帶一堆 ._ 開頭的中繼檔到 Linux 上：在指令前加 COPYFILE_DISABLE=1。完全離線、連 SSH 都還沒通時，最後手段是把 repo 放進 USB、掛載到機器上複製出來。

把 dotfile 弄進去之後，跑它的 install.sh 完成基礎安裝。如果安裝腳本一開始就要用 sudo，記得 sudo 必須在工具驗證階段就備好——它是 最小安裝後的工具驗證與補足 的前置，bootstrap 自身補不了。

換一台新機器（或重裝）時，SSH 為什麼突然連不上

SSH 的別名、金鑰、known_hosts 都是綁在「某一台特定機器」上的，所以當你重裝、或換一台新 VM，先前設好的 ssh <別名> 往往會以看似無關的錯誤失敗——那套設定是為舊機器建的，而重裝後是另一台機器：不同的 IP、不同的 SSH host key、還沒裝 sshd、authorized_keys 也是空的。判讀的起點是把重裝後的機器當成全新的一台，重做第一次連線的設定，而不是沿用舊別名。

失敗會以三種形式出現，各對應不同層、各有各的修法：

Permission denied (publickey) 是認證被拒，代表 sshd 有在跑、連線有到（這是進度），卡在金鑰這關。常見於你用的別名設了 IdentitiesOnly yes 只送某一把 key，而新機器的 authorized_keys 還沒有它。修法是改用帳號加 IP 直連、走密碼，繞過那個鎖死金鑰的別名：ssh user@<新 IP>，密碼是「這次安裝」為該使用者設的（每次重裝各自獨立，不是舊機器那個）。連進去後再把公鑰貼回新機器的 authorized_keys、把別名的 HostName 更新成新 IP，免密碼才會恢復。

Host key verification failed（或 REMOTE HOST IDENTIFICATION HAS CHANGED）發生在新機器剛好拿到跟舊機器一樣的 IP 時：你本機 known_hosts 存的是舊機器的 host key，SSH 偵測到同一個 IP 換了 key、當成可能的中間人攻擊而拒連。修法是刪掉那筆舊紀錄，再重連時接受新 key：

1ssh-keygen -R <IP>       # 刪掉該 IP 的舊 host key
2ssh-keygen -R <別名>     # 有用別名的話一併刪

Connection refused 代表沒有 sshd 在監聽，也就是新機器還沒把 SSH server 起來。修法回到最開始——在新機器的 console 裝 openssh、啟動服務（見本篇開頭「啟用 sshd」），這一步在每台全新機器上都要重做。

三個症狀的共同根因是同一件事：SSH 的便利設定（別名、金鑰、host key 快取）綁的是機器身分、不會跟著「重裝」自動轉移。把它們當成「為某一台機器設好的」，換機器就重做第一次連線，能省下對著看似無關的錯誤瞎猜的時間。

連入後可能遇到的兩個終端機問題

SSH 連線本身通了之後，互動 shell 還可能因為終端機環境不對而出現「打字變亂碼、prompt 重繪錯位」。這類問題在你用現代終端機（如 Ghostty、Kitty）連進一台剛裝好的最小 Linux、又跑了 unicode 較重的 prompt（如 Powerlevel10k）時最容易出現，根源是兩個跟字元處理有關的終端機設定，跟你的 shell 配置無關。

第一個是 locale。macOS 的終端機 SSH 連線時常把 LC_CTYPE=UTF-8 送到遠端，但 UTF-8 不是合法的 Linux locale 名稱，Linux 收到後 fallback 成 POSIX/C locale——於是 shell 的行編輯器把輸入當單位元組處理，配上 unicode 字元的 prompt 就重繪成一個字母重複好幾次的累加亂碼。判讀方式是在遠端跑 locale，看 LANG 是不是空的、LC_CTYPE 是不是 POSIX。修法是在 shell 設定裡強制一個合法的 UTF-8 locale（前提是該 locale 已生成，見 安裝選項判讀 的 locale 段）：

1export LANG=en_US.UTF-8
2export LC_CTYPE=en_US.UTF-8

第二個是 terminfo。現代終端機會把 TERM 設成自己的值（Ghostty 是 xterm-ghostty、Kitty 是 xterm-kitty），而一台剛裝好的 Linux 的 terminfo 資料庫沒有這些條目，shell 的行編輯器做「清行重繪」時找不到對應的控制序列、就把畫面畫壞。判讀方式是在遠端 echo $TERM 看是哪個值、toe | grep <值> 看遠端認不認得。修法有兩條：把你終端機的 terminfo 灌進遠端（保留完整功能），或退而求其次強制一個遠端一定有的 TERM：

1# 把本機終端機的 terminfo 灌進遠端的 ~/.terminfo（推薦）
2infocmp -x "$TERM" | ssh remote 'tic -x -'
3
4# 或：連線時強制遠端一定有的 TERM（功能略降，但保證能用）
5ssh -t remote 'TERM=xterm-256color exec zsh -l'

這兩個問題的共同點是：它們在你裝了 unicode 較重的互動 shell 之後才浮現，而陽春的 shell（ASCII prompt）即使 locale 跟 terminfo 都不對也照樣能用。所以排查時，先確認是不是這層、而不是去懷疑剛裝的 shell 配置壞了。

連入、傳輸、安裝的順序

這三件事有一個固定的先後，順序錯了會在中間卡住。先把 sshd 跑起來、從本機連入，取得一個能貼上、可捲動的 session；再把 dotfile 弄進機器（公開 repo 走 HTTPS clone、私有或本地走傳輸）；最後在機器上跑 install.sh 完成安裝。SSH key 是讓「連入」從每次打密碼變成免密碼的優化，可以在任何時候補，不是這條鏈的必要環節、也不是 bootstrap 的前置。

模組零的操作順序指引 把「生成 SSH key、部署公鑰」列為標準流程的一環，那是預設你會建 key 的主路徑。這篇補的是它沒展開的另一面：當你手上還沒有 key、或這台機器的 dotfile 根本不需要 key 就能取得時，怎麼一樣把 bootstrap 跑完。

下一步

連入、傳輸、安裝都跑通之後，真正的考驗是當 install.sh 中途失敗時——而它遲早會撞到失敗——你能不能快速看出哪裡錯了。這取決於安裝腳本有沒有把可觀測性內建進去，可除錯的 bootstrap 談的就是怎麼內建。

可觀測性要事先設計，是因為失敗發生的當下，你能拿到的資訊就已經定型了。如果腳本只把輸出丟到終端機、失敗時只留下一句通用的錯誤，那當下你就只有那句話可看；如果它一路把帶時間戳的紀錄寫進檔案、失敗時主動印出出錯的位置，那同一個失敗就變得可定位。差別不在失敗本身，在失敗前你準備了什麼。如果你寫的是自己的 bootstrap（例如部署 dotfile 的那支 install.sh），這層要在你第一次跑它之前就設計進去，而不是等它出事才回頭加；就算腳本不是你寫的、你只是來 debug 一次失敗，下一段「找程式自己的 log」一樣適用。

為什麼會瞎找

不可觀測的腳本失敗時，你手上只有終端機捲動過的那些輸出，而那往往不足以定位真正的原因。終端機的輸出是易逝的、會被後續輸出沖掉、多個來源的訊息交錯在一起；更麻煩的是，很多失敗的「表面錯誤」離「真正原因」隔了好幾層。一個指令因為前面某個變數是空的而失敗，但它報出來的錯可能完全沒提到那個空變數——你看著一個誤導性的症狀，往上游找不到源頭。

破解這種瞎找的，常常是一份你一開始沒看的 log。很多程式在終端機只印一段摘要，卻同時把詳細的執行紀錄寫進一個 log 檔；當終端機的訊息不足以定位時，那份程式自己寫的 log 裡往往就有答案。除錯時養成「找程式自己的 log，而不是只盯著終端機捲動」的習慣，是把瞎找變成定位的關鍵一步——這也是 模組七日誌判讀 的核心。而對你自己寫的 bootstrap，你可以更進一步：在設計時就讓它產生這樣一份 log。

三個內建可觀測性的手法

讓一支 bootstrap 腳本可診斷，有三個低成本、效果明顯的手法，它們合起來把「失敗了」變成「失敗在第幾行、哪個指令、什麼狀態」。

log 落地：把全部輸出 tee 進帶時間戳的檔案

第一個手法是讓腳本的全部輸出同時進終端機跟一個 log 檔，而不是只進終端機。終端機的捲動是易逝的，log 檔是持久的——可以事後 grep、可以貼給別人看、可以比對前後兩次跑的差異。在 bash 裡，一行 exec 就能把後續所有 stdout 與 stderr 都導去 tee：

1LOG_DIR="${XDG_STATE_HOME:-$HOME/.local/state}/dotfiles"
2mkdir -p "$LOG_DIR"
3LOG_FILE="$LOG_DIR/install-$(date +%Y%m%d-%H%M%S).log"
4exec > >(tee -a "$LOG_FILE") 2>&1

帶時間戳的檔名讓每次跑各留一份、不互相覆蓋，事後可以回溯「上一次成功跟這次失敗差在哪」。log 檔放在 XDG_STATE_HOME（狀態資料的標準位置）底下，符合慣例、也不污染家目錄。

錯誤定位：用 ERR trap 印出出錯的行與指令

第二個手法是讓腳本在中斷的瞬間，主動報出「是哪一行、哪個指令、什麼結束碼」失敗的。配合 set -e（出錯即停）的腳本，預設只會默默地停，不告訴你停在哪。加一個 ERR trap，就能在 set -e 中斷之前先印出定位資訊：

1set -Eeuo pipefail   # -E 讓 ERR trap 在函式/子 shell 也生效
2trap 'log "ERROR line $LINENO: [$BASH_COMMAND] exit=$?"' ERR

$LINENO 是出錯的行號、$BASH_COMMAND 是當下正在執行的那條指令、$? 是它的結束碼。三者合起來，輸出會長這樣：

1[00:06:51] ERROR line 40: [sudo pacman -S --needed stow git zsh] exit=1

範例裡的 pacman 換發行版會不同，這裡只是示意 trap 輸出的格式——手法本身（行號 + 指令 + 結束碼）跟發行版無關。這一行直接點名元兇。前面提過的那類「表面錯誤離真正原因隔好幾層」的情況——例如某個指令因為 which 不存在而拿到空字串、最後報一個看似無關的錯——有了這行，你會直接看到是哪一行的哪條指令掛了，不必從誤導性的症狀往回猜。set -E（-E 旗標）是為了讓 trap 在函式跟子 shell 裡也照樣觸發，少了它，包在函式裡的錯誤會漏掉。

步驟標記：用帶時間戳的 log 函式標出進度

第三個手法是在關鍵步驟前印一行帶時間戳的標記，讓你能看出腳本跑到哪、哪一步慢。一個極簡的 log 函式就夠：

1log() { printf '[%s] %s\n' "$(date +%H:%M:%S)" "$*"; }
2
3log "install.sh start | OS=$OS"
4log "Installing base packages..."
5log "Stowing configs..."

時間戳的價值在於它同時給你「進度」跟「效能」兩種資訊：失敗時，最後一行成功的 log 告訴你它跨過了哪些步驟、卡在哪一步之後；正常時，相鄰兩行的時間差告訴你哪一步耗時最久。這比沒有標記、只能從一堆套件下載輸出裡猜「現在到底在幹嘛」清楚得多。

失敗可診斷是設計目標

把這三個手法合起來，一支原本「失敗時只留一句通用錯誤」的腳本，會變成「每次跑都留一份完整 log、失敗時直接點名第幾行哪個指令、過程中每步都有時間戳」。成本是腳本開頭多幾行，回報是把未來每一次除錯從瞎找變成定位。這層可觀測性是 模組八 bootstrap script 設計 的延伸——那篇給安裝腳本的骨架與套件清單，這篇給它加上失敗時的診斷能力，兩篇處理的是同一支腳本的兩個層面。

這是設計階段的決定，不是事後能補的。當一支沒有可觀測性的腳本在一台陌生機器上失敗，你沒辦法回到過去讓它記錄當時的狀態——資訊在失敗的瞬間就已經流失了。所以「失敗可診斷」要跟功能一起設計進去，把它當成 bootstrap 的基本屬性，而不是出事之後才想加的補丁。

回到系列

這幾篇合起來，是把一台機器從「空的」帶到「能接收 dotfile、且部署過程可診斷」的完整地基：安裝選項判讀 處理 OS 怎麼裝、工具驗證與補足 處理裝完缺什麼、外部連入與無 key bootstrap 處理怎麼連進去把 dotfile 弄進來，這一篇處理當部署失敗時怎麼快速看出原因。再往前一步，把這套地基用在無人值守的長任務上、讓機器在你離開後自己跑完工作，見 讓機器跑無人值守的長任務——無人盯著的任務尤其依賴這篇談的可觀測性。地基打好，後面 模組一到八 的 dotfile 管理才有立足點。

底下用一個具體情境當例子：在一台用完即丟的測試 VM 上，讓 Claude Code 這類 agent 自己跑完一段工作、把成果推回 GitHub 給你早上 review。同一組障礙換成 overnight 編譯或 cron 批次也成立。

障礙一：互動提示擋住自動執行

無人值守的程序沒有人在鍵盤前，所以任何「停下來等你輸入」的提示都會讓它卡死，其中最常見的是 sudo 密碼。一個要裝套件、改系統設定的任務，跑到 sudo 那行就停在密碼提示、永遠等不到輸入，整個任務卡在那裡直到你回來。

解法是讓這台機器的 sudo 免密碼（NOPASSWD），但這是一個明確的安全取捨、不是預設該開的東西。設定方式是給 sudoers 加一條 NOPASSWD 規則：

1echo "$(whoami) ALL=(ALL:ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/20-nopasswd  # $(whoami) 會填入你的登入帳號
2sudo chmod 440 /etc/sudoers.d/20-nopasswd

開了 NOPASSWD，等於放棄「sudo 密碼」這道在你被入侵或程序失控時的最後防線。判讀軸是這台機器的爆炸半徑——它持有哪些憑證、能觸及哪些系統，也就是最壞情況下會波及多大範圍。一台範圍受限、沒有任何真實憑證、出事就重建的測試 VM，放棄這道防線換取自動執行是划算的；一台共享主機、生產伺服器、或裝著真實憑證與資料的機器，不該為了方便開 NOPASSWD。關鍵是「可不可丟」不等於「爆炸半徑小」：一台用完即丟的 VM，一旦塞進能碰到生產系統或你帳號的憑證，爆炸半徑就不小了——看的不是機器本身，是它最壞情況能波及什麼。

障礙二：SSH 斷線就把任務一起殺掉

直接在 SSH session 裡跑的程序，會隨著 SSH 連線中斷而一起死掉——你闔上筆電、網路斷一下、或單純關掉終端機，正在跑的任務就沒了。對一個要跑好幾小時的無人值守任務，這條等於「你不能離開」，跟無人值守的目的矛盾。

把任務搬進終端機多工器（zellij、tmux 這類，配置見 模組三）就解決了。多工器的 session 活在那台機器上、獨立於你的 SSH 連線：你在多工器裡啟動任務、然後 detach（卸離），任務繼續在機器上跑，你這頭關掉 SSH 都不影響；之後再連回來 attach（接回）就能看它跑到哪。典型流程是連入機器、起多工器、在裡面啟動任務、detach、走人：

1ssh user@host
2zellij                       # 起多工器（tmux 同理）
3./run-my-long-task.sh        # 在裡面啟動你的長任務（換成你的實際指令）
4# 然後 detach：zellij 預設 Ctrl+o 再按 d（tmux 是 Ctrl+b 再按 d）
5# 此時關掉 SSH 不影響任務，它在 host 上繼續跑
6
7# 之後連回來看進度：再 ssh 進去，然後
8zellij attach                # tmux 是 tmux attach

判讀訊號是「這個任務跑完前，我會不會斷線」。只要會（過夜、跨小時、不穩的網路），就把它放進多工器；幾秒鐘就結束的指令不需要這層。

障礙三：成果推不出去，等於沒做

無人值守任務的產出留在那台機器上，你看不到——除非它能把結果送出去。最常見的形式是把改動 commit 後 push 回 git 遠端，你在別處 pull 來看。但 push 需要認證，而一台剛連入的機器通常還沒設好推送的憑證，於是任務做完了、commit 也建了，卻卡在 push 那步推不出去，你隔天連回來才發現結果根本沒送出去。

先在這台機器上設好推送認證，這個障礙就消失。用 GitHub CLI 是直接的一條路，它認證後會一併把 git 的 credential helper（git 用來自動帶出認證、不必每次手打的機制）設好，後續 git push 就能用——但 gh auth login 本身是互動式的、要你在場完成一次，屬於離開前的人工前置：

1gh auth login    # 選 HTTPS、完成認證、同意設定 git 認證

判讀軸是「這個任務的價值要怎麼回到你手上」。如果你打算從遠端（GitHub）看結果，那 push 認證就是必要前置——沒設好，整段工作就被困在機器裡。連帶的紀律是讓任務頻繁 commit 當檢查點、做完務必確認 push 成功：對一個你不在場的任務，「沒推出去」跟「沒做」對你是一樣的。機器若沒裝 gh，也可以用 PAT 走 HTTPS，見 外部連入篇 的私有 repo 段。

把 push 憑證設進這台機器，等於提高了它的爆炸半徑——它現在能動你的 repo 了。這會回頭讓障礙一的 NOPASSWD、以及下面 agent 段的權限放行更該謹慎：最壞情況從「弄壞這台機器」升級成「污染你的 repo」，而後者不是重建一台 VM 就能還原的。所以設了 push 憑證之後，要連帶重估前面那些「因為機器可丟所以放心」的取捨。

額外一層：宿主暫停會連帶停掉任務

當這台機器是跑在某個宿主上的虛擬機，還有一個容易忽略的中斷源：宿主睡著，VM 跟著暫停，裡面的無人值守任務也一起停。你以為它整夜在跑，回來發現它從你離開那刻就凍在那裡。判讀方式是想一下「這台機器的存在依賴什麼」——VM 依賴宿主醒著、雲端主機依賴帳單沒欠費。對 VM 的情況，離開前確保宿主不會自動睡眠（macOS 用 caffeinate、Linux 宿主用 systemd-inhibit 或停用 suspend、Windows 調電源設定，或直接關掉節能的自動睡眠）。

如果無人值守的工作者是 AI agent

當你放著跑的是一個 AI agent，除了上面三個障礙，還多一個它自己的互動提示要處理：agent 預設會在每個有風險的動作前停下來問你確認，而無人值守時沒人回答，它就卡住。對應的是 agent 的「跳過確認」模式（如 Claude Code 的權限放行旗標），讓它不停下來問。這跟 NOPASSWD 是同一類取捨、判讀軸也一樣：放給一個無人盯著的 agent 在一台範圍受限、用完即丟的機器上自主動作是可接受的；在一台有真實資料或共享的機器上不該這樣。降低風險的兩個做法是把 agent 的工作範圍用清楚的指引限定（只動哪些目錄、別碰系統其他地方），以及讓它在分支上做、產出交給你 review，而不是直接動到你會依賴的東西。

下一步

把這三到四個障礙解決掉，一台機器就能在你離開後自己跑完工作、把成果送回你手上。這篇是 外部連入（怎麼連進去）的延伸——從「我連進去手動操作」進到「我設好讓它自己跑」。而要讓那個無人值守的任務在失敗時還留得下可診斷的痕跡，回到 可除錯的 bootstrap 的原則：無人盯著的任務尤其需要把可觀測性內建進去，因為你不在場、只能事後從 log 重建發生了什麼。

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

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

• 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 設計

差異的四個層次

套件管理器：每個平台各有原生解

macOS 用 Homebrew、Arch 用 pacman、Debian/Ubuntu 用 apt、Fedora 用 dnf。安裝指令、確認旗標、資料庫同步模型都不同，其中兩個差異會直接咬到自動化腳本：

• 非互動旗標不對稱：apt 的慣例是 -y，pacman 是 --noconfirm。腳本只寫了其中一邊，換平台就會卡在確認提示——非 TTY 環境下（SSH 一行式、CI、無人值守）沒人回答 [Y/n]，pacman 直接以錯誤結束。
• 資料庫同步模型不同：Arch 是 rolling release 且鏡像不保留舊版檔案，裝機當下的套件資料庫幾天內就會指向已被輪替掉的檔名，安裝時收到 404（failed retrieving file）。修法是安裝前先 pacman -Syu 同步資料庫並全系統升級——只 -Sy 不 -u 會造成 partial upgrade（新資料庫裝新套件、舊系統缺新依賴）。Debian stable 的套件庫凍結、沒有這個時序問題，但代價是版本舊。

套件名稱：同一個工具、各發行版各叫各的

Debian 的重命名還會連執行檔一起改（fdfind、batcat），所以連 shell alias 與腳本內的指令呼叫都要跟著分歧。維護跨發行版清單的可靠做法是逐台實測建立——憑印象抄一份對照表，漂移只是時間問題。

套件存在性：有些概念只存在於特定平台

Hyprland 在 Arch 官方 repo、Fedora 要 COPR、Debian stable 沒有；Quickshell 只有 Arch 打包。反過來，macOS 的 cask app（GUI 應用程式）概念在 Linux 對應的是各桌面環境自己的生態。這層差異沒有翻譯的空間——桌面層的清單是平台專屬的維護對象。

存在性差異還有一個容易漏看的軸：CPU 架構。發行版 repo 有這個工具、不代表它在你的架構上存在——尤其是專有軟體的二進位發行。實測案例：Arch aarch64（ALARM）的 repo 有 spotify-launcher（工具本身有 aarch64 建置），但它要下載的 Spotify 官方 client 只發 x86_64/i386 deb，實跑直接回報 There are no packages for your cpu's architecture (cpu="aarch64", supported=["amd64", "i386"])。這類失敗的判讀重點是分清「工具沒打包」跟「工具打包了、它依賴的專有 blob 沒有這個架構」——前者可能有 AUR / 第三方 repo 補、後者只能找替代路徑（Spotify 的替代是 Web Player + 從 ChromeOS 鏡像抽出的 arm64 Widevine CDM）。DRM、GPU driver、印表機 driver 這類含專有二進位的軟體，在非 x86_64 架構上都要先查架構支援再排進安裝清單。

版本節奏：rolling 與 stable 的行為差

Arch rolling 永遠最新，Debian stable 的同名工具可能舊兩年。版本差會讓 config 語法對不上（新版工具的設定選項在舊版不存在）、也會讓「照著文件做卻失敗」——文件寫的是新版行為。除錯時看到「同一份 config 在 A 機器能跑、B 機器報錯」，先比對兩邊的工具版本再懷疑 config 本身。

除錯前先定平台

跨平台差異對除錯的意義：判讀工具與修法都是平台相依的，先確認自己站在哪，再開始查。 三條指令建立座標：

1cat /etc/os-release        # 發行版與版本（Linux）
2uname -m                   # CPU 架構：x86_64 / aarch64（套件生態差很多）
3command -v pacman apt-get dnf brew   # 哪個套件管理器在場

架構那條容易被忽略：aarch64（ARM）的套件生態比 x86_64 小——Homebrew on Linux 對 aarch64 沒有預編譯 bottle、AUR 部分套件不支援 ARM。在 ARM 機器上照 x86 的教學走，會在意想不到的地方碰壁。

Bootstrap 的分歧設計判準

把差異收進腳本架構的三條判準，決定每段邏輯住在哪：

1. 安裝手段跨平台一致（git clone、curl installer、stow 部署）→ 進共通層，一份邏輯全平台用
2. 只是套件名或套件管理器不同 → 各平台一份安裝腳本 + 一份套件清單，獨立維護、分歧不寫進共通層的 if/else
3. 概念只存在於某平台（Hyprland、cask）→ 只出現在該平台清單的桌面層

這個切法的維護成本結構：共通層改一次全平台生效；平台層只在你真的用那個平台時才付維護成本。沒有實測機器的發行版不預先建清單——那種清單沒有實測支撐、注定漂移。

統一層的誘惑與代價

「用一個跨平台套件管理器統一所有機器」聽起來能消掉整個分歧層，實際的適用邊界很窄。Homebrew 支援 Linux，但它在 Arch 上會建一套與 pacman 平行的套件世界（獨立 prefix、重複的函式庫、PATH 互搶），而且對 aarch64 Linux 沒有 bottle、全部從原始碼編譯。它真正的適用場景是「發行版套件太舊」（如 Ubuntu LTS 上要新版工具）或「沒有 root 權限」。Nix 能做到真正的跨平台一致，代價是整套心智模型重學。判準是：分歧層的維護成本（每個發行版一份清單）低於統一層的引入成本時，保持原生套件管理器 + 分平台清單。

下一步路由

• Bootstrap 腳本本身的設計（log 落地、錯誤定位）見可除錯的 bootstrap
• 最小系統缺什麼、怎麼驗證見最小安裝後的工具驗證與補足
• 出問題時的判讀紀律見 Linux 除錯與診斷
• dotfile repo 怎麼同時服務 macOS 與 Linux 見一個 repo 管理跨平台環境