Kali Linux 2023.4安装教程：双系统、Hyper-V与持久化U盘

每次 Kali 有新版本出来，群里最先刷屏的不是更新内容，而是各种"下载链接"。Kali Linux 2023.4 是 2023 年的收官版本，12 月初发布，我前后在虚拟机、笔记本双系统、U 盘这三种环境里各装了一遍，顺手把这一轮遇到的问题记了下来。这篇东西不聊玄学，按我自己的操作顺序，把 2023.4 的版本说明怎么读、官方镜像怎么拿和怎么校验、Windows 11 双系统安装教程里最容易翻车的几个环节、Hyper-V 增强会话的实现思路、持久化 U 盘的制作流程，以及装完之后新手最该先建立的几个习惯，一条条捋清楚。刚接触 Kali Linux 的人可以把它当安装教程从头看，已经用了几年的人可以直接跳到双系统、Hyper-V 和持久化这三块，那里面的细节是我认为最容易在别的教程里被一笔带过的部分。

1. 2023.4 的版本说明该怎么读：桌面、镜像形态、工具集三条线

拿到一个新版本号，我一般不会先去看"新增了哪些工具"这种列表，而是先把官方变更说明里的三条线拆开看：桌面环境走到哪一版、镜像形态有哪些变化、工具集和元包动了什么。因为这三条线决定了你该下哪个 ISO、装完第一件事该干什么。

1.1 GNOME 45、KDE Plasma 5.27 与 Xfce 4.18：桌面不是随便挑的

Kali 从 2019.4 开始把 Xfce 定为默认桌面，这个习惯一直延续到 2023.4。官方同时提供带 GNOME 和带 KDE 的独立 ISO，2023.4 这一轮，GNOME 跟着上游走到了 45 这条线，KDE 侧是 Plasma 5.27 系列，Xfce 则停留在 4.18 线。版本号本身没什么可激动的，但对你来说有三个现实影响。

第一，GNOME 45 改了顶部栏和 Activities 的交互逻辑，一些老扩展会直接失效。如果你之前靠某个 GNOME 扩展做窗口平铺或者录屏，升级前先确认它有没有跟上。第二，KDE 的 Wayland 会话在虚拟机和部分老显卡上，输入法候选框定位、录屏、剪贴板这几个地方依然会出问题，X11 会话稳得多。第三，Xfce 界面朴素、组件老旧，但内存占用和硬件兼容性在三者里最好，装在老笔记本或者 4GB 内存的虚拟机里，体感差距非常明显。

我的建议很简单：主力机长期用、追求省心，选 Xfce；喜欢现代交互、屏幕素质好，选 GNOME；要自定义程度高、愿意折腾，选 KDE。三者之间不是锁死的，apt install kali-desktop-gnome这类操作可以后装，但桌面环境多装几个之后，登录管理器（Kali 用的是 LightDM/GDM 之类）的会话列表会变得很乱，也容易互相污染主题配置，我不太建议在同一个系统里堆两个以上桌面。

1.2 镜像形态：installer、live、netinst、ARM、云镜像分别给谁用

下载页面上最容易让人犯选择困难的就是这一堆文件名。它们不是"完整版"和"精简版"的关系，而是面向不同使用场景的几种形态，装错了不会报错，只会让你在后续使用里很别扭。

• installer images（安装镜像）：这是真正意义上的完整安装盘，支持 LUKS 全盘加密、LVM、自定义分区，可以在物理机硬盘上装一套完整的系统。双系统装机必须用它，Live 镜像改进来的系统在升级和分区上都会给你添麻烦。
• live images（实时镜像）：可以直接从 U 盘跑起来，不碰硬盘。用途是免安装试用、系统急救、U 盘持久化，也常用于取证场景（因为默认不写入磁盘，避免破坏现场数据）。
• netinst（网络安装）：体积小，安装过程从网络仓库拉包，适合带宽稳定、想完全自定义装什么的情况。网络一断就卡住，这是它最大的风险。
• ARM images：给树莓派一类的开发板用，2023.4 这轮覆盖了一些新的板子型号，具体列表以官方发布说明为准。ARM 版跟你手上的 x86 笔记本 ISO 完全不通用，别下错。
• 预构建虚拟机与云镜像：官网上有给 VirtualBox、VMware 的现成虚拟机包，还有云平台和容器场景的镜像。虚拟机包省事，缺点是默认配置（磁盘大小、内存）是按最小可用给的，用之前得调。

我自己的搭配是：笔记本双系统用 installer，随身 U 盘用 live + 持久化，日常实验用虚拟机包加自己重装的 installer。中间那套"Live 装完再改硬盘"的野路子我试过，最后放弃的原因是 Live 的默认分区结构和内核参数跟完整安装不一致，出问题时排查成本太高。

1.3 "下载链接"这件事：只认官方站点与校验文件

Kali 的官方入口就一个域名，Downloads 页面上按 installer、live、ARM、云镜像分好类，实际的分发文件放在官方镜像站上，按版本号组织目录。你能在搜索引擎里翻到的"某某网盘高速下载""免安装绿色版"这类东西，绝大多数是把 ISO 重新打包过一遍的，塞进去的东西你没法验证。

我更在意的是校验环节。官方在每个版本目录里都会提供SHA256SUMS和对应的SHA256SUMS.gpg签名文件，还有一段 GPG 公钥。这三个东西的存在意义是：哈希值保证文件在传输过程中没有损坏，GPG 签名保证这个哈希值列表本身没有被篡改。两个都做，才算真正验证过镜像来源；只做哈希，只能证明"我下到的文件和我手上的哈希列表对得上"，但那个列表是哪来的说不清。

还有一个概念要讲清楚：Kali 是滚动发行版，2023.4 这个版本号指的是 2023 年第四季度的一个发布快照，ISO 只是那个时间点的切片。你装完跑一次完整更新，系统就往前走了一大截，所以不必纠结"是不是必须用最新 ISO"。反过来说，如果你打算在三台以上机器上部署、又不想每次更新几百个包，那就尽量用最新版本的 ISO，能省不少下载时间。

提示：镜像站之间存在同步延迟，刚发布时某些镜像可能还没有对应版本目录。遇到 404 先换个镜像，不要以为是自己网络问题。

2. 镜像落地前的三个动作：校验、写盘、固件确认

从下载完成到按下开机键之间，有三件事做完能帮你挡掉后面 80% 的诡异问题。顺序不能反：先校验，再写盘，最后确认固件设置。

2.1 SHA256 与 GPG：两步都做，别只做一个

Linux 侧校验就一行：

sha256sum -c SHA256SUMS --ignore-missing kali-linux-2023.4-installer-amd64.iso

--ignore-missing的作用是让校验程序忽略文件里列出的、你没下载的其他镜像，只核对手上的这一个，不然它会一直报"找不到文件"。Windows 侧没有 sha256sum，但系统自带：

certutil -hashfile kali-linux-2023.4-installer-amd64.iso SHA256

输出的哈希值跟官方文件里对应那一行逐字符比对，注意有的编辑器会做自动换行或者补空格，建议直接复制粘贴到文本对比工具里。

GPG 环节稍微麻烦一点，但值得做一次：

# 导入 Kali 的官方签名公钥 wget -q -O - https://archive.kali.org/archive-key.asc | gpg --import # 验证哈希文件本身 gpg --verify SHA256SUMS.gpg SHA256SUMS

看到 "Good signature" 才算过。如果提示密钥缺失，说明公钥没导入成功；如果提示签名不匹配，别抱侥幸心理去装那个镜像，重新下载。

我踩过的一次坑是下载中断后重新续传，文件大小看着对，哈希也对不上。原因是某些下载工具在断点续传时把分片拼错了位置。所以校验失败第一件事是彻底删掉重下，而不是继续续传。

2.2 写盘：Rufus 的 DD 模式与 ISO 模式差在哪

Windows 上写盘，Rufus 是首选，因为它在写入模式上给了你选择权：

结论很清楚：除非 DD 模式写出来的 U 盘在你机器上压根引导不起来，否则一律选 DD。至于 balenaEtcher，操作上最省事，报错信息也最简陋，出了问题时它给你的信息基本等于没有，我不太推荐新手用它来排查问题。

Linux 或 macOS 上用 dd 也行，但of=参数写错一个字母就是抹盘，敲下去之前先lsblk确认设备名：

lsblk sudo dd if=kali-linux-2023.4-live-amd64.iso of=/dev/sdX bs=4M status=progress oflag=sync

写完 U 盘在文件管理器里显示的容量"变小"了，这是正常的，因为分区表里只有 ISO 那么大一块。剩下的空间是被保留的未分配区域，正是后面做持久化分区要用的。想恢复成普通 U 盘，Windows 上用diskpart的clean，Linux 上用wipefs -a或者直接重建分区表。

关于 U 盘本身，我建议：只做安装盘，8GB 起步够用；要做持久化，至少 32GB，而且优先选 USB 3.0 以上的接口和主控质量好一点的盘。持久化系统会把大量小文件写操作压到 U 盘上，廉价 U 盘的写入寿命和随机读写性能都会成为瓶颈，用一段时间后系统卡到怀疑人生，这跟 Kali 本身没关系。

2.3 固件侧的三个开关：UEFI、Secure Boot、启动顺序

写盘完成之后，进固件设置界面确认三件事：

第一，统一用 UEFI 模式。如果 Windows 11 是 UEFI 装的，Kali 也必须在 UEFI 模式下安装，否则会出现一个系统在 UEFI、一个在 Legacy 的混合引导局面，后期修引导能耗掉你整个周末。

第二，Secure Boot 的状态。Kali 的 amd64 镜像是带签名的，理论上可以在 Secure Boot 开启状态下引导，但实际装机时如果卡在引导阶段或者安装器报验证相关错误，先把 Secure Boot 关掉试试，能过就说明是链上某一环没跟上。需要注意的是，关掉 Secure Boot 之后，Windows 11 侧的某些游戏和带反作弊的软件可能会有意见，这个取舍要自己判断。

第三，Fast Boot 要关。这个开关的作用是跳过大部分硬件自检，副作用是可能直接跳过 USB 设备的检测，让你以为 U 盘做坏了。同一时间，Windows 侧的"快速启动"（另一个同名但完全不同东西）也必须关掉，原因在第 3 章讲。

3. Windows 11 与 Kali 共存：分区、引导与时钟的完整链路

双系统这件事，难的部分从来不是把 Kali 装上去，而是装完之后两套系统能和平共处。我把它拆成四段：Windows 侧预处理、分区规划、装完立刻要做的三件事、出问题时的回退路径。

3.1 动手前必须处理的 Windows 侧设置

按顺序做，别跳。

第一步，备份。至少把重要文件复制到外部存储；理想情况是做一次整机镜像。分区操作是不可逆的，一旦分区表玩坏，没有镜像就只能靠数据恢复工具碰运气。

第二步，处理 BitLocker。Windows 11 在满足条件的机器上默认开启设备加密，一旦你改动分区表或引导记录，下次开机很可能直接进恢复界面要你输 48 位恢复密钥。先查状态：

manage-bde -status

如果已经加密，先确认恢复密钥已经备份（微软账号里能找到，或者导出一份存到别的设备），然后临时暂停保护：

manage-bde -protectors -disable C: -rebootcount 2

-rebootcount 2的意思是接下来两次重启不要求验证，装完 Kali 之后记得重新启用。我见过太多人装完系统重启看到蓝色恢复界面，手上又没有密钥，最后只能重装 Windows。

第三步，关闭 Windows 快速启动和休眠。快速启动本质是混合关机，系统关机时把内核状态写进休眠文件。后果是你在 Linux 侧挂载 NTFS 分区时，看到的可能是"处于不一致状态"的文件系统，轻则只读挂载，重则写入损坏。关掉的方法是控制面板里电源选项的"选择电源按钮的功能"，先点"更改当前不可用的设置"才能看到这个开关；休眠则用管理员权限执行：

powercfg /h off

顺带还能省出和内存等量的磁盘空间。

第四步，压缩出可用空间。磁盘管理里的"压缩卷"经常只能压出几个 GB，因为页面文件、系统还原点、不可移动的文件挡在分区末尾。可以依次尝试：关闭系统还原、把页面文件临时移到别的盘或设为无、对 SSD 执行系统自带的"优化"（也就是 TRIM），再重新压缩。这些手段都用完还不够，再考虑第三方分区工具，但用之前一定先做镜像。

注意：如果这台机器你还打算用几年，别把 Kali 分区压到刚好够用。滚动发行版一年下来累积的包、日志、缓存很容易吃掉十几 GB。

3.2 分区怎么划：EFI、根分区、swap 与 /home 的取舍

进入 Kali 安装器的分区环节，一定要选"手动分区"，别用向导里的"整盘使用"——那个选项会把你辛苦腾出来的空间和 Windows 一起重新规划，后果不想描述。

EFI 系统分区这一项是最容易出事的。Windows 装机时已经建好了一个（通常 100 到 300MB），Kali 安装器会自动识别出来并显示为"EFI 系统分区"之类的标签，你要做的是把它挂载到/boot/efi，并且在格式化选项里选"不格式化"。如果你手滑勾了格式化，Windows 的引导文件就没了，后面得进恢复环境用bcdboot重建。

/home要不要单独分区，观点分成两派。单独分的好处是以后重装或者换发行版时个人配置和文件能保留；坏处是分区一旦划小了，后期扩容得先动相邻分区，麻烦。我的做法是：如果是 512GB 以上的盘，给/home单独切 100GB 左右；如果是小容量 SSD，就全给根分区，个人文件另外放外置盘或者网络存储上。

swap 这块，8GB 以上内存的机器日常用不着，但如果你想让 Linux 侧的休眠功能可用，swap 必须不小于物理内存。大多数人不需要在 Kali 上休眠，所以我一般只留一个 2-4GB 的 swap 走个形式，或者干脆用 swapfile 省一块分区。

3.3 装完立刻要做的三件事：GRUB、启动顺序、时钟

第一件，确认 GRUB 菜单里能看到 Windows。Kali 用的是 GRUB，正常情况下安装器会自动探测到 Windows 引导项。如果重启后菜单里只有 Kali，先检查/etc/default/grub里是否有GRUB_DISABLE_OS_PROBER=false这一行（某些版本默认会禁用探测），改完执行sudo update-grub。

第二件，调整固件启动顺序。理想状态下 GRUB 排在 Windows Boot Manager 前面，这样开机进 GRUB 再选系统。但 Windows 更新有时候会"好心"把 Boot Manager 抢回第一位，导致你开机直接进 Windows。处理方式有两种：进固件设置在启动项顺序里把 GRUB 调到前面，或者在 Linux 侧用efibootmgr查看并调整启动项编号。

第三件，解决时间差 8 小时的问题。这是双系统里最经典的坑：Windows 默认把主板 RTC 的时间当作本地时间读取，Linux 默认当作 UTC 读取，于是两边差出一个时区。两个修法：改 Windows，让它也把 RTC 当 UTC——在 Windows 侧新建注册表值RealTimeIsUniversal（DWORD，值 1）；或者改 Linux，让它妥协：

timedatectl set-local-rtc 1

我个人推荐改 Windows，因为 Linux 侧设成 local RTC 之后，在有夏令时的地区会出现时钟跳变，而 Windows 侧那个注册表值是官方认可的做法。唯一的副作用是 Windows 的某些更新可能重置它，发现时间又不对了，先来查这里。

3.4 出问题时的回退路径：一条真实排查链

说一个我实际遇到过的场景，把排查思路完整走一遍。装机完成后重启，结果直接进 Windows，连 GRUB 都没出现，说明引导顺序被改了。这时候不要重装，按这个顺序查：先进固件设置界面看启动项列表里有没有 Kali 或者 GRUB 的条目，有就调顺序；没有的话，说明 GRUB 没装上或者装到了错误的位置，用 Live U 盘启动，chroot 进系统重新执行grub-install和update-grub。

第二个常见场景：GRUB 出现了，但菜单里没有 Windows。先确认 Windows 分区还能不能挂载（sudo blkid看有没有 NTFS 分区），能挂载就说明系统还在，只是探测没生效，回到上面os-prober那一条处理。

第三个场景，也是最惨的：Windows 引导彻底丢了，开机直接报错。用 Windows 安装介质进恢复环境，命令行里用bcdboot重建引导文件（UEFI 模式下需要先把 EFI 分区挂成一个盘符，然后bcdboot C:\Windows /s S: /f UEFI），或者用bootrec系列命令。这类操作的关键是搞清楚 EFI 分区的盘符和实际位置，鲁莽执行反而会覆盖掉 Kali 的引导。

我的经验是：双系统机器上永远留一个 Kali Live U 盘，它能在两套系统都起不来的时候给你一个可操作的界面。另外，做完整机镜像之后再做任何分区操作，这个习惯比任何技巧都值钱。

4. Hyper-V 跑 Kali：增强会话与主机剪贴板互通的实现思路

Windows 11 专业版自带 Hyper-V，很多人图省事就在上面装 Kali。问题是默认的"基本会话"体验很差，而"增强会话"在老教程里步骤繁琐、名字又对不上。这一章把机制和思路讲清楚，剩下的按你的实际版本落地。

4.1 基本会话模式的三个体验痛点

Hyper-V 默认连上去的是一个类似老式远端的窗口，问题集中在三处：分辨率跟着窗口走但不能自适应，缩放之后画面要么模糊要么有黑边；主机和虚拟机之间剪贴板不通，复制一条命令都得靠手打；主机输入法和快捷键会打架，最典型的是释放鼠标的Ctrl+Alt+Left经常被虚拟机里的应用吃掉。

共享目录这块更是个长期误解：Hyper-V 没有像某些虚拟化软件那样的原生共享文件夹功能，指望在设置里找到"共享文件夹"选项的人最后都会失望。

4.2 增强会话的本质：xrdp 加 vsock 两条腿

搞明白一件事，后面的问题都好排查：Hyper-V 的"增强会话"本质上不是 Hyper-V 自己实现了一套显示协议，而是宿主通过 RDP 协议连到虚拟机内部跑着的一个 RDP 服务端，只不过传输通道用的不是普通 TCP 网络，而是一套专供宿主机和虚拟机通信的虚拟套接字机制。所以在 Linux 客体这边，你需要的组件是：

• 一个正在运行的xrdp服务；
• 内核里的vsock 传输支持（Hyper-V 相关模块）；
• xrdp 侧对 vsock 传输的支持；
• 宿主 Hyper-V 侧启用增强会话模式策略。

排查也从这四条依次过。先看内核模块：

lsmod | grep hv modinfo hv_sock

有输出说明模块在，没输出可能是内核精简掉了，得换内核或装额外的模块包。然后看服务：

apt policy xrdp systemctl status xrdp

这里有个关键点：xrdp 的版本决定了你是"改几行配置"还是"编译一套东西"。较新的 xrdp 开始内置 vsock 传输支持，配置起来简单不少；但发行版仓库里给的版本不一定够新，而 Kali 的滚动仓库虽然更新快，也要看具体时间点。装之前先apt policy看一眼版本号，再决定走哪条路。

宿主侧则是 Hyper-V 管理器里的增强会话模式策略（本地和服务器两处设置），以及虚拟机连接窗口工具栏上的"增强会话"按钮。全部到位之后，连接窗口会弹出一个分辨率选择对话框，进去之后剪贴板、分辨率自适应、声音这些体验才正常。

社区里流传的做法通常是：先备份 xrdp 的配置文件，再运行一个脚本，脚本干的事包括给 xrdp 打补丁或安装支持 vsock 的构建、生成对应的服务单元、修改监听配置。我对这类脚本的建议是，跑之前务必通读一遍，看它改了哪些文件、会不会覆盖你的配置文件、卸载方法是什么。我在一台机器上跑过一版老脚本，它把 xrdp 的默认端口配置改得乱七八糟，后来手动装 xrdp 从零配反而更快。

4.3 不想折腾增强会话？三条更省事的路

说实话，如果你只是偶尔复制粘贴几行命令，搞增强会话的投入产出比并不高。三条替代路线，按省事程度排序：

第一条，SSH。虚拟机里确认 SSH 服务可用，宿主直接在终端里ssh kali@<虚拟机IP>。Linux 侧要复制文件用scp或rsync，都是原生命令。这条路的优点是跟图形界面完全解耦，虚拟机窗口卡不卡都不影响你干活；缺点是要先搞清楚虚拟机的 IP（用 Hyper-V 的默认交换机的话，宿主机和虚拟机在同一个内部网段，ip addr一看就知道）。

第二条，临时 HTTP 服务。需要把某个文件从虚拟机传到宿主，在虚拟机里进到文件目录执行python3 -m http.server 8000，然后在宿主浏览器里访问虚拟机的 8000 端口。反过来，宿主也可以起一个临时服务，虚拟机用wget拉。用完就关，不需要做任何配置，这是我平时传小文件最常用的方法。

第三条，SMB 网络共享。宿主上建一个共享目录，虚拟机侧用mount -t cifs挂载，认证信息写进单独的凭据文件并设好权限，别把密码明文写在命令历史里。这条路适合需要双向同步一批文件的场景。

顺带说一句虚拟化平台的选择：Hyper-V 的优势是 Windows 专业版自带、和系统集成好；如果你更在意桌面体验和共享文件夹这类便利功能，某些第三方虚拟化软件在交互上确实更顺手。但 Hyper-V 的性能和快照管理能力足够日常练习用，没必要为了体验差异换来换去。

5. 持久化 U 盘：让 Live 镜像带上你的配置和文件

随身带一个 Kali 是很多人的执念。做这件事之前，先想清楚你要的是哪一种。

5.1 Live、持久化、完整安装到 U 盘：三种形态的取舍

我一般推荐持久化，因为它在"不污染宿主"和"配置能留住"之间平衡得最好。取证场景要特别注意：持久化会把你的操作记录写到 U 盘上，如果目标是分析现场数据，应该用纯 Live 或者专门的取证模式，避免无意中修改了要分析的东西。

5.2 持久化分区怎么建：卷标、文件系统、persistence.conf

整个流程分四步，每一步都有坑。

第一步，写盘。用 DD 模式把 live 镜像写进 U 盘，写完之后 U 盘上会有一块未分配空间，那就是给持久化分区留的位置。

第二步，建分区。用 GParted 或别的分区工具在未分配空间里新建一个分区，文件系统选 ext4，然后是最关键的一点：卷标必须叫persistence，全小写，不能有空格。这个卷标是系统识别持久化分区的方式，不叫这个名字就完全不会生效，很多人卡在这一步却一直在别处找原因。

第三步，写配置文件。挂载这个新分区，在它的根目录下创建一个名为persistence.conf的纯文本文件，内容写一行：

/ union

这一行的含义是"把整个根目录做联合叠加"。它的原理是把 Live 系统的只读文件系统和一个可写层叠加在一起，所有写操作都落到 U 盘的分区上，读的时候优先读可写层里的新版本。如果你只想保留个人文件、不想保留系统配置的改动，可以把它改成/home union，只把家目录叠加出来。多写几行也可以，比如同时叠加/home和/etc，但叠加/etc有个副作用：某些服务的配置文件被改坏之后，系统会一直以坏配置启动，而你在 Live 会话里改不回来，所以我不太建议持久化/etc。

第四步，引导时选对入口。Kali 的 live 镜像引导菜单里本身就带"持久化"相关的条目，只要持久化分区建好了，直接选那一项就能进。如果没有对应条目，也可以在引导菜单里按编辑键，在内核参数那一行末尾加上persistence关键字。

注意：把 U 盘插到 Windows 上时，系统很可能弹出"需要格式化"或者"扫描并修复"的提示。千万别点。Windows 不认识 ext4 分区，它只是在提示自己读不懂这块分区。点一次格式化，你的持久化数据就没了。

5.3 加密持久化与数据落地的注意事项

如果你打算在这个 U 盘里放比较敏感的东西（比如工作记录、客户环境信息），用加密持久化。做法是把持久化分区用 LUKS 加密，卷标同样必须是persistence，然后在引导时选择加密持久化对应的条目，或者在内核参数里加上persistence-encryption=luks。启动时会提示你输入密码解密这个分区。

这里有几个实操细节。第一，密码别用一堆特殊符号，Live 环境的键盘布局可能跟你想的不一样，输密码时看不到字符，输错了只会报解密失败，很浪费时间。第二，加密持久化分区一旦忘记密码，数据就真的拿不回来了，没有后门。第三，加密会带来一点点性能开销，在 U 盘这种本身就慢的介质上会更明显，但为了数据安全我认为值得。

最后是数据落地的观念问题：持久化不等于备份。U 盘会丢、会坏、会被踩、会掉在地上，我身边不止一个人把唯一一份资料放在持久化 U 盘里然后弄丢了。重要文件一定要另外同步一份，用移动硬盘、网络存储或者加密的云盘都可以。同时养成习惯：不要在系统正在写入的时候直接拔盘，U 盘的 ext4 分区被突然断开很容易进入需要 fsck 修复的状态，严重时目录结构会损坏。定期在能正常启动时会话里跑一次文件系统检查，比出事后到处找恢复工具划算得多。

6. 装好之后的日常：更新、快照、账号、工具集

系统装完只是开始。Kali 是滚动发行版，日常维护的方式跟固定版本发行版差别很大，新手最容易在这里吃亏。

6.1 滚动发行版的更新节奏与快照习惯

更新命令很简单，但用哪个参数有讲究：

sudo apt update sudo apt full-upgrade -y

用full-upgrade而不是upgrade，原因是滚动发行版在推进过程中经常需要替换或删除旧包、改变依赖关系，upgrade遇到这种情况会直接把操作搁置，结果是你以为更新完了，其实一堆包卡在那里。full-upgrade允许它做这些调整，代价是可能删掉你正在用的东西，所以更新前看一眼它打算删什么。

更新前做快照，这是我坚持了几年的一条规矩。虚拟机里最省事，直接打快照；物理机上装个快照工具，或者至少把/etc和你的个人配置目录打包备份一次。滚动发行版偶尔会出现某个包更新后跟其他包不兼容，有快照就能几分钟回滚，没有的话就得在命令行里跟依赖关系搏斗。

更新失败的常见原因和对应处理：镜像源同步延迟（换个源重试）、磁盘空间不足（清缓存）、上次更新中途被打断导致包管理锁死（sudo dpkg --configure -a修复）、某些包被人为锁定了版本（apt-mark showhold查一下）。另外更新完别马上关终端，看一眼有没有提示需要重启或者重新配置。

还有一个概念要澄清：Kali 的版本号不是"必须重装"的边界。你在 2023.4 上持续更新，自然就会拥有后续版本带来的一切功能，/etc/os-release里的版本标识也会跟着变。只有 ARM 镜像、云镜像这类需要重新获取介质的情况，才需要重新下载。

6.2 kali 用户、sudo 与 root 的边界

Kali 从 2020.1 开始默认不再是 root 登录，而是创建一个名为 kali 的普通用户（默认密码也是 kali，第一次登录后应该立刻改掉）。这个变化的理由很实在：很多图形化工具以 root 身份运行时会出现权限或渲染相关的异常，而且日常用 root 操作键盘的风险太高，一条命令敲错就是系统级的破坏。

所以日常用法是：以 kali 用户登录，需要特权操作时用sudo，需要连续做一堆特权操作时用sudo -i切一个 root shell，事情做完exit回来。有人图省事给自己的账号配了免密 sudo，我不推荐在随身设备上这么做；真被盗或者被同事拿去乱点，代价太大。

需要 root 的场景确实不少，比如抓包、修改网络接口配置、加载内核模块、操作某些底层设备。这些场景下别硬扛，老老实实切 root 做，做完切回来。切换的时候在提示符上看清楚自己现在是谁，这是最小成本的防错手段。

6.3 元包与系统调整工具：按需装，别"全都装"

Kali 把工具按用途打包成若干个元包，用元包装比单个装省事，但选错了会拖垮系统。

"全都装"这件事我劝退过很多人，理由有三个：体积大到几十 GB，小硬盘直接爆；依赖关系越复杂，滚动更新时出冲突的概率越高；更新一次要下载和处理的包数量翻好几倍，在慢速网络上就是灾难。更聪明的做法是按方向装，比如主攻 Web 应用方向就装那一组，主攻网络分析就装另一组，其余用apt install <包名>临时补。

Kali 自带一个系统调整工具，能做的事情包括切换元包、调整 shell 提示符、开关某些开机自启的服务、切换桌面主题等等。新手很值得花十分钟把这个工具里的选项翻一遍，它集中处理了不少需要手改配置文件的事情。另外还有一个把桌面外观伪装成常见办公系统样子的模式，适合在公共场合演示或者录屏时避免引人注目，用之前记得切换回正常主题，不然自己都会找不到菜单在哪。

6.4 在合法授权的环境里学习：三条边界

大部分人装 Kali 是为了学安全相关的技能，这件事本身没问题，但有三条边界最好一开始就划清楚。

环境边界：所有的练习都放在你自己拥有或者拿到明确书面授权的环境里。最省事的做法是在同一台机器上再跑几个虚拟机做靶机，网络设置成仅主机模式或者隔离的内部网段，跟真实网络彻底隔开。这样你可以随便折腾，也不会影响任何人。

数据边界：练习过程中如果碰到真实数据，立刻停手，不要复制、不要导出、不要打包带走。这个界限一旦模糊，性质就变了。

记录边界：养成记录操作过程的习惯。写清楚你做了什么、看到什么现象、得出什么结论，最后能输出一份像样的报告。这个能力在实际工作中的价值，往往比你记住多少条命令更高。工具的用法是滚动的、会变的，而"发现问题、验证假设、给出结论、形成文档"这套流程是不变的。

至于学习顺序，我的建议是先把 Linux 基础和网络基础打牢，再看工具是怎么工作的，而不是背命令。因为 Kali 里工具的版本更新很快，你照着两年前的教程敲，参数可能已经变了；而理解了协议和原理，工具换了也照样能用。

我个人在实际操作中的体会是，装 Kali 这件事本身半小时就能搞定，真正花时间的永远是装完之后那几件"好像不重要"的小事：校验没做、快照没打、时钟没对、持久化分区卷标写错。这几件事每件都能独立毁掉你一个下午，但它们加在一起也用不了二十分钟。所以我的做法是把它们写成一个清单，每次装新系统都照着过一遍，比出问题之后再去搜索引擎里翻答案快得多。