VMware Communities
fred13579
Contributor
Contributor
Jump to solution

UEFI problem after upgrading to VMWS player 12

Hi all,

6 or 7 month ago I started writing a boot loader using UEFI. So I created an "Other 64-bit" type of image with a USB device, modified the vmx  file to enable "efi", and started booting from the USB stick where I place the efi file.

So far so good, no one can beat vmware to help work on things like that, I've been a long way with it.

Last week I had to upgrade to version 12 and all I can get is an "unsuccessful" message when booting up, I guess it looks like the player doesn't reach my efi boot file. The logs are a bit difficult to follow.

I went back to building an hello world efi image from UEFI Programming - First Steps using fasm, and I get the same unsuccessful message.

Has anything changed on this side? Does anyone have experience with this type of problem?

Reply
0 Kudos
1 Solution

Accepted Solutions
dariusd
VMware Employee
VMware Employee
Jump to solution

The EFI Shell is quite handy... It's not a feature we officially support – It's a bonus extra that we hope will be helpful but is included as a debugging tool, and we specifically don't guarantee that it will always be available in future VMs or that its behavior will remain backwards-compatible across versions or products.  But it is very handy for investigating and correcting problems, and even has a text editor and a hex editor built in.

Either way, what you've described is not how we'd expect things to behave...  The error message is given when the file either doesn't exist or isn't a recognized file format.

Feel free to extract the BOOTX64.EFI from the VM and post it here in another zip file if you want me to try to figure it out. Smiley Wink

Cheers,

--

Darius

View solution in original post

Reply
0 Kudos
10 Replies
dariusd
VMware Employee
VMware Employee
Jump to solution

Hi fred13579, and welcome to the VMware Communities!

I'm one of the developers of our virtual EFI/UEFI firmware.  Good to hear that you are finding Player useful for your development, but not so good to hear that it's not working for you anymore with Workstation Player 12!  Our EFI firmware is in active development, so there have been lots of changes between the major releases lately... it'd be difficult to guess at a likely cause without knowing what the bootloader is doing.  Regardless, we don't like things to "regress" without a good explanation, so I'd like to figure out what's going on.

If you go to the EFI Shell in your virtual machine, do you see a filesystem ("fs0:", "fs1:" or similar) containing your bootloader in \EFI\BOOT\BOOTX64.EFI?

Could you please share the BOOTX64.EFI you have built from the Hello World example using FASM?  (I can try setting up FASM and building it too, but it'd be quicker if I could just grab your built copy, if that's OK...)

Cheers,

--

Darius

Reply
0 Kudos
fred13579
Contributor
Contributor
Jump to solution

Hi Darius, thanks for having a look at it.

I see the fs0: , I can cd to it but I can't ls, the error is "No Mapping". On my Windows machine I can verify that the usb stick is still a FAT32 with \EFI\BOOT\BOOTX64.EFI in it. I attached a small screenshot.

I also attached the fasm compiled file. It gloriously displays "Hello World!"

I recreated a new VM with exactly the same result, so it's probably not a backward compatibility issue.

I tried to rule out the usb stick by FAT32 formatting a virtual HD on another new VM. Interestingly, this VM doesn't show me the EFI Shell option so I can't test this way the HD.

There are odd things happening.

Fred

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee
Jump to solution

Instead of "cd fs0:", either just do "fs0:" (which will change to fs0:) or do "ls fs0:".  The "No mapping" error you're seeing is because there is no "current drive"... the shell prompt would change from "Shell>" to "fs0:\>" or similar once you have told the Shell which drive to consider the current drive.

"cd fs0:" – show the current directory on drive fs0:

"cd fs0:\" – set the current directory on drive fs0: to the root directory, but do not change the current drive to fs0:

"fs0:" – change the current drive to fs0:

Very interesting if the EFI Shell doesn't show up in the boot menu.  We won't automatically try to boot from the Shell on the first run through the boot options (it causes far too much end-user confusion!), but it certainly should be in the menu and should be able to be launched from there...

I'll try your hello.efi here and see what I can find.

Cheers,

--

Darius

Reply
0 Kudos
fred13579
Contributor
Contributor
Jump to solution

In this case, the fs0 access looks pretty good. Attached is a screenshot.

ok, then remains this efi file. I wonder what can be wrong with it.

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee
Jump to solution

We will only try to boot from BOOTX64.EFI, as required by the UEFI specification.  I see you have two different files – hello.efi (which you've described) and a BOOTX64.EFI (Where did that come from?  What is it?).

Your hello.efi works just fine in a VM here... You should be able to run it with the command "fs0:\EFI\BOOT\hello.efi"... what happens if you do that?

hello.efi screen shot.png

If you rename hello.efi to BOOTX64.EFI, it should run automatically – but it'll print the Hello World message and then it'll quickly jump straight back to the EFI Boot Manager menu, so you probably won't see it for more than a brief instant.

Cheers,

--

Darius

Reply
0 Kudos
fred13579
Contributor
Contributor
Jump to solution

sweet, thanks for pointing me to the EFI Shell, it'll actually make it easier to develop anything because I won't need a quick eye to catch a quick message at boot time.

Anyways, yes, the hello.efi works but not the BOOTX64.EFI

bootx64_nogood.PNG

The same file use to work and doesn't work anymore. Something has changed in the player, I would say a bug was fixed and doesn't allow my efi file to run any longer. I need to look deeper into what I did in this BOOTX64.EFI file.

Does the message above say that the BOOTX64.EFI is not recognized as valid PE image? Or is it a generic error message?

Darius, thanks for spending the time on it, I hope it was not too distracting. For me it helped a bunch.

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee
Jump to solution

The EFI Shell is quite handy... It's not a feature we officially support – It's a bonus extra that we hope will be helpful but is included as a debugging tool, and we specifically don't guarantee that it will always be available in future VMs or that its behavior will remain backwards-compatible across versions or products.  But it is very handy for investigating and correcting problems, and even has a text editor and a hex editor built in.

Either way, what you've described is not how we'd expect things to behave...  The error message is given when the file either doesn't exist or isn't a recognized file format.

Feel free to extract the BOOTX64.EFI from the VM and post it here in another zip file if you want me to try to figure it out. Smiley Wink

Cheers,

--

Darius

Reply
0 Kudos
fred13579
Contributor
Contributor
Jump to solution

So I need to go back to the BOOTX64.EFI file format and try to figure it out.

This boot loader is more of a hobby/personal curiosity type of thing, and it is in no way related to my day job. That's why I'm so glad the VMWS Player exists and works so that I can look into it in my personal time. And because it's more of a personal project, I'll give myself a chance to crack the issue first. This boot loader was not created with standard tools to say the least, giving it to someone to spend time on it doesn't feel right.

It's probably a format issue where the UEFI layer became more strict about PE rules, that's what I'll be looking at first.

I'll drop an update on what I found, it might be interesting or not.

Thanks for all your help Darius.

Fred

Reply
0 Kudos
fred13579
Contributor
Contributor
Jump to solution

Found it. It was in a PE section definition.

I have a code section at the end of the file where I put all of my functions, this section definition has an entry for "Size of Raw Data", which tells the loader how many bytes to copy from the binary file to memory. For this particular number I used to make it large so that I didn't need to do the math every time I do small additions to the section. It's the last section of the file so what's beyond its end didn't use to matter, but now the new UEFI implementation seem to be stricter on that size. If I set the "Size of Raw Data" to exactly what it is, the boot loader works.

Alright, at least one mystery solved.

cheers!

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee
Jump to solution

Cool.  Good to hear that it's working!

Sounds like you're doing some fun low-level stuff there... Feel free to post back here again if you encounter any further hurdles on your adventures in EFI land.

Cheers,

--

Darius

Reply
0 Kudos