virtualbox.org

See attached screenshot, and log file.
Host is OS X, Virtual Box 4.1.20.
Guest is Linux, but with the VDI I don't get past EFI Shell.

I'm not really understanding this. The VDI is GPT partitioned, with the first partition EFI System Partition with the proper partition type GUID. It's formatted FAT32 with mkfs.msdos -F 32 -n "EFI System" /dev/sda1. It mounts fine in Linux. GRUB sees and navigates it fine too. But the Vbox EFI Shell isn't mounting it, I don't think. Shouldn't it be fs0:? When I change to blk0: and list, it's considered invalid.

This must be user error but I can't figure out what's wrong the log is unrevealing.

Is the VDI one you created, or from someone else?

I did. The VDI was created in the same version of Vbox, in the same VM, although at the time of creation, the VM had Enable EFI unchecked.

Oh well there's the reason. You don't have the right grub installed. Search Fedora for how to convert to EFI.

Be advised that Fedora has some serious bugs which is keeping it from going gold and IIRC efi is one.
I do know that the build from 15th works.

I have converted already, in Fedora 18 both grub BIOS and UEFI packages are installed by default. The disk is GPT. It has an EFI System Partition. It has an /EFI/fedora/grub.efi and grub.cfg there. But I don't even get far enough to navigate the ESP, let alone load it. It seems to me I should get fs0 or fs1 options in the shell, but it's like the EFI doesn't like this ESP: Invalid file system mapping?

Sorry to say I don't know what else to tell you. I installed the fedora build from the 15th and it worked using EFI but was flaky. Previous daily builds didn't work for me and they have noted that EFI has bugs (redhat/fedora)

OK but flaky and didn't work are vague terms. It didn't work how? Was the mode of failure at all like what I'm seeing where you can't even navigate the ESP file system? It would seem to take a significant bug in grub-install to corrupt the file system enough to make it non-navigable.

And yes there are a ton of EFI bugs. The code base is huge, and relatively untested. But navigating a FAT volume seems really basic and should work. It does work on El Torito disks, and that's more obscure than a GPT disk.

Meaning previous EFI builds would start and get so far and hang. (live cd)
Flakey meaning that I needed to get the full install and do a VNC install because F18 could not deal with the video. Understandable because the guest additions need to be installed to get that to work properly. Once installed and then installing gnome, cinnamon, guest additions and creating a startup.nsh. Everything works as it should.

If you are having issues it almost has to be a Fedora issue or I guess maybe a VBox Mac version issue but I don't see how that could be, I guess it is possible.

Now converting may be an issue. This I have never attempted, but again I think it would still be a Fedora issue since using EFI, everything is really coming from the guest.

I would be curious to see if you could download the latest F18 Beta (full version) and see if you get to the install phase.

Here is a screen shot of my latest test.

OK again I'm no where near even getting to anything the EFI can identify as a valid file system. I need that sorted out first and foremost, or I have no chance getting to grub.efi, and no chance getting linux to boot. That I'm stuck getting an invalid file system to navigate manually tells me something must be wrong with the VDI (obscure, unexpected, but possible), or the GPT partition scheme which seems unlikely, or formatting of the ESP even though FAT32 should suffice. The EFI spec requires that EFI all by itself can navigate FAT 12, 16, and 32. So even if the VDI were empty, except for one ESP formatted as FAT32 with one text file called "hellokitty.txt" I should be able to navigate to that file from the EFI shell. So I need to do some regression.

I would be curious to see if you could download the latest F18 Beta (full version) and see if you get to the install phase.

Fedora 18 final test candidate 3 is current and while I can navigate either the DVD or LiveCD file system, find grub.efi, get a GRUB menu, and start booting linux, it is incredibly painfully slow and then hangs. So that's going to be some separate troubleshooting later on. This hang on boot problem was the reason why I did a BIOS install, and then went with conversion to EFI, rather than trying to get an oddly partitioned (by necessity) ISO to boot in EFI mode.

I've done this conversion many times on actual hardware, but this is my first experience using the VBox EFI other than for booting OS X (which interestingly enough is also really slow to boot, until the kernel is actually running - as if the EFI environment itself is running really really slow, but once released to the kernel everything picks up a lot of speed).

I don't know what to tell you. The steps I mentioned above are what it takes for me. Like I said the Live CD just hangs, and yes it was painfully slow during detection and loading the necessary packages before it finally decided to hang. Using the full version I did not have any issue other than needing to install via VNC. Actually it installed faster that way then using the normal live CD, of course then you have the extra packages to install. I also do EFI on Debian builds and I never have any issues with the live CD. I asked a few of my Fedora friends that are helping with the build and they told me it has issues, but would not say exactly what. I guess it's a secret.

OK as it turns out when the VM is using BIOS, grub2-install installs a bit of GRUB in the MBR. This prevents VBOX EFI from making any file system on the device visible, including the otherwise valid ESP. By zeroing the first 440 bytes of LBA0 this is resolved, and now the EFI "mounts" the ESP, it is navigable, and I can run grub.efi.