liloconfig命令详解：从MBR到LILO引导修复完整指南

我最早系统化管理Linux服务器那会儿，同事们还在为一个启动问题争论不休：为什么内核刚升级完，重启之后屏幕上只留下一个孤零零的“LI”就再也不动了。如果你用的是GRUB，很可能改一下menuentry就行；但如果你用的是Slackware默认的LILO，就必须老老实实重新生成引导配置，而这件事最常见的方式就是运行liloconfig命令。liloconfig是LILO引导加载器的交互式配置工具，也是Linux系统设置里最容易被低估的一个命令——它把手写/etc/lilo.conf的繁琐过程封装成一连串问答菜单，从选择引导设备、填写内核参数到设置帧缓冲分辨率，最后自动把引导代码写入磁盘。这篇实操篇就围绕liloconfig命令展开，结合我多年的服务器运维和双系统折腾经验，把运行前准备、菜单含义、验证排错和手工进阶一次讲透。

1. 先理顺关系：liloconfig、LILO与lilo.conf各自扮演什么角色

1.1 从一次内核升级后的黑屏说起

有一个场景我至今印象很深。某个周末夜里，我给一台跑着Slackware 14.2的旧服务器更换内核，把新编译好的vmlinuz-generic-4.4.302放到/boot，更新了initrd，然后满怀信心地reboot。结果屏幕左上角卡了一个“LI”就彻底没动静了。

当时第一反应是内核没编好，后来仔细排查才发现问题出在引导层：我换了内核文件，但忘了重新执行lilo。LILO不像GRUB那样在开机时去读文件系统里的菜单，它在安装引导代码时就把内核文件占用的磁盘块号固化进了/boot/map这个映射文件里。旧映射指向旧内核的数据块，新文件占的位置完全变了，引导自然失败。这也是为什么LILO体系里会出现liloconfig这种专门的配置命令——它存在的意义就是帮你把“配置生成”和“映射写入”这两件事一步做到位，避免我犯过的这种低级错误。

1.2 LILO的静态加载机制决定了liloconfig的运作方式

理解liloconfig，得先理解LILO的引导链。传统BIOS启动时，固件把磁盘第一个扇区（MBR）的446字节引导代码加载进内存，这是LILO的第一阶段；这段代码体积很小，干不了太多事，只能接着去加载/boot/boot.b这个第二阶段引导程序，由后者读取/boot/map，根据里面记录的绝对扇区位置把内核和initrd拉进内存。

map文件是这套机制里最关键也最容易被忽略的东西。它和内核文件不是绑定的，而是在你运行lilo命令时重新生成的。每当你升级了内核、修改了分区、甚至只是用e2fsck调整过文件系统布局，旧的映射就可能失效。liloconfig最后一步会替你调用/sbin/lilo完成映射重写和MBR写入，这正是我建议用户优先用它而不是手搓配置的原因：它能保证生成流程的完整闭环。

1.3 今天还有谁会用到liloconfig

听到这里你可能会问：LILO不是早就被GRUB取代了吗，为什么还要学这个命令？

现实是，存量系统远比我们想象的顽强。Slackware一直把LILO作为默认引导器直到较新的版本，一大批没有迁移的服务器、教学实验环境、嵌入式系统仍在用它。另外，很多Linux发行版在安装器的“高级模式”里也保留了liloconfig作为修复工具，你在救援模式下进入chroot环境后，可能就会用到它来重建引导。更关键的是，现在很多系统管理员只熟悉GRUB的grub2-mkconfig，遇到LILO体系往往无从下手。掌握liloconfig，本质上就是掌握一套“不管什么引导器都能修”的思路。

2. 运行liloconfig前的四类核对：磁盘布局、内核版本、MBR备份与分区表

2.1 确认引导设备：别让BIOS顺序和Linux设备名打架

liloconfig第一步会问你“把LILO装到哪个设备”，常见选项是/dev/sda的MBR、分区的引导扇区，或者历史上的软盘。这里最隐蔽的坑是：BIOS的设备枚举顺序和Linux内核的设备名不是一回事。

有的机器在BIOS里把第二块SATA盘设为第一启动项，但Linux检测后把它命名为