“更新”仅拉取补丁和小版本升级，安全低风险；“升级”是发行版迁移，高风险需人工干预。日常维护只需更新，大版本升级前须查eol时间并谨慎操作。
直接更新还是升级发行版？先分清这两个动作
Linux里“更新”和“升级”不是一回事：sudo apt update && sudo apt upgrade只是拉新包、修漏洞；而从 Ubuntu 22.04 升到 24.04、或从 CentOS 7 升到 Stream，属于发行版级迁移，风险高、耗时长、必须人工干预。
绝大多数日常维护只需做前者——它不改系统大版本，只打补丁、升内核小版本、修安全问题。后者则要重装大量基础组件，稍有不慎就进不了系统。
- 你执行
apt upgrade后没提示“新发行版可用”，说明当前就是常规更新 - 想确认是否该大版本升级？运行
lsb_release -a，再查对应发行版官网的 EOL（终止支持）时间 - Ubuntu LTS 用户注意：
do-release-upgrade -d会跳过中间版本直奔开发版，除非你明确测试需求，否则别加-d
不同包管理器的升级命令不能混用
Debian/Ubuntu 用 apt，RHEL/CentOS 8+ 用 dnf，Arch 用 pacman——它们底层逻辑不同，强行套用命令轻则报错，重则破坏依赖树。
比如在 Ubuntu 上敲 sudo dnf upgrade，系统会告诉你 “Command 'dnf' not found”；而在 CentOS Stream 上跑 apt update，连包管理器本体都不存在。
- Debian/Ubuntu：
sudo apt update→sudo apt full-upgrade（比upgrade更彻底，能删旧包） - RHEL/CentOS 8+：
sudo dnf check-update→sudo dnf upgrade --refresh（--refresh强制重拉元数据，避免缓存过期） - Arch Linux：
sudo pacman -Syu（-S安装，-y同步数据库，-u升级，三者缺一不可）
升级后不清理，/boot 早晚爆满
Linux 升级内核时默认保留旧内核，方便出问题回滚。但老内核文件（vmlinuz-*、initrd.img-*、linux-image-*）全堆在 /boot，几轮下来就占光空间，导致下次升级失败甚至无法启动。
这不是“多占点磁盘无所谓”的事——/boot 分区通常只有 512MB～1GB，且多数引导器（如 GRUB2）对目录下文件数量敏感，太多旧镜像可能让菜单变慢或漏项。
- Debian/Ubuntu：运行
sudo apt autoremove --purge，它会自动删掉未被任何linux-image包依赖的旧内核 - CentOS/RHEL：
sudo dnf autoremove kernel（注意不是kernel-core） - Arch：先
sudo pacman -Qdtq看孤儿包，再sudo pacman -Rns $(pacman -Qdtq)彻底清除 - 手动检查：
ls -l /boot/vmlinuz*和uname -r对照，确认哪些是“活着的”内核
内核更新了，但 uname -r 没变？别急着重装
这是最常被误判为“升级失败”的情况。真实原因是：新内核已安装，但 GRUB 还在用旧内核启动——系统根本没加载它。
典型表现是：运行 apt install linux-image-6.11.0-14-generic 成功，dpkg -l | grep linux-image 能看到新包，但 uname -r 仍显示 6.8.x。
- 先确认新内核是否真进了
/boot：ls /boot/vmlinuz-6.11.0-14-generic - 再生成最新 GRUB 配置：
sudo update-grub（Ubuntu/Debian）或sudo grub2-mkconfig -o /boot/grub2/grub.cfg（RHEL/CentOS） - 重启后，在 GRUB 启动菜单按
Shift（BIOS）或Esc（UEFI），手动选新内核项启动 - 若新内核启动失败，别删它——留着用于调试，下次启动时选上一个能用的就行
真正麻烦的是闭源驱动，比如 NVIDIA nvidia-driver-535 可能不兼容 6.11 内核，得等官方适配或降级内核。这种兼容性问题没法靠命令绕过，只能查对应驱动的 release note。
