Kali Linux 的升级不需要重装系统，也不需要专门的版本升级工具。每个 Kali 版本都对应 kali-rolling 仓库的一个快照，因此只要系统指向该仓库，执行一次 apt full-upgrade 并重启，就能得到最新版本。真正容易出问题的是命令之外的事情：旧格式的软件源文件、升级中途失败、升级后没有出现预期的新工具，以及 glibc 更新后数据库报告排序规则不一致。

本文按照 Kali 官方文档的方式，在一台六周没有更新的虚拟机上演示升级。流程包括检查版本和 deb822 格式的 kali.sources 文件，执行包含 916 个软件包的完整升级，从 /etc/skel 刷新点文件，重启系统，然后手动安装最新版本新增的工具，因为这些工具不会由升级过程自动加入。文中的命令和输出均来自一台运行 Kali rolling 2026.3、内核 7.1.5 的虚拟机，升级操作完成于 2026 年 10 月。

升级前准备

完整升级很少询问问题，但会下载大量数据，并重新启动正在运行的服务。因此，在执行命令前应做好准备：

• 任意版本的 Kali，并具备 sudo 权限
• 根文件系统 / 至少留有约 5 GB 空间；本次升级下载了 2,019 MB 的软件包
• 虚拟机快照，或者物理机上的主目录备份
• 能抵御连接中断的会话，例如 tmux、screen，或直接使用本地控制台

最后一项不要省略。本次测试虚拟机通过 QEMU 客户机代理操作，而 qemu-guest-agent 本身就在待升级的软件包中，因此配置阶段发出的远程命令全部返回“Server disconnected without sending a response”。由于升级是在 nohup 下启动的，断连后仍能继续运行。通过 SSH 升级时也会遇到同样的问题：先启动 tmux，在会话中运行升级，断线后再重新连接即可。Kali 更新文档还建议不要在演练或项目作业期间升级，因为工具的版本变化可能影响正在依赖的结果。

检查当前 Kali 版本

在修改系统前记录版本和内核，方便重启后进行对比：

grep VERSION /etc/os-release
uname -r

本次测试虚拟机由 9 月创建的模板克隆而来，已经显示版本 2026.3、内核 7.1.5：

VERSION_ID=2026.3
VERSION=2026.3
VERSION_CODENAME=kali-rolling
7.1.5+kali-amd64

这组输出容易被误读。VERSION 字段来自 base-files 软件包，Kali 通常会在正式发布公告的数周前就在 kali-rolling 中修改该值，所以系统即使显示 2026.3，仍可能落后数百个软件包。本次系统就有 916 个软件包等待升级。版本号只能作为标签，判断系统是否真正更新，应以 apt list --upgradable 的结果为准。

将 APT 指向 kali-rolling

从 Kali 2026.2 开始，网络安装版本的仓库配置放在 deb822 格式文件 /etc/apt/sources.list.d/kali.sources 中，新的网络安装不再提供 /etc/apt/sources.list。先检查系统使用哪一种：

ls /etc/apt/sources.list /etc/apt/sources.list.d/

如果只有 kali.sources，打开它并确认 suite 为 kali-rolling：

sudo vim /etc/apt/sources.list.d/kali.sources

测试虚拟机中的文件与 Kali APT 源文档给出的默认配置完全一致：

# See https://www.kali.org/docs/general-use/kali-apt-sources/
Types: deb
URIs: http://http.kali.org/kali/
Suites: kali-rolling
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/kali-archive-keyring.gpg

旧版安装可能在 sources.list 中保留一行式配置：

deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware

这仍然有效，不过可以交给 APT 自动转换，旧文件会被备份：

sudo apt modernize-sources

测试时把旧格式条目重新放回虚拟机，APT 只询问一次，随后写入 deb822 文件，并自动填写密钥环路径：

The following files need modernizing:
  - /etc/apt/sources.list

Modernizing will replace .list files with the new .sources format,
add Signed-By values where they can be determined automatically,
and save the old files into .list.bak files.
...
Rewrite 1 sources? [Y/n] y
Modernizing /etc/apt/sources.list...
- Writing /etc/apt/sources.list.d/kali.sources

无论最终采用哪种格式，suite 都必须是 kali-rolling。使用 kali-last-snapshot 的系统只会在新版本发布时移动，继续指向第三方镜像或旧代号则根本不会更新。

刷新软件包索引

获取当前软件包列表，让 APT 知道最新版本包含哪些软件包：

sudo apt update

先看最后一行。六周未更新后，本次共有 916 个软件包待升级：

Get:1 http://kali.download/kali kali-rolling InRelease [34.0 kB]
Get:2 http://kali.download/kali kali-rolling/main amd64 Packages [21.8 MB]
Get:3 http://kali.download/kali kali-rolling/contrib amd64 Packages [108 kB]
Get:4 http://kali.download/kali kali-rolling/non-free amd64 Packages [163 kB]
Get:5 http://kali.download/kali kali-rolling/non-free-firmware amd64 Packages [26.9 kB]
Fetched 77.6 MB in 9s (9,081 kB/s)
Reading package lists...
Building dependency tree...
Reading state information...
916 packages can be upgraded. Run 'apt list --upgradable' to see them.

此时出现 NO_PUBKEY，说明本机软件源密钥环比仓库签名密钥旧，APT 会拒绝新的软件包列表，升级也就没有可用的数据。先安装最新的密钥环，再重新运行更新：

sudo apt install kali-archive-keyring
sudo apt update

本次测试虚拟机的密钥环是最新的，因此没有遇到该问题。

执行完整升级

使用 full-upgrade，不要只用 upgrade。apt upgrade 会安装新依赖，但不会删除软件包；apt-get upgrade 则连新依赖也不安装。两者在滚动发行版上都会遗留待更新软件包。本次在虚拟机中模拟 apt-get -s upgrade，它会升级 840 个软件包并保留 76 个，其中包括 cherrytree、clang-21、faraday、freerdp3-x11 和 gvmd，原因多是库依赖发生变化。

在 tmux 中启动升级：

sudo apt full-upgrade -y

APT 在下载前会显示摘要。执行前务必阅读 REMOVING 区块；如果其中出现正在依赖的软件包，应停止并调查。本次只移除了已被替代的库：

REMOVING:
  libblosc2-7           libgvm22t64          libshiboken6-py3-6.10
  libfalcosecurity0t64  libpyside6-py3-6.10  python3-pkg-resources

Summary:
  Upgrading: 916, Installing: 27, Removing: 6, Not Upgrading: 0
  Download size: 2,019 MB
  Freed space: 414 MB

下载耗时 1 分 45 秒，速度约 19.2 MB/s。整次安装在 4 核虚拟机上约用了 20 分钟，大部分时间用于解包和运行触发器（initramfs、GRUB、man-db、Java 证书）。由于没有更新的内核，内核仍为 7.1.5，但许多常用工具发生了变化：

• metasploit-framework：6.5.3 → 6.5.7
• burpsuite：2026.8 → 2026.9
• nmap：7.99 → 7.991
• openssh-server：10.4p1 → 10.6p1
• systemd：261.2 → 262；glibc：2.43-4 → 2.43-7

即使版本标签没有变化，这次升级也带来了新的 Metasploit 和 SSH 服务端，所以两次版本发布之间的升级并非表面工作。如果脚本依赖工具输出，在正式任务中继续使用前，应先重新运行脚本验证结果是否变化。

对于无人值守或由 Ansible 驱动的升级，可使用下面的脚本化命令，它接受默认值并保留已经编辑过的配置文件：

sudo DEBIAN_FRONTEND=noninteractive apt -y full-upgrade \
  -o Dpkg::Options::=--force-confdef \
  -o Dpkg::Options::=--force-confold

日志中有 30 条“Installing new version of config file”，包括 /etc/login.defs、/etc/john/john.conf、/etc/sqlmap/sqlmap.conf 和 /etc/snmp/snmpd.conf。脚本参数会保留本地修改过的文件，但本虚拟机没有此类修改，所以 dpkg 直接安装了新版本。只有当本地文件与软件包提供的新版本都存在冲突时，dpkg 才会暂停询问。交互式运行会出现“Configuration file … Modified (by you or by a script) since installation”提示。按 D 查看差异，然后为经过定制的配置（例如自定义 john.conf）保留自己的版本，其余采用维护者版本。

中断后的恢复

如果升级中途失败，例如未使用 tmux 导致会话断开、停电或磁盘写满，已解包的软件包可能尚未配置，下一次 APT 操作会拒绝执行，并显示：

E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.

先完成已经解包软件包的配置，修复损坏的依赖关系，然后重新执行完整升级，让尚未开始的软件包继续处理：

sudo dpkg --configure -a
sudo apt --fix-broken install -y
sudo apt full-upgrade -y

最后确认没有处于半安装状态的软件包。在清理完成的系统上，sudo dpkg --audit 不输出内容并以状态码 0 退出，本次虚拟机也得到这一结果。

从 /etc/skel 刷新 Shell 点文件

APT 会更新 /etc/skel 中的默认点文件，但不会碰主目录中的副本，因此新版本提供的提示符或 Zsh 配置不会自动生效。Kali 发布说明给出的复制命令如下：

cp -vrbi /etc/skel/. ~/

-i 会在覆盖前逐项询问，-b 会把旧文件保留为带 ~ 后缀的备份，因此在再次运行该复制命令前都可回退。每次再次运行都会覆盖这些备份。本次用户共获得 15 个文件，包括 .zshrc、.bashrc、.profile 和一份 Xfce 面板 genmon 配置：

'/etc/skel/./.profile' -> '/home/josphat/./.profile' (backup: '/home/josphat/./.profile~')
'/etc/skel/./.zshrc' -> '/home/josphat/./.zshrc' (backup: '/home/josphat/./.zshrc~')
'/etc/skel/./.bashrc' -> '/home/josphat/./.bashrc' (backup: '/home/josphat/./.bashrc~')

如果在 .zshrc 中积累了大量别名，该文件应回答 n，手动与 /etc/skel/.zshrc 比较，或者之后从 .zshrc~ 备份中合并自己的别名。

重启并确认升级完成

需要重启的软件包会写入 /var/run/reboot-required，请求重启的软件包列表位于 reboot-required.pkgs。本次是 dbus；即使内核没有变化，dbus 更新也足以要求重启。Kali 发布说明使用 sudo reboot -f，但 -f 会跳过有序的服务关闭流程，可能直接终止 PostgreSQL。建议使用普通重启，并且只在标志文件存在时执行：

[ -f /var/run/reboot-required ] && sudo reboot

系统恢复后，检查版本、内核、重启标志和是否仍有待处理事项：

grep VERSION /etc/os-release
uname -r
ls /var/run/reboot-required
sudo apt update

没有重启标志，APT 也没有任何待办，才是真正的完成标志：

VERSION 和内核与升级前相同，这是预期结果，因为版本标签早已更新到 2026.3。若系统来自 2026.2 或更早版本，VERSION 会变为 2026.3，uname -r 会变为 7.1.5 内核。不论标签显示什么，“All packages are up to date”才是升级完成的证据。重启后本次虚拟机的 systemctl --failed 也没有输出。

安装 Kali 2026.3 新工具

Kali 2026.3 主要是构建脚本更新，软件包变化不算大。升级系统能够获得以下变化：

• 内核从 2026.2 的 6.19 升级到 7.1.5
• KDE 版本使用 Plasma 6.7
• 126 个软件包更新，新增 6 个工具
• 每个更新后的构建脚本仓库都包含 build-in-container.sh，可在 Docker 或 Podman 中构建镜像

新增工具最容易被忽略。full-upgrade 只升级已安装的软件包，这 6 个工具都不在 kali-linux-default 中，因此即使完成了 916 个软件包的升级，dpkg-query 对它们仍返回“no packages found”。需要按名称安装：

sudo apt install -y dalfox katana qsreplace rustscan sdrangel snaffler-ng

APT 共拉取 83 个软件包、189 MB 数据，其中包含 Qt WebEngine 库。如果没有 SDR 硬件，可以从命令中去掉 sdrangel。安装的版本如下：

---
	dalfox		3.2.4-0kali1		面向自动化的 XSS 扫描器		dalfox
	katana		1.8.0-0kali1		爬虫与 Web 路径发现框架		katana
	qsreplace		0.0.3-0kali1		替换从标准输入读取的 URL 查询值		qsreplace
	rustscan		2.4.1-0kali1		快速端口扫描器，可将结果交给 nmap		rustscan
	sdrangel		7.27.2+dfsg-1+b1		SDR 设备的 Qt 图形界面		sdrangel
	snaffler-ng		1.5.13-0kali1		在 SMB 共享中查找凭据和敏感文件		snaffler

如果在脚本中使用这些工具，有两个细节需要注意。snaffler-ng 软件包安装的二进制名称是 /usr/bin/snaffler，并非 snaffler-ng。软件包中的 RustScan 2.4.1 执行 rustscan --version 时会报告 rustscan 2.3.0，脚本中的版本检查可能因此误判为旧版本。

处理升级遗留问题

升级过程中没有 APT 错误，但日志反复出现一条警告。凡是从旧镜像保留 PostgreSQL 集群的 Kali 系统，都可能遇到该问题。

WARNING: database “postgres” has a collation version mismatch

PostgreSQL 在配置 faraday 软件包时首次打印该警告，之后每次调用 psql 都会出现，在 msfdb init 期间共出现四次：

WARNING:  database postgres has a collation version mismatch
DETAIL:  The database was created using collation version 2.42, but the operating system provides version 2.43.
HINT:  Rebuild all objects in this database that use the default collation and run ALTER DATABASE postgres REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

PostgreSQL 18 集群创建时 glibc 为 2.42，现在已变为 2.43。glibc 版本之间的文本排序规则可能变化，因此 PostgreSQL 会警告：在旧规则下建立的索引用于范围扫描时可能返回错误结果。虽然 Metasploit 数据库仍能初始化，但不应只屏蔽警告。需要为警告提到的每个数据库重建索引并记录新版本。Kali 不会在启动时自动启动 PostgreSQL，因此先确认 pg_lsclusters 显示集群为 online；本次重启后用 sudo pg_ctlcluster 18 main start 启动：

sudo -u postgres psql -d postgres \
  -c 'REINDEX DATABASE postgres;' \
  -c 'ALTER DATABASE postgres REFRESH COLLATION VERSION;'

sudo -u postgres psql -d template1 \
  -c 'REINDEX DATABASE template1;' \
  -c 'ALTER DATABASE template1 REFRESH COLLATION VERSION;'

每个数据库都会确认修改，pg_database 随后显示所有数据库都使用 2.43，包括升级后创建的 msf 数据库：

REINDEX
NOTICE:  changing version from 2.42 to 2.43
ALTER DATABASE
  datname  | datcollversion
-----------+----------------
 msf       | 2.43
 template0 |
 msf_test  | 2.43
 postgres  | 2.43
 template1 | 2.43

PostgreSQL 16 及更高版本中，REINDEX DATABASE 会跳过系统目录索引；若也要重建这些索引，需要额外执行 REINDEX SYSTEM postgres;，并对每个数据库重复。如果曾在旧 glibc 上运行过 msfdb init，还要对 msf 和 msf_test 执行同样两条命令。可通过 SELECT datname, datcollversion FROM pg_database; 检查，并修复仍使用旧版本的记录。

The following packages have been kept back

使用 upgrade 而非 full-upgrade 时会出现该提示。apt-get upgrade 会保留任何需要安装新软件包或移除软件包的更新，apt upgrade 则会保留需要移除软件包的更新。本次模拟 apt-get -s upgrade 保留了 76 个软件包，而 full-upgrade 全部处理。如果 full-upgrade 仍列出未升级的软件包，重新运行 apt update 后再升级；镜像同步期间可能短暂提供缺少新依赖的软件包。

清理旧软件包

每次升级都会留下不再被依赖的库。APT 会在完整升级输出顶部列出它们，本次有 13 个，包括旧版 FFmpeg、gRPC、protobuf 库以及 chromium-sandbox。可以这样删除：

sudo apt autoremove -y

自动移除释放了 133 MB，但不会删除旧内核。本次虚拟机仍保留 linux-image-6.19.14+kali-amd64 和 7.1.5，前者是 GRUB“Advanced options”菜单中的备用内核，应至少保留到新内核连续几次干净启动后再处理。之后也不必运行 apt clean：apt 命令会在软件包安装后删除下载的包，本次下载约 2 GB，安装后 /var/cache/apt/archives 只有 92 KB，且没有 .deb 文件。只有 apt-get 会保留这些缓存。

让 Kali 持续保持更新

六周未更新就积累了 916 个软件包和约 2 GB 数据，本文更早一次跨越两个版本的升级则涉及 1,800 多个软件包。真正提高升级风险的是更新跨度，而非版本号，因此更稳妥的习惯是每一到两周执行一次小规模更新：

sudo apt update && sudo apt full-upgrade -y

如果 Kali 运行在虚拟机中，每次执行前创建快照；本文的 Proxmox 渗透测试实验环境就是这样处理的。如果需要让工具集在整个项目期间保持不变，应把 suite 切换到 kali-last-snapshot，而不是完全不更新，完成任务后再切回。Kali Purple 也跟踪同一个仓库，因此同样方式升级。内核跳版本后，应重新检查无线网卡注入是否正常；使用 DKMS 构建的驱动需要针对每个新内核重新编译。