Updated: January 16, 2013
This will be a very short tutorial, I promise. You are facing the following problem: you are testing Fedora as a guest operating system in a virtual machine on top of VirtualBox. Your test includes the installation of Fedora, which seems to be going on well. Done with the test, you reboot. However, instead of the expected GRUB menu, you get an error that reads: FATAL: INT18: BOOT FAILURE.
So what do you do now? Well, basically you read this tutorial. It's not just Fedora, although you're more likely to encounter this problem with RedHat-based and SUSE operating systems than you are with the Debian family. All right, enough babbling, let's get this quickly and simply resolved.
Problem & solution
So the problem that you see this error on first boot after the installation of a guest operating system in VirtualBox, most likely but not limited to Fedora:
FATAL: INT18: BOOT FAILURE
The problem is documented in a VirtualBox ticket aged four years, but I've come across this issue both in Fedora 16 and the latest Beefy Miracle. The problem manifests on first boot if you keep the operating system image mounted in the guest CD/DVD drive. For example:
To resolve this, just unmount the CD/DVD ROM-and reboot. You can do this by changing the available list of images for the controller to Empty. Here's another screenshot, showing the feature in action, without Fedora specifically being involved.
All in all, this weird error is very similar to the problem we faced with KVM, in my troubleshooting tutorial. One of the tips revolves around the first boot failure, only it comes with a different kind of warning. The resolution is identical in both cases.
root (hd0,1)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/vmlinuz
Error 15: File not found
Press any key to continue...
You can also change the boot order to HDD > CD/DVD-ROM > other. This way, if there is no partition table on the disk prior to the installation, VirtualBox will skip to the second boot device, and then you won't see the error afterwards. Again, using our CentOS test thingie to demonstrate:
Conclusion
Why would two different virtualization have the exact same issue, beats me. Everything about this error is strange, including the somewhat erratic manifestation, as well as the fact the bug has been open for ages. But in both cases, VirtualBox and KVM, the resolution is identical, both the removal of the ISO as well as the change in the boot order.
Hopefully, you've learned something valuable and perhaps saved yourself an extra installation or two or endless hours working in the GRUB rescue mode somehow trying to fix something that isn't broken. Or perhaps blaming Fedora for a share of problems that does not rightfully belong to it. Well, I guess that would be all. We'll review Fedora 18 in just a few days, so stay tuned.
Cheers.