virtualbox.org

Does the latest version of Virtualbox support UEFI firmware or not? I want to set up a Windows 10 virtual machine in UEFI/GPT.

VirtualBox has OS X oriented UEFI BIOS support because OS X guests won't boot without it, there is no alternative. The same is not true of other guests hence I doubt that the devs will see this as a priority. Maybe when >2TB boot drives become the norm, probably not before.

I want to set up a virtual machine with 32-bit UEFI, another vm with 64-bit UEFI for testing.
It seems that OS X only accepts 64-bit UEFI. Is it right?

This is not the forum for discussing OS X guests. I would hope also that you are aware of Important notice regarding Mac OS X as Guest.

On a lark I setup a Windows 10 via UEFI / GPT and it works fine. Please note that on a 64 bit processor it is only possible to boot a 64 bit OS.

And to answer your question, YES, OSX only boots via UEFI. It is not legal to run OSX as a VM on anything but under OSX on a MAC machine.

Rootman wrote:Please note that on a 64 bit processor it is only possible to boot a 64 bit OS.

Say what? I'm running a 32bit OS on a 64bit processor right now.

mpack wrote:

Rootman wrote:Please note that on a 64 bit processor it is only possible to boot a 64 bit OS.

Say what? I'm running a 32bit OS on a 64bit processor right now.

That's UEFI boot, what the entire thread is about. You can boot 32 or 64 bit on a 64 bit processor using BIOS / CSM. UEFI only boots a 64 bit OS on a 64 bit processor - normally. There are exceptions where a manufacturer may supply 32 EFI boot files that will work on a 64 bit processor but they are far from the norm.

There are a few articles about it, one I found is here: https://blogs.intel.com/evangelists/201 ... 4-systems/

Ah, I see what you mean. I still don't understand it. I wonder how the BIOS (UEFI or other) would know what kind of code the OS is going to run?

mpack wrote:Ah, I see what you mean. I still don't understand it. I wonder how the BIOS (UEFI or other) would know what kind of code the OS is going to run?

If I understand correctly it doesn't. The UEFI system still has a sort of stub in the firmware that basically just says "find any bootable devices" and this stub will typically only look for UEFI files that are the same architecture as the processor - for a 64 bit CPU those named with a -64 in the name. The boot partition (or indeed the entire OS disk) must be FAT32 and have these boot files in the correct path in order to be recognized as a bootable drive. After the UEFI firmware finds the files it passes the boot process off to them by loading them into memory and executing them. This flips the processor into protected mode much sooner in the processes and is supposed to speed up booting.

This is how it works "out of the box" with a standard MS OS on UEFI. As the article I linked to above states some manufacturers have written 32 bit UEFI boot files that will work on a 64 bit processor to boot a 32 bit OS on a 64 bit processor. This is mainly on cheap tablets or very low end laptops.

Here's a more in depth article I found: https://www.happyassassin.net/2014/01/2 ... work-then/

UEFI is fairly simply as far as the user is concerned, it's just that we have decades of MBR knowledge and tools that will no longer work with it. The MBR boot processor from the BIOS has become so hacked, patched and is so loosely defined it's a miracle it works as well as it does over the decades since it's inception.

UEFI is NOT needed if your boot disk is less than 2TB in size, the good ol' BIOS / MBR boot will still work fine (for now) regardless of CPU architecture or OS bittedness. UEFI will work on any sized disk as well. Disks larger than 2tb when using the MBR / BIOS will be limited to 2tb total. So that giant 6tb drive you put in will only be 2tb total, the other 4tbs are simply hanging out there and will be totally unavailable. This is when the GPT portion of the UEFI/GPT tag team steps up. GPT allows the entire disk to be used, and can only be BOOTED to with the UEFI system. Now a SECONDARY disk larger than 2tb can be still used by making it GPT regardless if the OS boots is MBR / CSM or UEFI. Unfortunately the MBR / CSM simply can't be booted to on a GPT disk normally right "out of the box", although there are users that have hacked it to do so. Conversely UEFI won't boot to a disk that isn't marked GPT - and there are hackers that have made this work as well but an OS like Windows just won't do it "out of the box'.

The 2 tb limit CAN be overcome for a MBR / CSM boot by low level formatting the disk to a weird 4k sector size to "hack" the limitations of the MBR boot system. This works and is indeed the ONLY way a disk > 2tb will work on an XP system. See this article for more info: https://en.wikipedia.org/wiki/Advanced_Format

Rootman wrote:The UEFI system still has a sort of stub in the firmware that basically just says "find any bootable devices" and this stub will typically only look for UEFI files that are the same architecture as the processor

Hmm. I struggled for a moment to imagine what use that feature has. Why (and how?) would anyone install an incompatible OS on the local hard drve? However it occurs to me that this feature must envisage portable hard drives with multiple boot blocks to match whatever processor box they're plugged into.

I was already aware of the other stuff: disk sizes, MBR limits etc are relevant factors in the CloneVDI tool I wrote.

mpack wrote:Hmm. I struggled for a moment to imagine what use that feature has. Why (and how?) would anyone install an incompatible OS on the local hard drve? However it occurs to me that this feature must envisage portable hard drives which multiple boot blocks to match whatever processor box they're plugged into.

I am not sure what you're asking. When UEFI type boot is selected and the system boot menu is called up (F12 or whatever the systems keystroke is) then the firmware looks for and presents any bootable media that it finds with EFI files in a FAT32 partition (or formerly setup EFI entries) in the boot menu. I am no expert but that's the way I see it working. Most, if secure boot is turned off, will also show any CSM / MBR formatted bootable devices as well as an optional boot device when the system boot menu is called up. That's if it HAS a CSM mode.

It's certainly not necessary for any Windows OS setup under Virtualbox, but at least for Windows 10 it will work. I did it just because I again needed a Windows 10 VM to mess around with. I had a few others but Windows 10 ran so crappy under VB I just deleted them in frustration and fell back to Windows 7.

Some day, probably sooner than later almost ALL new physical systems will come with only EFI boot only and will drop CSM mode altogether. Virtualbox should still support CSM / MBR booting for VM's. Who knows what Microsoft will do with the OS itself. I've just seen a lot of confusion and fear about EFI booting. It's different and actually is better than CSM / MBR, but nothing to be afraid or confused about.

Thanks for all the answers. If we want to install Windows 32-bit OS in UEFI/GPT mode, only 32-bit UEFI is accepted. The 64-bit UEFI firmware will refuse to boot from Windows 32-bit ISO file.

PabloR wrote:Thanks for all the answers. If we want to install Windows 32-bit OS in UEFI/GPT mode, only 32-bit UEFI is accepted. The 64-bit UEFI firmware will refuse to boot from Windows 32-bit ISO file.

You can't boot a 32 bit OS on a 64 bit processor via EFI - no there are exceptions which a manufacturer might make it work, but a stock PC or VM isn't one of them. This would rely on a manufacturer making it specifically work. VMWare isn't one of those manufacturers.

Either install a 64 bit OS via EFI/GPT (or BIOS/MBR if you want) or a 32 bit OS via BIOS/MBR - again, 32 bit OS can't do EFI on a 64 bit processor.