如何正確損壞和修復 MBR？
我曾嘗試在 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但它沒有成功再次啟動。我錯過了什麼？
在 chrooting 之後，但在執行之前
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或類似的。消息：FATAL: INT18: BOOT FAILURE根本與 Grub 無關，而是 VirtualBox 的問題。
顯然，VirtualBox 檢查分區表以驗證分區是否已標記為活動分區，如果沒有活動分區，它會報告錯誤，而不是嘗試載入和執行 MBR 程式碼。
GRUB 不需要此檢查，因為如果 GRUB 已安裝到 MBR，無論哪個分區被標記為活動，它都會控制引導過程。
來源：https ://neosmart.net/wiki/fatal-int18-boot-failure/
將安裝媒體映像仍插入虛擬 CD-ROM 驅動器也可能會這樣做，至少對於較舊的 VirtualBox 版本：