|
| 图片来自网络 |
Debian 前不久刚刚发布了 Debian 13，也就是代号为 trixie 的版本。本周一上班后，从 Repo 的变更看到了这个消息，我就进行了升级。
之前已经把我的所有 Debian 环境统一到 bookworm 了，也是不久前的事情。当时 Stretch 和 Buster 已经停止维护了，Bulleyes 还是 oldstable 状态。我只有两个环境是 bookworm，于是一咬牙把所有的环境都升级到了 bookworm，也踩了一些坑，下面合在一起说。这次确实没想到来 trixie 得这么快，也这么巧，趁上次坑里的屎还是热乎的，也就再咬一回牙了，反正我的牙也不是自己的。
简化的正常升级流程
首先强调一点，升级不要跳版本，从低往高一级一级地升。每次升级解决这一次的问题，然后再往下走。我这次是从 bookworm 往 trixie 升，只需要升级一次。如果是 jessie，那么就要 stretch -> buster -> bulleyes -> bookworm -> trixie，以此类推。
历史版本代码参见官方说法，最好是看 英文版，更新最及时。
升级过程完整的指引，最好参见 Debian官方文档（有 中文版，但翻译得很不好，很多没翻。还是看英文版吧，Google 翻译或喂 AI 都行。拜托了，都 2025 年了）。但如果要简单说的话，要点只有以下这些：
- 先把当前版本升级到没法再升。
-
去 /etc/apt/sources.list 里面，把版本代号改掉。去 /etc/apt/sources.list.d 下面，把文件里面的版本代号都改掉。
这一步原则上可以用 shell 命令来做，但其实还有 non-free-firmware 之类的小点，依赖别人的脚本并不是好事情，所以我也就不贴了。我觉得还是讲个原则，手动操作吧。必要的时候去参考已有的新版 OS。 - 正式开始升级：
- 对选项作出反应：
- 升级过程中要不要重启服务，可以选 yes。
- 要不要覆盖旧版配置文件，自己看吧。如果不记得以前改了哪些就建议选N了（特别是针对 sshd），建议还是自己「合并」看看。
- 如果升级顺利，重启。
- 清掉不再需要的包。
apt update apt upgrade
apt update apt full-upgrade
reboot
apt autoremove
坑一：升级过程中 ssh 连接中断了
是我自己的锅。正在升级的时候，来了同事问我问题，作了一番长篇演说以后，忘记了这事，去忙别的了。回头想起来时，发现 ssh 已经断了。
ssh 断之前应该是在 apt
full-upgrade 的过程中，等我回答某个配置文件如何处置。赶紧再连上，apt
full-upgrade 继续，发现被锁。
遵照提示：
dpkg --configure -a
得以继续。
随后提醒自己下次记得集中注意力。
坑二：sysctl
升级完后发现有些不对，检查了一下，发现 /etc/sysctl.conf 配置文件被 dpkg 给备份起来了，后缀是 dpkg-bak。
改名回来后 sysctl -p，以为解决问题。重启之后发现 BBR 还是没能启用。翻找资料，发现是 机制改了。现在得把这些配置写到 /etc/sysctl.d/ 下面去，自己建 conf 文件。
当然，这样也有好处。现在可以把不同的内容分别写在不同的配置文件里面，不用像以前那样全部放在 sysctl.conf 里面，找起来比较麻烦了。
另外，记得用 sysctl --system 而不是 sysctl -p 来进行参数的临时加载。机制不一样了。
坑三：haproxy 启动不起来
算是一个小坑，因为报错信息在日志中写明白了。
我的 haproxy 是早期版本安装的，需要在 haproxy.cfg 中把 ulimit-n 设为 524288。
global
ulimit-n 524288
坑四：其它软件还没提供 trixie 源
我周一把 Debian 升级到 trixie 的时候，顺手把 Nginx / PHP / Redis 在 /etc/apt/sources.list.d 下面的 Repo 也给改了。然后就发现 PHP 已经有了 trixie 源，但 Nginx 还是 404，Redis 是 403。
截止本文首次刊发的时候，Nginx 已经 OK 了 ，Redis 还没好。后来直到过完十一长假，我发现redis 有更新，再去看，才发现也提供 trixie 源了。
还有一个问题是 simple-obfs 在 trixie 官方源中没有提供，而 bookworm 是提供的。git 然后源代码编译是一个解决方法。如果还是想从 apt 直接安装省些事情，请在 bookworm 的时期先完成 simple-obfs 的安装，或者临时改成 bookworm 的源。
坑五：GFW 捣什么乱
这个就坑我大发了，几乎可以专门写一篇。不过我还没完全弄明白，以后搞清楚了再说吧。
我家里的网络访问 Debian 官方源不算快（应该说很慢），我又不想改源，于是用了 SS 代理来「加速」。
apt
update 的时候发现，Debian 源没问题，但 Nginx 和 PHP 一直连接超时。区别就在于，Debian 源是 http，后二者是 https。
用 curl
-x -I 简单试了一下，https 还真是走不了 SS 代理。http 就可以。
如果答案是「GFW 检测并干扰了 TLS over
SS」，那我没话说。我知道它有这能力，TLS 的确特征明显，尤其是握手时。这可能也是最合理的一种解释了。
但我 HTPC 上有一台 VM 使用自己的 ss-local 是 OK 的。如何解释？同样的 OS 版本，同样的 SS 版本，同样的网络环境、节点、线路、协议、密钥、插件，同样的 payload 和访问特征，连 TTL 和 MTU 我都看了，实在是想不明白。
有问题的 VM 只是说 TLS 握手出问题的概率很高，但并非 100％。我开了 Verbose 猫在两端看了一下，发现有问题的时候貌似有 replay attack。我拿不准，但看起来像。两端的节点都换过，没有什么差别，该 replay 还 replay。
在公司没问题，在家里有两台都有问题，可见应该跟家里接入的上海电信宽带有关。然而家里 HTPC 上从 Windows 去用那两台上的 ss-local / privoxy 作代理都没有问题，在我遇到问题的时候，儿子还在欢看 YouTube 呢，线路没被封。SS 是 AEAD 版本，cipher 不对时的反应是 No Data Transfer，GFW 肯定拿不准。
那台没问题的 VM 就是不会引发，100％ 地 OK，让我始终想不通的终归还是这一点。在 SS 上面再叠一层 tor，也是 OK 的。最后不得已，我让 apt 走了 tor。没去试 SS over FRP 的方式。先这样吧，也没慢多少就是了。
