企业官网建设流程全解析

1. 项目概述：mkbootdisk 到底是干什么的

搞 Linux 运维的朋友，大概率都经历过这种时刻：某台服务器的内核引导配置出了问题，或者新装的内核没生效，机器起不来，而你手上除了安装光盘、U 盘之外什么都没有。在系统还能进单用户模式、或者 grub 还能交互运行的情况下，用mkbootdisk给当前系统做一张应急启动盘，往往是恢复系统最快、最不折腾的一条路。

mkbootdisk是早期 Red Hat 系 Linux（RHEL、CentOS、Fedora 等）自带的一个命令行工具，作用很直接：把当前运行的内核、initrd（早期叫 initrd，后来才是 initramfs）以及必要的引导信息写到一块软盘或者磁盘镜像文件里，生成一个“当前系统专用”的启动盘。它不需要你去记 grub 的复杂写法，也不需要你手动画分区、装引导器，一条命令加上适当参数就能生成一张能引导进入当前系统的盘。

这个命令对老运维来说就是救场神器，对新手来说则是一个理解 Linux 启动链路的好抓手：内核、initrd、引导设备、内核参数，这几个概念在 mkbootdisk 的实际使用中都会暴露出来。这篇文章就以 mkbootdisk 为主线，把它的使用姿势、原理背景、常见坑点和现代替代方案一次说清楚。

2. 为什么需要 mkbootdisk：背景与适用场景

2.1 它诞生的年代和生态

mkbootdisk 的存续主要对应的是 Linux 2.4 / 2.6 内核时代，那个年代服务器上软驱还是标配，U 盘引导还没有成为统一标准，很多机房给服务器装系统靠的是光盘和软盘。当时 Red Hat 系发行版的安装引导也大量使用软盘镜像——启动盘有实打实的物理载体需求。

那会儿 Linux 的系统修复还没有今天这么多花样，live CD 算一种方案，但一个数据中心里几十台机器，不可能每台配一套光驱和安装盘。mkbootdisk 的定位就是给“已经装好系统的机器”量身定做一张启动介质，它读取当前系统的 /boot、内核模块、grub 配置，帮你把启动盘生成出来。万一系统起不来了，拿这张盘引导，再挂载根分区，就能进到原有环境里修东西。

2.2 不做新系统安装盘，只做“当前系统的恢复钥匙”

这里有个关键区分：mkbootdisk 不是通用安装盘生成器，它做的是“刻舟求剑”式的备份——这张盘只保证引导“这台机器上当前安装的内核”。你把这张盘拿到另一台机器上，除非硬件几乎一致且内核驱动匹配，否则大概率起不来。

为什么会这样？因为 mkbootdisk 在生成启动盘时，会把当前运行内核对应的模块路径写进 initrd，还会把根文件系统的类型、根设备的 UUID 或者设备名带进去。这些信息都是跟着当前系统走的，跨机器就失效。理解这一点之后，你就知道它的使用边界了：

• 当前系统能启动到单用户、或者 grub 交互模式，但正常启动失败；
• 根分区、引导分区出问题，但内核和 initrd 文件本身还在 /boot 里；
• 你需要进入一个相对完整的系统环境，而不是只有 busybox 的急救 shell；
• 机器没有光驱、没有 U 盘引导选项，只剩一个软驱（这种情况现在少了，但老设备群里依然存在）。

2.3 它和 grub 修复的关系

很多人第一次接触 mkbootdisk 是因为 grub 坏了。grub.conf 被误删、grub 阶段1写错 MBR、/boot 分区被格式化但内核文件靠 ext3 的备份块还能捞回来……这些场景下，mkbootdisk 生成的启动盘可以临时引导系统，让你进入原来的 root 环境，然后再执行 grub-install、修复 grub.conf，等于“先绕过问题，再解决问题”。这也是它最大的价值所在。

3. mkbootdisk 的核心用法与参数解析

3.1 命令格式与基本参数

mkbootdisk 的调用方式很简单，需要指定一个目标设备或者镜像文件：

mkbootdisk [选项] 内核版本

这里“内核版本”不是随便写的，它对应 /boot 下 vmlinuz 文件的后缀。比如 /boot/vmlinuz-2.6.32-642.el6.x86_64，那内核版本就是 2.6.32-642.el6.x86_64。你可以在命令行用uname -r拿到当前运行内核的版本，通常情况下我们就是要给当前内核做启动盘，所以直接拿 uname -r 的结果填进去最省事。

常用参数有这么几个：

3.2 最简单的用法：给当前内核生成启动盘

假设机器上还有一个软驱，并且软驱设备是 /dev/fd0，想直接生成一张软盘启动盘，命令就是：

mkbootdisk --device /dev/fd0 $(uname -r)

执行过程中它会做几件事：找到 /boot 下对应的 vmlinuz 和 initrd 文件；根据当前系统的模块依赖生成一个新的 initrd（这个细节后面会展开）；把引导信息写到软盘的引导扇区；把内核和 initrd 写入磁盘。完成后这张盘就拥有独立引导能力了。

我在实际测试中发现，直接写物理软盘有很高的概率因为介质质量问题失败，尤其软盘保存时间长、磁道有坏块的时候。mkbootdisk 写盘失败会中断并提示 I/O 错误，不会像 dd 那样产生一个半成品还继续往下跑，这一点对操作者来说反而是保护。

3.3 生成镜像文件而不是直接写盘

现代机器基本没有软驱，再绑定 /dev/fd0 就太死板了。mkbootdisk 支持把启动盘生成到一个镜像文件里，后续你可以用 dd 或专用工具把它写进 U 盘、CF 卡、虚拟机磁盘：

mkbootdisk --device /tmp/bootdisk.img --size 1440 $(uname -r)

这里有个细节：如果目标设备是一个普通文件，mkbootdisk 会尝试把它当作块设备来处理，直接执行会报错或者行为异常。安全做法是先创建一个大小的空文件，再让 mkbootdisk 基于这个文件去写：

dd if=/dev/zero of=/tmp/bootdisk.img bs=1024 count=1440 mkbootdisk --device /tmp/bootdisk.img --size 1440 $(uname -r)

某些发行版打补丁之后可以直接写普通文件，但早期的 RHEL 5 / CentOS 5 自带的版本对普通文件支持并不友好。如果命令报“设备名格式不对”之类的错误，先创建一个稀疏文件或者完整空文件再用--noverify跳过校验，能绕开大部分问题。

3.4 内核参数：让启动盘更灵活

默认生成的启动盘会沿用当前系统的内核启动参数，包括 root 设备、ro/rw 标志等。但修复场景下，我们通常不希望它直接进入多用户模式，而是进单用户模式去操作。这时--kernelargs就有用了：

mkbootdisk --device /dev/fd0 --kernelargs "single" $(uname -r)

生成的启动盘引导后会直接进入单用户模式，省得你等系统起来再去改 runlevel。这个参数还可以塞进去selinux=0、enforcing=0这类临时关掉 SELinux 的设置。要注意的是，单引号双引号的处理取决于执行环境，参数中间有空格时一定要整体引用起来。

4. 实操过程：从生成到验证一条龙

4.1 环境准备与信息收集

开始操作之前，先把关键信息摸清楚。我通常按这个顺序检查：

uname -r ls -l /boot/vmlinuz-$(uname -r) ls -l /boot/initrd-$(uname -r).img df -h /boot cat /boot/grub/grub.conf | grep -E "root|kernel|initrd"

这几条命令分别确认当前内核版本、内核文件和 initrd 文件是否存在、/boot 分区剩余空间、以及 grub 里记录的内核启动参数。为什么要看 /boot 空间？因为生成 initrd 的过程中，mkbootdisk 有时候会临时生成文件再打包，如果 /boot 已经满了，操作会失败。

看 grub.conf 里的 kernel 行尤其重要，它记录着 root 设备的写法。有的系统是/dev/sda2，有的是UUID=xxxx，mkbootdisk 默认会从当前运行的 /proc/cmdline 里读取并沿用，但如果 /proc/cmdline 里的 root 是设备名而 /etc/fstab 里已经改成 UUID 了，生成的启动盘可能会在挂载根分区时找不到设备。提前记录下来，后面万一有问题可以手动用--kernelargs补。

4.2 标准生成流程示例

假设当前系统是 CentOS 6，内核是 2.6.32-642.el6.x86_64，机器没有软驱，我打算生成一个软盘镜像，然后写到 U 盘里用于应急。实际操作步骤大致如下：

# 第一步：创建工作目录 mkdir -p /root/rescue # 第二步：准备镜像文件，软盘标准容量是 1440 KB dd if=/dev/zero of=/root/rescue/boot.img bs=1024 count=1440 # 第三步：生成启动盘镜像 mkbootdisk --device /root/rescue/boot.img --size 1440 $(uname -r)

执行过程中 mkbootdisk 会输出类似下面的信息：

Insert a disk in /dev/fd0. Press any key to continue

如果目标是普通文件，它可能会去检测设备类型。如果卡在这一步，多半是它拿文件当块设备在等，这时候 ctrl-c 中断，挂上--noverify再跑一次。

生成完镜像之后，先别急着拿去用，用 file 命令看一眼：

file /root/rescue/boot.img

正常情况下会输出软盘镜像信息，包括文件系统类型，一般是 ext2。如果 file 输出里面只看到 data 字样，说明引导结构没写好，这张盘引导不起来。

4.3 把镜像写到 U 盘

生成镜像之后，写 U 盘是关键一步。注意你的 U 盘会成为区块设备，写错盘符后果非常严重，所以我每次都会先确认设备名：

lsblk

找到目标 U 盘之后，再用 dd 写入：

dd if=/root/rescue/boot.img of=/dev/sdX bs=1024 conv=fsync

这里可以加一个status=progress参数（取决于 dd 版本）看写入进度。1440 KB 的镜像写入 U 盘是瞬间的事情，但要注意：很多现代 U 盘固件对软盘镜像的兼容性并不好，不一定能从这样的 U 盘引导。如果测试环境是虚拟机，建议把镜像直接挂载为虚拟软驱（fd0），兼容性最好。

4.4 测试验证：启动盘是否真的能用

生成完启动盘，必须实际引导一次才能确定它可靠。做法分两种：

• 实体机：把 U 盘插上，启动时选择 U 盘引导；
• 虚拟机：直接把 boot.img 作为软驱镜像挂载到虚拟机上，从软驱启动。

启动过程中重点观察几个节点：引导加载器是否有输出、内核是否被加载、initrd 是否被识别、根文件系统是否挂载成功。如果一切正常，你会进入原来系统的环境（或者指定的 runlevel）。如果中途卡住，看一下是卡在内核解压（说明内核文件损坏或者格式不兼容）、卡在挂载根分区（说明 initrd 有问题、root 参数不对）、还是卡在模块加载（说明缺少对应的磁盘控制器驱动）。

这步测试一定不能省。我见过不少同事把启动盘生成完就扔一边，真到要用的那天才发现盘根本引导不了。生成只是做完了一半，验证通过才算真的能用。

5. 常见问题与排查技巧实录

5.1 问题速查表

5.2 为什么生成的 initrd 可能缺驱动

mkbootdisk 生成启动盘的时候，initrd 里包含的模块是依据当前系统内核模块目录来收集的。它会把 SCSI 控制器、文件系统、IDE 等基础模块打进去。但这里有个很现实的坑：如果当前系统启动时用的是 initramfs 机制的 dracut，而你的 mkbootdisk 版本比较老，它打包的 initrd 结构可能不被当前内核识别，或者模块收集逻辑不一致，导致引导时缺少必要的驱动。

我遇到过一次典型的案例：某台用了外置 SAS 存储的机器，根分区在 SAS 盘上，系统内核是正常的，但做出来的启动盘引导后就是找不到根设备。排查到最后发现，mkbootdisk 生成的 initrd 里缺少对应 SAS 控制器的驱动模块。原因是这台机器的内核模块放在/lib/modules/$(uname -r)/kernel/drivers/scsi下，但 mkbootdisk 收集模块时有自己的白名单逻辑，没把这些模块收进去。

遇到这种情况，最快的兜底方案是先启动到一个能用的最小环境（比如安装盘自带的 rescue 模式），用mkinitrd或者 dracut 重新生成一个完整的 initrd 文件，放到 /boot 下，然后手动构造引导参数，而不是死磕 mkbootdisk 一家。

5.3 镜像大小为什么不能随便填

mkbootdisk 的--size参数决定镜像文件大小，单位是 KB。软盘标准是 1440 KB，但这只是理论容量，实际上格式化和写入引导信息后可用空间更小。如果当前内核的 vmlinuz 加上 initrd 打包后超过镜像容量，写入就会失败。

现代 Linux 内核 vmlinuz 通常有 3~6 MB，initrd（或者 initramfs）更可能到 20~50 MB，显然塞不进 1.44 MB 的软盘。这也是 mkbootdisk 在实践中最尴尬的地方——它能把软盘做出来，但不代表能装下现代内核。如果你在做镜像文件而不是物理软盘，可以把这个 size 设置得大一些，比如 4096 或 8192（即 4 MB、8 MB）。

注意：如果你给--size填了一个比内核+initrd 实际大小还小的数字，mkbootdisk 在写入时会直接失败，不会做截断处理，这是好事，避免了你拿到一个残缺的启动盘。

5.4 现代内核的替代方案

进入 dracut 和 grub2 时代之后，mkbootdisk 在主流发行版中逐渐被淘汰。RHEL 7 / CentOS 7 及以后的系统里已经没有 mkbootdisk 了，取而代之的是：

如果你只是想要一个“当前系统的启动盘”，现代做法通常是：

grub2-mkrescue -o /tmp/boot.iso

这条命令生成的 ISO 可以用 xorisso 写入 U 盘，引导后进入 grub 菜单，再手动选择启动项，加载本地磁盘上的内核和 initramfs。它比 mkbootdisk 更灵活，也不存在软盘容量限制。

但如果你手里维护的还是一批老机器（RHEL 5/6 时代），那 mkbootdisk 依然是 PXE 和安装盘之外的实用选择。与其强行在新系统上装老工具，不如把场景和工具匹配清楚。

5.5 应急启动盘还能不能干别的

mkbootdisk 做出来的启动盘，本质上是“调用当前系统内核与 initrd 的引导器”，所以它的能力边界取决于内核和 initrd。你可以在生成的镜像文件上做二次修改，比如把 initrd 解开，往里面加一个自己的修复脚本，然后重新打包。这样做出来的启动盘引导后，会自动执行你的修复逻辑。

有一个我从老前辈那里继承来的技巧：在生成启动盘时，把--kernelargs设成一个自定义参数，比如rescue_mode=1，然后在 initrd 的启动脚本里判断这个参数是否存在，如果存在就自动挂载根分区、启动网络、拉起 sshd。这样你就得到了一张“插上即进入救援模式”的盘，比单纯进单用户模式好用得多。不过这个玩法依赖 initrd 的 ramfs 结构，不同内核版本之间差异较大，建议先在自己的测试环境里跑通模板再投入实战。

6. 写在最后的实操体会

mkbootdisk 这个东西，单看命令本身非常简单，就是收集当前内核信息、生成 initrd、写入目标设备三步。但真正让这条命令有价值的，是它背后对 Linux 启动流程的封装。你在用它的时候，实际上是被迫捋了一遍“内核版本号—/boot 目录—initrd 结构—root 参数—设备驱动”这一整条链路的。把这条链路捋顺的人，遇到系统启动类问题都会比只会点 grub 的人从容得多。

从操作习惯上，我给自己定了几条规矩，分享出来供参考：

第一，生成的应急启动介质永远要做引导验证。在虚拟机里挂载镜像开一次机，比什么都灵。第二，不要把 mkbootdisk 的输出文件当普通文件乱改，它写的是带引导结构的镜像，用 dd 追加数据会直接破坏引导扇区。第三，老系统上如果有条件，优先把它和 grub 修复配合使用，而不是想办法让 mkbootdisk 一步到位完成所有修复工作——它本身就是用来降低修复门槛的，不是修复工具本身。

如果你接下来维护的环境正好是 RHEL 5/6 或者 CentOS 5/6 的存量机器，建议花半小时在测试机里把生成、写盘、引导、修复这一套流程走一遍。真等到凌晨三点线上机器起不来的时候，你就知道一张验证过的启动盘有多值钱了。