错误不 …
错误不会滚：即便内核安装过程中已经报错，但 dnf 仍然在 grub 中新增了内核启动选项并有可能成为默认，导致无法开机。
dracut扫描/bin/vi → 发现指向nvim → 解析nvim依赖 → 遇到绝对路径lpeg.so → 解析失败 → 终止构建
initramfs 的角色理解
initramfs 不仅是存放硬件驱动的压缩包，更是一个微型根文件系统，包含：
- 存储驱动和文件系统模块
- LVM/RAID工具
- 基础用户态环境（shell、mount、vi 编辑器等）
当系统启动失败时，initramfs 会提供一个救援 Shell 环境，允许管理员手动修复系统。这就是为什么 dracut 如此坚持要打包/bin/vi——救援模式下没有编辑器将寸步难行。
解决方案
首先在 Grub 界面选择旧内核启动进入系统，删除原本的vi、vim软链接：
rm -rf /bin/vi /bin/vim
最佳方案：恢复 vim-minimal
这是最安全、最符合 Linux 设计的方案：
# 1. 安装vim-minimal（轻量级，无lua依赖）
dnf install vim-minimal
# 2. 恢复/bin/vi指向vim-minimal（一般安装后自动完成）
# 确认指向正确
which vi # 应显示/usr/bin/vi
# 3. 重新生成initramfs
dracut --force /boot/initramfs-内核版本号.img 内核版本号
# 4. 更新GRUB配置
grub2-mkconfig -o /boot/grub2/grub.cfg
# 5. 重启验证
reboot
优势：
/bin/vi→ vim-minimal（系统级，供 dracut 和救援模式使用）nvim命令独立存在（用户级，供日常开发使用）- 两者互不干扰，各司其职
替代方案：重装内核
如果只是安装脚本执行不完整：
dnf reinstall kernel-core-内核版本号
经验教训：Linux 核心工具管理原则
核心思想：区分"基础设施"与"应用软件"
- 基础设施：
/bin/、/sbin/、/etc/、/usr/lib/下的系统核心文件，如/bin/vi、/bin/sh、glibc 库等。 - 应用软件：通过包管理器安装的普通应用，如 Neovim、VSCode、Chrome 等。
原则：基础设施像大楼的承重墙，应用软件像家具——你可以随意更换家具，但绝不能为了美观去敲承重墙。
对于本次踩坑的需求，安装 neovim 后用nvim命令启动；应当将alias vi=nvim写在~/.bashrc（仅对当前用户生效），不应当直接修改/bin/vi软链接指向/bin/nvim（全局修改）
总结
Linux 系统的魅力在于高度的可定制性，但这种自由也伴随着责任。系统核心工具就像一个精密的钟表内部齿轮——每个零件都有其存在的理由，随意替换可能引发连锁故障。
个人习惯（如偏好 Neovim）应隔离在用户空间（~/.bashrc、容器、虚拟环境），而不是侵入系统空间。当需要修改系统级配置时，优先使用官方提供的机制（如 alternatives、sysctl、systemd 配置），而不是手动覆盖文件。 收起