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 是否新增持久化。
容器宿主机是否有异常特权容器或挂载。

如果怀疑已经被利用，优先隔离主机、保留证据、轮换凭据，再做清理。不要只靠卸载模块或清缓存就认为安全。

关于 drop_caches

Microsoft 文中提到，在某些入侵后完整性验证场景，可以评估是否清理缓存：

`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，而是一种在线校验流程：读取文件系统中的数据和元数据，验证校验和、超级块、元数据块头以及磁盘读错误，并在有可靠副本时尝试修复损坏。

如果你的 Btrfs 用在 NAS、家用服务器、备份盘或多盘阵列上，scrub 应该成为定期巡检的一部分。它的价值不是“等出事再修”，而是在磁盘还能读、阵列还有好副本的时候，尽早发现静默损坏。

scrub 到底检查什么

根据 Btrfs 官方文档，scrub 会遍历文件系统数据和元数据，主要检查：

数据块校验和错误。
基础 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 能做的是：

利用校验和发现数据或元数据损坏。
在有其他可靠副本时自动修复。
发现磁盘读错误和部分基础结构错误。

scrub 不能做的是：

重建没有好副本的数据。
替代离线文件系统检查。
修复所有复杂的树结构损坏。
保证应用层文件内容一定正确。

如果文件系统结构已经严重损坏，通常需要在专家指导下使用 btrfs check 等工具。不要把 scrub 当成“万能修复命令”。

NOCOW 文件的风险

Btrfs 官方文档特别提醒：对文件设置 NOCOW 属性，也就是常见的 chattr +C，当前实现中会隐式启用 NODATASUM。这意味着这些文件的数据本身没有校验和。

scrub 仍然可以校验和修复这些文件的元数据，但不能校验文件数据内容。问题在多副本场景里尤其明显：如果某个 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 则是为闪存设计的日志结构文件系统，虽然能把很多随机写组织成顺序写，但在空间紧张、垃圾回收频繁或元数据更新密集时，仍然可能把机械叠瓦盘拖进很长的内部整理周期。

先确认是不是这类问题

建议先看三个现象：

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 闪存。它采用日志结构写入，并通过 segment cleaning 和 garbage collection 回收空间。这个设计在 SSD 上通常很自然，因为 SSD 没有机械寻道；但在机械硬盘上，尤其是 SMR 盘上，GC 产生的读写搬运可能变成明显的长尾延迟。

当 F2FS 后台 GC、前台写入、checkpoint、元数据更新和硬盘自身的 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：减少部分访问时间更新带来的元数据写入。

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；长期方案是迁移到 BTRFS/XFS，或者把这类 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:18:10 +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:26:01 +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 引入了自修复相关能力。配合新的通用文件系统错误报告机制，文件系统可以把元数据损坏和 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 不是单纯“把包放进仓库”，而是在按一个可维护的软件栈去验证它。

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 到底检查什么

常用命令