Fedoraで「FATAL: INT18: BOOT FAILURE」エラーが発生する原因と対処法（VirtualBox編）

今回はとても短いチュートリアルになります。あなたは今、次のような問題に直面しているはずです。VirtualBox上の仮想マシンでゲストOSとしてFedoraをテストしていて、インストール自体は順調に完了した。ところがテスト後に再起動すると、期待していたGRUBメニューの代わりに、次のエラーが表示される——

FATAL: INT18: BOOT FAILURE

さて、どうすればいいのでしょうか。答えはこの記事を読むことです。この問題はFedora特有のものではなく、Debian系よりもRed Hat系やSUSE系のOSで遭遇しやすい傾向があります。それでは、手短に解決方法を見ていきましょう。

問題の内容と解決策

このエラーは、VirtualBox上にゲストOSをインストールした直後の初回起動時に発生します。Fedoraで最もよく報告されていますが、それ以外のディストリビューションでも起こり得ます。

実はこの問題は、すでに4年以上前から存在するVirtualBoxのバグチケットとして記録されています。筆者自身もFedora 16や当時最新のBeefy Miracle（Fedora 17）でこの現象に遭遇しました。

問題が発生する条件は明確です。ゲストOSのISOイメージがCD/DVDドライブにマウントされたままになっている状態で初回起動を行うと、このエラーが表示されます。

解決策1：ISOイメージをアンマウントする

対処法は非常にシンプルです。仮想マシンの設定でCD/DVDドライブの割り当てを解除し、再起動してください。具体的には、ストレージ設定でコントローラーに接続されている光学ドライブを選択し、「空」に変更します。これだけでエラーは解消され、正常にGRUBメニューが表示されるようになります。

解決策2：起動順序を変更する

もう一つの方法として、仮想マシンの起動順序を「HDD > CD/DVD-ROM > その他」の順に変更することも有効です。こうしておけば、インストール前にディスク上にパーティションテーブルが存在しない場合でも、VirtualBoxが自動的に2番目の起動デバイスへスキップするため、インストール後の再起動でエラーに悩まされることはありません。

ちなみに、この奇妙なエラーはKVM環境でも同様のトラブルシューティング事例が存在します。KVMの場合も初回起動時の失敗に関するもので、警告メッセージの形式こそ違えど、根本的な原因と解決策は同じです。例えばGRUB rescueモードでは次のようなエラーが表示されます。

root (hd0,1)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/vmlinuz

Error 15: File not found

Press any key to continue...

まとめ

なぜVirtualBoxとKVMという異なる仮想化ソフトウェアで全く同じ問題が発生するのかは謎です。エラーの発生条件がやや不安定である点や、バグチケットが長期間放置されている点を含め、この問題には不可解な部分が多くあります。

しかし重要なのは、両環境において解決策が同一だということです。つまり、ISOイメージの取り外しと起動順序の変更、この2点です。

この記事が、不要な再インストール作業や、GRUB rescueモードでの何時間にも及ぶ無駄な格闘、そして実際には壊れていないのにFedoraを疑ってしまうような時間の節約につながれば幸いです。それではまた次の記事でお会いしましょう。