Questions about USB Booting on UEFI systems

I was recently asked to implement UEFI boot support in MistyPE and have made some progress with this. It's currently being tested by someone with the required hardware - not being able to test your own work is an unusual position to be in as a project developer.

Anyway, I've been doing my best to research UEFI - in particular booting WinPE on UEFI systems. I'm pretty confused due to the sometimes conflicting information I've come across, hence this post. If someone can clarify/confirm any of the following then please help.

1] - UEFI systems can be 32-bit or 64-bit, but not both?

2] - a 32-bit UEFI system cannot boot a 64-bit WinPE?

3] - a 64-bit UEFI system cannot boot a 32-bit WinPE?

4] - the UEFI boot file is \EFI\boot\bootia32.efi on 32-bit UEFI systems?

5] - the UEFI boot file is \EFI\boot\bootix64.efi on 64-bit (amd64) UEFI systems?

6] - if \EFI\boot\bootia32.efi is not available then bootmgfw.efi can be copied from a 32-bit Windows installation (path \Windows\boot\EFI\bootmgfw.efi) and renamed as \EFI\boot\bootia32.efi? Or alternatively the same file can be extracted from 32-bit install.wim.

7] - if \EFI\boot\bootix64.efi is not available then bootmgfw.efi can be copied from a 64-bit Windows installation (path \Windows\boot\EFI\bootmgfw.efi) and renamed as \EFI\boot\bootia32.efi? Or alternatively the same file can be extracted from 64-bit install.wim.

8] - the only boot files actually required on a UEFI system (for WinPE boot) are -
* \EFI\boot\bootia32.efi (or bootx64.efi on amd64 UEFI systems)
* \EFI\microsoft\boot\BCD

9 - if a hard disk is used, or a fixed type USB disk, then the disk should be converted to GPT and should include the following partitions -
* EFI (FAT32)
* MSR (128 MB)
* Seperate partition for data

10 - Microsoft recommends that the EFI partition not contain WinPE, however WinPE will boot from this hidden partition?

11] - Removable media cannot be converted to a GPT disk?

12] - if Removable media is used then it should contain one FAT32 partition containing the EFI boot files?

13] - if removable media with one FAT32 partition is used then this partition can also be set as active and the same device can be booted on BIOS based systems providing that bootmgr and \boot\BCD are also present?

14] - the Compatibility Support Module (CSM) provides legacy BIOS compatibility and will boot MBR partitioned disks.


Any help/clarification/information will be appreciated as my tests so far have been limited to VMWare Player with the following workaround manually added to the virtual machine configuration file -

firmware="efi"

Regards,

Misty

See answers in red (to the best of my understanding!)

 

I was recently asked to implement UEFI boot support in MistyPE and have made some progress with this. It's currently being tested by someone with the required hardware - not being able to test your own work is an unusual position to be in as a project developer.

 

Why not use a VM like VirtualBox? You can boot from a VDisk or a USB disk by using DavidB's VMUB utility. You can test both 64-bit and 32-bit UEFI booting. Just set up the VM.

 

Anyway, I've been doing my best to research UEFI - in particular booting WinPE on UEFI systems. I'm pretty confused due to the sometimes conflicting information I've come across, hence this post. If someone can clarify/confirm any of the following then please help.

1] - UEFI systems can be 32-bit or 64-bit, but not both?

 

Not sure if this is a rule, but generally a system with a 64-bit CPU has a UEFI firmware which will only list devices with 64-bit efi boot files (even though it could also boot 32-bit efi).

2] - a 32-bit UEFI system cannot boot a 64-bit WinPE?

 

A 32-bit CPU cannot run 64-bit code!

3] - a 64-bit UEFI system cannot boot a 32-bit WinPE?

 

Not sure if it cannot boot - but most UEFI firmware versions which are running on 64-bit CPUs  just ignore 32-bit efi boot files.

4] - the UEFI boot file is \EFI\boot\bootia32.efi on 32-bit UEFI systems?

 

on x86 systems this is the default file. Any file name/path can be set up in NVRAM in the UEFI BIOS.

5] - the UEFI boot file is \EFI\boot\bootix64.efi on 64-bit (amd64) UEFI systems?

 

ditto

6] - if \EFI\boot\bootia32.efi is not available then bootmgfw.efi can be copied from a 32-bit Windows installation (path \Windows\boot\EFI\bootmgfw.efi) and renamed as \EFI\boot\bootia32.efi? Or alternatively the same file can be extracted from 32-bit install.wim.

 

so it is written...

7] - if \EFI\boot\bootix64.efi is not available then bootmgfw.efi can be copied from a 64-bit Windows installation (path \Windows\boot\EFI\bootmgfw.efi) and renamed as \EFI\boot\bootia32.efi? Or alternatively the same file can be extracted from 64-bit install.wim.

 

so it is written...

8] - the only boot files actually required on a UEFI system (for WinPE boot) are -
* \EFI\boot\bootia32.efi (or bootx64.efi on amd64 UEFI systems)
* \EFI\microsoft\boot\BCD

 

depends what is in the .efi file - it could boot to grub2 first... I have not studied the 'boot chain' fully - maybe someone else can fill you (and me) in?

9 - if a hard disk is used, or a fixed type USB disk, then the disk should be converted to GPT and should include the following partitions -
* EFI (FAT32)
* MSR (128 MB)
* Seperate partition for data

 

No, EFI will boot from a single FAT32/FAT16 disk as well as GPT/ESP

10 - Microsoft recommends that the EFI partition not contain WinPE, however WinPE will boot from this hidden partition?

 

What is an EFI partition? Do you mean ESP? I think it could in theory.

11] - Removable media cannot be converted to a GPT disk?

 

Never tried - maybe Easus Home Partition Master will do it?

12] - if Removable media is used then it should contain one FAT32 partition containing the EFI boot files?

 

yes - but this applies to ANY type of boot device (e.g. USB HDDs) also.

13] - if removable media with one FAT32 partition is used then this partition can also be set as active and the same device can be booted on BIOS based systems providing that bootmgr and \boot\BCD are also present?

 

In theory the partitions 'Active' flag could be set or cleared - it shouldn't matter for UEFI booting. It also shouldn't matter for MBR booting - e.g. grub4dos mbr will boot to grub4dos in MBR mode even if no partition is marked as Active - it depends on what the MBR boot code does. In practise, some MBR BIOSes do seem to need an active partition.

14] - the Compatibility Support Module (CSM) provides legacy BIOS compatibility and will boot MBR partitioned disks.

Yes

Any help/clarification/information will be appreciated as my tests so far have been limited to VMWare Player with the following workaround manually added to the virtual machine configuration file -

firmware="efi"

Regards,

Misty

 

JFYI (should you have missed any of them):

http://homepage.ntlw...ot-process.html

http://homepage.ntlw...ot-process.html

http://www.thomas-kr...tick_in_Windows

http://technet.micro...y/dn336950.aspx

http://www.911cd.net...showtopic=25262

http://www.911cd.net...showtopic=25596

 

Wonko

Guess a useful bit from Wonko's link for the PE boot chain is...

 

Windows NT versions 5.x

For the 64-bit versions of Windows NT 5.x, the EFI boot loader is \EFI\Microsoft\WINNT50\IA64LDR.EFI (sometimes \EFI\Microsoft\WINNT50C\IA64LDR.EFI), which comprises NTLDR, the Windows NT boot loader that loads and executes the Windows NT kernel from files in the Windows boot volume.

64-bit versions of Windows NT 5.x use EFI as it was designed to be used.

 

Windows NT versions 6.x

For Windows NT 6, the EFI boot loader is \EFI\Microsoft\Boot\Bootmgfw.efi, which is the Microsoft Boot Manager — another boot manager, which presents a second menu of boot options, read from a database file in a Microsoft-proprietary format, which in turn list boot loader programs to invoke and options to pass to them.

 

Windows NT 6 needlessly duplicates the functionality of the EFI boot manager, and needlessly makes a user-visible distinction between all other operating systems (listed on the first boot manager menu, which Microsoft configures to be displayed for only 2 seconds in order to, in Microsoft's own words, "make it easier" for users) and Windows NT (listed on the second boot manager menu).

 

 

 

So after Bootmgfw.efi I guess it looks at the BCD...?

 

and

On EFI firmware machines, it is a file located in the "\EFI\Microsoft\Boot\" directory on the EFI system partition.

Hi Misty,

 

Another common mistake as well : dont forget that a EFI BCD shall look at winload.efi whereas a non EFI BCD shall look at winload.exe.

 

Regards,

Erwan

@steve6375, Wonko and erwan.l
Thank you all very much for the informative responses. This will really help with the goal of implementing UEFI support in MistyPE/Mini-WinFE

So after Bootmgfw.efi I guess it looks at the BCD...?

and

On EFI firmware machines, it is a file located in the "\EFI\Microsoft\Boot\" directory on the EFI system partition.

On my test (VM) system I didn't use Bootmgfw.efi at all - just bootia32.efi/bootx64.efi copied from a Windows source DVD. I suspect these files are identical to the respective bootmgfw.efi files - although I haven't checked in a hex editor.

@everyone
Is there any advantage at all in using a GPT disk (with a seperate ESP) over a basic (MBR) disk with a FAT32 partition?

Regards,

Misty

P.s. If I follow all of Wonko's links (+ links to links to links, etc) how many years older will I be

You will be Teraold then.

Is there any advantage at all in using a GPT disk (with a seperate ESP) over a basic (MBR) disk with a FAT32 partition?

It may be possible a strange OEM machine requires GPT and declines MBR.
I haven't detected one so far. MBR works always.

@all
Can anybody claim GPT only case?
Which machine requires GPT and declines MBR?

At small USB SSD I'm using MBR and one FAT32 partition.
At bigger ones one FAT32 and another NTFS partition.

There is disk limit 2 TB at MBR.
It'll take a some time till I reach the limit at a spare 4 TB USB SSD...

Another case: given a GPT disk with data.
Add UEFI boot files to this disk. Given existings partitions this is simple less simple.

Related (thus including PXE) : Boot WINPE over PXE on a UEFI computer (http://labalec.fr/erwan/?p=791)

Thanks again to everyone for their responses. I have a bit more time to reply, so here goes.
 

It may be possible a strange OEM machine requires GPT and declines MBR.
I haven't detected one so far. MBR works always.

This is interesting and welcome news - most of the Windows based UEFI booting appears to be steering towards the use of GPT disks

 

Another common mistake as well : dont forget that a EFI BCD shall look at winload.efi whereas a non EFI BCD shall look at winload.exe.

My UEFI BCD store did contain an entry for winload.efi. Your comment prompted me to check my NORMAL (non-UEFI) BCD store and I noticed that an entry for winload.exe was missing, however WinPE was still booting. I did a quick test and made a new BCD store without the path \windows\system32\winload.efi entry - the VM still booted my WinPE. In fact, it was possible to boot both a UEFI and non-UEFI with the same BCD store (in different locations). This was a quick test with an x64 build of WinPE 4.0.

 

JFYI (should you have missed any of them):

I did (miss them, ALL of them) - so thanks. Your google fu is extra-ordinary I particularly liked the 911cd forum threads - your ongoing education of Ed is most amusing. You are a very patient teacher.

 

Why not use a VM like VirtualBox? You can boot from a VDisk or a USB disk by using DavidB's VMUB utility. You can test both 64-bit and 32-bit UEFI booting. Just set up the VM.

I did use VMWare Player, and this was helpful. Most of the questions in my first post were actually verified on a VM, however I was also after feedback about UEFI on real hardware as there's a lot of information out there about very different implementations of UEFI depending on the vendor/OEM. The VMUB utility sounds interesting - thanks for the headsup
 

3] - a 64-bit UEFI system cannot boot a 32-bit WinPE?

Not sure if it cannot boot - but most UEFI firmware versions which are running on 64-bit CPUs just ignore 32-bit efi boot files.

I did a quick test in my VM prior to my first post. I used a 64-bit VM and a 64-bit .efi boot file to try to boot a 32-bit WinPE. boot.wim was loaded to RAM and the boot process started, then resulted in an error (can't remember what the error was, I think it related to winload.efi. This is frustrating as I see no reason why a 32-bit WinPE cannot boot on a 64-bit UEFI system. This (from here) might be relevant -

Processor compatibility
...UEFI requires the firmware and operating system loader (or kernel) to be size-matched; for example, a 64-bit UEFI implementation can only load a 64-bit UEFI operating system boot loader or kernel. After the system transitions from "Boot Services" to "Runtime Services", the operating system kernel takes over. At this point, the kernel can change processor modes if it desires, but this bars usage of the runtime services (unless the kernel switches back again)....

8] - the only boot files actually required on a UEFI system (for WinPE boot) are -
* \EFI\boot\bootia32.efi (or bootx64.efi on amd64 UEFI systems)
* \EFI\microsoft\boot\BCD

depends what is in the .efi file - it could boot to grub2 first... I have not studied the 'boot chain' fully - maybe someone else can fill you (and me) in?

Whilst this is interesting, my very narrow focus (at this time) is UEFI WinPE boot using standard MS files. Cheers anyway.
 

10 - Microsoft recommends that the EFI partition not contain WinPE, however WinPE will boot from this hidden partition?

What is an EFI partition? Do you mean ESP? I think it could in theory.

I did mean ESP - thanks for the correction. It did boot on a VM and the added advantage is that a generic BCD store can be used with paths (device, etc) set as boot.
 

12] - if Removable media is used then it should contain one FAT32 partition containing the EFI boot files?

yes - but this applies to ANY type of boot device (e.g. USB HDDs) also.

The best news of all - also confirmed by others.

Thanks again to everyone.



Misty

P.s. If I follow all of Wonko's links (+ links to links to links, etc) how many years older will I be

 

 

Ever wondered WHY EXACTLY you say "wise, old man"?

 

 

 

I did (miss them, ALL of them) - so thanks. Your google fu is extra-ordinary I particularly liked the 911cd forum threads - your ongoing education of Ed is most amusing. You are a very patient teacher.
 

JFYI, Ed_P is a rather expert user (and I believe a mainframe programmer in a previous job), he knows much more than you might think about computers, but he has a strange "allergy" for the initial booting part, and sometimes, when these matters are touched, it can happen that he goes a bit astray and needs to be shouted at to regain connection with the issue at hand. I am not particularly patient, but when I have to "fight" with my friend Ed_P, I find it useful to shout a little louder than usual, as -historically - it helps getting faster to the solution (besides having some fun with the bickering ).

 

Wonko

P.s. If I follow all of Wonko's links (+ links to links to links, etc) how many years older will I be

Peter

3] - a 64-bit UEFI system cannot boot a 32-bit WinPE?

Not sure if it cannot boot - but most UEFI firmware versions which are running on 64-bit CPUs just ignore 32-bit efi boot files.

I did a quick test in my VM prior to my first post. I used a 64-bit VM and a 64-bit .efi boot file to try to boot a 32-bit WinPE. boot.wim was loaded to RAM and the boot process started, then resulted in an error (can't remember what the error was, I think it related to winload.efi. This is frustrating as I see no reason why a 32-bit WinPE cannot boot on a 64-bit UEFI system. This (from here) might be relevant -

Processor compatibility
...UEFI requires the firmware and operating system loader (or kernel) to be size-matched; for example, a 64-bit UEFI implementation can only load a 64-bit UEFI operating system boot loader or kernel. After the system transitions from "Boot Services" to "Runtime Services", the operating system kernel takes over. At this point, the kernel can change processor modes if it desires, but this bars usage of the runtime services (unless the kernel switches back again)....

Just checked this again. The error code is as follows -

File: \windows\system32\winload.efi
Status: 0xc0000359
Info: The selected entry could not be loaded because the application is missing or corrupt.

This was an attempt to use a 32-bit WinPE 4.0 on a 64-bit VM with UEFI firmware.

Regards,

Misty

 

 

 Removable media cannot be converted to a GPT disk?

 

 

"Rufus" can create GPT partitioned removable disk.

 

http://rufus.akeo.ie/

 

http://www.eightforu...te-windows.html

 

 

But so far all UEFI systems seems to boot fine from MBR partitioned, FAT32 formatted  removable media.

Actually, is not there often a confusion between UEFI and GPT?

The first is a firmware specification whereas the later is a disk specification.

 

The UEFI specs include GPT but it does not mean GPT is a pre requisite to UEFI.

Even if some vendors might make it mandatory in the future.

 

To my understanding, GPT was invented to get rid of MBR limitations (the 2TB limit being one of them).

 

I did not read in depth the UEFI specs but wikipedia for states:

Disk device compatibility

In addition to the standard PC disk partition scheme, which uses a master boot record (MBR), UEFI works with a new partitioning scheme: GUID Partition Table (GPT). GPT is free from many of the limitations of MBR. In particular, the MBR limits on the number and size of disk partitions (up to 4 primary partitions per disk, up to 2 TB  per disk) are relaxed. GPT allows for a maximum disk and partition size of 8 ZB .

The UEFI specification explicitly requires support for FAT32 for EFI System partitions (ESPs), and FAT16 or FAT12 for removable media; specific implementations may support other file systems.

Lots of thanks to Everyone for sharing very useful information regarding UEFI booting...........

 

Regards...............

Edited by devdevadev, 29 June 2014 - 05:42 PM.