我尝试在 CentOS 7 上使用此命令损坏 MBR
dd if=/dev/zero of=/dev/sda bs=446 count=1
据我所知，引导扇区有512字节长度，前446字节是引导加载程序代码，其余是分区表。
在重新安全模式下启动后，/dev/sda1安装在/mnt和 上chroot /mnt，我曾经grub2-install修复过启动加载程序/dev/sda，但没有成功再次启动。
我错过了什么点？
答案1
在 chroot 之后，但在运行之前grub2-install，您应该检查是否/boot/grub/device.map存在。通常，grub2-install如果它尚不存在，则创建它，并尝试猜测哪个 Linux 设备对应于哪个 BIOS/GRUB 磁盘标识符。如果这个映射错误，你会得到奇怪的结果。
除非您的系统非常特殊，否则如果您告诉 BIOS 从磁盘启动/dev/sda，则应/boot/grub/device.map包含以下行：
(hd0) /dev/sda
如果运行时 device.map 文件不存在grub2-install，则必须猜测 Linux 设备名称和 BIOS/GRUB 磁盘标识符之间的映射。有时也grub2-install可能猜错。因此，如果/boot/grub/device.map不存在，您应该在运行之前使用正确的信息创建它，grub2-install以确保修复成功。
如果/boot/grub/device.map文件存在但信息错误，您应该在运行之前修复它grub2-install。
现在您应该再次启动进入救援模式，chroot，然后检查/boot/grub/device.map文件，然后运行grub2-install /dev/sda。
另一种可能性：
当您覆盖 MBR 的前 446 个字节时，它包括用作 MBR 分区磁盘上的磁盘 UUID 的签名字节。如果 GRUB 配置使用磁盘 UUID 来选择 GRUB“根”分区，则 UUID 现在将不同。您的发行版应该有一个可用于轻松重建 GRUB 配置文件的命令。
在 Debian 风格的系统中，它可能是update-grub.
在 RedHat 风格的系统（Fedora、CentOS 等）中，它可能是grub2-mkconfig > /boot/grub/grub.cfg或类似的。
消息：致命：INT18：启动失败与Grub完全无关，而是VirtualBox的问题。
显然，VirtualBox 检查分区表以验证分区是否已标记为活动分区，如果没有活动分区，它会报告错误，而不是尝试加载并运行 MBR 代码。
对于 GRUB 来说，此检查是不必要的，因为如果 GRUB 已安装到 MBR，则无论哪个分区被标记为活动分区，它都会控制引导过程。
来源：https://neosmart.net/wiki/fatal-int18-boot-failure/
将安装介质映像仍然插入虚拟 CD-ROM 驱动器中也可以实现此目的，至少对于较旧的 VirtualBox 版本是这样：