Linux on KnightLi的博客

pci=nomsi 和 pcie_aspm=off 詳解：Linux 下 SATA 擴展卡不認盤、掉盤、卡死時該怎麼排查

Sun, 24 May 2026 00:41:23 +0800

在 Linux / Ubuntu 上使用 PCIe SATA 擴展卡時，很多人會遇到不認盤、運行一段時間掉盤、系統卡死，或者開機階段卡在 PCIe 鏈路訓練的問題。常見對象包括 JMB585、ASM1166 等 SATA 擴展卡，尤其是在 NAS、小主機、工控機、魔改主板或廉價轉接卡環境裡更容易出現。

pci=nomsi 和 pcie_aspm=off 是排查這類問題時經常用到的兩個 Linux 核心參數。它們看起來都和 PCIe 有關，但解決的不是同一個問題：

pci=nomsi 主要處理 中斷訊號問題，也就是設備和 CPU 之間的「通知方式」不穩定。
pcie_aspm=off 主要處理 PCIe 電源管理問題，也就是鏈路進入省電狀態後喚醒失敗或訊號不穩。

如果把這兩個參數混在一起理解，很容易變成玄學調參。更合理的做法是先看現象，再判斷應該優先懷疑中斷、鏈路省電，還是硬體本身。

pci=nomsi：禁用消息信號中斷

pci=nomsi 可以拆開看：

PCI：外設部件互連相關設備。
no：禁用。
MSI：Message Signaled Interrupts，消息信號中斷。

它的意思是：讓 Linux 核心不要給 PCI 設備使用 MSI / MSI-X 中斷機制，而是退回傳統的 INTx 中斷方式。

MSI 是什麼

傳統硬體設備要通知 CPU「我有事要處理」，通常依賴物理中斷引腳，也就是傳統 IRQ。這個機制比較老，能用，但共享和擴展能力有限。

後來出現了 MSI / MSI-X。設備不再一定要拉物理中斷引腳，而是向特定記憶體地址寫入一條消息。CPU 收到這條消息後，就知道哪個設備觸發了中斷。對現代系統來說，MSI / MSI-X 通常更靈活，也更適合高併發設備。

問題在於，並不是每張 PCIe 擴展卡的韌體都把 MSI 做得足夠可靠。部分廉價擴展卡、二手拆機卡、橋接晶片方案，或者韌體品質一般的 SATA 控制器，在 Linux 驅動下可能出現 MSI 消息異常、中斷丟失或中斷風暴。

常見表現包括：

開機檢測 PCIe 擴展卡時卡住。
SATA 擴展卡完全不認盤。
系統隨機卡死。
dmesg 中出現類似 irq xx: nobody cared 的報錯。
某張卡在 Windows 下看似正常，但 Linux 下很不穩定。

這類問題的核心不是硬碟本身，也不是檔案系統，而是設備和 CPU 之間的中斷通信方式不可靠。

加上 pci=nomsi 後會發生什麼

啟用：

`1`	`pci=nomsi`

等於告訴 Linux 核心：不要讓 PCI 設備使用進階的 MSI 消息中斷，統一退回傳統 INTx 中斷模式。

這可能帶來一點效能和併發效率損失，尤其是在高吞吐、高手動中斷頻率設備上。但對家用 NAS、SATA 擴展卡、普通機械硬碟陣列來說，實際影響通常不明顯。它的價值在於繞過某些設備韌體或橋接晶片的 MSI 相容性問題，讓系統能穩定識別設備並處理 I/O。

簡單說，pci=nomsi 處理的是「設備通知 CPU 的方式不可靠」。

pcie_aspm=off：禁用 PCIe 活動狀態電源管理

pcie_aspm=off 也可以拆開看：

PCIe：PCI Express，高速串行擴展總線。
ASPM：Active State Power Management，活動狀態電源管理。
off：關閉。

它的意思是：關閉 PCIe 鏈路的省電機制，讓 PCIe 鏈路不要進入低功耗狀態。

ASPM 是什麼

ASPM 是 PCIe 總線上的省電機制。當系統發現某條 PCIe 鏈路暫時沒有資料傳輸時，可以把鏈路切到低功耗狀態，例如 L0s 或 L1。等設備再次有資料讀寫時，再把鏈路喚醒回正常工作狀態。

在設計良好的硬體上，這套機制可以降低功耗，而且對使用者幾乎無感。但在一些消費級主板、小主機、工控機、廉價 SATA 擴展卡、轉接板或訊號品質一般的硬體上，問題會出在「睡下去以後醒不穩」。

典型情況是：JMB585、ASM1166 這類 PCIe SATA 擴展卡在空閒後進入低功耗狀態，下一次存取硬碟時鏈路需要從 L1 喚醒。如果控制器、主板、轉接線、供電或韌體品質不夠好，喚醒可能太慢，或者鏈路恢復時發生物理層抖動。Linux 核心就可能認為設備短暫失聯。

常見 dmesg 表現包括：

1
2
3

pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer
ata1: link is slow to respond, please be patient
ata1: COMRESET failed (errno=-16)

隨後可能出現：

硬碟掉線。
陣列降級。
檔案系統變成唯讀。
NAS 服務異常。
系統 I/O 卡死。
重啟後硬碟又暫時恢復正常。

這類問題最麻煩的地方在於，它不一定開機就出現，往往是運行一段時間、空閒後喚醒，或高負載切換時突然發生。

加上 pcie_aspm=off 後會發生什麼

啟用：

`1`	`pcie_aspm=off`

等於告訴核心：關閉全系統 PCIe ASPM 省電功能。PCIe 鏈路不管空閒還是忙碌，都盡量保持在正常連接狀態，不要進入低功耗睡眠。

副作用是功耗可能略有上升。對桌機、NAS、小主機來說，通常只是幾百毫瓦到一兩瓦級別；對筆記型電腦來說，可能會影響續航。它換來的好處是減少因為 PCIe 鏈路睡眠和喚醒造成的掉盤、鏈路訓練錯誤和物理層報錯。

簡單說，pcie_aspm=off 處理的是「PCIe 鏈路睡著後醒不穩」。

兩個參數的區別

可以把它們理解成兩類不同問題：

參數	解決的核心問題	常見表現	主要副作用
`pci=nomsi`	中斷訊號衝突、MSI / MSI-X 相容性差	開機卡死、完全不認盤、`irq xx: nobody cared`、系統死機	極高併發下中斷效率可能下降
`pcie_aspm=off`	PCIe 省電喚醒失敗、鏈路訊號不穩	剛開機正常，運行一會兒掉盤，`PCIe Bus Error`、`COMRESET failed`	功耗略升，筆電續航略降

所以它們不是互相替代關係。一個管中斷，一個管鏈路電源管理。

如果機器開機階段就卡死、設備完全不認，優先懷疑 pci=nomsi。如果開機正常、運行一段時間後掉盤，或者 dmesg 裡有 PCIe Physical Layer、COMRESET、link is slow to respond 之類資訊，優先懷疑 pcie_aspm=off。

是否應該兩個一起加

很多 NAS 玩家會直接同時加：

`1`	`pci=nomsi pcie_aspm=off`

這確實是快速排查的辦法，尤其是在 JMB585、ASM1166、小主機、轉接卡、供電和線材都不太確定的環境裡。它可以同時繞開 MSI 相容性問題和 ASPM 喚醒問題。

但從排障角度，更推薦先記錄現象和日誌：

如果是中斷報錯或啟動卡死，先試 pci=nomsi。
如果是運行後掉盤、PCIe Bus Error、COMRESET，先試 pcie_aspm=off。
如果問題嚴重且急著恢復穩定，可以兩個一起加，穩定後再拆開驗證。

這樣能知道到底是哪一類問題導致的，後續換卡、換槽、換主板或調整 BIOS 時更有依據。

Ubuntu / Debian 中如何永久生效

編輯 Grub 配置檔案：

`1`	`sudo nano /etc/default/grub`

找到這一行：

`1`	`GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"`

在雙引號內追加參數，參數之間用空格隔開。例如：

`1`	`GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=nomsi pcie_aspm=off"`

保存並退出。如果使用 Nano，按 Ctrl+O 保存，回車確認，再按 Ctrl+X 退出。

更新 Grub 並重啟：

1
2

sudo update-grub
sudo reboot

重啟後，可以查看目前核心啟動參數是否已經生效：

`1`	`cat /proc/cmdline`

如果輸出裡能看到 pci=nomsi 和 pcie_aspm=off，說明參數已經進入目前核心啟動命令列。

還應該檢查哪些地方

這兩個參數很有用，但它們不是所有掉盤問題的萬能解法。排查 SATA 擴展卡和 NAS 掉盤時，也建議同時檢查：

SATA 資料線是否鬆動或品質太差。
硬碟供電是否穩定，尤其是多盤同時啟動時。
PCIe 插槽是否接觸不良。
擴展卡是否過熱。
主板 BIOS 是否有 PCIe ASPM、Above 4G Decoding、PCIe speed 等相關選項。
SATA 擴展卡韌體是否有已知問題。
系統日誌中是否有硬碟本體壞道、I/O error 或 SMART 告警。

如果硬碟 SMART 已經報錯，或者供電本身不穩，單靠核心參數無法真正解決問題。

小結

pci=nomsi 和 pcie_aspm=off 都常用於 Linux 下 PCIe SATA 擴展卡不穩定的排查，但它們解決的是兩條不同鏈路：

pci=nomsi：關閉 MSI / MSI-X，繞開中斷通信相容性問題。
pcie_aspm=off：關閉 PCIe ASPM，避免鏈路省電後喚醒失敗。

對 JMB585、ASM1166、NAS、小主機和廉價 PCIe 擴展卡來說，這兩個參數確實經常能救場。更穩妥的做法是先看 dmesg，判斷是中斷問題還是鏈路省電問題，再決定單獨使用還是一起使用。

它們是排障工具，不是硬體品質的替代品。如果加上參數後系統穩定了，說明問題大機率在中斷相容性或 PCIe 電源管理上；如果仍然掉盤，就要繼續檢查供電、線材、散熱、硬碟健康和擴展卡本身。

CVE-2026-43494 / PinTheft：Linux RDS 與 io_uring 組合出的本地提權風險

Fri, 22 May 2026 15:16:59 +0800

CVE-2026-43494 是一個 Linux 核心本地權限提升風險，外界也用 PinTheft 來稱呼相關利用鏈。它的關鍵不在遠端入口，而在於本地低權限使用者能否同時碰到 RDS zerocopy、io_uring fixed buffer、可讀 SUID-root 程式和合適的核心版本。

需要先說明一個編號細節：Unclecheng-li/poc-lab 倉庫目錄名寫的是 CVE-2026-43494 PinTheft，README 標題裡又寫了 QVD-2026-27616 - PinTheft。從公開 CVE 條目和第三方通告來看，CVE-2026-43494 指向的是 Linux kernel RDS zerocopy 中 op_nents 未正確重置引發的 double-free / 引用計數異常問題；QVD-2026-27616 更像是奇安信風險通告編號。實際排查時建議同時記錄這兩個標識，但以發行版安全公告和核心補丁狀態為準。

漏洞核心是什麼？

這個問題出現在 Linux RDS，也就是 Reliable Datagram Sockets 的 zerocopy 發送路徑中。公開描述裡的關鍵函式是：

1
2

rds_message_zcopy_from_user()
rds_message_purge()

當 iov_iter_get_pages2() 在 rds_message_zcopy_from_user() 中失敗時，已經 pin 住的頁面會先被錯誤路徑釋放；但相關 op_nents 資訊沒有被正確清零，後續 rds_message_purge() 仍可能按殘留條目再釋放一次。結果就是同一批頁面引用被多減，形成可被利用的引用計數錯誤。

單看 RDS bug，它是核心記憶體管理裡的錯誤路徑問題。PinTheft 的危險之處在於利用鏈把它和 io_uring 固定緩衝區機制連了起來：io_uring 仍保存著舊的 struct page *，而頁面本身已經被釋放並重新分配給其他用途。PoC 進一步把這個狀態引向 SUID-root 程式的 page cache 覆寫，最終達到本地提權。

為什麼叫 PinTheft

io_uring REGISTER_BUFFERS 會固定使用者頁。對普通頁面來說，FOLL_PIN 並不只是簡單增加一個引用，而是透過較大的 bias 增加 page refcount。公開 PoC 中使用了 GUP_PIN_COUNTING_BIAS = 1024 這個概念。

PinTheft 這個名字的意思是：攻擊鏈透過 RDS zerocopy 的失敗路徑，一次次「偷走」這些 pin 引用。等引用被耗掉後，io_uring 仍以為自己持有有效頁面，但該實體頁已經可以被釋放並被 page cache 重新占用。

這類漏洞容易被誤讀成「直接改了磁碟上的 /usr/bin/su」。更準確的說法是：利用鏈嘗試覆寫的是記憶體中的 page cache。檔案本體不一定被寫回磁碟，但核心執行該 SUID 程式時可能從被污染的頁快取取指令，從而執行攻擊載荷。

觸發條件並不寬

這不是一個「任意 Linux 伺服器都能遠端打」的漏洞。公開資訊顯示，利用鏈至少依賴這些條件：

核心啟用了 CONFIG_RDS 和 CONFIG_RDS_TCP。
系統啟用了 CONFIG_IO_URING，且 kernel.io_uring_disabled=0。
rds / rds_tcp 模組已經載入，或低權限使用者可以觸發自動載入。
本地存在可讀的 SUID-root 二進位程式，例如 /usr/bin/su、/usr/bin/passwd、/usr/bin/pkexec。
公開 PoC 還依賴較新的 IORING_REGISTER_CLONE_BUFFERS API，CloudLinux 的分析提到公共 PoC 更偏向 kernel 6.13 及以上形態。

只要其中一環不成立，公開鏈路就會斷掉。比如很多 RHEL 系發行版預設不編譯 RDS，Ubuntu 舊核心可能缺少 PoC 需要的 io_uring clone buffer API，部分環境也會限制非特權使用者自動載入 RDS 模組。

一分鐘自查

先看核心設定：

1
2

zgrep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /proc/config.gz 2>/dev/null \
  || grep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /boot/config-$(uname -r)

再看 io_uring 是否被禁用：

`1`	`cat /proc/sys/kernel/io_uring_disabled 2>/dev/null`

常見含義可以按這個思路理解：

0：允許使用，風險面最大。
1：限制非特權使用者使用，具體行為看核心版本和發行版策略。
2：禁用 io_uring。

檢查 RDS 模組是否存在、是否可載入：

1
2

lsmod | grep -E "^rds|^rds_tcp"
modprobe -n -v rds_tcp 2>&1 | head -3

如果 CONFIG_RDS 是 not set，或者系統根本沒有 rds_tcp 模組，通常就無法走到這個 bug。反過來，如果 RDS 可用、io_uring 未禁用、系統又是較新的通用核心，就應該提高優先級繼續確認發行版修復狀態。

哪些機器更值得優先看？

優先排查這些環境：

多使用者 Linux 主機、教學機、跳板機、共享開發機。
容器宿主機，尤其是允許不可信本地使用者或較寬鬆容器逃逸面的環境。
開啟較新 mainline / rolling kernel 的桌面或伺服器，例如 Arch 一類滾動發行版。
HPC、Oracle RAC 或其他可能真實使用 RDS 的場景。
允許非特權使用者執行大量本地程式碼的 CI worker、建置機和實驗環境。

普通 Web 服務如果只有受控服務帳號執行應用，並且 RDS 未啟用，實際風險會低很多。但「低很多」不等於不用處理：核心本地提權的典型影響是攻擊者先透過 Web、SSH、CI、容器或應用漏洞拿到低權限，再用本地提權擴大控制面。

臨時緩解建議

正式修復仍應以發行版核心更新為準。補丁、回溯版本和受影響範圍需要看 Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、SUSE、Arch、雲廠商或容器基礎映像各自的安全公告，不要只按上游版本號判斷。

在等待補丁或無法馬上重啟核心時，可以按環境選擇臨時措施：

# 如果業務不依賴 RDS，可阻止相關模組載入
sudo sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false\ninstall rds_rdma /bin/false\n' > /etc/modprobe.d/pintheft.conf"
sudo rmmod rds_tcp 2>/dev/null
sudo rmmod rds_rdma 2>/dev/null
sudo rmmod rds 2>/dev/null

如果業務不依賴 io_uring，也可以考慮禁用或限制它：

`1`	`sudo sysctl -w kernel.io_uring_disabled=2`

持久化設定需要寫入對應的 /etc/sysctl.d/*.conf。不過這一步要謹慎，現代資料庫、代理、執行時或高效能 I/O 程式可能使用 io_uring；生產環境修改前最好先確認業務依賴。

修復後怎麼驗證

升級核心後，不要只看套件管理器輸出成功。建議確認三件事：

1
2
3

uname -a
cat /proc/sys/kernel/io_uring_disabled 2>/dev/null
modprobe -n -v rds_tcp 2>&1 | head -3

如果發行版公告明確寫明已修復 CVE-2026-43494，即使 uname -r 看起來不是最新上游版本，也可能是已經回溯補丁的穩定核心。反過來，如果核心來源是自行編譯、第三方倉庫、雲市場映像或容器宿主機模板，就要繼續核對補丁 commit 和建置時間。

參考資訊

近期四個 Linux 本地提權漏洞影響梳理：Copy Fail、Dirty Frag、Fragnesia 與 ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

最近 Linux 生態連續出現幾起高關注度的本地安全問題。單獨看，它們分別落在加密介面、網路/IPsec 路徑、頁快取處理、ptrace 存取檢查等不同位置；放在一起看，真正值得警惕的是同一個結論：只要攻擊者已經拿到低權限本地執行點，Linux 宿主機、容器節點、CI 機器和多使用者伺服器的風險都會被明顯放大。

本文重點不複述每個漏洞的技術細節，而是整理它們對實際環境的影響，並給出站內四篇單獨分析文章作為延伸閱讀。

四次事件分別影響什麼

近期最需要關注的四個風險是：

Copy Fail（CVE-2026-31431）：低權限本地使用者可能透過內核加密相關路徑影響頁快取，進而擴大權限。
Dirty Frag（CVE-2026-43284 / CVE-2026-43500 相關）：風險集中在 xfrm/ESP、RxRPC 等網路和內核資料路徑，後滲透階段危害很高。
Fragnesia（CVE-2026-46300）：與 Dirty Frag 相近，同樣圍繞 XFRM ESP-in-TCP、共享 fragment 和頁快取寫入風險展開。
ssh-keysign-pwn（CVE-2026-46333）：不是直接 root shell 類型漏洞，而是本地資訊洩露風險，可能讀取 SSH 主機私鑰、/etc/shadow 等敏感檔案。

這四類問題的入口不同，緩解方式也不完全一樣。不能因為處理了 Copy Fail，就預設 Dirty Frag 和 Fragnesia 也安全；也不能因為禁用了某些網路模組，就認為 ssh-keysign-pwn 的資訊洩露風險自動消失。

Copy Fail：容器和 CI 節點優先級很高

Copy Fail 的關鍵影響不是「某個應用崩潰」，而是低權限執行能力可能被轉化為 root 權限。它對以下環境尤其敏感：

允許使用者上傳或執行程式碼的 CI/CD 節點。
託管不可信工作負載的容器宿主機。
開發測試機、跳板機、共享伺服器。
執行舊內核且補丁節奏較慢的雲主機。

Copy Fail 的危險點在於攻擊門檻偏低，而且容易和容器場景疊加。很多團隊把容器當作強隔離邊界，但普通容器預設仍共享宿主機內核。如果攻擊者能在容器內取得 shell，內核本地提權就可能把容器問題放大為宿主機問題。

詳細分析見站內文章：Copy Fail 漏洞 CVE-2026-31431：Linux 內核檔案複製路徑中的容器逃逸風險。

Dirty Frag：後滲透階段的放大器

Dirty Frag 更像是攻擊者進入系統後的權限放大工具。它不是典型的遠端無認證漏洞，前提通常是攻擊者已經透過弱密碼、WebShell、低權限服務帳號、容器任務或其他方式取得本地執行能力。

它的實際影響主要體現在：

已被入侵的低權限帳號可能進一步變成 root。
容器環境中的低權限執行點可能威脅宿主機。
使用 IPsec、ESP、RxRPC 或相關內核網路能力的系統需要謹慎評估補丁和臨時緩解。
安全團隊不能只看邊界防護，還要關注入侵後的提權鏈條。

Dirty Frag 提醒運維團隊：本地提權漏洞雖然不是第一入口，卻可能決定一次入侵最終能走多遠。只要存在低權限落點，攻擊者就會尋找內核漏洞把權限推到最高。

詳細分析見站內文章：Dirty Frag CVE-2026-43284：Linux 本地提權漏洞風險與緩解指南。

Fragnesia：同類攻擊面沒有一次性清乾淨

Fragnesia 的重要性在於，它說明 Dirty Frag 附近的攻擊面並不是一個孤立問題。即使某個漏洞被修復，相鄰路徑、相似資料結構、相同模組組合裡仍可能存在新的可利用點。

它對運維的影響主要是：

不能只按漏洞名稱做一次性處置，要按攻擊面持續檢查。
esp4、esp6、rxrpc、XFRM、ESP-in-TCP 等相關路徑需要結合業務依賴評估。
如果系統不依賴相關網路能力，可以考慮臨時禁用，但必須先在測試環境確認不會影響 VPN、IPsec、隧道或內部網路功能。
頁快取污染類風險可能帶來「看似檔案沒改，實際執行路徑受影響」的檢測盲點。

Fragnesia 對企業最大的提醒是：補丁管理不能只盯單個 CVE。更穩妥的做法是圍繞子系統和攻擊面建立清單，確認哪些機器暴露相關能力，哪些業務真正需要這些模組。

詳細分析見站內文章：Fragnesia (CVE-2026-46300)：Linux 內核本地提權漏洞影響與緩解。

ssh-keysign-pwn：不直接 root，也足夠危險

ssh-keysign-pwn 與前三個漏洞的性質不同。它更偏向本地敏感資訊洩露，不是直接拿 root shell 的漏洞。但在真實攻擊中，敏感資訊洩露常常能變成更嚴重的後果。

它的影響重點包括：

SSH host private keys 洩露後，可能影響主機身分可信度。
/etc/shadow 等檔案被讀取後，可能引發離線破解和帳號接管。
多使用者伺服器、跳板機、建置機、共享開發機風險更高。
即使攻擊者沒有立刻提權，也可能拿到後續橫向移動需要的憑據材料。

這類問題容易被低估，因為它沒有「直接 root shell」那麼刺激。但對企業環境來說，密鑰和密碼雜湊洩露往往意味著更長週期的清理：輪換 SSH 主機密鑰、排查信任關係、檢查帳號密碼、審計登入日誌，都可能成為必要動作。

詳細分析見站內文章：ssh-keysign-pwn（CVE-2026-46333）解讀：Linux 本地資訊洩露、SSH 主機密鑰與 /etc/shadow 風險。

共同影響：容器隔離不能再被當作強邊界

這四次事件合在一起，最直接的影響是重新提醒大家：普通容器隔離不是虛擬機隔離。

Docker、containerd 和 Kubernetes 依賴 namespace、cgroup、capabilities、seccomp、AppArmor 或 SELinux 等機制減少攻擊面，但它們通常仍共享宿主機內核。只要漏洞發生在共享內核裡，容器內的低權限執行點就可能成為攻擊入口。

高風險環境應重點檢查：

是否允許不可信程式碼執行在共享宿主機上。
容器是否預設 root 使用者執行。
是否授予了不必要的 capabilities。
seccomp 配置是否過寬。
多租戶工作負載是否應該遷移到 gVisor、Kata Containers、Firecracker microVM、獨立虛擬機或專用節點。

對 CI/CD 平台尤其要謹慎。建置任務天然會執行外部程式碼、依賴安裝腳本、測試腳本和臨時二進位。如果這些任務與長期服務共享宿主機，一次本地提權就可能影響更大的基礎設施。

共同影響：補丁必須落到「正在執行的內核」

Linux 內核補丁有一個很常見的誤區：套件管理器顯示已經更新，不代表機器正在執行新內核。

運維上至少要確認三件事：

`1`	`uname -a`

確認目前執行內核版本。

`1`	`dpkg -l \| grep linux-image`

或在 RHEL 系發行版上：

`1`	`rpm -qa \| grep kernel`

確認已安裝內核套件。

最後，還要確認機器已經重啟到修復後的內核。對不能重啟的核心業務，要評估 livepatch、熱補丁或短期隔離方案，但不要把臨時緩解當作最終修復。

共同影響：攻擊面最小化要具體到模組和系統呼叫

這幾次漏洞涉及的路徑提醒我們，Linux 加固不能只停留在「更新系統」和「開防火牆」。

更具體的檢查方向包括：

AF_ALG / algif_aead 是否被業務使用。
XFRM、ESP、ESP-in-TCP、IPsec 是否被 VPN、隧道或安全閘道依賴。
RxRPC 是否需要啟用。
非特權使用者命名空間是否必須開放。
容器是否能建立過寬的 socket 類型。
ptrace 存取策略是否過鬆。

如果業務確實不需要某些能力，可以評估禁用模組、調整 sysctl、收緊 seccomp、減少 capabilities。生產環境不要盲目複製命令，應先盤點依賴，再灰度執行。

建議的處置順序

第一，優先修復可本地執行程式碼的高暴露機器：

容器宿主機。
CI/CD runner。
跳板機。
多使用者伺服器。
對外服務所在主機。
執行不可信插件、腳本、擴充的系統。

第二，確認發行版公告和實際執行內核。不要只看上游版本號，Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、SUSE、openEuler 等發行版可能會 backport 安全補丁。

第三，收緊容器執行策略。盡量做到非 root 使用者、最小 capabilities、no-new-privileges、唯讀檔案系統、明確 seccomp 和 AppArmor/SELinux 策略。

第四，檢查密鑰和憑據風險。尤其是涉及 ssh-keysign-pwn 的環境，應評估 SSH host key、/etc/shadow、跳板機憑據和 CI secrets 是否需要輪換。

第五，補上監控。重點關注異常 root shell、可疑本地提權 PoC、關鍵檔案修改、異常 ptrace 行為、容器程序存取宿主機路徑、CI 節點上的異常網路連線。

結論

這四次事件的重點不是「Linux 不安全了」，而是「預設信任不夠用了」。

Linux 仍然是透明、可修復、可裁剪、可加固的主流系統。但在容器、CI、多租戶和 AI 自動化程式碼執行越來越普遍的環境裡，低權限執行點已經不能被看作小問題。只要內核裡存在可利用的本地提權或敏感資訊洩露漏洞，局部入侵就可能變成宿主機控制、憑據洩露或橫向移動。

更現實的做法是把這四次事件當成一次提醒：補丁要快，重啟要確認，模組要按需啟用，容器要收緊，密鑰要能輪換，多租戶要重新評估隔離等級。

站內延伸閱讀：

ssh-keysign-pwn（CVE-2026-46333）解讀：Linux 本地資訊外洩、SSH 主機金鑰與 /etc/shadow 風險

Sun, 17 May 2026 09:29:03 +0800

ssh-keysign-pwn 是圍繞 Linux kernel __ptrace_may_access() 邏輯問題公開的一組利用路徑，CVE 編號為 CVE-2026-46333。它不是遠端未授權漏洞，也不是直接取得 root shell 的漏洞，但風險仍然很高：本地低權限使用者可能讀取本不該存取的 root 敏感檔案，例如 SSH 主機私鑰或 /etc/shadow。

對維運來說，重點不是重現 PoC，而是盡快判斷哪些機器受影響、升級核心、重新啟動生效，並在必要時輪換 SSH host keys 和重設密碼。

先說結論

這次漏洞的處置優先級很高，原因有四點：

觸發條件是本地低權限使用者，不需要 root。
已有公開 PoC，利用門檻明顯降低。
影響目標不是普通檔案，而可能是 SSH 主機私鑰和 /etc/shadow。
修復需要核心修補並重新啟動，不能只升級套件後不重啟。

如果你的伺服器有多使用者、本地 shell、共享主機、CI runner、容器宿主機、學生機房、跳板機或任何「不完全可信的本地使用者」，應該優先處理。

漏洞是什麼

Qualys 在 2026 年 5 月 15 日透過 oss-security 公開說明：他們此前向 security@kernel.org 回報了 Linux kernel __ptrace_may_access() 的邏輯問題，上游修復已由 Linus 合入。隨後社群出現公開利用程式，因此 Qualys 將資訊發到 oss-security。

Linux kernel CVE 團隊隨後為這個問題分配了 CVE-2026-46333。NVD 頁面顯示該 CVE 來源為 kernel.org，問題描述對應核心提交 ptrace: slightly saner 'get_dumpable()' logic。

簡單說，這個漏洞出現在程序退出路徑上。某些特權程序正在退出時，核心中與 ptrace 存取檢查相關的邏輯可能因目標任務已經沒有 mm，而繞過本應依賴的 dumpable 檢查。攻擊者可以在很窄的競態窗口中，取得正在退出的特權程序仍然開啟的檔案描述符。

這也是為什麼它被稱為 ssh-keysign-pwn：公開利用路徑之一會圍繞 ssh-keysign 讀取 SSH host private keys。

為什麼能讀到 SSH 主機私鑰和 /etc/shadow

這個問題本質上是本地資訊外洩。它利用的是特權程式在退出過程中「記憶體描述符已經脫離，但檔案描述符還沒關閉」的時間窗口。

AlmaLinux 的公告對風險說得比較清楚：如果特權程式在降權前開啟了敏感檔案，而攻擊者在退出窗口中成功取得對應檔案描述符，就可能讀取這些敏感檔案。

公開討論中常見的兩個目標是：

ssh-keysign：可能涉及 /etc/ssh/ssh_host_*_key 這類 SSH 主機私鑰。
chage：可能涉及 /etc/shadow。

SSH 主機私鑰外洩後，攻擊者可能偽裝成該主機，影響 SSH 主機身分信任。/etc/shadow 外洩後，攻擊者可以離線破解密碼雜湊，進一步擴大影響。

這也是為什麼它雖然不是「直接 root shell」，但仍然應按高優先級處理。

影響範圍怎麼判斷

從上游角度看，這是 Linux kernel 的漏洞。NVD 記錄顯示該問題在 2026 年 5 月 15 日進入 NVD 資料集，當時 NVD 還沒有給出 CVSS 評分。

發行版層面的狀態要以各自公告為準：

AlmaLinux 8、9、10 都發布了處理說明，並在 2026 年 5 月 16 日更新稱 patched kernels 已進入生產倉庫。
Debian security tracker 已列出 bullseye、bookworm、trixie、sid 等分支的 vulnerable/fixed 狀態和固定版本。
其他發行版需要分別查看 Ubuntu、Red Hat、SUSE、Arch、Alpine 等官方安全頁面或更新源。

不要只按核心大版本判斷是否安全。發行版會 backport 修復，同一個上游版本號在不同發行版中可能代表不同修補狀態。

應該優先處理哪些機器

建議按風險排序處理：

多使用者伺服器和共享主機。
有普通 shell 帳號的跳板機、教學機、開發機。
CI runner、建置機、託管平台宿主機。
容器宿主機和虛擬化宿主機，尤其是不完全可信 workload 共存的環境。
公開服務機器，雖然漏洞需要本地存取，但一旦 Web/RCE/弱密碼帶來低權限落點，風險會疊加。

純單使用者桌面環境風險相對低一些，但仍建議隨系統更新修復。原因很簡單：本地低權限程式碼執行在桌面上並不少見，瀏覽器、開發工具、腳本和第三方軟體都可能成為落點。

修復建議

首選方案是安裝發行版提供的修復核心並重新啟動。

不同發行版命令不同，原則相同：

更新軟體源中繼資料。
安裝包含 CVE-2026-46333 修復的 kernel 套件。
重新啟動進入新核心。
用 uname -r 和發行版安全公告核對目前執行中的核心是否已修復。

AlmaLinux 公告中提到，生產倉庫已推出修復核心，使用者可以執行常規 dnf upgrade 並重啟。Debian tracker 也列出了多個分支的 fixed versions。

需要注意：只安裝新 kernel 套件但不重啟，舊核心仍在執行，漏洞仍然存在。

臨時緩解：收緊 ptrace_scope

如果暫時不能重啟，可以先收緊 Yama 的 ptrace_scope。

Qualys 在 oss-security 後續回覆中確認，將 /proc/sys/kernel/yama/ptrace_scope 設定為 2（admin-only attach）或 3（no attach）可以阻止他們已知的公開利用路徑。但他們也說明，理論上可能存在其他利用方式，所以這只是緩解，不是修復。

臨時設定可以用：

`1`	`sudo sysctl -w kernel.yama.ptrace_scope=3`

持久化可以寫入 sysctl 設定：

`1`	`echo 'kernel.yama.ptrace_scope = 3' \| sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf`

ptrace_scope=3 會停用 ptrace attach，可能影響 gdb、strace -p 等除錯場景。如果生產環境需要除錯，可以評估使用 2。無論選哪一個，都應盡快安排核心升級和重啟。

是否需要輪換 SSH 主機金鑰

如果機器在漏洞公開前後存在以下情況，建議保守處理：

有不可信本地使用者。
有共享主機或容器/CI 多租戶環境。
有 Web 漏洞、弱密碼、供應鏈腳本等可能給攻擊者本地落點。
日誌中出現可疑本地程序、異常除錯行為或公開 PoC 檔案。
機器在修復前暴露了較長時間。

保守處置包括：

修復並重啟後輪換 SSH host keys。
更新已知主機指紋管理系統。
通知依賴該主機指紋的自動化系統。
檢查 SSH 連線告警，避免誤把合法指紋變化當成中間人攻擊，或反過來忽略真實風險。

如果懷疑 /etc/shadow 已外洩，還應評估密碼重設、禁止弱密碼、檢查是否存在可離線破解的舊雜湊。

需要監控什麼

這類漏洞利用窗口很短，傳統日誌未必能完整記錄。但仍可以關注：

普通使用者目錄下是否出現 ssh-keysign-pwn、chage_pwn 或類似 PoC 檔案。
可疑編譯行為，例如短時間內編譯陌生 C 程式。
異常存取 /etc/ssh/ssh_host_*_key、/etc/shadow 的跡象。
異常 pidfd_getfd、ptrace、除錯器相關行為。
SSH 主機指紋被外部系統回報異常。

這些訊號不能證明一定被利用，也不能證明沒有被利用。真正的優先事項仍然是補丁、重啟、憑證輪換和風險隔離。

常見誤區

第一個誤區：它不是 OpenSSH 遠端漏洞。名字裡有 ssh-keysign，但根因在 Linux kernel 的 ptrace 存取檢查邏輯，不是 sshd 遠端認證流程。

第二個誤區：沒有本地使用者就完全沒風險。漏洞確實需要本地執行條件，但很多真實攻擊鏈會先透過 Web 服務、CI、腳本、弱密碼或容器逃逸前置步驟取得低權限本地落點。

第三個誤區：設定 ptrace_scope 就夠了。它是臨時緩解，不是根本修復。核心更新和重啟仍然需要做。

第四個誤區：只要沒被拿 root 就沒事。SSH 主機私鑰和 /etc/shadow 的外洩本身就足以導致後續橫向移動、主機偽裝和離線破解風險。

處置清單

建議按這個順序執行：

盤點受影響 Linux 主機，特別是多使用者和共享環境。
查看發行版官方安全公告，確認 fixed kernel 版本。
安裝修復核心並重啟。
暫時不能重啟的機器，先設定 kernel.yama.ptrace_scope=2 或 3。
修復後核對正在執行的核心版本。
對高風險機器輪換 SSH host keys。
如果懷疑 /etc/shadow 外洩，評估密碼重設和帳號稽核。
檢查是否存在公開 PoC、異常編譯和可疑本地除錯行為。

總結

ssh-keysign-pwn（CVE-2026-46333）是一個本地資訊外洩漏洞，根因在 Linux kernel __ptrace_may_access() 相關邏輯。它不需要遠端直接打進來，也不直接給 root shell，但可以讓低權限本地使用者讀取高價值敏感檔案，這使它在多使用者、共享主機、CI 和容器宿主環境中非常值得警惕。

最可靠的修復是升級到發行版提供的修復核心並重啟。ptrace_scope=2/3 可以作為臨時緩解，但不能替代補丁。已經暴露在風險窗口中的關鍵主機，還應考慮 SSH 主機金鑰輪換和密碼風險評估。

參考連結：

Dirty Frag、Copy Fail 與 Fragnesia：近期三個 Linux 本地提權漏洞對比

Fri, 15 May 2026 13:24:04 +0800

最近 Linux 核心連續出現幾個高關注度的本地提權漏洞：Dirty Frag、Copy Fail 和 Fragnesia。它們看起來像一組「同類事件」，因為最終效果都很接近：低權限本地使用者可能把權限提升到 root。

但從維運處置角度看，不能把它們混成一個漏洞。三者的入口模組、觸發路徑、緩解方式和補丁節奏都不同。更準確的理解是：它們暴露了 Linux 核心在「頁面快取、splice、socket buffer、加密路徑」這些複雜交界處的共同風險。

本文只做風險和處置分析，不展開可復現利用步驟。

三個漏洞分別是什麼

Dirty Frag：CVE-2026-43284

Dirty Frag 主要指向 Linux 核心網路路徑裡的頁面快取寫入問題。公開資料中，它通常和兩個問題一起討論：xfrm-ESP 側的 CVE-2026-43284，以及 rxrpc 側的 CVE-2026-43500。

其中 CVE-2026-43284 與 ESP 處理共享 skb fragment 時的原地解密有關。問題的關鍵不是攻擊者直接修改磁碟檔案，而是讓核心在不該寫的共享頁面上發生寫入，進而影響頁面快取裡的檔案內容。

維運上最需要記住的是：Dirty Frag 觸達的是 esp4、esp6、rxrpc 這一組核心模組和網路子系統路徑。它和 IPsec、ESP、RxRPC 相關，臨時緩解也會圍繞這些模組展開。

Copy Fail：CVE-2026-31431

Copy Fail 是 Theori / Xint Code 披露的 Linux 核心本地提權漏洞。它的入口不在 IPsec 網路路徑，而在核心使用者態加密 API 的 algif_aead / AF_ALG 相關路徑。

公開說明中提到，它源於 2017 年引入的一處原地最佳化：某些情況下，核心沒有按預期複製資料，而是把頁面快取頁放進可寫目標路徑裡。攻擊者可以借助 AF_ALG 與 splice() 組合，對頁面快取支援的頁面做小範圍可控寫入。

它的風險點在於可利用性很強，而且影響面跨多個主流發行版。和 Dirty Frag 不同，Copy Fail 的臨時緩解重點是限制或禁用 algif_aead，以及在容器和 CI 環境中限制 AF_ALG socket。

Fragnesia：CVE-2026-46300

Fragnesia 是 V12 Security 披露的另一個 Linux 核心本地提權漏洞，和 Dirty Frag 屬於相近攻擊面。它不是 Dirty Frag 的同一個 bug，但仍然圍繞 IPsec ESP / rxrpc 相關模組，以及頁面快取寫入效果展開。

AlmaLinux 的說明把它定位為同一程式碼區域裡的第三個本地 root 問題。其關鍵點在於 skb_try_coalesce() 在合併 socket buffer 片段時沒有正確保留共享 fragment 標記，導致後續 XFRM ESP-in-TCP 接收路徑可能在外部頁面快取頁上做原地解密。

也就是說，Fragnesia 和 Dirty Frag 更接近：兩者都繞著 esp4、esp6、rxrpc、skb fragment、ESP 解密路徑轉。它們的臨時緩解也高度重疊。

相同點：為什麼都危險

這三個漏洞的共同點不是「程式碼位置完全一樣」，而是攻擊結果和風險模型非常像。

第一，它們都是本地提權。攻擊者通常需要先在機器上取得普通使用者程式碼執行能力，然後再把權限提升到 root。對單使用者桌面來說，它不是遠端一鍵入侵；但對多使用者伺服器、CI runner、容器宿主機、共享開發機和暴露 SSH 的 VPS 來說，低權限入口並不罕見。

第二，它們都和頁面快取寫入有關。攻擊者不一定永久改寫磁碟檔案，而是影響記憶體中的頁面快取副本。這會讓傳統檔案完整性檢查變得不夠可靠：磁碟 hash 可能正常，但執行路徑讀到的頁面快取內容已經被污染。

第三，它們都偏向確定性邏輯漏洞，而不是傳統意義上很吃時序的競爭條件。公開資料多次強調這類漏洞不依賴贏得 race condition。對防守方來說，這意味著「利用成功率」不能按老經驗低估。

第四，它們都放大了容器和自動化執行環境的風險。容器內的低權限程式碼、CI 任務、建置腳本、第三方外掛，一旦能觸達宿主核心相關介面，就可能把漏洞從「本地問題」變成「平台問題」。

不同點：不要用一個補丁思路套全部

三者最大的區別在入口模組。

Copy Fail 的關鍵入口是 algif_aead / AF_ALG，屬於核心使用者態加密 API。它的臨時防護重點是禁用或限制 algif_aead，以及用 seccomp 阻斷容器裡建立 AF_ALG socket。

Dirty Frag 的關鍵入口在 xfrm-ESP 和 rxrpc。它更接近網路協定和 socket buffer 處理路徑，臨時防護通常會考慮禁用 esp4、esp6、rxrpc。但這可能影響 IPsec、VPN、隧道或相關網路能力。

Fragnesia 的入口也在 Dirty Frag 相近區域，但具體問題落在 skb_try_coalesce() 沒有保留共享 fragment 標記。它更像是 Dirty Frag 風險面裡的另一個分支，而不是 Copy Fail 的加密 API 問題。

所以，不能因為已經處理了 Copy Fail，就認為 Dirty Frag 和 Fragnesia 也被覆蓋；也不能因為禁用了 esp4 / esp6，就認為 Copy Fail 自動消失。它們需要分別確認補丁狀態和緩解策略。

影響範圍該怎麼判斷

判斷這類漏洞是否受影響，不要只看發行版名字，也不要只看核心大版本號。發行版會回合補丁，雲廠商會維護自己的核心分支，企業發行版還可能有額外 backport。

更穩妥的順序是：

先看發行版安全公告和核心套件 changelog。
再核對 CVE 是否已被目前核心套件修復。
對雲主機、容器宿主機和 CI 節點，額外關注雲廠商或平台方公告。
對臨時緩解，確認業務是否依賴對應模組。
完成核心升級後安排重啟，確保實際執行核心已經切換。

這一步最容易踩坑的是「套件已經更新，但機器還沒重啟」。核心漏洞不是普通使用者態服務升級，安裝新套件之後，舊核心仍可能繼續執行。

維運優先級

這些漏洞最該優先處理的機器，不是「所有 Linux 平均排隊」，而是低權限程式碼最容易出現的地方。

優先級最高的環境包括：

多使用者登入伺服器
CI / CD runner
建置機和製品打包機
容器宿主機和 Kubernetes 節點
共享開發機
暴露 SSH 的雲主機和 VPS
執行第三方腳本、外掛、任務佇列的平台
有 Web 漏洞、弱密碼或歷史入侵痕跡的機器

相對封閉、單使用者、沒有外部程式碼執行入口的機器，風險仍然存在，但處置順序可以排在後面。

臨時緩解應該怎麼理解

臨時緩解不是補丁替代品。它的價值是幫你在無法立刻重啟或等待發行版補丁時降低暴露面。

對 Copy Fail，重點關注 algif_aead 和 AF_ALG。如果業務沒有使用核心 AF_ALG 加密介面，可以評估禁用相關模組；容器環境則應優先檢查 seccomp 策略，避免不受信任工作負載隨意建立對應 socket。

對 Dirty Frag 和 Fragnesia，重點關注 esp4、esp6、rxrpc。如果系統不依賴 IPsec ESP、相關 VPN、隧道或 RxRPC，可以評估臨時禁用。但生產環境不要盲目執行，因為這些模組可能影響真實網路業務。

最終仍然要回到核心更新。臨時緩解只能減少攻擊面，不能證明系統已經徹底安全。

這三個漏洞說明了什麼

這組漏洞真正值得警惕的地方，不只是 CVE 數量，而是它們都集中在核心高複雜度路徑：零拷貝、splice、socket buffer、頁面快取、加密介面、協定堆疊最佳化。

這些路徑的共同特點是效能收益很大，但所有權邊界也更難維護。一個 fragment 是否共享、一個頁面是否還能原地寫、一個最佳化是否真的只是減少複製，都會變成安全邊界的一部分。

對安全團隊和維運團隊來說，結論很實際：

本地提權漏洞要按「已有低權限入口會被放大」處理。
容器不是核心漏洞的天然隔離邊界。
檔案完整性檢查不能只看磁碟內容。
CI、建置機、外掛平台要當成高優先級資產。
核心補丁需要驗證「已安裝」和「已執行」兩個狀態。

小結

Dirty Frag、Copy Fail 和 Fragnesia 都是近期 Linux 本地提權風險裡的高優先級事件，但它們不是同一個漏洞的三個名字。

Copy Fail 走的是 algif_aead / AF_ALG 加密介面路徑；Dirty Frag 走的是 xfrm-ESP 與 rxrpc 相關路徑；Fragnesia 則在 Dirty Frag 相近攻擊面上，透過 skb fragment 標記處理問題再次觸發頁面快取寫入風險。

處置上，最穩妥的做法是：按發行版公告升級核心並重啟；對無法立即升級的系統，分別按漏洞入口評估臨時禁用模組或收緊 seccomp；對多租戶、CI、容器宿主機和共享開發環境優先處理。

參考資料：

Theori Copy Fail 說明：https://github.com/theori-io/copy-fail-CVE-2026-31431
CERT-EU Copy Fail 安全公告：https://cert.europa.eu/publications/security-advisories/2026-005/
AlmaLinux Dirty Frag 說明：https://almalinux.org/blog/2026-05-07-dirty-frag/
AlmaLinux Fragnesia 說明：https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
V12 Security Fragnesia PoC 說明：https://github.com/v12-security/pocs/tree/main/fragnesia

Fragnesia (CVE-2026-46300)：Linux 核心本地提權漏洞影響與緩解

Fri, 15 May 2026 13:18:01 +0800

Linux 核心最近又曝出一個和 Dirty Frag 同一類攻擊面相關的本地提權漏洞：Fragnesia (CVE-2026-46300)。

根據 V12 Security 的披露，Fragnesia 是一個 Linux 本地提權漏洞。攻擊者不需要在宿主機上已有高權限，只要能在本地執行程式碼，就可能借助核心 XFRM ESP-in-TCP 子系統中的邏輯缺陷，把唯讀檔案的頁面快取內容按位元組改寫，最終觸發 root shell。

原始資料：

V12 Security PoC 說明：https://github.com/v12-security/pocs/blob/main/fragnesia/README.md

本文不展開可復現利用步驟，只整理維運側需要知道的風險點和處置思路。

它和 Dirty Frag 是什麼關係

V12 Security 在說明中把 Fragnesia 歸到 Dirty Frag 漏洞類別裡。它不是 Dirty Frag 本身的同一個 bug，而是同一攻擊面上的另一個問題：Linux 核心的 XFRM ESP-in-TCP。

XFRM 是 Linux 核心裡處理 IPsec 的框架。ESP-in-TCP 則和透過 TCP 承載 ESP 加密流量有關。Fragnesia 的問題出在共享頁面片段和 socket buffer 合併過程中的邏輯處理：某些情況下，核心會「忘記」某個 fragment 仍然是共享狀態，進而留下可控寫入空間。

這類問題讓人聯想到 Dirty Pipe / Dirty Frag 這一類頁面快取寫入漏洞。共同點不是具體程式碼完全相同，而是都把攻擊效果落到了頁面快取裡的唯讀檔案副本上。

風險為什麼高

Fragnesia 的危險之處有三個。

第一，它是本地提權。只要攻擊者已經能在系統上執行普通使用者程式碼，就可能把權限提升到 root。對多使用者伺服器、容器宿主機、CI runner、共享開發機、VPS 和暴露 Shell 的環境來說，這類漏洞比普通桌面更敏感。

第二，它不依賴傳統競爭條件。V12 的說明中提到，該漏洞透過構造 ESP-in-TCP 處理流程，讓核心把加密流處理到已經 splice 進 socket buffer 的檔案頁面上，進而按位元組影響頁面快取內容。這意味著風險不只是「理論上可能」，而是研究團隊已經驗證了穩定利用路徑。

第三，它改的是頁面快取，不是磁碟檔案。公開說明裡的示例目標是 /usr/bin/su。利用成功後，磁碟上的檔案並不會被永久改寫，改動存在於記憶體頁面快取中。很多只檢查磁碟檔案 hash 或完整性的巡檢流程，可能看不出異常。

這也是它對管理員麻煩的地方：系統看起來檔案沒變，但一旦執行被污染頁面快取裡的目標二進位檔，就可能觸發提權效果。

已知影響範圍

V12 Security 的說明稱，受 Dirty Frag 影響且沒有套用 2026 年 5 月 13 日相關修補的核心，也會受 Fragnesia 影響。公開驗證環境包括 Ubuntu 22.04、Ubuntu 24.04，以及 6.8.0-111-generic 這類核心版本。

這裡要注意兩點。

第一，不要只看發行版大版本。Ubuntu 22.04 / 24.04 是否受影響，最終取決於核心修補狀態，而不是發行版名字。

第二，不要只看有沒有預設 AppArmor 限制。Ubuntu 對非特權使用者命名空間的 AppArmor 限制可以提高門檻，但披露方明確把它視為額外繞過問題，不是漏洞本體的根治方式。

真正可靠的判斷方式，仍然是查看發行版安全公告和核心套件更新。

臨時緩解思路

如果系統暫時不能立刻升級核心，可以先評估是否依賴相關協定模組。

V12 給出的緩解方向與 Dirty Frag 相同：如果系統不依賴 IPsec ESP 或 RxRPC，可以禁用相關模組，例如 esp4、esp6、rxrpc。這類操作會影響相關網路能力，生產環境不要盲目執行，應先確認業務是否使用 IPsec、VPN、隧道或相關核心功能。

更穩妥的處置順序是：

確認發行版是否已經發布核心安全更新。
優先安裝核心修補並安排重啟。
如果無法立即升級，再評估臨時禁用相關模組。
對多使用者系統和 CI / 建置環境優先處理。
檢查是否開放非必要本地帳號、Shell、容器逃逸面和低權限執行入口。

這裡不要把禁用模組當作最終修復。它更像是臨時降低暴露面。

如果懷疑已經被利用

Fragnesia 的一個特點是頁面快取污染。V12 在說明中強調，利用後目標檔案在頁面快取中的副本可能含有注入內容，後續執行仍可能觸發異常行為，直到頁面被驅逐或系統重啟。

如果懷疑系統已經被利用，至少要做幾件事：

盡快保留現場日誌和稽核記錄。
檢查近期異常本地登入、低權限使用者活動、可疑程序和 root shell 痕跡。
清理相關頁面快取或直接重啟。
升級到已修復核心。
對關鍵二進位檔做完整性檢查，但不要只依賴磁碟 hash。
輪換可能已經暴露的憑證和金鑰。

如果是生產伺服器，更建議把它當作一次潛在本地提權事件處理，而不是只當作普通補丁升級。

維運側該優先看哪些機器

這類漏洞優先級最高的不是所有 Linux 機器平均處理，而是先看攻擊者最容易拿到低權限程式碼執行的地方。

優先級較高的環境包括：

多使用者登入伺服器
CI / CD runner
建置機
共享開發機
容器宿主機
VPS 和雲主機
暴露 SSH 的邊緣節點
執行第三方腳本或外掛的平台

相對封閉、單使用者、沒有外部程式碼執行入口的機器，風險仍然存在，但緊急程度可以低一些。

小結

Fragnesia 值得關注，不是因為它名字新，而是因為它再次把 Linux 本地提權問題拉回到頁面快取和核心網路子系統這一類複雜交界處。

對管理員來說，最重要的不是研究利用細節，而是確認核心修補狀態、評估是否依賴 ESP / RxRPC、對高暴露機器優先升級，並理解「磁碟檔案沒變」不等於「系統沒有被影響」。

如果系統受影響，最終答案仍然是盡快安裝發行版提供的核心更新。臨時禁用模組只能算過渡措施，不能替代補丁。

Dirty Frag CVE-2026-43284：Linux 本地提權漏洞風險與緩解指南

Sat, 09 May 2026 07:25:55 +0800

Dirty Frag 是 2026 年 5 月公開並已出現利用跡象的一組 Linux 內核本地提權漏洞。Microsoft 將其描述為攻擊者在已經獲得低權限執行能力後，用來把權限提升到 root 的後滲透風險；Ubuntu 也將 CVE-2026-43284 標為 High。

這類漏洞最危險的地方不在「遠端直接打進來」，而在「進來以後迅速擴大控制權」。一旦攻擊者透過弱 SSH 帳號、WebShell、容器逃逸、低權限服務帳號或釣魚後的遠端存取拿到本地執行機會，就可能利用 Dirty Frag 取得 root，進而關閉安全工具、讀取敏感憑證、篡改日誌、橫向移動或建立持久化。

Dirty Frag 涉及哪些 CVE

目前公開資訊裡，Dirty Frag 主要關聯兩個編號：

CVE-2026-43284：涉及 Linux 內核 xfrm/ESP 路徑，Microsoft 提到的 esp4、esp6 元件屬於這一類風險。
CVE-2026-43500：Microsoft 稱其與 rxrpc 相關，但截至 2026 年 5 月 8 日，該 CVE 在 NVD 尚未正式發布，修補狀態也仍在變化。

因此，實際排查時不要只盯一個 CVE。更穩妥的思路是同時關注 esp4、esp6、rxrpc 以及相關 xfrm/IPsec 功能是否啟用、是否需要、是否已有發行版內核修補。

技術原因簡單理解

根據 Microsoft 和 Ubuntu 的說明，CVE-2026-43284 與 Linux 內核網路和記憶體碎片處理有關，尤其是 ESP/IPsec 路徑中對共享頁面片段的處理。

更具體地說，某些場景下，資料頁可能透過 splice 等機制被掛到網路緩衝區裡。如果內核後續路徑把這些片段當成可以原地修改的私有資料處理，就可能在不該寫的位置發生原地解密或修改。攻擊者可以藉此操縱 page cache 行為，最終達到本地提權。

這和此前披露的 CopyFail（CVE-2026-31431）有相似背景：都圍繞 Linux page cache、內核資料路徑和本地提權展開。Dirty Frag 的危險點在於，它引入了更多攻擊路徑，可能比傳統依賴競態窗口的 LPE 更穩定。

哪些環境需要優先關注

Dirty Frag 是本地提權漏洞，所以前提是攻擊者已經能在目標機器上執行程式碼。需要優先關注的環境包括：

暴露 SSH 的 Linux 伺服器。
執行 Web 應用、可能被寫入 WebShell 的伺服器。
多使用者登入、跳板機、開發機、CI/CD runner。
容器宿主機、Kubernetes 節點、OpenShift 節點。
使用 IPsec、VPN、xfrm、RxRPC 相關功能的系統。
執行 Ubuntu、RHEL、CentOS Stream、AlmaLinux、Fedora、openSUSE 等主流發行版的伺服器。

如果你的伺服器完全沒有本地多使用者、沒有容器、沒有暴露可被利用的應用入口，風險會低一些；但只要存在「攻擊者可能拿到低權限 shell」的路徑，就應該把它作為高優先級內核漏洞處理。

先做修補優先

最穩妥的修復方式永遠是安裝發行版提供的內核安全更新，並重啟進入新內核。

Ubuntu 的 CVE 頁面顯示，CVE-2026-43284 發布於 2026 年 5 月 8 日，優先級為 High。Microsoft 也指出 Linux Kernel Organization 已經發布 CVE-2026-43284 相關修復，並建議盡快應用補丁。

實際操作建議：

1
2

uname -a
cat /etc/os-release

然後按發行版更新內核：

`1`	`sudo apt update && sudo apt full-upgrade`

或：

`1`	`sudo dnf update`

更新後務必確認已重啟到新內核：

`1`	`uname -r`

只安裝內核包但不重啟，舊內核仍在執行，漏洞依然可能存在。

臨時緩解：停用相關模組

如果補丁尚未可用，或生產環境不能立即重啟，可以先評估是否能臨時停用相關模組。Ubuntu 給出的緩解思路是阻止 esp4、esp6、rxrpc 載入，並卸載已經載入的模組。

建立 modprobe 停用規則：

1
2
3

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

更新 initramfs，避免早期啟動階段載入：

`1`	`sudo update-initramfs -u -k all`

卸載已載入模組：

`1`	`sudo rmmod esp4 esp6 rxrpc 2>/dev/null`

確認模組是否仍在：

`1`	`grep -qE '^(esp4\|esp6\|rxrpc) ' /proc/modules && echo "Affected modules are loaded" \|\| echo "Affected modules are NOT loaded"`

如果模組正在被業務使用，可能無法卸載，重啟後停用規則才會生效。

停用前一定要評估業務影響

不要把上面的緩解命令當成無腦複製貼上。esp4、esp6 和 xfrm/IPsec 相關功能可能被 VPN、隧道、加密網路、Kubernetes/容器網路或特定企業網路設定使用。rxrpc 也可能影響依賴該協議的場景。

在生產環境執行前，至少確認：

1
2
3

lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

如果你依賴 IPsec VPN 或相關內核網路功能，停用模組可能直接導致連線中斷。此時更推薦盡快安排內核補丁和維護窗口，而不是長期依賴停用模組。

入侵後檢查不能省

Microsoft 特別提醒，緩解措施不一定能撤銷已經發生的成功利用。攻擊者如果已經拿到 root，可能留下持久化、篡改檔案、修改日誌或存取 session 資料。

建議至少檢查：

journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

還應重點關注：

異常 su、sudo、SUID/SGID 行程啟動。
近期新增的 ELF 可執行檔。
Web 目錄下的可疑 PHP、JSP、ASP 檔案。
SSH authorized_keys 是否被改動。
systemd service、cron、rc.local 是否新增持久化。
容器宿主機是否有異常特權容器或掛載。

如果懷疑已經被利用，優先隔離主機、保留證據、輪換憑證，再做清理。不要只靠卸載模組或清 cache 就認為安全。

關於 drop_caches

Microsoft 文中提到，在某些入侵後完整性驗證場景，可以評估是否清理 cache：

`1`	`echo 3 \| sudo tee /proc/sys/vm/drop_caches`

但這不是漏洞修復命令，也不是入侵清理命令。清 cache 可能帶來額外磁碟 I/O 和生產效能影響，只適合在理解影響後作為輔助操作。真正的修復仍然是打補丁、重啟、檢查完整性和排查持久化。

總結

Dirty Frag 不是一個「遠端一鍵打穿」的漏洞，但它會顯著放大已經入侵後的風險。只要攻擊者能獲得本地低權限執行機會，就可能藉助 CVE-2026-43284 以及相關 rxrpc 攻擊面把權限提升到 root。

對管理員來說，重點不是研究 PoC，而是盡快完成三件事：確認內核是否受影響，安裝發行版安全更新並重啟；在補丁窗口前評估停用相關模組；對已經暴露或疑似被入侵的系統做完整性和持久化檢查。

參考連結：

Btrfs Scrub 使用指南：資料校驗、自動修復與定期巡檢

Sat, 09 May 2026 07:11:01 +0800

Btrfs scrub 是 Btrfs 日常維護裡最重要、也最容易被誤解的功能之一。它不是傳統意義上的 fsck，而是一種線上校驗流程：讀取檔案系統中的資料和 metadata，驗證校驗和、superblock、metadata block header 以及磁碟讀取錯誤，並在有可靠副本時嘗試修復損壞。

如果你的 Btrfs 用在 NAS、家用伺服器、備份碟或多碟陣列上，scrub 應該成為定期巡檢的一部分。它的價值不是「等出事再修」，而是在磁碟還能讀、陣列還有好副本的時候，盡早發現靜默損壞。

scrub 到底檢查什麼

根據 Btrfs 官方文件，scrub 會遍歷檔案系統資料和 metadata，主要檢查：

資料區塊校驗和錯誤。
基礎 super block 錯誤。
基礎 metadata block header 錯誤。
磁碟讀取錯誤。

在使用複製型 block group profile 的檔案系統上，例如 RAID1，讀寫掛載下的 scrub 可以自動修復部分損壞。修復方式不是「憑空恢復」，而是從另一個已驗證正確的副本複製好資料回來。

這點很關鍵：scrub 的修復能力依賴「存在可用的好副本」。如果單碟上只有一份資料，scrub 可以發現校驗錯誤，但通常無法自行恢復原始內容。

常用命令

對掛載點啟動 scrub：

`1`	`sudo btrfs scrub start /`

以前台方式執行，適合手動觀察結果：

`1`	`sudo btrfs scrub start -B /`

查看狀態：

`1`	`sudo btrfs scrub status /`

取消正在執行的 scrub：

`1`	`sudo btrfs scrub cancel /`

恢復被中斷的 scrub：

`1`	`sudo btrfs scrub resume /`

如果指定的是 Btrfs 掛載路徑，Btrfs 會平行 scrub 該檔案系統裡的所有裝置。如果指定的是某個裝置，則只 scrub 該裝置；但當指定裝置上的副本讀取或校驗失敗時，Btrfs 仍會嘗試從其他裝置讀取好副本。

scrub 不是 fsck

這是最容易踩坑的地方。scrub 不是 btrfs check，也不是傳統意義上的檔案系統檢查器。

scrub 能做的是：

利用校驗和發現資料或 metadata 損壞。
在有其他可靠副本時自動修復。
發現磁碟讀取錯誤和部分基礎結構錯誤。

scrub 不能做的是：

重建沒有好副本的資料。
替代離線檔案系統檢查。
修復所有複雜的樹結構損壞。
保證應用層檔案內容一定正確。

如果檔案系統結構已經嚴重損壞，通常需要在專家指導下使用 btrfs check 等工具。不要把 scrub 當成「萬能修復命令」。

NOCOW 檔案的風險

Btrfs 官方文件特別提醒：對檔案設定 NOCOW 屬性，也就是常見的 chattr +C，目前實作中會隱式啟用 NODATASUM。這意味著這些檔案的資料本身沒有校驗和。

scrub 仍然可以校驗和修復這些檔案的 metadata，但不能校驗檔案資料內容。問題在多副本場景裡尤其明顯：如果某個 NOCOW 檔案的一個副本壞了，Btrfs 沒有資料校驗和判斷哪個副本是好的，就可能把壞內容返回給使用者空間工具。

需要特別注意的是，一些軟體會預設使用 +C 來提升效能。例如 systemd journal 和部分 libvirt 儲存池場景可能會設定 NOCOW。對於虛擬機映像、資料庫、日誌目錄，這種做法有效能理由，但也意味著你不能期待 scrub 像保護普通 COW 檔案那樣保護它們的資料內容。

唯讀 scrub 也可能寫入

另一個反直覺點是：在讀寫掛載的檔案系統上執行 read-only scrub，仍然可能導致一些寫入。

官方文件說明，這是為了避免 block group 標記唯讀和寫回 block group items 之間的競態。換句話說，如果你希望 scrub 過程中完全沒有寫入，就需要在唯讀掛載的檔案系統上執行唯讀 scrub，而不是在讀寫掛載上加一個唯讀 scrub 選項就完事。

對普通使用者來說，這意味著：

日常線上 scrub 可以在讀寫掛載上執行。
如果你在做取證、故障分析或極度保守的唯讀檢查，要先明確掛載狀態。
不要把 read-only scrub 誤解成絕對零寫入。

中斷與恢復

新內核中，scrub 可能被多種事件中斷，例如系統掛起/休眠、檔案系統凍結、cgroup freezing、pending signals 等。被中斷後，正在執行的 scrub 會取消，但可以透過 btrfs scrub resume 從保存的位置繼續。

scrub 狀態會記錄在：

`1`	`/var/lib/btrfs/`

檔案名通常類似：

1
2

scrub.status.UUID
scrub.progress.UUID

狀態檔案會定期更新。恢復 scrub 時，會從最後保存的位置繼續，而不是完全從頭再來。

建議多久跑一次

官方建議的週期是每月一次，實際可以根據資料重要性和磁碟狀態調整。

比較常見的安排是：

家用 NAS：每月一次。
備份碟：每次長期接入後或每月一次。
重要多碟陣列：每月一次，必要時更頻繁。
新碟遷移或懷疑壞碟：遷移後立即跑一次。

scrub 在空閒檔案系統上的裝置頻寬利用率可能接近 80%，所以不要在業務高峰期跑。對機械碟陣列，scrub 期間延遲可能明顯升高；對 SSD，也會增加讀放大和後台壓力。

限制 scrub 頻寬

過去可以用 ionice 嘗試降低 scrub 對前台 I/O 的影響，但官方文件提醒，並不是所有 I/O 調度器都支援這種方式。CFQ 已經不再是主流；BFQ 支援相關優先級，但使用前應先理解其行為。對 mq-deadline 等常見調度器，更推薦使用 cgroup2 I/O controller 或 Btrfs 自帶的限速介面。

使用 systemd 限制讀取頻寬的例子：

`1`	`sudo systemd-run -p "IOReadBandwidthMax=/dev/sdx 10M" btrfs scrub start -B /`

Linux 5.14 以後，可以透過 Btrfs 專用 sysfs 介面設定每裝置 scrub 限速：

`1`	`echo 100m \| sudo tee /sys/fs/btrfs/FSID/devinfo/DEVID/scrub_speed_max`

查看目前限制：

`1`	`sudo btrfs scrub limit /`

注意這個設定不是永久的，檔案系統卸載後會失效。實際路徑裡的 FSID 和 DEVID 要按你的系統替換，可以先查看：

1
2

sudo btrfs filesystem show /
ls /sys/fs/btrfs/

實用維護流程

一個比較穩妥的 Btrfs 巡檢流程可以是：

sudo btrfs scrub start -B /
sudo btrfs scrub status /
sudo btrfs device stats /
dmesg -T | grep -Ei "btrfs|checksum|i/o error|read error"

如果 scrub 報告有 corrected errors，說明已經從好副本修復過資料，但這不代表可以忽略。你應該繼續檢查磁碟 SMART、線材、電源、控制器和 Btrfs device stats。

如果 scrub 報告 uncorrectable errors，說明 Btrfs 找不到可用好副本，必須盡快備份仍能讀取的資料，定位具體檔案或裝置，並根據情況替換硬碟或從備份恢復。

總結

Btrfs scrub 的定位很明確：它是線上資料巡檢和副本修復工具，不是 fsck，也不是備份。

它最適合用在有校驗和、有冗餘副本的 Btrfs 檔案系統上，定期發現靜默損壞並自動從好副本恢復。它不能保護沒有校驗和的 NOCOW 檔案資料，也不能在沒有好副本時憑空恢復損壞內容。

如果你使用 Btrfs 存重要資料，建議每月跑一次 scrub，配合 SMART、device stats、備份和告警一起使用。真正可靠的資料安全，永遠是校驗、冗餘、監控和備份一起工作，而不是只依賴某一個命令。

參考連結：

Btrfs 官方文件：Scrub

F2FS 導致 HC620 疊瓦碟卡死？Linux SMR 硬碟排障指南

Fri, 08 May 2026 22:34:39 +0800

HC620 這類氦氣封裝疊瓦碟配合 F2FS 使用時，如果出現系統卡住、應用程式無回應、iowait 長時間飆高，通常不是單一參數沒調好，而是裝置特性和檔案系統策略撞在了一起。

Western Digital Ultrastar DC HC620 屬於 Host-managed SMR。它更適合順序寫、分區化寫入和明確知道底層約束的軟體棧。F2FS 則是為快閃記憶體設計的日誌結構檔案系統，雖然能把很多隨機寫組織成順序寫，但在空間緊張、垃圾回收頻繁或 metadata 更新密集時，仍然可能把機械疊瓦碟拖進很長的內部整理週期。

先確認是不是這類問題

建議先看三個現象：

1
2
3

iostat -x 1
iotop -oPa
dmesg -T | grep -Ei "f2fs|blk|zoned|reset|timeout|I/O error"

如果能看到磁碟 %util 長時間接近 100%，await 很高，系統裡大量行程卡在 D 狀態，基本可以判斷瓶頸在區塊裝置 I/O。

再確認硬碟是否以 zoned 裝置暴露：

1
2

lsblk -o NAME,MODEL,SIZE,ROTA,ZONED,SCHED,MOUNTPOINTS
cat /sys/block/sdX/queue/zoned

如果是 Host-managed SMR，普通檔案系統和普通隨機寫負載都可能表現很差。它不像常見的桌面 SMR 碟那樣完全由硬碟韌體隱藏複雜度，而是更依賴主機端軟體理解寫入規則。

為什麼 F2FS 容易把卡頓放大

SMR 的問題在於寫入不是任意覆蓋那麼簡單。疊瓦磁軌為了提高容量，會讓相鄰磁軌部分重疊；當寫入模式偏隨機、覆蓋頻繁或快取耗盡時，硬碟需要做額外的資料搬運和整理。

F2FS 的問題在於它本來面向 NAND flash。它採用日誌結構寫入，並透過 segment cleaning 和 garbage collection 回收空間。這個設計在 SSD 上通常很自然，因為 SSD 沒有機械尋道；但在機械硬碟上，尤其是 SMR 碟上，GC 產生的讀寫搬運可能變成明顯的長尾延遲。

當 F2FS 後台 GC、前台寫入、checkpoint、metadata 更新和硬碟自身的 SMR 整理疊在一起時，I/O 佇列會被持續占滿。表現到使用者層，就是複製檔案、刪除目錄、跑下載、解壓縮或資料庫寫入時系統像「凍住」一樣。

掛載參數先這樣保守調整

如果暫時不能遷移檔案系統，可以先從 /etc/fstab 的掛載參數下手：

`1`	`UUID=xxxx /data f2fs defaults,nodiscard,active_logs=2,gc_merge,flush_merge,lazytime 0 0`

幾個參數的含義：

nodiscard：關閉即時 discard。機械硬碟通常不需要像 SSD 那樣頻繁發送 TRIM/discard，保守關閉更穩。
active_logs=2：F2FS 支援 2、4、6 個 active logs，預設通常是 6。降到 2 可以減少日誌並發帶來的尋道壓力。
gc_merge：讓後台 GC 執行緒處理部分前台 GC 請求，降低前台行程直接觸發慢 GC 時的卡頓。
flush_merge：合併 cache flush 請求，底層裝置處理 flush 很慢時可能有幫助。
lazytime：減少部分存取時間更新帶來的 metadata 寫入。

checkpoint=disable 不建議作為常規方案。它確實可能減少 checkpoint 壓力，但在異常斷電或崩潰後風險更高，而且內核文件也提醒，停用 checkpoint 後檔案系統仍需要 GC 來確保可用空間。除非你非常清楚代價，否則不要把它當成「效能開關」長期使用。

調整 I/O 調度器

機械碟和 SMR 碟通常更需要請求合併與延遲控制。可以先查看目前調度器：

`1`	`cat /sys/block/sdX/queue/scheduler`

可嘗試切換到 mq-deadline：

`1`	`echo mq-deadline \| sudo tee /sys/block/sdX/queue/scheduler`

如果系統用於桌面互動，也可以測試 bfq。不要只看順序吞吐，重點觀察卡頓是否減少、await 是否下降、互動是否更穩定。

限制 F2FS 後台 GC

F2FS 的 sysfs 路徑以實際裝置名為準，先確認：

`1`	`ls /sys/fs/f2fs/`

然後針對對應掛載裝置調整 GC 間隔，例如：

1
2

echo 60000 | sudo tee /sys/fs/f2fs/sdX/gc_min_sleep_time
echo 120000 | sudo tee /sys/fs/f2fs/sdX/gc_max_sleep_time

這裡的 sdX 只是示例，實際可能是 sda1、dm-0 或其他名稱。調大 GC sleep time 的作用是降低後台 GC 搶占 I/O 的頻率，但代價是空間回收更慢。磁碟空間越接近滿碟，越容易再次觸發前台 GC，所以還要留出足夠空閒空間。

更推薦的長期方案

如果這塊碟存重要資料，最穩妥的方案是備份後換檔案系統，或者換更適合的硬碟。

對大容量機械硬碟，優先考慮：

XFS：適合大檔案、備份碟、媒體庫、歸檔和順序寫負載。
EXT4：相容性強，行為穩定，排障資料多。

如果是 Host-managed SMR，還要確認你的內核、控制器、檔案系統和應用是否真正支援 zoned block device 的使用方式。否則，把它當成普通隨機寫硬碟用，很容易遇到不可預測的長時間卡頓。

實用建議

這類碟更適合冷資料、歸檔、備份、媒體檔案和順序寫入，不適合下載快取、容器映像、虛擬機磁碟、資料庫、頻繁解壓縮目錄或小檔案隨機寫。

如果必須繼續用 F2FS，建議至少做到：

關閉即時 discard。
active_logs=2，減少並發日誌。
開啟 gc_merge 和 flush_merge。
保持較高空閒空間，不要接近滿碟。
避免把下載目錄、資料庫、虛擬機映像放在這塊碟上。
定期觀察 iostat -x 1，不要只看平均速度。

總結一下：HC620 + F2FS 卡死，本質上是 SMR 寫入約束、F2FS GC 和機械碟長尾延遲疊加後的結果。臨時方案是調掛載參數、調調度器、限制後台 GC；長期方案是遷移到 XFS/EXT4，或者把這類 SMR 碟放回更適合它的順序寫歸檔場景。

參考連結：

Canonical Ubuntu AI 路線圖：本地推理優先，拒絕強制整合

Fri, 08 May 2026 22:23:46 +0800

Canonical 最近披露的 Ubuntu AI 路線圖，最值得注意的地方不是「Ubuntu 要把 AI 強塞進系統」，而是它正在嘗試一條更謹慎的路線：AI 功能按層提供、預設關閉、使用者明確選擇後才啟用，並優先把推理放在本地完成。

這和 Windows、macOS 上一些圍繞系統級 AI 的爭議形成對比。Ubuntu 的方向不是做一個無法避開的全域 AI 層，也不是替系統加一個統一的「AI 總開關」，而是把 AI 能力拆成相對獨立的工具，讓使用者自己決定是否安裝、是否啟用、接入哪個模型，以及資料是否離開本機。

先釐清時間線：不是 Ubuntu 26.04 LTS

這次路線圖真正指向的是 Ubuntu 26.10 “Questing Quokka”，預計在 2026 年 10 月 9 日發布。Canonical 的計畫是先以實驗性、預覽性的方式加入部分 AI 工具，而不是把它們塞進 Ubuntu 26.04 LTS。

這點很關鍵。LTS 版本承擔的是長期穩定、企業部署和安全維護，Canonical 不太可能把仍在探索階段的桌面 AI 能力直接作為預設體驗放進去。更合理的路徑是先在 26.10 這樣的常規版本裡試水，讓開發者和早期使用者回饋，再決定哪些能力適合進入後續長期支援版本。

本地推理優先，雲端不是預設選項

Canonical 強調的核心原則之一，是 local inference first，也就是預設優先在本機執行推理。只有使用者主動設定雲端提供商、自架伺服器或企業模型服務時，請求才會離開本機。

這背後的邏輯很現實：系統級 AI 很容易接觸到命令列輸出、日誌、檔案路徑、錯誤訊息、系統設定等敏感內容。如果這些資訊被自動送往雲端，即使只是為了「幫你解釋錯誤」，也會帶來明顯的隱私和合規風險。

因此，Ubuntu 的 AI 路線並不是「雲端 AI 系統入口」，而更像是一套可插拔的推理層。使用者可以選擇本地模型，也可以選擇公司內部的推理服務，或者在需要時接入 Canonical 管理的服務。重點不在於綁定某一家模型廠商，而在於讓系統有能力呼叫不同後端。

AI CLI：先從終端助手開始

最先落地的能力之一，可能是面向終端使用者的 AI Command Line Helper，也就是常被提到的 ai-cli。

它的定位不是替代 shell，也不是自動替你執行危險命令，而是幫助使用者理解命令、日誌、systemd 單元、錯誤輸出和系統狀態。比如你遇到一段複雜的服務啟動失敗日誌，它可以解釋可能的原因；你不確定某條命令的參數含義，它可以給出更直觀的說明。

這種入口很符合 Ubuntu 的使用者結構。Ubuntu 桌面使用者和伺服器使用者裡，有大量人本來就依賴終端工作。與其先做一個花俏的聊天視窗，不如把 AI 放在錯誤排查、命令解釋和維運輔助這些高頻場景裡。

不過，這也意味著安全邊界必須非常清楚。日誌裡可能包含 token、內網位址、使用者名稱、路徑、金鑰片段和業務資訊。即使預設本地推理，工具也應該盡量提醒使用者先做脫敏；如果使用者選擇雲端後端，更要明確哪些內容會被送出。

Settings Agent：自然語言控制系統設定

另一個方向是 Settings Agent，也就是讓使用者用自然語言查詢或調整系統設定。

這類功能看起來簡單，實際很容易踩坑。一個成熟的 Settings Agent 不應該靠「讀螢幕、猜按鈕、模擬點擊」來操作系統設定，而應該有受控的內部 API：能讀哪些設定、能改哪些設定、修改前是否需要確認、失敗後如何回滾，都需要有清楚邊界。

所以它更像是 26.10 之後繼續推進的方向，而不是馬上完整交付的功能。對桌面 Linux 來說，這部分如果做得好，會顯著降低一般使用者調整系統的門檻；如果做得太激進，則可能變成新的安全風險。

為什麼不需要一個「AI 總開關」

很多使用者擔心系統廠商加入 AI 後，會出現一種「到處都是 AI、關也關不乾淨」的體驗。因此有人自然會問：Ubuntu 是否應該提供一個全域 AI kill switch？

Canonical 的回答思路是：如果 AI 功能本身就是 opt-in、分層、可獨立安裝和設定的，那麼全域 kill switch 就不是第一優先級。也就是說，它試圖從設計上避免「預設開啟、深度嵌入、使用者再去關閉」的問題。

這個判斷是否足夠，還要看後續實作。原則上，只要 AI 工具不預設啟用、不預設連網、不預設收集資料，並且每個功能都有清楚的開關和設定入口，那麼使用者就不需要為了關閉 AI 到處找隱藏選項。

對開發者和企業使用者的意義

對開發者來說，AI CLI 這類工具最實際的價值，是減少查文件、讀日誌、定位系統問題的時間。它不是替代工程判斷，而是把大量「我先幫你解釋一下這段輸出」的工作自動化。

對企業使用者來說，本地推理和可插拔後端更重要。很多公司不能把原始碼、日誌、客戶資料或基礎設施資訊送到公共大模型服務。Ubuntu 如果能把系統級 AI 和本地模型、私有推理服務、企業權限體系結合起來，就能在合規環境裡提供更可控的智慧輔助。

這也是 Linux 桌面和工作站的一個機會。Windows 和 macOS 更容易把 AI 做成廠商生態的一部分，而 Ubuntu 的優勢在於開放、可審計、可替換、可自架。如果 Canonical 能把這些原則保留下來，AI 反而可能成為 Linux 專業使用者體驗的一次補強。

不要過度解讀

目前還不適合把這條路線解讀成「Ubuntu 會預裝某個小模型」「Ubuntu 26.04 會內建 AI 審計模式」或「未來會有一個固定的 ubuntu-ai 命令」。公開資訊裡更確定的是方向，而不是完整產品形態。

更穩妥的理解是：Canonical 正在為 Ubuntu 引入一套系統級 AI 工具框架，先從命令列、設定輔助、本地推理和後端選擇這些場景開始；預設策略是使用者主動選擇，而不是系統替使用者選擇。

總結

Ubuntu 的 AI 路線圖真正值得關注的，不是它終於也要「加入 AI 大潮」，而是它試圖給開源作業系統定義一套更克制的 AI 整合方式：智慧可以成為基礎設施，但隱私、可控性和使用者選擇權必須放在前面。

如果 26.10 的實驗性功能能兌現這些原則，Ubuntu 可能會走出一條和消費級系統不同的路線：不把 AI 做成無法迴避的系統廣告位，而是做成使用者可選擇、可替換、可審計的生產力工具。

參考連結：

2026 年 Linux 桌面發行版怎麼選：Ubuntu、Deepin/UOS、Linux Mint 和 Fedora 對比

Thu, 07 May 2026 21:17:11 +0800

2026 年選 Linux 桌面發行版，重點不是誰最「純」，也不是誰最「先進」，而是誰能讓你每天順手用下去。

桌面端和伺服器不同。伺服器更看重生命週期、套件穩定性和維運規範；桌面端還要看介面、驅動、應用商店、輸入法、辦公軟體、顯卡、藍牙、聲音、觸控板、外接顯示器和日常小毛病。

如果你只想少折騰，優先看 Ubuntu、Linux Mint 和 Deepin/UOS。如果你是開發者，願意用更新的軟體棧和更快的新技術節奏，Fedora 更值得關注。

快速結論

發行版	最適合	主要優點	主要注意點
Ubuntu 26.04 LTS	新手、開發者、主力桌面	文件最多，生態完整，硬體和軟體支援好	預設 GNOME 需要適應，Snap 策略不是所有人都喜歡
Deepin / UOS	中文使用者、國產化環境、重視介面體驗	美觀易用，中文本地化好，國產軟體和政企相容性強	社群版和商業版定位不同，更新策略要分清
Linux Mint	Windows 轉 Linux、穩定優先使用者	介面親切，極易上手，Cinnamon 穩定	新技術節奏慢，預設軟體棧不激進
Fedora	開發者、Linux 新技術體驗者	新內核、新 GNOME、新技術推進快	更新頻率高，對穩定保守使用者不如 LTS 舒服

一句話：

新手和主力桌面：Ubuntu 26.04 LTS。
中文和國產化體驗：Deepin / UOS。
Windows 使用者平滑遷移：Linux Mint。
開發者和新技術嘗鮮：Fedora。

Ubuntu 26.04 LTS：全能型桌面

Ubuntu 26.04 LTS Resolute Raccoon 已在 2026 年 4 月發布。作為 LTS 版本，它適合用作長期主力桌面。

Ubuntu 的優勢非常直接：資料最多，教程最多，遇到問題最容易搜到答案。無論你要裝 VS Code、Docker、NVIDIA 驅動、Steam、Chrome、Slack、JetBrains、CUDA、Python、Node.js，Ubuntu 基本都是廠商和社群優先覆蓋的目標。

Ubuntu 26.04 LTS 適合這些人：

第一次認真使用 Linux 桌面；
想找一個能長期用的主力系統；
開發工作需要穩定的 Linux 環境；
需要大量教程、驅動和商業軟體支援；
想兼顧桌面、伺服器和 WSL 生態。

它的優點：

LTS 生命週期長；
官方映像和文件成熟；
GNOME 桌面現代，觸控板和多顯示器體驗較好；
驅動、雲、容器和開發工具生態完整；
出問題時搜尋成本最低。

需要注意的是，Ubuntu 預設使用 GNOME，和 Windows 桌面邏輯不同。新手可能需要適應活動概覽、Dock、工作區和應用啟動器。Ubuntu 也長期推動 Snap，一些使用者不喜歡 Snap 的啟動速度、套件管理方式和生態策略。

我的判斷：如果你不知道該選哪個桌面發行版，Ubuntu 26.04 LTS 仍然是最安全的預設答案。它不是每個方向都最極致，但綜合分最高。

Deepin / UOS：中文桌面體驗和國產化相容

Deepin 和 UOS 的優勢，在於它們更理解中文桌面使用者。

Deepin 25 已在 2025 年發布，2026 年繼續透過 deepin 25.1 等版本更新。官方說明中，deepin 25 重點包括 DDE 桌面環境最佳化、UOS AI、Solid 不可變系統、Linyaps 應用相容方案、Distrobox 子系統和 Treeland 視窗合成器預覽。

這些方向說明 Deepin/UOS 不只是「做一個漂亮 Linux 皮膚」，而是在嘗試解決中文桌面長期痛點：

應用安裝和依賴衝突；
國產軟體相容；
桌面美觀和易用；
系統更新失敗回滾；
中文輸入、辦公、政企軟體生態；
Windows 應用相容和過渡。

Deepin / UOS 適合這些人：

更重視中文介面、輸入法、辦公和本地化體驗；
想要開箱即用、介面漂亮的 Linux 桌面；
需要在國產化軟硬體環境中使用；
需要政企辦公、國產軟體、國產 CPU 或相容認證；
不想從零配置 GNOME/KDE。

Deepin 的優點：

DDE 介面統一，美觀度高；
中文使用者體驗細節更好；
應用商店和系統設定更接近普通使用者習慣；
Linyaps、Distrobox 等方案有助於緩解 Linux 應用相容問題；
UOS 商業版本在國產化場景中更有現實意義。

需要注意的是，Deepin 社群版和 UOS 商業版不是完全同一個定位。Deepin 更適合個人體驗和社群使用者，UOS 更偏政企、國產化、商業服務和認證環境。對於生產辦公環境，要看硬體、軟體和單位要求，不要只看介面。

我的判斷：如果你是中文使用者，尤其重視外觀、輸入法、國產軟體和辦公體驗，Deepin/UOS 的吸引力很強。但如果你是重度開發者，且依賴最標準的上游 Linux 生態，Ubuntu 或 Fedora 可能更順手。

Linux Mint：最像 Windows，也最省心

Linux Mint 的定位一直很穩定：讓普通使用者輕鬆用 Linux。

截至 2026 年，Linux Mint 主線仍然圍繞 22.x 系列推進，基於 Ubuntu 24.04 LTS。Linux Mint 22.3 Zena 已在 2026 年初發布。它不是最新技術展示台，而是一個穩定、熟悉、低學習成本的桌面系統。

Linux Mint 最適合 Windows 使用者遷移，尤其是 Cinnamon 桌面：

左下角選單；
工作列；
系統匣；
視窗最小化/最大化邏輯；
設定面板；
檔案管理器；
更新管理器。

這些細節讓它很像傳統 Windows 桌面。對於不想適應 GNOME 工作流的人，Linux Mint 比 Ubuntu 更容易上手。

Linux Mint 適合這些人：

從 Windows 遷移到 Linux；
給父母、家人或非技術使用者裝 Linux；
想要穩定桌面，不追新技術；
主要用途是瀏覽器、辦公、影片、檔案管理和輕開發；
不喜歡 GNOME，也不想折騰 KDE。

它的優點：

Cinnamon 桌面直觀；
更新管理器友好；
系統保守穩定；
對舊電腦更友好；
社群資料多，問題相對少。

需要注意的是，Linux Mint 不是新技術優先。Wayland、PipeWire、最新 GNOME/KDE、最新內核、最新 Mesa 這些東西，它通常不會衝在最前面。它追求的是「今天能穩定工作」，不是「第一時間用上最新 Linux 桌面技術」。

我的判斷：如果你想把 Windows 筆電改成 Linux，又不想解釋太多概念，Linux Mint 是最穩的選擇之一。它沒有 Ubuntu 那麼強的商業生態，也沒有 Fedora 那麼新，但日常體驗非常踏實。

Fedora：開發者和新技術優先

Fedora 是桌面 Linux 新技術的前沿陣地之一。

截至 2026 年 5 月，Fedora 當前主線版本是 Fedora Linux 44。Fedora Workstation 一直是 GNOME、Wayland、PipeWire、Mesa、內核、systemd 等新技術較早落地的發行版之一。

Fedora 適合這些人：

Linux 開發者；
GNOME 使用者；
想盡早用到新內核、新 Mesa、新編譯器和新工具鏈；
想體驗 Wayland、PipeWire、Flatpak 等現代 Linux 桌面棧；
不害怕半年一次升級。

Fedora 的優點：

新技術推進快；
預設系統相對乾淨；
GNOME 體驗接近上游；
開發工具鏈較新；
Flatpak 和開源桌面生態結合緊密；
對現代硬體支援通常很積極。

它的注意點也很明確：

生命週期短，需要定期升級；
不適合完全不想維護系統的人；
NVIDIA、專有編解碼、部分商業軟體需要額外倉庫；
如果你只想「裝好五年不動」，Fedora 不如 LTS 發行版合適。

我的判斷：Fedora 很適合開發者、Linux 愛好者和新技術體驗者。它不是最省心的普通人桌面，但它能讓你更早接觸 Linux 桌面未來會變成什麼樣。

四者怎麼選

新手第一次裝 Linux

優先選 Ubuntu 26.04 LTS 或 Linux Mint。

Ubuntu 的優勢是資料多、生態廣；Linux Mint 的優勢是像 Windows、學習成本低。如果你願意適應 GNOME，選 Ubuntu；如果你想越像 Windows 越好，選 Linux Mint。

中文辦公和國產化環境

優先看 Deepin / UOS。

如果你要用國產辦公軟體、國產瀏覽器、政企系統、國產 CPU 或單位要求的相容環境，UOS 的現實價值更高。個人使用者想要漂亮中文桌面，可以看 Deepin。

開發者主力機

Ubuntu 26.04 LTS 和 Fedora 都值得看。

如果你追求穩定、教程和商業軟體支援，選 Ubuntu。如果你追求新內核、新 GNOME、新工具鏈和開源技術前沿，選 Fedora。

舊電腦或家用電腦

Linux Mint 更合適。

它介面傳統、資源占用相對友好、維護壓力小。對舊電腦、家用上網機、輕辦公機來說，Mint 的體驗比追求新技術的 Fedora 更穩。

AI/GPU/開發工具鏈

優先 Ubuntu。

NVIDIA 驅動、CUDA、PyTorch、TensorFlow、Docker、VS Code、JetBrains 等工具的教程和官方說明裡，Ubuntu 仍然最常見。Fedora 也能用，但解決問題時通常需要更多 Linux 經驗。

選擇時看這些問題

桌面 Linux 不要只看截圖。真正影響體驗的是這些細節：

顯卡驅動是否穩定，尤其是 NVIDIA；
Wi-Fi、藍牙、指紋、攝像頭是否正常；
外接顯示器、縮放和多螢幕是否舒服；
中文輸入法是否好用；
常用軟體有沒有官方包或 Flatpak；
系統更新是否容易理解；
出問題時能不能搜到解決方案；
你能不能接受它的預設桌面工作流。

很多人換 Linux 失敗，不是因為內核不夠強，而是因為輸入法、縮放、微信、網銀、印表機、顯卡驅動這些日常細節不順手。

我的推薦組合

場景	推薦
新手主力桌面	Ubuntu 26.04 LTS
Windows 使用者遷移	Linux Mint
中文美觀桌面	Deepin
國產化辦公/政企環境	UOS
開發者穩定環境	Ubuntu 26.04 LTS
Linux 新技術體驗	Fedora Linux 44
舊電腦輕辦公	Linux Mint
AI/GPU 開發	Ubuntu 26.04 LTS

簡短結論

Ubuntu 26.04 LTS 是 2026 年最穩妥的全能桌面選擇，適合新手、開發者和主力機。

Deepin/UOS 的優勢在中文體驗、美觀介面和國產化相容，適合重視本地化和政企環境的使用者。

Linux Mint 的優勢是極致易用和穩定，尤其適合 Windows 使用者平滑遷移。

Fedora 的優勢是新技術和開發者體驗，適合願意跟隨 Linux 桌面前沿的人。

桌面系統的好壞，最終要看你每天打開電腦時是否願意繼續用它。選一個能長期舒服使用的發行版，比選一個參數最好看的發行版更重要。

2026 年 Linux 伺服器發行版怎麼選：Debian、Rocky Linux、AlmaLinux 和 Ubuntu Server 對比

Thu, 07 May 2026 21:03:12 +0800

2026 年選 Linux 伺服器發行版，核心問題不是「哪個最好」，而是「哪個最適合你的維運模型」。

如果你需要最穩的社群發行版，Debian 仍然是首選之一。如果你需要 RHEL 相容生態，但不想直接購買 RHEL，Rocky Linux 和 AlmaLinux 是 CentOS 之後最自然的替代者。如果你重視雲端映像、文件、快速部署和新軟體包，Ubuntu Server 仍然最省事。

下面按伺服器場景做一次實用對比。

快速結論

發行版	最適合	主要優點	主要注意點
Debian	長期穩定、自託管、基礎服務	穩定、簡潔、社群強、自由軟體傳統深	預設軟體版本偏保守，企業商業支援不如 RHEL/Ubuntu 明確
Rocky Linux	RHEL 相容生產環境	接近 RHEL 使用習慣，適合企業遷移 CentOS	軟體包更新節奏保守，桌面/新技術體驗不是重點
AlmaLinux	RHEL 相容生產環境、雲和企業替代	RHEL 相容、社群活躍、生命週期清楚	與 RHEL 仍有少量差異，要關注 release notes
Ubuntu Server	雲伺服器、容器、開發部署	雲平台支援好，資料多，部署快，LTS 週期長	Snap、內核/HWE、PPA 等機制需要團隊統一規範

一句話：

最穩妥通用：Debian。
企業 RHEL 生態替代：Rocky Linux / AlmaLinux。
雲端和開發效率優先：Ubuntu Server。

Debian：堅如磐石的穩定性

截至 2026 年 5 月，Debian 當前 stable 是 Debian 13 trixie。Debian 12 bookworm 已經進入 oldstable 階段，仍有安全和 LTS 支援，但新部署伺服器更建議優先看 Debian 13。

Debian 的特點一直很清楚：

預設包選擇保守；
系統結構乾淨；
不強綁定商業廠商；
社群治理成熟；
適合長期運行的基礎服務。

如果你的伺服器主要跑這些東西，Debian 很舒服：

Nginx / Apache；
PostgreSQL / MariaDB / Redis；
Docker / Podman；
WireGuard / Tailscale；
檔案服務、備份服務、監控服務；
小型自託管應用。

Debian 的優勢不是「最新」，而是「少折騰」。很多伺服器裝好之後，幾年內只需要正常安全更新和小版本維護。

適合 Debian 的場景：

你希望系統盡量樸素，不想被發行版廠商策略影響太多。
你熟悉 apt、systemd、Debian 檔案布局。
你可以接受軟體版本不是最新。
你更重視穩定、安全更新和可預期升級。

不太適合 Debian 的場景：

你需要某些廠商只認證 RHEL 或 Ubuntu。
你需要企業級商業支援 SLA。
你依賴最新內核、最新 GPU 棧或新硬體支援。
團隊內部已經全面圍繞 RHEL 系生態寫了維運規範。

我的判斷：個人伺服器、自託管、輕量 SaaS、小團隊基礎服務，Debian 仍然非常值得優先考慮。

Rocky Linux：CentOS 之後的穩健替代

Rocky Linux 的定位很明確：面向需要 RHEL 相容生態的使用者，延續過去 CentOS Linux 在企業生產環境中的角色。

2026 年，Rocky Linux 9 和 Rocky Linux 10 都在支援週期內。Rocky Linux 9 適合更保守的生產環境，Rocky Linux 10 則適合新專案、新硬體和更長未來週期。

Rocky Linux 適合這些場景：

原來跑 CentOS 7 / CentOS 8 的企業環境；
需要 RHEL 系目錄結構、包名和維運習慣；
依賴 dnf、RPM、SELinux、firewalld；
軟體供應商明確支援 RHEL-compatible 發行版；
內部自動化腳本圍繞 Enterprise Linux 編寫。

它的優點是遷移阻力小。很多團隊過去多年圍繞 CentOS 積累了 Ansible playbook、監控規則、審計腳本和安全基線。換到 Rocky Linux，整體心智負擔比遷到 Debian 或 Ubuntu 小很多。

Rocky Linux 的注意點：

包版本偏保守，這是 Enterprise Linux 的設計目標，不是缺點。
如果你需要非常新的使用者態元件，可能要依賴 EPEL、第三方倉庫或容器。
RHEL 相容不等於所有商業軟體廠商都自動提供正式支援，要看廠商認證列表。
Rocky Linux 10 對硬體基線和第三方生態會有新的要求，新上生產前要驗證。

我的判斷：如果你的伺服器環境本來就是 CentOS / RHEL 系，Rocky Linux 是非常自然的替代方案，尤其適合穩定生產環境和企業內部服務。

AlmaLinux：更主動的 RHEL 相容路線

AlmaLinux 也是 CentOS 之後的重要替代者，定位同樣是企業級、長期支援、RHEL 相容。

它和 Rocky Linux 的共同點很多：

都面向 RHEL 相容生態；
都適合伺服器生產環境；
都有 8、9、10 代長期支援路線；
都適合從 CentOS 遷移；
都能使用大量 Enterprise Linux 生態工具。

不同點在於，AlmaLinux 在 RHEL 相容之外，會更主動記錄和處理上游差異。例如 AlmaLinux 10 提供了面向舊硬體的 x86-64-v2 架構選擇，並在 release notes 中明確說明與 RHEL 的差異。

這對一部分使用者很有用：他們既想留在 RHEL 生態，又希望社群發行版能在硬體支援、包構建、EPEL 相容等問題上更靈活。

適合 AlmaLinux 的場景：

你需要 RHEL 相容，但不想完全被 RHEL 發布策略限制。
你重視社群治理和透明 release notes。
你在雲平台、容器映像、企業工作負載中需要穩定基礎系統。
你想從 CentOS 或舊 Enterprise Linux 平滑遷移。

需要注意的是，AlmaLinux 不是「閉眼等於 RHEL」。對嚴格合規、廠商認證、資料庫認證、硬體認證場景，仍然要檢查軟體供應商是否明確支援 AlmaLinux。

我的判斷：Rocky Linux 和 AlmaLinux 都能作為 CentOS 替代。更保守、更貼近傳統 CentOS 敘事，可以看 Rocky；更重視社群透明和相容路線靈活性，可以看 AlmaLinux。

Ubuntu Server：雲端支援和部署效率最好

Ubuntu Server 的優勢很現實：雲平台、文件、社群教程、映像、自動化工具和開發者生態都很強。

2026 年伺服器新部署，主力仍然是 Ubuntu 24.04 LTS。Ubuntu LTS 通常有 5 年標準支援，並可透過 ESM 延長支援週期。對雲伺服器、容器宿主機、開發環境、CI/CD 節點來說，Ubuntu Server 往往是最快上手的選擇。

Ubuntu Server 適合這些場景：

AWS、Azure、Google Cloud、Oracle Cloud、阿里雲、騰訊雲等雲伺服器；
Docker、Kubernetes、GitLab Runner、CI/CD；
AI / GPU / CUDA 開發環境；
需要大量教程和社群方案的團隊；
開發與生產都希望盡量一致的環境。

Ubuntu 的優點：

雲映像品質高；
官方和第三方文件多；
新硬體支援通常更積極；
LTS 節奏清楚；
開發者工具鏈更新更方便；
很多商業軟體會優先給 Ubuntu 安裝說明。

Ubuntu 的注意點：

Snap 在伺服器上不是所有團隊都喜歡，是否使用要提前規範。
PPA 很方便，但生產環境濫用會增加維護風險。
HWE 內核、雲內核、標準內核之間要選清楚。
對極簡穩定派來說，Ubuntu 預設系統元件會比 Debian「更熱鬧」。

我的判斷：如果你主要跑雲伺服器、容器、開發部署、AI 工具鏈，Ubuntu Server 通常是效率最高的選擇。它不是最「純」的發行版，但它能讓很多事情少查資料、少踩坑。

四者怎麼選

個人 VPS / 自託管

優先推薦 Debian 或 Ubuntu Server。

如果你想穩定、省心、少折騰，選 Debian。如果你經常照著教程部署新專案，或者需要較新的軟體棧，選 Ubuntu Server。

企業生產環境

優先推薦 Rocky Linux、AlmaLinux 或 RHEL。

如果公司過去使用 CentOS，遷移到 Rocky / Alma 成本最低。如果涉及商業資料庫、硬體認證、安全合規和廠商支援，要優先確認認證清單。

雲原生和容器宿主機

Ubuntu Server、Debian、Rocky / Alma 都能勝任。

如果團隊偏開發效率，選 Ubuntu Server。如果追求極簡穩定，選 Debian。如果企業標準圍繞 RHEL 系，選 Rocky / Alma。

AI / GPU 伺服器

優先看 Ubuntu Server，其次看 Rocky / Alma。

原因很簡單：NVIDIA、CUDA、PyTorch、TensorFlow、驅動安裝教程和社群經驗裡，Ubuntu 通常最多。企業 GPU 叢集如果已經圍繞 RHEL 生態建設，則可以選 Rocky / Alma，但要提前驗證驅動、CUDA、容器運行時和監控工具。

傳統業務系統

優先看 Rocky Linux / AlmaLinux。

傳統 Java、資料庫、中介軟體、商業軟體、審計和維運規範往往更偏 RHEL 系。此時選擇 Rocky / Alma，會比 Debian / Ubuntu 更容易貼合舊體系。

選擇時看這幾個指標

不要只看發行版名字。伺服器選型時，建議按下面幾個問題判斷：

生命週期：這個版本能維護到哪一年？
升級路徑：大版本升級是否成熟？是否支援平滑遷移？
軟體來源：是否依賴第三方倉庫？第三方倉庫誰維護？
安全更新：安全公告、補丁節奏、CVE 處理是否清楚？
硬體支援：CPU、網卡、RAID、GPU、儲存控制器是否驗證過？
團隊經驗：團隊熟悉 apt 還是 dnf？熟悉 Debian 系還是 RHEL 系？
廠商認證：業務軟體是否明確支援該發行版？
自動化資產：現有 Ansible、Terraform、映像構建腳本是否可重複使用？

真正決定成本的，往往不是安裝 ISO，而是後續五年的升級、審計、排障和交接。

我的推薦組合

如果讓我給 2026 年伺服器選型一個預設建議：

場景	推薦
個人 VPS、自託管	Debian 13
雲伺服器、快速部署	Ubuntu Server 24.04 LTS
CentOS 遷移	Rocky Linux 9 / AlmaLinux 9
新企業專案	Rocky Linux 10 / AlmaLinux 10，先驗證生態
AI / GPU 開發	Ubuntu Server 24.04 LTS
強合規商業生產	RHEL，或確認廠商支援後使用 Rocky / Alma

簡短結論

Debian 的關鍵詞是穩定、簡潔、社群和自由軟體傳統。它適合長期運行的基礎伺服器。

Rocky Linux 和 AlmaLinux 的關鍵詞是 RHEL 相容、企業生產和 CentOS 替代。它們適合已有 Enterprise Linux 維運體系的團隊。

Ubuntu Server 的關鍵詞是雲端、文件、開發效率和生態完整。它適合快速部署、容器、AI/GPU 和雲伺服器。

沒有永遠正確的發行版，只有和團隊、業務、硬體、生命週期最匹配的發行版。伺服器上最好的選擇，通常不是最熱門的那個，而是五年後你還願意維護的那個。

fdupes 怎麼控制刪除順序？按目錄優先級保留重複檔案

Wed, 06 May 2026 09:23:09 +0800

用 fdupes 刪除重複檔案時，如果有 a、b、c 三個目錄，並且希望優先保留 a，其次保留 b，最後刪除 c 中的重複檔案，關鍵不在於寫一個複雜規則，而在於目錄輸入順序。

fdupes 在非互動刪除模式下，會保留每組重複檔案中最先出現的檔案，刪除後續發現的重複項。因此目錄參數要按「保留優先級從高到低」排列。

也就是說，想實現「先刪 c，再刪 b，最後盡量保留 a」，命令應該寫成：

`1`	`fdupes -rdN a b c`

掃描順序是 a -> b -> c。當三個目錄中存在相同檔案時，a 裡的檔案會先被發現並保留，b 和 c 中重複的檔案會被刪除。如果只有 b 和 c 有重複檔案，則保留 b，刪除 c。

參數含義

常用參數如下：

-r：遞迴掃描子目錄。
-d：刪除重複檔案。
-N：與 -d 配合使用，不進入互動確認，自動保留每組重複檔案中的第一個，刪除其餘檔案。

因此，自動刪除重複檔案的基本格式是：

`1`	`fdupes -rdN 目录A 目录B 目录C`

目錄越靠前，保留優先級越高；目錄越靠後，越容易被刪除。

先預覽再刪除

直接使用 -dN 會刪除檔案，建議先預覽重複檔案分組：

`1`	`fdupes -r a b c`

輸出結果會按重複檔案分組展示。每組中靠前的檔案，就是非互動刪除時更可能被保留的檔案。

也可以查看統計資訊：

`1`	`fdupes -rm a b c`

如果資料重要，建議先把結果保存下來人工檢查：

`1`	`fdupes -r a b c > duplicates.txt`

確認每組重複檔案的排列順序符合預期後，再執行：

`1`	`fdupes -rdN a b c`

子目錄怎麼處理

只要開啟 -r，fdupes 會遞迴掃描傳入目錄下的所有檔案。決定保留優先級的，仍然是命令中路徑出現的先後順序。

例如：

`1`	`fdupes -rdN dir_a dir_b dir_c`

這表示：

dir_a 的優先級最高。
dir_b 次之。
dir_c 最低。

如果 dir_a/sub1/file.txt 和 dir_c/sub1/file.txt 內容相同，會保留 dir_a 下的檔案。如果 dir_a/x/y/file.txt 和 dir_c/file.txt 內容相同，也會優先保留 dir_a 下的檔案。fdupes 比較的是檔案內容，不要求檔名或目錄層級完全一致。

精確控制子目錄優先級

如果只傳父目錄，子目錄內部的掃描順序由 fdupes 的遍歷邏輯決定。多數情況下，這已經夠用。但如果你想讓某個子目錄擁有更高優先級，就要把它顯式寫在前面。

例如，希望優先保留 dir_a，然後保留 dir_b/special，再處理 dir_b 的其他內容，最後處理 dir_c：

`1`	`fdupes -rdN dir_a dir_b/special dir_b dir_c`

這樣 dir_b/special 會先於 dir_b 被掃描。之後掃描 dir_b 時，special 裡的檔案已經被記錄，整體優先級就會高於 dir_b 的其他部分。

這個寫法適合下面這種需求：

a 是最重要的基準目錄。
b 中某個子目錄比 b 的其他內容更重要。
c 主要作為低優先級備份目錄。

路徑順序可以繼續擴展：

`1`	`fdupes -rdN a b/important b c/keep-first c`

規則仍然只有一個：越靠前，越優先保留。

目錄很多時使用列表

如果有很多目錄和子目錄，手動寫一長串命令容易出錯。可以把路徑按優先級寫入一個文字檔，比如 folders.txt：

/path/to/dir_a
/path/to/dir_b/sub_important
/path/to/dir_b
/path/to/dir_c/sub_1
/path/to/dir_c

然後用 xargs 傳給 fdupes：

`1`	`cat folders.txt \| xargs fdupes -rdN`

如果路徑中可能包含空格，更穩妥的方式是使用空字元分隔：

`1`	`tr '\n' '\0' < folders.txt \| xargs -0 fdupes -rdN`

需要注意的邊界

第一，fdupes 比較的是檔案內容，而不是檔名。如果兩個檔名完全不同，但內容一致，也會被識別為重複檔案。

第二，如果 a 目錄內部本身就有重複檔案，使用 fdupes -rdN a b c 時，a 內部靠後的重複項也可能被刪除。這個命令表達的是「按整體掃描順序保留最先出現的檔案」，不是「絕對不刪除 a 中任何檔案」。

第三，預設情況下，fdupes 不會跟隨符號連結。如果需要處理軟連結相關檔案，要先確認是否需要加 -s，以及這樣做是否符合你的資料安全預期。

第四，fdupes 只刪除重複檔案，不負責清理空目錄。刪除完成後，如果 b、c 中留下了空資料夾，可以再執行：

`1`	`find b c -type d -empty -delete`

更安全的操作習慣

如果目錄裡是重要資料，不建議一上來就執行 -rdN。更穩的流程是：

先執行 fdupes -r a b c 查看重複分組。
確認每組中排在前面的檔案確實應該保留。
再執行 fdupes -rdN a b c 自動刪除。
刪除後檢查是否需要清理空目錄。

如果你非常擔心誤刪 a 中的檔案，可以先只對低優先級目錄做更小範圍的清理，或者把結果匯出後人工篩選。fdupes 的目錄順序很好用，但它不是權限隔離規則；只要路徑被納入掃描，路徑內部的重複檔案就可能參與刪除判斷。

小結

用 fdupes 按優先級刪除重複檔案，核心就是把「想保留的目錄」放在前面，把「優先刪除的目錄」放在後面。

想保留 a，再保留 b，優先刪除 c：

`1`	`fdupes -rdN a b c`

想讓某個子目錄優先級更高，就把它單獨寫在父目錄前面：

`1`	`fdupes -rdN a b/important b c`

記住一句話就夠了：fdupes -dN 會保留先出現的重複檔案，刪除後出現的重複檔案。目錄順序，就是你的保留優先級。

Snap、Flatpak 和 apt 到底有什麼區別

Sat, 02 May 2026 11:22:26 +0800

在 Ubuntu 上安裝軟體時，經常會遇到三個名字：apt、Snap 和 Flatpak。它們都能安裝應用程式，但解決的問題不一樣。

簡單說：

工具	主要定位	更適合
`apt`	Ubuntu/Debian 的傳統套件管理器	系統元件、命令列工具、發行版維護的軟體
Snap	Canonical 推動的應用打包格式	Ubuntu 桌面應用、服務端工具、自動更新軟體
Flatpak	面向桌面應用的跨發行版格式	圖形軟體、沙盒化應用、Flathub 生態

apt：系統的一部分

apt 是 Debian/Ubuntu 系的傳統套件管理器。它從發行版軟體源安裝 .deb 套件，並由發行版維護依賴關係。

安裝方式通常是：

`1`	`sudo apt install firefox`

apt 的特點是：

和系統整合最深。
依賴由發行版統一管理。
軟體版本通常跟隨發行版節奏。
適合系統函式庫、驅動、命令列工具和伺服器元件。

它的缺點也明顯：軟體版本可能偏舊。因為發行版更重視穩定性，不會總是第一時間提供上游最新版。

Snap：把應用和依賴打進一個包

Snap 是 Canonical 推動的打包格式。它把應用和大量執行依賴一起打包，減少對系統函式庫版本的依賴。

安裝方式類似：

`1`	`sudo snap install firefox`

Snap 的優勢是：

同一個包更容易跨 Ubuntu 版本執行。
應用更新可以獨立於系統更新。
預設有一定隔離和權限控制。
適合需要快速更新的桌面應用和部分服務端工具。

它的常見槽點是啟動慢、佔用空間更大、主題整合不夠自然，以及更新節奏不如 apt 那樣完全由使用者控制。

Flatpak：更偏桌面應用

Flatpak 也是跨發行版應用打包方案，但它更偏向 Linux 桌面應用生態。很多 Flatpak 應用來自 Flathub。

常見安裝方式是：

`1`	`flatpak install flathub org.mozilla.firefox`

Flatpak 的特點是：

跨發行版能力強。
更關注桌面應用分發。
使用 runtime 共享基礎依賴。
沙盒和權限模型更清晰。
Flathub 上的軟體選擇很多。

Flatpak 也會佔用額外空間，第一次安裝 runtime 時尤其明顯。但多個應用共享 runtime 後，空間浪費會少一些。

最大區別：依賴怎麼處理

apt 更像「系統拼裝」。應用依賴系統裡的函式庫，多個軟體共享同一套依賴。

Snap 和 Flatpak 更像「應用自帶執行環境」。應用帶著自己需要的一部分依賴走，減少系統版本差異帶來的問題。

這帶來一個取捨：

方式	優點	缺點
`apt` 共享系統依賴	省空間、整合好、維護統一	版本受發行版限制
Snap/Flatpak 自帶執行環境	跨版本、跨發行版、更容易更新	包更大、可能啟動慢、整合感較弱

隔離和權限

apt 安裝的軟體通常直接執行在系統環境裡。它們和系統整合自然，但隔離較少。

Snap 和 Flatpak 都有沙盒思路：應用預設不能隨便存取所有系統資源，需要透過權限接口存取檔案、攝影機、網路、桌面通知等。

這不等於它們絕對安全，但至少提供了更明確的權限邊界。對來源複雜的桌面應用來說，這很有意義。

更新方式不同

apt 通常跟隨系統更新：

1
2

sudo apt update
sudo apt upgrade

Snap 會自動更新，這是它方便也容易引起爭議的地方。使用者不用管版本，但也少了一些控制感。

Flatpak 可以手動更新：

`1`	`flatpak update`

所以如果你很在意「什麼時候更新」，apt 和 Flatpak 的控制感通常更強；如果你想讓應用自動保持新版本，Snap 更省心。

該用哪個

可以按場景選：

系統工具、驅動、服務端元件：優先 apt。
Ubuntu 預設推薦的桌面應用：可以用 Snap。
想要較新的桌面軟體，尤其是跨發行版應用：可以用 Flatpak。
同一個軟體三種方式都有：優先看穩定性、啟動速度、主題整合和更新需求。

一個保守的選擇是：系統層用 apt，桌面應用按需要在 Snap 和 Flatpak 之間選。

小結

apt、Snap、Flatpak 不是誰完全替代誰，而是分發模型不同。

apt 更適合維護系統；Snap 更強調應用自帶依賴和自動更新；Flatpak 更適合跨發行版桌面應用和沙盒化分發。

如果只是日常使用，不必糾結「哪個最好」。系統軟體用 apt，桌面應用看發行版推薦和自己的體驗，能穩定執行、更新可控、權限清楚，就是合適的選擇。

參考：

https://www.reddit.com/r/Ubuntu/comments/9awvip/eli5_snap_and_flatpak_how_are_they_differ_from_apt/

詳解 Linux 7.0 和 7.1 的 NTFS 驅動變化

Sat, 02 May 2026 10:46:20 +0800

Linux 7.0 發布後，7.1 開始進入下一輪特性合併窗口。其中一個值得關注的變化，是新的 NTFS 核心驅動。

這裡的「新」不是說 Linux 第一次支援 NTFS，也不是說 ntfs3 被替換。更準確地說，Linux 7.1 合入了一個新的可選核心態 NTFS 讀寫驅動。它基於早年的核心 ntfs 驅動重新整理，並補上更完整的讀寫能力。

先說結論

Linux 上目前主要有三條 NTFS 路線：

方案	位置	讀寫能力	適合場景
`ntfs-3g`	使用者態 FUSE	讀寫	穩定優先，發行版長期預設方案
`ntfs3`	核心態	讀寫	追求更直接的核心整合和效能
新 `ntfs`	核心態	讀寫	Linux 7.1 新增的可選實作

所以這次變化不是強制遷移，而是多了一種選擇。普通使用者短期內繼續跟隨發行版預設策略即可。

7.0 和 7.1 的關係

Linux 7.0 只是核心版本進入 7.x 系列，不代表 NTFS 支援在 7.0 裡突然重寫。真正和 NTFS 相關的新變化，出現在 7.1 的特性合併階段。

NTFS 一直是 Linux 桌面使用者繞不開的檔案系統：雙系統、外接硬碟、U 盤、Windows 資料碟都會用到它。問題在於，NTFS 寫入路徑複雜，一旦驅動有 bug，風險可能直接落到資料上。因此核心社群對 NTFS 驅動會比較謹慎。

`ntfs-3g`、`ntfs3` 和新 `ntfs`

ntfs-3g 是使用者態 FUSE 驅動，長期承擔 Linux 上的 NTFS 讀寫任務。它效能不一定最好，但成熟、相容性好，資料也多。

ntfs3 是 Paragon Software 貢獻的核心態 NTFS 驅動，已經進入 Linux 主線。它路徑更短，和 VFS 整合更直接，理論效能也更好。但檔案系統驅動對維護品質要求很高，ntfs3 合入後也經歷過維護節奏和程式碼品質方面的討論。

Linux 7.1 新增的 ntfs 驅動，則由 Namjae Jeon 維護。它不是從零開始，而是把舊核心 ntfs 驅動現代化，補齊讀寫能力，作為另一套可選實作與 ntfs3 並存。

這三者的關係可以簡單理解為：

ntfs-3g：保守、成熟、使用者態。
ntfs3：主線已有的核心態方案。
新 ntfs：7.1 新增的核心態方案，還需要觀察穩定性。

應該怎麼選

日常使用不用急著切換。比較穩妥的順序是：

重要資料繼續使用發行版預設方案，通常是 ntfs-3g 或已驗證的 ntfs3。
需要效能時，可以測試 ntfs3。
新 ntfs 驅動先用於測試碟、臨時碟或可恢復資料。
重要 NTFS 分區寫入前先備份。

如果要手動使用 ntfs3，常見掛載方式是：

`1`	`sudo mount -t ntfs3 /dev/sdX1 /mnt/ntfs`

如果只是臨時讀取資料，可以唯讀掛載：

`1`	`sudo mount -o ro /dev/sdX1 /mnt/ntfs`

確認目前使用哪個驅動，可以看掛載資訊：

1
2

findmnt -T /mnt/ntfs
mount | grep ntfs

雙系統使用者要注意

NTFS 分區如果來自 Windows 系統碟，寫入前要先確認 Windows 已真正關機。快速啟動和休眠會讓 NTFS 卷保留未完成狀態，Linux 再寫入可能造成一致性問題。

建議檢查這幾項：

關閉 Windows 快速啟動。
確認分區不在 hibernation 狀態。
BitLocker 或其他加密狀態不會阻礙存取。
外接硬碟在 Windows 中已正常退出。

無論使用 ntfs-3g、ntfs3 還是新 ntfs，這些注意事項都一樣。

為什麼需要多個 NTFS 驅動

同一種檔案系統有多個實作，在 Linux 裡並不罕見。舊實作、新實作、廠商實作、社群實作會並存一段時間，直到維護狀態和實際回饋逐漸分出主次。

NTFS 更適合保守處理，原因很簡單：

使用者資料風險高。
相容場景複雜。
不同實作的效能和穩定性取捨不同。
發行版需要時間驗證預設策略。

因此，Linux 7.1 新 ntfs 驅動的意義，不是立刻淘汰 ntfs-3g 或 ntfs3，而是給核心社群多一個可維護的選擇。

小結

Linux 7.1 新增的 ntfs 驅動，是一個可選的核心態 NTFS 讀寫實作。它和 ntfs-3g、ntfs3 並存，不是直接替代誰。

普通使用者可以繼續使用發行版預設方案；需要折騰或測試效能的人，可以關注 ntfs3 和新 ntfs 的後續穩定性。涉及重要資料時，優先備份，再考慮切換驅動。

sudo 和 sudo-rs 有什麼差異：Rust 版本 sudo 會改變什麼

Fri, 01 May 2026 19:27:08 +0800

sudo 是 Linux 使用者最熟悉的命令之一。它讓普通使用者在授權範圍內臨時以更高權限執行命令，例如安裝軟體、修改系統設定或重啟服務。

最近 sudo-rs 受到更多關注，原因是 Ubuntu 25.10 開始預設使用 Rust 實現的 sudo-rs 來替代傳統 sudo。對普通使用者來說，表面上仍然輸入 sudo。真正變化在系統底層：執行的可能已經是 Rust 版本的 sudo。

這件事容易引發兩個問題：

傳統 sudo 出什麼問題了嗎？
sudo-rs 會不會影響日常使用和伺服器設定？

簡單結論是：普通桌面使用者基本不用擔心；如果你維護伺服器、寫過複雜 sudoers 規則，或者依賴特殊 sudo 行為，就需要認真測試。

sudo-rs 是什麼

sudo-rs 是用 Rust 編寫的 sudo / su 實現。它的目標不是創造一個完全不同的新命令，而是重新實現傳統 sudo 的主要功能，同時利用 Rust 的記憶體安全特性降低常見安全風險。

傳統 sudo 主要由 C 語言編寫，歷史很長，功能也很完整。這種成熟度帶來穩定性，也帶來維護負擔。很多程式碼來自很早的 Unix/Linux 使用場景，後來又疊加了大量相容邏輯、擴充和邊界處理。

sudo-rs 選擇重新實現，是為了獲得幾個好處：

借助 Rust 減少記憶體安全問題；
用更現代的程式碼結構降低維護難度；
去掉部分歷史功能和高風險預設行為；
吸引熟悉 Rust 的新貢獻者參與維護；
為未來權限提升工具提供更容易稽核的基礎。

不過，sudo-rs 不是傳統 sudo 的 100% 相容替代品。它仍在發展中，一些傳統功能暫時沒有實現，另一些功能可能不會再實現。

普通使用者會感覺到什麼變化

對普通使用者來說，變化很少。

你仍然這樣使用：

`1`	`sudo apt update`

或者：

`1`	`sudo systemctl restart nginx`

在 Ubuntu 25.10 中，sudo 會指向 sudo-rs。使用者輸入的命令不需要改成 sudo-rs，腳本裡常見的 sudo 也不會因為命令名變化而立刻失效。

比較容易看到的變化是密碼輸入回饋。 sudo-rs 預設會在輸入密碼時顯示星號。傳統 sudo 也可以透過設定實現類似效果，但很多發行版預設是不顯示任何字元。

另外，部分錯誤資訊和警告資訊的文字可能不同。例如密碼錯誤、權限不足、設定不相容時，提示內容可能和以前不完全一樣。這對人類使用者影響不大，但如果某些腳本依賴解析 sudo 的錯誤輸出，就需要檢查。

管理員需要關注哪些差異

真正需要注意的是系統管理員和進階使用者。

傳統 sudo 的生態很大，不少伺服器會有複雜的 sudoers 設定。這些設定可能包含命令參數匹配、環境變數控制、日誌、郵件通知、PAM 行為和不同主機組策略。

sudo-rs 目前和傳統 sudo 存在一些差異。例如，原文提到 sudo-rs 不包含傳統 sudo 的 sendmail 支援。過去有些環境會透過 sendmail 發送 sudo 使用通知，這類設定遷移時就需要換方案。

認證方面，sudo-rs 使用 PAM。這意味著資源限制、umask 等行為應更多透過 PAM 設定，而不是完全依賴 sudoers 文件。如果你過去在 sudoers 裡處理了很多細節，切換前要確認這些規則是否仍然生效。

還有一個重要變化是命令參數位置的萬用字元支援。 sudo-rs 不支援在命令參數位置使用萬用字元，以避免 sudoers 文件中常見的設定錯誤。這對安全是好事，但可能影響已有規則。

Ubuntu 裡怎麼處理 sudo 和 sudo-rs

從 Ubuntu 25.10 開始，系統預設使用 sudo-rs。使用者繼續輸入 sudo，底層會執行 Rust 實現。

傳統 sudo 並沒有馬上消失。在 Ubuntu 的過渡設計中，經典 sudo 仍然以 sudo-ws 的形式保留。如果確實需要傳統實現，可以使用 sudo-ws，或者透過 alternatives 機制切換預設 sudo。

切換命令類似這樣：

`1`	`sudo update-alternatives --config sudo`

不過，不建議普通使用者主動切回傳統 sudo。如果你沒有自訂 sudoers，也沒有依賴特殊行為，繼續使用發行版預設選擇更省心。

如果你想在舊版本 Ubuntu 上測試，sudo-rs 從 Ubuntu 24.04 開始已經可以從 universe 倉庫獲得。其他發行版也可能提供對應套件，但命令名稱和整合方式不一定相同。

sudo-rs 為什麼選擇 Rust

sudo 是高權限工具。一旦這類工具出現漏洞，後果可能比普通命令嚴重得多。歷史上，sudo 也出現過多個權限提升漏洞。

Rust 的優勢在於記憶體安全。它透過所有權、借用檢查和型別系統，減少懸空指標、越界存取、use-after-free 等常見問題。這不能保證程式絕對安全，但可以減少 C/C++ 專案裡很常見的一類漏洞。

對 sudo 這種長期執行在安全敏感位置的工具來說，用更安全的語言重寫有現實意義。它不只是「為了 Rust 而 Rust」，而是試圖降低維護和稽核成本。

當然，語言不能解決全部安全問題。權限檢查邏輯、設定解析、PAM 互動、環境變數處理、日誌和使用者體驗，仍然需要嚴謹設計和長期測試。

sudo-rs 不是唯一選擇

sudo 生態裡本來就有其他替代品。

比較常見的是 doas。它來自 OpenBSD，設計更簡單，設定也更小。一些使用者喜歡它，是因為它沒有 sudo 那麼複雜。

還有一些 Rust 或 systemd 相關的替代方案，例如 RootAsRole、systemd 的 run0 等。不過這些工具的目標和適用場景並不完全相同。

對大多數 Linux 發行版來說，sudo 仍然是預設選擇。 sudo-rs 的意義在於，它嘗試在保持使用者習慣的同時，把底層實現換成更現代的程式碼基礎。

遷移前應該檢查什麼

如果你只是個人桌面使用者，可以跟隨發行版預設設定。

如果你維護伺服器或工作站，建議檢查這些內容：

是否有複雜的 /etc/sudoers 或 /etc/sudoers.d/ 規則；
是否使用了命令參數萬用字元；
是否依賴 sudo 的郵件通知；
是否有腳本解析 sudo 的錯誤輸出；
是否透過 sudoers 控制 umask、資源限制或環境變數；
是否有 LDAP、PAM、SSSD 等認證整合；
是否有自動化部署腳本預設假設傳統 sudo 行為。

可以先在測試機上驗證：

sudo -l

再執行關鍵維護命令，確認權限、環境變數和日誌行為都符合預期。

是否應該主動切換到 sudo-rs

如果發行版已經預設切換，普通使用者可以直接接受。如果你使用的是伺服器或生產環境，不建議只為了嘗鮮手動替換。

更穩妥的做法是：

在測試環境安裝 sudo-rs；
對照現有 sudoers 設定逐項驗證；
檢查 PAM、日誌、稽核和自動化腳本；
確認回滾方式；
等發行版給出穩定整合後再遷移。

這類工具處在權限鏈路上，不適合用「能執行幾個命令」來判斷是否安全。真正要驗證的是邊界條件和異常情況。

小結

sudo-rs 是傳統 sudo 的 Rust 實現，目標是用更現代、更安全的程式碼基礎承接 sudo 的核心功能。 Ubuntu 25.10 預設啟用它，說明主流發行版已經開始認真推動這條路線。

對普通使用者來說，變化很小。你仍然輸入 sudo，只是底層實現可能變成了 sudo-rs。最多會注意到密碼輸入顯示星號，或者錯誤提示文字略有變化。

對系統管理員來說，重點是相容性。如果系統裡有複雜 sudoers 規則、sendmail 通知、PAM 整合、參數萬用字元或依賴 sudo 輸出的腳本，就應該在升級前測試。

Rust 重寫不是萬靈丹，但對 sudo 這種安全敏感工具來說，減少記憶體安全風險、降低維護複雜度，是值得認真考慮的方向。

參考來源：

X11 和 Wayland 的差異、優劣與選擇建議

Fri, 01 May 2026 19:23:01 +0800

Linux 桌面裡經常會遇到兩個名字：X11 和 Wayland。它們都和圖形顯示有關，但設計年代、架構思路和使用體驗差別很大。

簡單說，X11 是老一代顯示協定和生態，功能完整、相容性強，但架構複雜，安全模型比較陳舊。 Wayland 是新一代顯示協定，目標是減少中間層、提升安全性和流暢度，但仍然有一些軟體和工作流需要適配。

如果只是日常使用，結論可以先放在前面：

新裝 Linux 桌面，優先試 Wayland；
需要老軟體、複雜遠端桌面、特殊輸入裝置或某些專業工具時，X11 仍然更穩；
遊戲和普通辦公場景，Wayland 已經越來越可用；
遇到相容性問題，可以切回 X11，不需要把它當成二選一的信仰問題。

X11 是什麼

X11，也常被叫作 X Window System 或 Xorg，是 Linux 和 Unix 桌面使用了很多年的圖形系統。它的設計目標來自早期網路計算環境：程式可以執行在一台機器上，視窗顯示在另一台機器上。

X11 的典型結構是：

應用程式負責繪製視窗內容；
X Server 管理顯示、輸入、視窗基礎操作；
視窗管理器負責視窗邊框、移動、堆疊；
合成器負責陰影、透明、動畫、撕裂控制等效果。

這個架構很靈活，也讓 X11 累積了大量工具和擴充。但時間久了以後，問題也明顯：元件多、路徑長、權限邊界鬆散，很多現代桌面需求需要靠擴充和補丁維持。

Wayland 是什麼

Wayland 不是一個傳統意義上的完整顯示伺服器，而是一套更現代的顯示協定。在 Wayland 下，合成器通常同時承擔顯示伺服器的角色。 GNOME 的 Mutter、KDE 的 KWin、wlroots 系列合成器都可以作為 Wayland compositor。

Wayland 的典型結構更短：

應用程式自己渲染視窗內容；
合成器接收應用提交的 buffer；
合成器統一管理視窗、輸入、顯示輸出和合成；
最終畫面直接交給核心圖形堆疊顯示。

這種設計減少了傳統 X11 裡 X Server、視窗管理器、合成器之間的繞路。它也讓權限控制更明確：應用預設不能隨便讀取其他視窗內容，也不能隨意監聽全域鍵盤輸入。

架構差異

最核心的差異在於職責劃分。

X11 裡，X Server 處在中心位置，很多應用都可以和它互動。視窗管理器、合成器、輸入法、截圖工具、遠端控制工具也能透過 X11 的開放介面取得大量資訊。這帶來了強相容性，也帶來了安全問題。

Wayland 裡，合成器是中心。應用不能直接拿到其他視窗的內容，也不能預設監聽所有鍵盤輸入。截圖、錄影、螢幕共享、全域快捷鍵、遠端控制等能力，需要透過桌面入口、PipeWire 或合成器提供的受控介面實現。

可以把它理解成：

對比項	X11	Wayland
設計年代	更早	更新
中心元件	X Server	Compositor
合成器角色	可選或額外元件	核心元件
應用間隔離	較弱	較強
遠端顯示	原生思路更強	依賴新工具鏈
相容性	很強	仍在補齊
現代桌面體驗	依賴擴充和補丁	設計上更貼近現代需求

X11 的優點

X11 最大的優點是成熟。它執行了很多年，幾乎所有 Linux 圖形程式都能在 X11 下工作。一些老工具、專業軟體、特殊輸入法、遠端控制方案和自動化腳本，也往往優先支援 X11。

X11 的另一個優點是可操作性強。很多工具可以直接讀取視窗、模擬輸入、抓取螢幕、移動視窗、監聽按鍵。這對自動化、遠端協助、視窗管理腳本和一些特殊工作流很方便。

如果你的需求包括：

使用老舊 GUI 軟體；
依賴 xrandr、xinput、xdotool、wmctrl；
使用傳統遠端桌面或視窗轉發；
需要某些特殊截圖、錄影、鍵鼠巨集工具；
某個應用在 Wayland 下還不穩定；

那麼 X11 仍然是很現實的選擇。

X11 的缺點

X11 的缺點主要來自歷史包袱。

首先是安全模型舊。在傳統 X11 工作階段裡，一個普通應用往往可以監聽其他視窗輸入、截取螢幕內容、模擬按鍵和滑鼠操作。這在現代桌面安全視角下很難接受。

其次是渲染路徑複雜。 X11 時代經歷過很多擴充：Composite、GLX、DRI、RandR、Present 等。這些擴充讓它能繼續支援現代桌面，但也讓圖形堆疊變得複雜。高刷新率、多顯示器、不同縮放比例、混合 DPI、低延遲輸入等場景，X11 更容易出現邊角問題。

再者，X11 的維護重點已經逐漸轉向相容。主流桌面環境仍然支援 X11，但新功能和新最佳化通常更優先落在 Wayland 上。

Wayland 的優點

Wayland 的優勢主要在現代桌面體驗。

它的渲染路徑更直接。應用渲染 buffer，合成器負責統一合成和顯示，減少了傳統 X11 架構裡的繞路。在動畫、視窗移動、高刷新率、多顯示器、觸控板手勢、分數縮放等場景裡，Wayland 更容易做得乾淨。

安全性也是 Wayland 的重要優點。應用預設不能隨便截取其他視窗，也不能無條件監聽全域鍵盤輸入。截圖、錄影和螢幕共享需要使用者授權，通常透過桌面入口和 PipeWire 處理。

Wayland 對現代硬體也更友好。觸控板手勢、HiDPI、可變刷新率、不同顯示器使用不同縮放比例等能力，在 Wayland 下通常更自然。 GNOME 和 KDE 這幾年也把大量桌面體驗最佳化放到了 Wayland 工作階段裡。

Wayland 的缺點

Wayland 的問題不在於「不能用」，而在於生態還在遷移。

有些工具過去依賴 X11 的開放能力，例如全域按鍵監聽、視窗列舉、自動點擊、螢幕抓取、視窗移動。這些在 Wayland 下不能直接照搬，必須透過入口、合成器協定或桌面環境 API 實現。因此部分老工具會失效，或者只能在特定桌面環境下工作。

遠端桌面也是典型問題。 X11 天生有網路透明的歷史設計，雖然現代使用體驗未必總是好，但很多工具已經圍繞它成熟。 Wayland 下遠端桌面需要 PipeWire、RDP、VNC、桌面入口或合成器支援，具體體驗取決於 GNOME、KDE、Sway 等環境的實現。

輸入法也曾經是痛點。現在 Fcitx5、IBus 在主流 Wayland 桌面裡已經明顯改善，但某些 Electron 應用、老程式或特殊組合仍可能出現候選框位置、焦點和快捷鍵問題。

NVIDIA 也曾長期是 Wayland 的阻力之一。近幾年 NVIDIA 驅動和桌面環境支援已經改善很多，但如果你使用舊顯示卡、舊驅動或特殊多螢幕配置，仍然可能遇到 X11 更穩定的情況。

Xwayland 的作用

很多人以為切到 Wayland 後，X11 應用就完全不能用了。實際不是這樣。

Wayland 桌面通常會透過 Xwayland 相容舊 X11 應用。應用以為自己執行在 X11 上，實際視窗內容再交給 Wayland 合成器顯示。

這讓遷移過程平滑很多：

原生 Wayland 應用走 Wayland；
老 X11 應用走 Xwayland；
使用者可以在一個桌面工作階段裡同時使用兩類程式。

不過，Xwayland 不是萬能的。如果某個工具依賴全域輸入監聽、視窗管理腳本或底層 X11 擴充，它可能仍然受限制。

效能誰更好

不能簡單說 Wayland 一定比 X11 快，或者 X11 一定更穩定。實際表現取決於桌面環境、顯示卡驅動、應用類型和使用場景。

一般來說：

普通桌面動畫和高刷新率顯示，Wayland 往往更順；
混合 DPI、多顯示器縮放，Wayland 更有優勢；
老應用和特殊工具，X11 更少踩坑；
遊戲場景，Wayland 透過 Xwayland 和原生支援已經很成熟，但個別遊戲或擷取工具仍可能偏向 X11；
專業圖形、遠端控制和自動化腳本，要按具體工具測試。

對大多數普通使用者來說，效能不是最主要差異。真正決定體驗的是相容性、安全邊界、顯示器配置和輸入裝置支援。

截圖、錄影和螢幕共享

這是 Wayland 最常被誤解的地方。

在 X11 下，截圖和錄影工具通常可以直接抓螢幕。這很方便，但也意味著惡意程式更容易偷看螢幕。

在 Wayland 下，應用不能隨便抓螢幕。截圖、錄影、直播和會議共享通常要透過桌面入口和 PipeWire，並經過使用者授權。這更安全，但也要求應用支援新的介面。

所以如果你發現某個會議軟體、錄影工具或截圖工具在 Wayland 下不好用，不一定是 Wayland「不支援」，更可能是應用沒有適配好入口或 PipeWire。

遊戲該選哪個

現在 Linux 遊戲已經不再是 X11 獨占。 Steam、Proton、Mesa、KDE、GNOME、Gamescope、Xwayland 都讓 Wayland 遊戲體驗進步很大。

如果你使用 AMD 或 Intel 顯示卡，Wayland 通常已經可以作為日常遊戲環境。如果你使用 NVIDIA，新驅動下也越來越可用，但建議保持驅動和桌面環境較新。

遊戲玩家可以這樣選擇：

普通 Steam / Proton 遊戲：先試 Wayland；
遇到錄製、直播、疊加層、輸入延遲問題：切 X11 對比；
使用 Gamescope：Wayland 生態更合適；
使用舊顯示卡或舊驅動：X11 可能省心。

遠端桌面和自動化

如果你的工作流依賴遠端桌面、視窗自動化或全域鍵鼠控制，需要更謹慎。

X11 在這些場景裡工具多，行為直接。例如腳本控制視窗、模擬點擊、抓取指定視窗內容，在 X11 下通常更容易。

Wayland 出於安全設計，不允許普通應用隨便控制其他視窗。這意味著自動化工具需要走桌面環境提供的介面，或者使用專門的遠端桌面實現。 GNOME、KDE 都在補齊這類能力，但不同桌面之間一致性還不如 X11。

如果你是普通桌面使用者，Wayland 沒問題。如果你是重度遠端控制、自動化測試、視窗管理腳本使用者，X11 仍然可能更適合。

怎麼判斷自己正在用哪個

可以用環境變數查看目前工作階段類型：

`1`	`echo $XDG_SESSION_TYPE`

如果輸出是：

wayland

說明目前是 Wayland 工作階段。

如果輸出是：

x11

說明目前是 X11 工作階段。

在 GNOME、KDE 等桌面登入介面，通常可以透過齒輪選單或工作階段選擇項切換 X11 / Wayland。

選擇建議

可以按下面方式判斷：

場景	建議
新電腦、主流發行版、普通辦公	優先 Wayland
GNOME / KDE 最新版本	優先 Wayland
多顯示器、HiDPI、高刷新率	優先 Wayland
老軟體、舊顯示卡、舊驅動	優先 X11
遠端桌面、視窗腳本、自動化測試	優先 X11 或逐項測試 Wayland
遊戲	先試 Wayland，出問題切 X11
會議共享、錄影	看具體軟體對 PipeWire / 入口支援
安全敏感、多使用者桌面	優先 Wayland

Wayland 是未來方向，但 X11 還沒有馬上消失。兩者會繼續共存一段時間。

小結

X11 的優勢是成熟、相容、工具多。它適合老軟體、遠端桌面、視窗自動化和一些特殊工作流。缺點是安全邊界弱，架構複雜，面對現代多螢幕、高刷新率和混合縮放時不夠清爽。

Wayland 的優勢是架構更現代、安全性更好、顯示路徑更直接，也更適合 HiDPI、觸控板手勢、多顯示器和現代桌面體驗。缺點是部分老工具、遠端控制、截圖錄影和輸入法場景仍有適配成本。

普通使用者可以把 Wayland 當作預設選擇。如果遇到某個軟體或外設不正常，再切回 X11 驗證。對 Linux 桌面來說，這不是站隊問題，而是根據硬體、軟體和工作流選擇更省心的方案。

參考來源：

Linux Kernel 7.0 更新特性整理

Fri, 01 May 2026 14:46:07 +0800

Linux 核心版本號一直不是語意化版本號，主版本號提升更多是維護節奏上的滾動。 Linus Torvalds 在發布郵件中也把 7.0 描述成一次正常發布：最後一週主要是網路、架構、工具、自測和驅動等方向的小修小補。

真正值得關注的是這批增量更新本身。 Linux 7.0 覆蓋了檔案系統、記憶體管理、硬體支援、安全隔離、Rust 支援和驅動清理等多個方向。

檔案系統：XFS、EXT4、NTFS3 都有變化

Linux 7.0 最容易被感知的一類更新在檔案系統。

XFS 引入了自我修復相關能力。配合新的通用檔案系統錯誤回報機制，檔案系統可以把 metadata 損壞和 I/O 錯誤透過更統一的方式傳遞到使用者空間。在合適的系統服務配合下，XFS 可以在檔案系統仍然掛載時自動處理部分修復流程。這並不等於所有磁碟損壞都能無痛修好，但對伺服器和長期執行系統來說，錯誤發現和修復鏈路更完整。

EXT4 繼續改善並行 direct I/O 寫入表現。如果機器上經常有備份、建置、下載、資料庫或日誌任務同時寫盤，這類最佳化會讓並行寫入路徑更穩。它不是那種所有桌面使用者馬上能感知的變化，但對高 I/O 場景有意義。

NTFS3 也獲得了較大的驅動更新，包括 delayed allocation、基於 iomap 的檔案操作，以及大目錄掃描場景下更好的 readahead。如果經常在 Linux 下存取 Windows 分割區或外接 NTFS 磁碟，這類更新更值得留意。

此外，exFAT 改進了多 cluster 順序讀取，部分小 cluster 裝置在順序讀取時會更快。

記憶體與 swap：繼續最佳化記憶體壓力下的表現

Linux 7.0 延續了前幾個版本對 swap 子系統的整理。這次重點之一是改進從 swap 讀回記憶體的路徑，尤其是多個行程共享同一批被換出的記憶體頁時，吞吐會更好。

對桌面使用者來說，這不一定會變成明顯的「系統突然更快」。但在記憶體緊張、容器密集、Redis 這類服務啟用持久化，或 zram 搭配後端磁碟的場景裡，這類變化會減少系統在記憶體壓力下的抖動。

zram 相關路徑也有最佳化。過去某些情況下，核心需要先把 zram 頁面解壓再寫入後端裝置；新的路徑可以直接寫入壓縮資料，減少不必要的處理。

CPU 與效能：Intel TSX auto、執行緒和檔案操作更快

Linux 7.0 對 Intel TSX 的預設策略做了調整。過去因為安全問題，TSX 在不少處理器上預設關閉。現在核心採用更細的 auto 策略：受影響的 CPU 繼續關閉，不受影響或適合啟用的 CPU 可以自動打開。

這對部分多執行緒工作負載會有幫助，尤其是依賴事務同步擴展的應用。不過它不是通用加速開關，實際收益仍取決於 CPU 型號和應用是否使用相關能力。

另外，Linux 7.0 還包含 PID 分配、執行緒建立/銷毀、檔案 open/close 等路徑的最佳化。這些最佳化通常不會單獨成為宣傳點，但會累積成系統回應和高並行服務上的細微收益。

硬體支援：新平台預備和現有裝置改善

Linux 7.0 繼續做大量硬體啟用工作。這類更新通常分成兩類：一類是還沒大規模上市的新平台預備，另一類是已經在使用者手上的裝置改善。

新平台方面，Linux 7.0 包含更多 Intel Nova Lake、Intel Crescent Island、AMD 新圖形 IP、AMD Zen 6 相關準備工作。這類改動對普通使用者不一定馬上有用，但它決定了新硬體上市後能否更快獲得主線核心支援。

ARM64 和單板機方向，Rockchip RK3588/RK3576 的 H.264/H.265 硬體影片解碼進入主線支援範圍。這意味著 Orange Pi 5、Radxa ROCK 5 等裝置不再完全依賴廠商 BSP 核心才能獲得硬解體驗。

筆電和外設方向也有不少細節更新：

ASUS WMI 改善 ROG、TUF 機型的背光、鍵盤燈和風扇快捷鍵支援；
HP WMI 增加部分 Victus 機型的手動風扇控制和音訊指示燈修正；
Lenovo WMI 為 Legion 裝置暴露更多 HWMON 監控資訊；
Intel Xe 圖形驅動暴露更多溫度感測器；
Intel Arc B 系列獨顯可以進入更深的 PCIe 省電狀態；
Rock Band 4 藍牙吉他和 Logitech K980 藍牙鍵盤獲得更好的核心支援。

這些變化單看都不大，但對筆電、遊戲裝置、開發板和外設使用者來說，主線核心支援越完整，後續發行版維護越省心。

安全與隔離：io_uring 可以做 BPF 過濾

Linux 7.0 給 io_uring 增加了 BPF 過濾能力。這對容器、沙箱和高安全要求環境比較重要。

過去一些管理員為了降低攻擊面，會直接停用 io_uring。現在透過 BPF 過濾，可以更細地限制允許的操作，而不是只能在「全開」和「全關」之間選擇。

這不會讓 io_uring 的安全風險自動消失，但給系統管理員和執行時框架提供了更可控的隔離手段。

Rust 支援不再只是實驗標籤

Linux 7.0 中，Rust for Linux 的狀態進一步穩定。這不意味著核心會大規模改寫成 Rust，也不意味著 C 會被替代。

更準確地說，Rust 在核心裡的基礎設施已經進入更正式的階段。後續新驅動、新子系統或部分安全敏感程式碼，可以在合適場景下選擇 Rust。這是一條漸進路線：先把介面、建置、文件和維護流程打穩，再讓具體程式碼慢慢增加。

清理舊功能：laptop_mode 被移除

Linux 7.0 移除了 laptop_mode。這是一個歷史很久的省電功能，主要面向機械硬碟時代的筆電，透過減少磁碟喚醒來節省電量。

現在筆電主流已經是 SSD，核心裡的記憶體回收、區塊裝置和檔案系統路徑也發生了很多變化。繼續保留這種老機制會增加維護成本，而且測試覆蓋並不理想。移除它可以減少舊程式碼對現代路徑的干擾。

AI 相關按鍵：面向新一代鍵盤互動

Linux 7.0 增加了幾個新的 HID keycode，用於上下文 AI 互動場景，例如對選中內容執行動作、插入上下文生成內容、發起上下文查詢等。

這並不是核心內建 AI 功能。它更像是給未來筆電鍵盤和外設留好輸入事件定義，讓桌面環境、應用或廠商工具可以識別這些按鍵。實際能做什麼，仍取決於發行版、桌面環境和應用層整合。

是否應該馬上升級

如果你使用滾動發行版，Linux 7.0 很可能會自然進入系統更新。如果你使用 Ubuntu 26.04 LTS 這類新發行版，7.0 也會作為預設或主要核心版本出現。

但如果你的機器是生產環境、NAS、虛擬化宿主機，或依賴閉源驅動和專有核心模組，不建議只因為版本號變成 7.0 就立刻手動升級。更穩妥的做法是：

等發行版提供正式核心套件；
查看顯示卡、網卡、ZFS、VirtualBox、VMware、DKMS 模組相容性；
在測試機或快照環境裡先驗證；
關注 7.0.x 小版本修復情況。

截至 kernel.org v7.x 目錄，7.0.1、7.0.2、7.0.3 已經陸續發布。如果要手動建置或測試，優先選擇最新的 7.0.x 穩定小版本，而不是只盯著最初的 7.0 tarball。

小結

Linux Kernel 7.0 不是一次「因為大版本號而重寫一切」的發布。它更像是一次覆蓋面很廣的常規核心更新：檔案系統更可靠，swap 和 I/O 路徑繼續最佳化，新硬體支援繼續前移，Rust、io_uring 隔離和 HID 輸入定義也在補齊長期演進所需的基礎設施。

對普通桌面使用者來說，最實際的變化可能來自硬體支援、圖形驅動、省電和檔案系統修復。對伺服器和開發者來說，XFS 錯誤回報、自我修復、io_uring BPF 過濾、swap 最佳化和新平台支援更值得關注。

參考來源：

Ubuntu 26.04 LTS 的 GPU 與硬體支援更新：CUDA、ROCm、DPC++ 和更多平台變化

Sun, 26 Apr 2026 19:35:57 +0800

如果上一篇比較像是 Ubuntu 26.04 LTS 的桌面總覽，那這篇可以看作它在硬體與算力側的補充版。官方在這一輪 26.04 裡，把不少和 AI、GPU 計算、平台相容性直接相關的內容都推進了主倉庫或正式支援範圍。

先說結論：這次最值得關注的，不只是桌面和核心升級，而是 Ubuntu 正在把 Intel、NVIDIA、AMD 三家的 GPU 計算堆疊，更系統地納入發行版生態。

1. Intel DPC++ 與相關元件進入 Ubuntu Archive

從 26.04 開始，Intel 開源的 oneAPI DPC++ 編譯器已經可以直接從 Ubuntu Archive 取得，用來建構 SYCL 程式碼。其執行階段也包含面向 Intel GPU 的配接器。

同時進入 Ubuntu 倉庫的，還有兩個相關元件：

oneDPL，也就是 DPC++ library，提供更高生產力的開發介面
oneDNN，而且是基於 dpclang-6 建構，可在 Intel GPU 上運行

這代表如果你本來就在看 SYCL、異質運算，或是 Intel GPU 上的 AI 工作負載，Ubuntu 現在給出的路徑會直接很多，不再需要完全依賴一套獨立維護的外部環境。

官方也特別提醒一點：如果要實際調用這些 Intel GPU 相關能力，使用者需要加入 render 群組。

2. NVIDIA CUDA toolkit 現在也能直接 `apt install`

對很多開發者和維運人員來說，這可能是這份更新裡最實用的一條。

從 26.04 開始，NVIDIA CUDA toolkit 已經可以直接透過 Ubuntu Archive 安裝。命令就是：

`1`	`sudo apt install cuda-toolkit`

這背後的意義，不只是「少打幾條指令」。

對以 Ubuntu 為目標平台發佈軟體的開發者來說，新的模式意味著可以直接宣告對 CUDA runtime 的依賴，後續安裝與相容性由 Ubuntu 在發行版層面處理。這會讓 CUDA 在 Ubuntu 上更容易取得，也更接近系統原生能力，而不是額外疊上一層需要單獨維護的外部軟體堆疊。

3. AMD ROCm 7.1.0 進入 Universe

AMD 這邊，Ubuntu Universe 現在已經包含 ROCm 7.1.0。

這套函式庫主要提供的是：

面向 AMD GPU 的 AI 訓練與推論後端能力
機器學習與高效能運算相關的軟體基礎設施

官方還提到，Canonical 會在自己的 CI/CD 流程裡持續測試 ROCm 相關元件。除了 autopkgtests，也覆蓋了一些使用者態應用，包括：

llama.cpp
pytorch
Blender
Lemonade Server

這條資訊其實很關鍵，因為它說明 Ubuntu 不是單純「把套件放進倉庫」，而是把 ROCm 當成一套可維護的軟體堆疊來驗證。

4. 這一輪真正的重點，是三家 GPU 生態都在落地

把 DPC++、CUDA 和 ROCm 放在一起看，會更容易理解 26.04 的方向：

Intel：推進 SYCL / oneAPI 相關能力進入官方倉庫
NVIDIA：讓 CUDA toolkit 具備發行版級的安裝路徑
AMD：把 ROCm 7.1.0 納入 Universe，並持續做測試

如果你平常會在 Ubuntu 上碰到這些場景，這一輪更新會比較有感：

本地大模型推論
GPU 加速訓練或微調
Blender、科學運算、HPC
需要在多種 GPU 平台之間切換的開發環境

換句話說，Ubuntu 現在不只是「能裝顯卡驅動」，而是開始更完整地承接 AI 與 GPU 計算所需的使用者態軟體堆疊。

5. NVIDIA Dynamic Boost 預設啟用

從 25.04 開始，支援的 NVIDIA 筆電已經預設啟用 Dynamic Boost。

這個功能的邏輯很直接：系統會根據當前負載，在 CPU 和 GPU 之間動態分配功耗。對遊戲場景來說，常見收益就是在需要時把更多功率給 GPU，以換取更高效能。

不過它有兩個前提：

裝置接上交流電
GPU 負載夠高

在電池供電狀態下，它不會介入。

6. Intel 新一代內顯與獨顯支援持續往前推進

Ubuntu 這一輪也把對新 Intel GPU 的支援繼續往前推，重點包括：

整合顯示：

Intel Core Ultra Xe2
Intel Core Ultra Xe3

獨立顯示：

Intel Arc 5 B570
Intel Arc 5 B580
Intel Arc Pro B50
Intel Arc Pro B60
Intel Arc Pro B65
Intel Arc Pro B70

圍繞這批裝置，官方也列出了一些已經到位的特性：

基於 Intel Embree 的 GPU 與 CPU 光線追蹤渲染效能提升，像 Blender 4.2+ 這類應用可受益
“Battlemage” 裝置支援 AVC、JPEG、HEVC 和 AV1 的硬體視訊編碼
Intel Compute Runtime 引入新的 CCS 最佳化
已啟用 Intel Xe GPU 偵錯支援

如果你更關注後續版本，25.10 還會繼續帶進一些新能力，例如：

借助 Linux kernel 6.17 初步支援代號 Panther Lake 的下一代 Intel 用戶端平台
改進 IOMMU、PCIe 子系統與多 GPU 支援
Mesa 25.2.3 為 Battlemage 和 Panther Lake 啟用 VK_KHR_shader_bfloat16
intel-media-driver 25.3.0 增加 Panther Lake 解碼與 VP9 編碼支援
intel-compute-runtime 25.31 調整 Level Zero 的 USM 池與本地顯存事件配置策略
level-zero 1.24 與 level-zero-raytracing 1.1.0 帶來更完整的規範與 RTAS 擴充支援

7. Nvidia 桌機的掛起恢復也更穩定了

從 25.10 開始，Ubuntu 在專有 Nvidia 驅動中啟用了掛起恢復支援，以減少桌機喚醒後的損毀與卡死問題。

這類改動不算「看得見的新功能」，但對實際日常穩定性很重要，尤其是長時間開機、經常掛起恢復的桌面環境。

8. ARM、樹莓派、RISC-V 和 IBM Z 也有硬性門檻變化

除了 GPU 軟體堆疊，這份發行說明裡還有幾條平台層面的變化很值得單獨記一下。

ARM64 桌面平台

從 25.10 開始，linux-generic 的 ARM64 核心會提供更廣泛的桌面相容性，覆蓋那些使用 UEFI 開機的 ARM64 桌面平台。

Raspberry Pi 新開機配置

25.10 引入、26.04 持續調整的一個變化，是樹莓派開機分割區的新配置。

它的目標是提升開機可靠性：新寫入的開機資源會先被「測試」，確認沒問題後才會提交為新的 “known good” 集合。

這裡最需要注意的是韌體時間要求：

Pi 3 / 3+ / CM3+ / Zero 2W：不需要額外操作，開機韌體就在映像檔內
Pi 4 / 400 / CM4：開機韌體日期不得早於 2022-11-25
Pi 5 / 500 / CM5：開機韌體日期不得早於 2025-02-11

檢查命令是：

`1`	`sudo rpi-eeprom-update`

如果韌體太舊，而且你使用的是 Ubuntu 24.04 LTS 或更新版本，可以這樣更新：

1
2

sudo rpi-eeprom-update -a
sudo reboot

Raspberry Pi 桌面映像改用 desktop-minimal

從 25.10 開始，樹莓派版 Ubuntu Desktop 映像改為基於 desktop-minimal，而不是完整的 desktop seed。

官方給出的收益很明確：預設安裝的應用更少，未壓縮映像與實際系統都能節省大約 777MB 空間。

如果升級後想批次移除這批預設應用，可以使用：

`1`	`sudo apt purge ubuntu-desktop --autoremove`

如果你想保留其中某些應用，先用 apt 把它們標記為手動安裝即可。

樹莓派 swap 改由 cloud-init 處理

從 25.10 開始，樹莓派桌面映像裡的 swap 檔建立改由 cloud-init 負責。
如果你想在首次開機前自訂 swap 大小，可以直接修改開機分割區上的 user-data。

RISC-V 門檻上調

從 25.10 開始，Ubuntu 26.04 LTS 的 RISC-V 版本要求硬體實作 RVA23S64 ISA profile。

不符合這個要求的裝置，已經不能執行 Ubuntu 26.04 LTS。如果你手上還是較早的 RVA20 處理器板卡，那就得繼續留在 Ubuntu 24.04 LTS 這一代支援線上。

按照官方說明，截至 2026 年 4 月，現實裡還沒有可用的 RVA23S64 硬體，因此目前唯一受支援的平台，其實是基於 QEMU 並使用 -cpu rva23s64 配置的虛擬化環境。

IBM Z 最低要求提高到 z15

從 26.04 開始，s390x 架構最低要求提高到 z15。

這意味著：

z14 / LinuxONE II 以及更早的平台，已經不能安裝 Ubuntu 26.04 LTS
z15 / LinuxONE III 以及更新平台，會有更好的效能表現

9. 哪些人更適合先看這篇

如果你屬於下面這些場景，這篇會比桌面總覽更值得優先看：

在 Ubuntu 上做 CUDA、ROCm、SYCL 或本地 AI 推論
用 Intel、NVIDIA、AMD GPU 做開發或計算任務
維護 Raspberry Pi、ARM64、RISC-V、IBM Z 等非標準 x86 平台
對升級後的驅動、執行時、倉庫可用性和平台門檻更敏感

10. 一句話總結

Ubuntu 26.04 LTS 在硬體與 AI 軟體堆疊上的重點，不是哪一家顯卡單獨增強了什麼，而是 Intel 的 DPC++、NVIDIA 的 CUDA、AMD 的 ROCm，都開始以更官方、更多倉庫內、也更可維護的方式進入 Ubuntu 生態。

如果你過去把 Ubuntu 當成「先裝系統，再自己拼 GPU 環境」的底座，那從 26.04 開始，它已經更像一個願意主動承接 AI 與異質運算工作負載的發行版了。

Ubuntu 26.04 LTS 發布：桌面大更新，GNOME 50 和 Linux 7.0 全來了

Sun, 26 Apr 2026 16:10:25 +0800

Ubuntu 26.04 LTS 已在 2026 年 4 月 23 日 發布，代號是 Resolute Raccoon。這次是新的長期支援版，官方支援週期到 2031 年 4 月；如果使用 Ubuntu Pro，安全維護可延長到 10 年。

如果你是從 Ubuntu 24.04 LTS 升級上來，這一版不只是一次常規更新，而是把 24.10、25.04、25.10 之間的主要變化一起帶了進來。所以這篇更適合當成一份「升級前先看什麼」的快速摘要。

如果只看這版最核心的更新，可以先記住四件事：

GNOME 50 進入 LTS，桌面體驗和顯示支援明顯往前走了一步
Linux kernel 7.0 成為新基線，底層硬體支援和後續維護週期一起更新
Ubuntu Desktop 正式全面轉向 Wayland
預設應用集體換新，Firefox、LibreOffice、Thunderbird、GIMP 都是大版本更新

1. 重點更新先看這幾項

Ubuntu 26.04 LTS 是長期支援版，標準支援到 2031-04
桌面環境升級到 GNOME 50
通用核心升級到 Linux kernel 7.0
Ubuntu Desktop 工作階段現在只提供 Wayland
從更舊版本升級時，不能直接跨太多版本跳到 26.04

如果你現在還在 Ubuntu 22.04 LTS 或 25.04，官方建議先升到 Ubuntu 24.04 LTS 或 25.10，再繼續升級到 26.04 LTS。

2. 最大變化一：GNOME 50 進 LTS 了

這次桌面側最明顯的變化，是 GNOME 50 終於進了 LTS。對一般使用者來說，它帶來的不是某一個單點新功能，而是整套桌面體驗一起變順了：

小螢幕裝置和窄視窗的可用性更好
通知支援按應用分組
HDR、VRR、分數縮放這些顯示相關能力持續完善
遠端桌面、Wayland、NVIDIA 驅動下的流暢度和穩定性都在往前走
無障礙支援繼續增強，Orca 螢幕閱讀器也有明顯更新

Ubuntu 自己也補了一些更實用的改動：

GNOME Shell 全域搜尋可以直接搜可用的 snap 應用
也可以在搜尋裡直接發起網頁搜尋
Yaru 主題繼續向上游 GNOME 風格靠攏
snap 應用和桌面的權限、檔案存取、拖放體驗更自然

如果你平時主要用桌面版，這一代 LTS 的重點其實不是「樣子大變」，而是很多過去零散的小摩擦在這一版裡一起被磨平了。

3. 最大變化二：預設應用大面積換新

和 24.04 LTS 相比，26.04 LTS 內建應用整體更新幅度不小：

Firefox 升到 150
LibreOffice 從 24.2 升到 25.8
Thunderbird 升到 140
GIMP 從 2.10 跨到 3.2

另外還有幾項和日常使用關係很大的替換：

PDF 檢視器改為 Papers，取代 Evince
圖片檢視器改為 Loupe
終端機改為 Ptyxis
系統監視器改為 Resources
預設影片播放器改為 Showtime

這些變化背後的共同方向很明確：Ubuntu 正在更徹底地擁抱新一代 GTK4、libadwaita 和部分以 Rust 重寫過的 GNOME 應用堆疊。

4. 最大變化三：Wayland 成了唯一桌面工作階段

這一條對很多老使用者最關鍵。

從 25.10 開始的變化，在 26.04 LTS 上正式落穩：Ubuntu Desktop 現在只執行在 Wayland 後端上，因為 GNOME Shell 已經不能再作為 X.org 工作階段執行。

這不等於老應用全都不能用了。官方說明裡明確提到，面向 X.org 的應用仍然可以透過 XWayland 相容層繼續執行。但如果你的工作流裡還依賴某些老顯示卡驅動、遠端桌面方式、錄影工具或輸入法細節，這一條仍然值得你在升級前先確認。

5. 最大變化四：Linux kernel 7.0 和底層堆疊一起升級

Ubuntu 26.04 LTS 的 GA generic 堆疊從 Linux 6.8 升到 Linux 7.0，HWE 堆疊也統一到 7.0。

官方點到的幾項底層變化裡，比較值得一般使用者和維運注意的是：

桌面版和伺服器版預設啟用 crash dump
sched_ext 帶來新的排程擴充機制，方便開發者用 eBPF 方式實作排程策略
linux-lowlatency 二進位套件退出，改由 linux-generic 配合 lowlatency-kernel 使用者空間套件實現低延遲調校
amd64v3 架構變體可選啟用，但預設仍然是 opt-in

如果你機器比較新，amd64v3 是一個可以關注的點。官方給出的啟用方式是：

1
2
3

echo 'APT::Architecture-Variants "amd64v3";' | sudo tee /etc/apt/apt.conf.d/99enable-amd64v3
sudo apt update
sudo apt upgrade

不過這項能力預設不會自動打開，Ubuntu 仍然優先把相容性放在第一位。

6. 硬體需求和安裝門檻

官方給出的 Ubuntu Desktop 26.04 LTS 建議底線是：

2 GHz 雙核心處理器或更高
至少 6 GB RAM
至少 25 GB 可用儲存空間

如果機器配置偏低，官方更建議考慮 Xubuntu、Lubuntu 這類官方風味版本。
伺服器版門檻更低，文件裡提到可以低到 1.5 GB RAM 和 4 GB 儲存起步，具體還是要看你的服務負載。

7. 這版適合誰優先升級

如果你現在就在 24.04 LTS，而且想要這些東西，26.04 LTS 會很值得看：

更新一代完整桌面堆疊，而不只是補丁修修補補
更成熟的 Wayland 和顯示支援
更新的預設應用生態
新一代核心與更長的後續支援週期

但如果你高度依賴老 X11 工作流、特殊驅動、客製桌面外掛，或者你現在的生產環境對「能跑就別動」非常敏感，那升級前最好還是先過一輪相容性驗證。

8. 一句話總結

Ubuntu 26.04 LTS 的價值，不在於某一個特別炸眼的新功能，而在於它把過去兩年的桌面、核心、應用和相容性演進，一次性沉澱進了新的 LTS 基線裡。

如果你要找一句最簡短的判斷，那就是：這是一版偏「整體變穩、整體變新」的 Ubuntu LTS，而不是只靠單個賣點撐起來的版本。

理解 nftables 框架：表、鏈、規則和集合

Sat, 18 Apr 2026 10:31:12 +0800

學習 nftables 時，容易一開始就陷入命令細節：怎麼新增規則、怎麼刪除 handle、怎麼寫連接埠匹配。命令當然重要，但如果先把框架概念理清楚，後面讀規則、排查問題和設計規則集都會輕鬆很多。

可以把 nftables 理解成一套分層結構：

table 負責隔離規則空間。
family 決定規則處理哪類網路協定。
chain 決定規則在什麼階段執行。
rule 負責具體匹配和動作。
set、map、verdict map 用來減少重複規則，讓規則集更易維護。

下面按概念逐層說明。

table：規則的命名空間

table 是 nftables 裡最外層的規則容器。不同 table 之間相互隔離，因此常見做法是把一組相關規則放進同一個 table。

例如，你可以把過濾規則、NAT 規則或自訂測試規則分開放。這樣做的好處是邊界清楚：除錯時知道自己在改哪一組規則，清理時也不容易誤刪無關內容。

table 本身不會直接處理封包。真正參與封包處理的是 table 裡面的 chain 和 rule。

family：規則面對哪類協定

建立 table 時需要選擇 family。它決定這張表裡的規則適用於哪類封包。

常見 family 可以這樣理解：

ip：只處理 IPv4。
ip6：只處理 IPv6。
inet：同時處理 IPv4 和 IPv6。
arp：處理 ARP。
bridge：處理橋接層流量。
netdev：更靠近網路設備入口，適合較早階段處理流量。

日常寫普通防火牆規則時，inet 很常用。它可以把 IPv4 和 IPv6 規則放在同一個 table 裡，避免維護兩套結構相似的規則。

chain：規則執行的位置

chain 是 rule 的列表。封包進入某個 hook 後，會按順序經過 chain 裡的規則。

chain 大致可以分為兩類：

基本 chain：掛到核心網路路徑的某個 hook 上，會被封包流程主動呼叫。
常規 chain：不直接掛 hook，需要被其他規則跳轉呼叫。

基本 chain 通常會指定幾個關鍵屬性：

type：這條 chain 的用途，例如 filter、nat、route。
hook：掛在哪個處理階段，例如 prerouting、input、forward、output、postrouting。
priority：同一個 hook 上有多條 chain 時，誰先執行。
policy：沒有規則匹配時的預設動作，常見是 accept 或 drop。

理解 chain 的關鍵是：規則不是「隨便寫在哪裡都能生效」。同一條規則放在 input、forward 或 output，含義完全不同。

rule：匹配條件加動作

rule 是 nftables 裡真正做判斷的地方。它通常由兩部分組成：

匹配條件：例如來源 IP、目標 IP、協定、連接埠、介面、連線狀態。
動作：例如 accept、drop、reject、counter、jump、return。

規則會按順序求值。封包命中某條會終止流程的動作後，就不會繼續執行後面的規則。沒有命中時，則繼續往下走，直到 chain 結束或觸發預設策略。

這也是為什麼規則順序很重要：更具體的規則通常要放在更寬泛的規則前面，否則可能永遠沒有機會被執行。

set：把一組值放在一起

如果有很多 IP、連接埠或介面需要匹配，直接寫多條規則會很難維護。set 用來把一組同類型的值集中管理。

例如，一組可信 IP、一組禁止存取的連接埠、一組需要限速的位址，都可以放進 set。規則只需要判斷某個值是否屬於這個 set。

set 的好處是：

規則數量更少。
可讀性更好。
後續增刪元素更方便。

當規則裡出現大量重複條件時，通常就該考慮用 set。

map：把匹配值映射成結果

map 可以理解成「查表」。它根據一個輸入值返回一個結果。

例如，不同連接埠映射到不同標記，不同位址映射到不同處理參數，都可以透過 map 表達。相比寫多條 if/else 式規則，map 更集中，也更容易維護。

set 關心的是「是否在集合裡」，map 關心的是「這個值對應什麼結果」。

verdict map：把匹配值映射成動作

verdict map 是 map 的一個重要用法：它把匹配值映射成 verdict，也就是規則動作。

例如，不同 IP 段可以對應 accept、drop 或跳轉到不同 chain。這樣可以把很多分支判斷壓縮到一個結構裡。

當規則集開始變複雜時，verdict map 很有用。它能減少重複規則，也能把策略表達得更像一張表，而不是一長串判斷語句。

從概念看規則設計

設計 nftables 規則時，可以按這個順序思考：

先確定規則屬於哪個 family。
再決定放進哪個 table。
然後選擇合適的 hook 和 chain。
最後編寫具體 rule。
如果重複條件很多，再引入 set、map 或 verdict map。

這樣寫出來的規則會更容易維護，也更容易排錯。

小結

nftables 的概念並不複雜，但層級很重要：

table 管規則邊界。
family 管協定範圍。
chain 管執行位置。
rule 管匹配和動作。
set、map、verdict map 管複雜度。

先理解這些概念，再去看具體命令，會比直接背命令更穩。尤其是在規則集變多以後，概念清楚能幫助你判斷：問題到底出在協定範圍、執行階段、規則順序，還是匹配條件本身。

參考

https://docs.redhat.com/zh-cn/documentation/red_hat_enterprise_linux/10/html/configuring_firewalls_and_packet_filters/concepts-in-the-nftables-framework

nftables 快速入門：表、鏈、規則和常用操作

Sat, 18 Apr 2026 10:22:07 +0800

nftables 是 Linux 上常用的封包過濾和防火牆規則管理工具。如果只是做設備連線控制、流量統計、連接埠匹配或簡單限速，不需要一開始就把完整規則體系全部學完，先理解三個概念就夠了：

table：規則的容器。
chain：規則執行的位置，通常會掛到某個 hook 上。
rule：真正的匹配條件和動作。

下面整理一套最小可用的入門流程，適合先在測試環境裡做實驗。

基礎結構

先準備幾個變數，後面的命令會重複使用：

table=customtable
chain=custom_control
target=drop
ip=192.168.18.251
mac=00:00:01:02:03:04

建立一個同時支援 IPv4 和 IPv6 的 inet table：

`1`	`nft add table inet $table`

再建立一條掛在 forward 階段的 chain：

`1`	`nft add chain inet $table $chain { type filter hook forward priority 0\; }`

這裡的 type filter 表示做過濾規則，hook forward 表示處理經過轉發的封包。

常見匹配方式

按來源 IP 匹配，通常可以理解為設備上傳方向：

`1`	`nft add rule inet $table $chain ip saddr $ip $target`

按目標 IP 匹配，通常可以理解為設備下載方向：

`1`	`nft add rule inet $table $chain ip daddr $ip $target`

按 MAC 位址匹配時，可以用 ether saddr 控制上行：

`1`	`nft add rule inet $table $chain ether saddr $mac $target`

需要注意的是，在經過橋接、轉發或位址轉換的網路裡，下行封包未必能可靠用目標 MAC 過濾。實際做設備連線控制時，優先從 ether saddr 或 IP 規則開始驗證。

匹配連接埠時，可以同時覆蓋 TCP 和 UDP：

`1`	`nft add rule inet $table $chain { tcp, udp } dport 22 $target`

如果要匹配連接埠範圍，可以使用比較表達式：

`1`	`nft add rule inet $table $chain tcp dport \>= 1024 $target`

統計單個設備流量

如果只是想統計某個 IP 的上下行流量，可以用 counter return。這樣命中後記錄計數並返回，後面還有其他統計規則時，能減少繼續匹配的開銷。

1
2

nft add rule inet $table $chain ip saddr $ip counter return
nft add rule inet $table $chain ip daddr $ip counter return

查看統計結果：

`1`	`nft list chain inet $table $chain`

如果需要看到每條規則的 handle，加上 -a：

`1`	`nft -a list chain inet $table $chain`

handle 很重要，因為 nftables 刪除單條規則時通常要靠它定位。

簡單限速

限速可以用 limit rate over。例如按 MAC 位址限制超過指定速率的流量：

rate=10
unit=mbytes

nft add rule inet $table $chain ether saddr $mac limit rate over $rate $unit/second drop

這裡的 mbytes、kbytes 可以按日常理解的 M、K 來看，不需要再手動做 8 倍換算。實際使用時建議先用較寬鬆的值測試，確認命中方向和效果後再收緊。

刪除和清理規則

先查看帶 handle 的規則：

`1`	`nft -a list chain inet $table $chain`

再按 handle 刪除某條規則：

`1`	`nft delete rule inet $table $chain handle <handle>`

清空某條 chain：

`1`	`nft flush chain inet $table $chain`

刪除 chain：

`1`	`nft delete chain inet $table $chain`

刪除整個 table：

`1`	`nft delete table inet $table`

日常除錯時，建議先只清理自己建立的 table，不要直接改系統或其他服務自動生成的 table。這樣即使規則寫錯，也更容易回滾。

使用建議

使用 nftables 時，可以優先自己建立獨立的 table 和 chain。這樣做有兩個好處：

不容易和系統已有規則混在一起。
除錯、清空和刪除都更安全。

另外，規則寫完後一定要用 nft list chain 看實際命中情況。尤其是 MAC、介面、連接埠和限速規則，不同設備、橋接方式和系統版本下表現可能不同，先小範圍測試比一次性寫複雜規則更穩。

參考

https://www.right.com.cn/forum/thread-8369750-1-1.html

Ollama 模型預設儲存位置與遷移方法（避免 C 槽爆滿）

Mon, 06 Apr 2026 09:38:00 +0800

本機執行大模型時，最容易先爆掉的通常是系統碟。Ollama 預設會把模型下載到使用者目錄或系統目錄，如果不先規劃路徑，C 槽很快就會被占滿。

Ollama 常見預設模型目錄

Windows：C:\Users\<使用者名稱>\.ollama\models
macOS：~/.ollama/models
Linux：/usr/share/ollama/.ollama/models（不同安裝方式可能略有差異）

Windows：把模型目錄遷移到非系統碟

建議將模型目錄遷移到例如 D:\OllamaModels。核心做法是設定系統環境變數 OLLAMA_MODELS。

1. 建立目標目錄

例如先建立：D:\OllamaModels

2. 設定系統環境變數

變數名稱：OLLAMA_MODELS
變數值：D:\OllamaModels

可在「系統內容 -> 進階 -> 環境變數」中新增，也可使用命令列設定（系統管理員 PowerShell）：

`1`	`[System.Environment]::SetEnvironmentVariable("OLLAMA_MODELS", "D:\OllamaModels", "Machine")`

3. 重啟 Ollama（或重啟系統）

環境變數生效後，重新啟動 Ollama 服務或應用程式。若不確定是否已生效，直接重啟電腦最穩妥。

4. 驗證新目錄是否生效

拉取任意模型後，檢查 D:\OllamaModels 下是否出現新檔案。

5. 清理舊目錄（確認無誤後）

確認模型已在新目錄正常工作，再刪除舊目錄內容，回收 C 槽空間。

常見問題

設定後仍寫入 C 槽怎麼辦

先確認環境變數是「系統變數」，而不是「目前工作階段臨時變數」。
確認 Ollama 行程已重啟。
檢查變數名稱是否正確：必須是 OLLAMA_MODELS。

是否需要遷移舊模型檔案

如果你不想重複下載，可在停止 Ollama 後手動複製舊模型到新目錄，再啟動 Ollama 驗證。

在 Linux 上徹底移除 Ollama（含殘留清理）

Mon, 06 Apr 2026 09:16:29 +0800

如果你需要在 Linux 上徹底移除 Ollama，可以依照下列順序執行。本文會清理服務、執行檔、模型目錄，以及 ollama 使用者與群組。

移除前提醒

以下指令會刪除本機 Ollama 模型檔案（通常位於 /usr/share/ollama），請先確認是否需要備份。
指令預設使用 sudo，請確認目前帳號具備管理員權限。

1. 停止並移除 systemd 服務

sudo systemctl stop ollama
sudo systemctl disable ollama
sudo rm -f /etc/systemd/system/ollama.service
sudo systemctl daemon-reload

2. 刪除 Ollama 執行檔

OLLAMA_BIN="$(command -v ollama)"
if [ -n "$OLLAMA_BIN" ]; then
  sudo rm -f "$OLLAMA_BIN"
fi

3. 刪除 Ollama 相關函式庫目錄（若存在）

如果你的安裝方式在 lib 目錄寫入了 Ollama 檔案，可用下列方式清理：

1
2
3

for d in /usr/local/lib/ollama /usr/lib/ollama /lib/ollama; do
  [ -d "$d" ] && sudo rm -rf "$d"
done

4. 刪除模型與資料目錄

`1`	`sudo rm -rf /usr/share/ollama`

5. 刪除系統使用者與群組（若存在）

1
2

id -u ollama >/dev/null 2>&1 && sudo userdel ollama
getent group ollama >/dev/null 2>&1 && sudo groupdel ollama

6. 驗證是否已完成移除

1
2

command -v ollama || echo "ollama binary not found"
systemctl status ollama || true

若以上檢查都不再找到 ollama，即代表已移除完成。

rsync --delete 參數詳解與清空目錄實務

Sun, 29 Mar 2026 11:00:00 +0800

rsync --delete 的核心作用是：刪除目標目錄中「來源目錄不存在」的檔案，讓目標端與來源端保持一致。

它常用於以下場景：

同步時清理目標端的歷史冗餘檔案
透過空目錄快速清空目標目錄

基礎語法

`1`	`rsync -a --delete 來源目錄/ 目標目錄/`

-a：封存模式，保留權限、時間戳等屬性
--delete：刪除目標端多出的檔案

關鍵注意：來源目錄 結尾是否帶 / 會影響同步行為。帶 / 代表同步目錄內容，不帶 / 代表同步目錄本身。

如果你的目標是「保留目錄結構但清空內容」，可以讓空目錄作為來源進行同步：

# 1) 建立空目錄
mkdir -p /tmp/empty_dir

# 2) 同步並刪除目標目錄中的內容
rsync -a --delete /tmp/empty_dir/ /path/to/target_dir/

這種方式在大目錄場景下通常比逐一刪除更有效率，也更容易寫入自動化腳本。

常用擴展參數

--delete-before：先刪除再傳輸，在部分場景下效率更高
--progress：顯示傳輸與處理進度

示例（清理 Nginx 日誌目錄）：

`1`	`rsync -a --delete --progress /tmp/empty_dir/ /var/log/nginx/`

使用建議

先用 --dry-run 預演，確認刪除範圍再執行
在生產環境操作前，建議先備份目標目錄
對關鍵路徑執行時，優先安排在低峰時段

Git 如何追蹤檔案可執行權限（+x）

Sun, 29 Mar 2026 10:00:00 +0800

在 Linux 環境中，Git 會追蹤檔案的可執行位（+x）。如果你希望腳本在倉庫中被當作「可執行檔」保留下來，需要用 Git 明確記錄這次權限變更。

為檔案新增可執行權限

1
2
3

git update-index --chmod=+x script.sh
git commit -m "chore: mark script.sh as executable"
git push

這條指令會把 script.sh 的可執行位變更加入暫存區。提交並推送後，其他人在拉取或克隆倉庫時也會保留這個權限狀態。

取消檔案可執行權限

1
2
3

git update-index --chmod=-x script.sh
git commit -m "chore: remove executable bit from script.sh"
git push

驗證是否生效

可以用下面的指令檢查工作區權限：

1
2

git clone xxxxxxxxxxxxxxx
ls -l script.sh

如果看到類似 -rwxr-xr-x，表示檔案包含可執行權限；如果是 -rw-r--r--，則表示不可執行。

說明

git update-index --chmod=+x/-x 只會修改 Git 記錄的檔案模式，不會替代你對檔案內容本身的修改。
在團隊協作中，建議把這類權限調整獨立提交，便於審查與追溯。

Linux on KnightLi的博客

pci=nomsi 和 pcie_aspm=off 詳解：Linux 下 SATA 擴展卡不認盤、掉盤、卡死時該怎麼排查

pci=nomsi：禁用消息信號中斷

MSI 是什麼

加上 pci=nomsi 後會發生什麼

pcie_aspm=off：禁用 PCIe 活動狀態電源管理

ASPM 是什麼

加上 pcie_aspm=off 後會發生什麼

兩個參數的區別

是否應該兩個一起加

Ubuntu / Debian 中如何永久生效

還應該檢查哪些地方

小結

CVE-2026-43494 / PinTheft：Linux RDS 與 io_uring 組合出的本地提權風險

漏洞核心是什麼？

為什麼叫 PinTheft

觸發條件並不寬

一分鐘自查

哪些機器更值得優先看？

臨時緩解建議

修復後怎麼驗證

參考資訊

近期四個 Linux 本地提權漏洞影響梳理：Copy Fail、Dirty Frag、Fragnesia 與 ssh-keysign-pwn

四次事件分別影響什麼

Copy Fail：容器和 CI 節點優先級很高

Dirty Frag：後滲透階段的放大器

Fragnesia：同類攻擊面沒有一次性清乾淨

ssh-keysign-pwn：不直接 root，也足夠危險

共同影響：容器隔離不能再被當作強邊界

共同影響：補丁必須落到「正在執行的內核」

共同影響：攻擊面最小化要具體到模組和系統呼叫

建議的處置順序

結論

ssh-keysign-pwn（CVE-2026-46333）解讀：Linux 本地資訊外洩、SSH 主機金鑰與 /etc/shadow 風險

先說結論

漏洞是什麼

為什麼能讀到 SSH 主機私鑰和 /etc/shadow

影響範圍怎麼判斷

應該優先處理哪些機器

修復建議

臨時緩解：收緊 ptrace_scope

是否需要輪換 SSH 主機金鑰

需要監控什麼

常見誤區

處置清單

總結

Dirty Frag、Copy Fail 與 Fragnesia：近期三個 Linux 本地提權漏洞對比

三個漏洞分別是什麼

Dirty Frag：CVE-2026-43284

Copy Fail：CVE-2026-31431

Fragnesia：CVE-2026-46300

相同點：為什麼都危險

不同點：不要用一個補丁思路套全部

影響範圍該怎麼判斷

維運優先級

臨時緩解應該怎麼理解

這三個漏洞說明了什麼

小結

Fragnesia (CVE-2026-46300)：Linux 核心本地提權漏洞影響與緩解

它和 Dirty Frag 是什麼關係

風險為什麼高

已知影響範圍

臨時緩解思路

如果懷疑已經被利用

維運側該優先看哪些機器

小結

Dirty Frag CVE-2026-43284：Linux 本地提權漏洞風險與緩解指南

Dirty Frag 涉及哪些 CVE

技術原因簡單理解

哪些環境需要優先關注

先做修補優先

臨時緩解：停用相關模組

停用前一定要評估業務影響

入侵後檢查不能省

關於 drop_caches

推薦處理順序

總結

Btrfs Scrub 使用指南：資料校驗、自動修復與定期巡檢

scrub 到底檢查什麼

常用命令