CentOS 7では、このコマンドを使用してMBRを破損しようとしました。
dd if=/dev/zero of=/dev/sda bs=446 count=1
私が知る限り、ブートセクタの長さは512バイト、最初の446バイトはブートローダコード、残りはパーティションテーブルです。
セーフモードで再起動後/dev/sda1on /mnt, off インストールをしてからchroot /mnt一度grub2-installブートローダを復旧したが/dev/sda再起動に成功しませんでした。
私が逃したことは何ですか？
ベストアンサー1
ルートを変更した後、実行する前にそのエントリがあることをgrub2-install確認する必要があります/boot/grub/device.map。通常、grub2-installまだ存在しない場合は、それを作成し、どのLinuxデバイスがどのBIOS / GRUBディスク識別子に対応するかを推測してください。このマッピングが間違っていると、奇妙な結果が表示されます。
システムが非常に特別でない場合は、BIOSにディスクから起動するように指示する場合は、次の行を含める必要があり/dev/sdaます。/boot/grub/device.map
(hd0) /dev/sda
実行時にdevice.mapファイルがない場合は、grub2-installLinuxデバイス名と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バージョンでこれが行われます。