Grub

如何正確損壞和修復 MBR?

  • May 20, 2018

我曾嘗試在 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 版本:

https://www.dedoimedo.com/computers/fedora-fatal-18.html

引用自:https://unix.stackexchange.com/questions/442053