结论是压缩算法不匹配导致解压失败，将/etc/initramfs-tools/initramfs.conf中compress=lz4改为compress=gzip并执行sudo update-initramfs -u即可修复，因老内核或部分虚拟化环境不支持lz4解码。
直接说结论：这不是内核崩溃，也不是硬盘坏了，而是内核在解压 initramfs 时卡住了——大概率是压缩算法不匹配、内存不足、或镜像损坏。抢救成功率很高，但得对症下药。
为什么改 COMPRESS=gzip 就能救活？
Debian/Ubuntu 系统默认用 lz4 压缩 initramfs，但老内核或某些虚拟化环境（比如 CloudStack、KVM 轻量实例）不支持 lz4 解码。内核读到不认识的压缩头，直接报 Decoding failed。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
/etc/initramfs-tools/initramfs.conf里把COMPRESS=lz4改成COMPRESS=gzip（gzip兼容性最稳） - 改完必须运行
sudo update-initramfs -u，否则配置不生效 - 别只改 conf 就重启——没重新生成镜像，等于白改
- 如果系统起不来，得进 GRUB 选 recovery 模式，或者用 Live USB
chroot进去改
进不去系统？先绕过再修
GRUB 启动时按 e 编辑启动项，在 linux 行末尾加参数，不是为了永久修复，而是抢出一个可操作环境：
- 加
nouveau.modeset=0：NVIDIA 显卡驱动冲突导致解压中途花屏，这个参数禁用 nouveau 的 KMS，让内核能继续跑完 initramfs 解压流程 - 加
systemd.unit=rescue.target或rd.break：强制停在 initramfs shell 里，可以手动检查/boot/initramfs-*.img是否损坏、空间是否满、甚至尝试gunzip -t测试镜像完整性 - 注意：这些只是临时绕过，不能替代重生成 initramfs
内存不足也会触发 “Decoding failed”
看起来像解码错误，其实是解压过程申请内存失败，内核静默 fallback 到错误路径。常见于虚拟机内存配得太小（比如
- CloudStack/KVM 场景下，把虚拟机内存从 1024MB 提到 2048MB 经常就能过这一关
- 真实物理机可进 BIOS 查看 “DVMT Pre-Allocated” 或 “iGPU Memory” 设置，调低到 64MB 或 128MB
- Live 环境下用
free -h和dmesg | grep -i memory看有没有Cannot allocate memory类提示
真正容易被忽略的是：update-initramfs -u 默认只更新当前运行的内核对应镜像。如果你刚升级过内核但没重启，又手动删过旧内核，ls /boot/vmlinuz* 和 ls /boot/initramfs-*.img 版本可能对不上——这种“错配”不会报错，但启动时必挂。
