dhclient 消失的隐性原因（非显式 autoremove）
即使没有任何脚本显式执行 apt autoremove，在 Debian 的高级包管理中，isc-dhcp-client 依然会被“隐性”连根拔起。这通常由以下两种机制触发：
互斥依赖被强行拉入（Conflicts/Replaces）： 第三方内核在安装时，往往会附带安装一些“推荐的”现代化网络工具包（比如为了支持新的高级网络特性）。如果在拉取这些包的过程中，碰巧引入了 systemd-networkd 的某些强关联组件，或者诸如 resolvconf、dhcpcd5 这类包，Debian 的 APT 包管理器发现它们与传统的 isc-dhcp-client 存在功能互斥，就会在处理安装事务时，自动且静默地卸载掉旧的 dhclient，以保证系统包的唯一性。
Netboot 依赖树断裂： 你的系统是极简网络安装版。它的依赖链非常像一栋搭好的积木，dhclient 是挂载在某个基础虚拟包（如 linux-image-amd64）上的“推荐依赖”。当第三方脚本强行把底层的内核积木抽走换成 linux-image-xanmod 时，这棵依赖树就断了。在随后的任何一次 apt 操作（哪怕只是脚本执行了一次 apt update 配合内核安装），APT 都可能顺手把失去根基的 dhclient 清理掉。
- 为什么 DNS 会随之崩溃？
既然你的 sysctl 没被篡改，网络和 DNS 都没有在底层被屏蔽，那为什么连 google.com 都解析不了？
答案就在消失的 dhclient 身上。
在传统的 Debian 网络体系（ifupdown）中，DHCP 客户端不仅仅负责获取 IP，它还负责配置 DNS。当你获取到那个 100.104.1.4 等内网或公网 IP 时，dhclient 会触发一个后台钩子（Hook 脚本），将网关下发的 DNS 服务器地址实时写入 /etc/resolv.conf。
故障发生的瞬间是这样的：
内核被脚本替换。
dhclient 在后台由于包冲突或依赖断裂被 APT 隐性卸载。
系统因 Secure Boot 拦截卡死，你强制重启。
切回旧内核启动后，networking 服务试图读取网卡，发现找不到 dhclient，直接报错退出。
因为没有 dhclient 运行，自然也没有钩子去刷新和配置 /etc/resolv.conf。系统的 DNS 解析失去了“司机”，直接瘫痪。
dhclient 消失的隐性原因（非显式 autoremove）
即使没有任何脚本显式执行 apt autoremove，在 Debian 的高级包管理中，isc-dhcp-client 依然会被“隐性”连根拔起。这通常由以下两种机制触发：
既然你的 sysctl 没被篡改，网络和 DNS 都没有在底层被屏蔽，那为什么连 google.com 都解析不了？
答案就在消失的 dhclient 身上。
在传统的 Debian 网络体系（ifupdown）中，DHCP 客户端不仅仅负责获取 IP，它还负责配置 DNS。当你获取到那个 100.104.1.4 等内网或公网 IP 时，dhclient 会触发一个后台钩子（Hook 脚本），将网关下发的 DNS 服务器地址实时写入 /etc/resolv.conf。
故障发生的瞬间是这样的：