Useful (UEFI) things to know

If you add ISO files or other payload files to your E2B USB drive, it will only boot in Legacy\MBR\BIOS mode - it will not boot from a UEFI system.

To UEFI-boot, you must first convert the ISO (or payload source files) into a .imgPTN file using the MPI Tool Kit.

You then add the .imgPTN file to your E2B USB drive - the original .ISO file is not required to be on the E2B drive.

You can then MBR-boot to the E2B menu and select the .imgPTN file or use the \_ISO\SWITCH_E2B.exe utility to select the .imgPTN file (see here).

This will remove the E2B partition and replace it with a FAT32 partition (which contains the contents of the .imgPTN file).

You can then both MBR-boot or UEFI-boot (including Secure Boot) from the new partition on the USB drive.

You can boot to linux, Windows and other payload types via UEFI, in this way.

You can also set up the E2B drive so that you can UEFI-boot to WinPE and then run SWITCH_E2B.exe from WinPE to select any .imgPTN file you require and then reboot via UEFI to that image.

See here for more details and a YouTube video.

The easiest and most versatile way to UEFI-boot is to add a second FAT32 partition containing WinPE boot files.

This allows you to directly UEFI-boot (even Secure Boot) from the E2B drive and use SWITCH_E2B.exe under WinPE to select any image from the hundreds of .imgPTN files that can be copied to your E2B USB drive.

Due to some UEFI BIOS bugs however, I recommend that you reserve this type of E2B USB drive for UEFI-systems only because some systems may not be able to MBR\Legacy boot from the same E2B drive. So have one E2B drive for MBR\Legacy systems and another for UEFI-booting.

For more details see this page.

Gotchas

• A FAT32 partition #2 is normally required for UEFI booting (although some systems can UEFI-boot from an NTFS partition, many cannot).
• Some systems will not MBR-boot (i.e. Legacy\CSM boot to E2B) from the USB drive if any EFI boot file is present on the USB drive (on a FAT partition) - the only option presented by the BIOS will be a UEFI-boot option.
• When you Secure UEFI-boot, only signed 'secure' EFI files can be loaded and there are not many of these available. Some implementations (e.g. E2B REFIND images and E2B grub2 menu system) allow you to boot to unsigned files or you can use Mok manager to 'whitelist' unsigned boot files, but this makes changes to the system BIOS's NVRAM which can be difficult to remove\change at a later date.

Other options

1. WinSetupFromUSB uses the Microsoft EFI version of bootmgr (bootmgfw.efi) to boot to multiple Windows versions only (not UEFI Linux or other UEFI files).

2. grub2 - (aka 'grub') is the UEFI boot manager most commonly used by linux distros. It can boot via UEFI and also Secure boot to UEFI. It has the same problem as mentioned above in that separate partitions are usually required for 'flat file' booting. However, certain linux distros can UEFI-boot from an ISO file if you also specify the path of the ISO file in the kernel boot parameters. This means you can have a UEFI grub2 boot menu for each linux ISO so you can 'live boot' to each ISO or install from an ISO.

The problem is that you need to use the correct kernel boot parameters in your grub2 menu file and these parameters will vary from distro to distro and even version to version! This means that you (or the utility that you use to add the linux files to the USB drive), must know the correct parameters for each and every version in the entire world. If a new version of linux is released by the developers tomorrow, it may well not work if it requires different parameters.

E2B can switch-in a grub2 menu system. It recognises about 60 different ISOs. The ISO must be renamed (e.g. ubuntu.iso) so you can only have one of each distro. Also the kernel parameters may not be correct for later versions. However, you can add extra menu .grub2 files for any linux ISO you like and the menu system will automatically add in the new menu entries. You could also add Windows Install ISOs and multiple Windows VHDs.

3. Syslinux - this is in Beta. YUMI UEFI uses this, but for many payloads it then uses grub2 to get them to work!

The UEFI specification says that a UEFI BIOS must be able to load the EFI boot file from a FAT partition (either an MBR partition or a GPT partition).

For this reason, ext2/3/4, exFAT and NTFS volumes are not usually used as UEFI boot partitions because, unless the UEFI BIOS supports that filesystem, it won't be able to 'see' any files.

So it is best to place the .EFI boot files on a simple FAT16 or FAT32 partition on a USB drive or the FAT32 EFI partition of a USB GPT-partitioned drive.

Some UEFI BIOSes also include an NTFS filesystem UEFI driver as well as a FAT filesystem driver - this means that they can also load the EFI boot file from an NTFS partition. However, there is no guarantee that your BIOS will contain an NTFS UEFI driver, so we must use a FAT12/FAT16/FAT32 volume for best compatibility across all systems.

Bugs!

There are four Primary partition table entry 'slots' available in an MBR partition table - no mention is made in the (loosely written) specification on how to determine if they are FAT-based or if the BIOS should search each one for a valid .EFI boot file or in what order they should be searched or if the four Primary partitions must be in ascending order or if the partitions can overlap each other or what to do if there is more than one valid partition with valid boot files!

The UEFI specification does not mention which MBR partition to boot from (just that it does not need to be marked as 'active'=bootable in the partition table).

This then leaves it up to the BIOS writers to decide how to enumerate FAT partitions when looking for EFI boot files, so of course, we end up with a complete compatibility mess!

• Some BIOSes, for instance, will refuse to boot from a valid FAT32 partition if one of the MBR partitions is an ext type!
• Some BIOSes only look at the first FAT partition for boot files and then give up!
• Some BIOSes list any partition in the UEFI boot menu (even if they are not FAT-based).
• Some BIOSes list any USB drive that is FAT-based in the UEFI boot menu (even if it does not contain a suitable EFI boot file - e.g. no BOOTX64.EFI).
• Some BIOSes will always UEFI-boot (if a valid EFI boot file is present), even if you tell them to MBR-boot!
• Some BIOSes will not boot from a Primary partition if it starts at a lower sector position than the previous partition entry.
• Some BIOSes will look for a \EFI\BOOT\GRUBX64.EFI file and list that as a boot option (e.g. Linpus lite UEFI) and completely omit an entry for the standard default boot file at \EFI\BOOT\BOOTX64.EFI!

The writers of the UEFI specification missed a perfect opportunity to collaborate with BIOS writers to accurately define both Legacy and UEFI boot processes from MBR- and GPT-partitioned drives! The specification does however seem to allow nested MBR partitions (Section 13.3.2) and so implies that all Primary and nested (=Logical?) partitions should be searched for all FAT partitions and list all valid partitions as UEFI-bootable entries. i.e. The UEFI developers expanded on the MBR specification but failed to standardise the MBR boot specification!

MBR = Master Boot Record - first 512 byte sector on a partitioned disk.

PBR = Partition Boot Record (also known as VBR = Volume Boot Record), i.e. VBR == PBR - first 512 byte sector of a partition. A floppy disk does not have a MBR, the first sector of a floppy disk is the PBR.

Tip: To see the first sector of your USB drive, use the Disk Info button on RMPrepUSB and enter 0 as the sector value. To see the PBR sector, enter P1.

A 512-byte MBR usually contains a 64-byte Partition Table starting at byte 1BE (hex). This can contain up to 4 Primary partition entries (16 bytes each entry). Each 16-byte partition table entry contains this information:

• Active Flag (the BIOS will boot to this partition if bit 7 set - typically 80h)
• Partition Type - gives a hint as to what filesystem is contained in the partition - e.g. 0C or 0B = FAT32, 07=exFAT or NTFS.
• Partition Start - the disk sector where the partition starts and where the PBR can be found (in CHS format)
• Partition End - the last disk sector of the paritition (in CHS format, only used if
• Partition Start (LBA) -  the disk sector where the partition starts and the PBR can be found (
• Partition Size - number of sectors in the partition (

The PBR typically contains BIOS Boot Parameters (BPB) which contains data about the filesystem in the partition and more boot code which will boot the operating system that is on that partition.

The UEFI specification states that the MBR partitions must not overlap each other.

For more details on the MBR and PBR see  here .

There are two types of Intel x86 CPU computer PC systems, those systems with 'MBR\IBM\Legacy BIOS' firmware and those with 'UEFI' firmware. Firmware is the non-volatile code in a PC which is first executed when you turn it on - it is typically used to select and load boot code from sectors on a boot disk. It also provides basic display and keyboard input support functions.

The older 'BIOS' type of system cannot access files on a disk, it has to load code from sectors contained within the MBR and PBR and so must boot from drives with MBR-type partitions or floppy drives containing a PBR. The newer UEFI-type of system firmware (BIOS) can only directly access files on FAT and GPT partitions (not NTFS or exFAT or ext2/3/4, etc.). The UEFI specification says that booting from a FAT filesystem must be supported.

Most UEFI BIOSes usually also contain extra code called a 'Compatibility Support Module' (CSM) in it's firmware. This is an extra 'block' of firmware code which allows a UEFI system to boot in MBR mode using a BIOS code module that boots in the same way as the old BIOS firmware does (this is often called CSM-mode). MBR-mode, CSM-Mode and BIOS-mode are therefore equivalent but are completely different from UEFI-mode.

New Windows 8/10 systems shipped by an OEM manufacturer will all be UEFI systems and they will boot in UEFI-mode and the internal hard disk will contain GPT partitions. To boot from an external USB drive in MBR\CSM mode, you will need to disable Secure Boot and enable CSM-mode (which may be called 'Legacy' mode in some Setup menus). You may also need to disable 'Fast Boot'.

A few UEFI-based systems can also boot from .EFI boot files on NTFS partitions (e.g. Asus Z87 mainboard) - this is not typical of all systems however. 

Hers is a typical boot sequence for a BIOS-based MBR\CSM system:

1. Switch on system
2. Firmware (BIOS) code inside the system executes
3. First sector (MBR) of each disk is read (order depends on how user has configured BIOS)
4. If the sector is a valid bootable sector, the sector is read into memory and executed by the CPU

• Look at the four partition table entries in the MBR
• If one is marked as Active, load the data contents of first sector of the active partition (PBR) into memory and execute the code

• The boot sequence for Windows 7 (MBR mode) is: Power on - MBR - PBR - bootmgr
• The boot sequence to boot to grub4dos (installed to PBR, not MBR) is: Power on - MBR - PBR - grldr
• The boot sequence to boot to grub4dos (installed to MBR) is: Power on - MBR - grldr
• The boot sequence to boot to syslinux (installed to PBR) is: Power on - MBR - PBR - ldlinux.sys
• The boot sequence to boot to FreeDos (installed to PBR) is: Power on - MBR - PBR - kernel.sys
• The boot sequence to boot to MS-Dos (installed to PBR) is: Power on - MBR - PBR - io.sys

When booting from a USB drive, the BIOS will assign the USB drive as the first drive (BIOS drive 0 = 80h) and the first internal hard disk will be assigned as the second drive (BIOS drive 1 = 81h). Typically, the boot drive will always have a BIOS designation of 80h - drive 0.

Note: Floppy drives are given a BIOS ID number of 0-3, 'hard disks' from 80h-9fh and CD\DVDs A0h-FFh (but only if you boot from them).

Most modern systems will treat a USB drive (Removable-type or Fixed disk type) as a 'hard disk' and thus give it an ID number of 80h when it boots from it.

E2B will often swap over drive 0 (the E2B USB drive = 80h) with drive 1 (the first internal hard disk = 81h) before it boots to a payload - this is so that the operating system that you boot to does not see the E2B USB drive as the system boot drive - otherwise if you are installing an OS, the installer might write the boot files onto the E2B USB drive instead of the internal hard disk! E2B file extensions ending in '01' will make this ID swap for you.

Boot chain:
BIOS (PCAT) -> BootMgr { BootMgr stub -> embedded BootMgr.exe } -> WinLoad.exe -> Windows
64-bit (U)EFI -> bootx64.efi -> BootMgFw.efi -> BootMgr.efi -> WinLoad.efi -> Windows

UEFI systems boot in this sequence  (if in UEFI boot mode):

1. Switch on system
2. Check non-volatile memory to see what boot device and boot file has been defined by the user or a previous OS as the first boot device
3. Check for a valid filesystem in each partition (FAT12/FAT16/FAT32 or GPT EFI)
4. Look for the designated boot file (default = \EFI\boot\bootxxxxx.efi where xxxxx depends on the CPU architecture - see below)
5. Load the boot file into memory and execute the code

Most UEFI-capable Operating Systems can tell the UEFI BIOS which boot file to load in future - for instance, Windows 8 can specify that the UEFI firmware should load the \EFI\microsoft\boot\bootmgr.efi file instead of the default  \EFI\boot\bootx64.efi file. Thus if we have installed both Ubuntu and Windows 8 to the system, the UEFI may allow the user to choose to boot to either of these via the UEFI boot menu, because each OS has added a boot option into the UEFI non-volatile RAM storage area. In a typical UEFI setup menu, you can view these boot options and delete or clear the entries if you wish.

If no valid boot files are specified in the UEFI non-volatile RAM storage area, then the default boot file will be used (e.g. \EFI\boot\bootx64.efi for an Intel x86 64-bit UEFI system).

Beware: Just because a system has a 64-bit CPU, does not mean it has 64-bit UEFI firmware! Some systems with 64-bit CPUs have 32-bit UEFI firmware and will only UEFI-boot to a 32-bit OS (they look for \EFI\boot\bootia32.efi).

A 64-bit UEFI system cannot boot from 32-bit UEFI boot files. 64-bit UEFI code is not compatible with 32-bit UEFI code because the CPU is in a different mode.

Note: The file \bootmgr.efi is used by UEFI systems to boot from a CD/DVD (el Torito specification), it is not used for USB/hard disk booting.

Some systems do not have a Legacy\MBR\CSM option in their firmware (i.e. they have no IBM-compatible 'BIOS').

This means that you cannot boot to the E2B Menu System from them because E2B uses grub4dos which only boots on MBR\CSM BIOS systems.

Before you start, make sure you have updated the firmware (BIOS) to the latest version.

If you want to boot from a payload file on your E2B USB drive using one of these UEFI-only systems:

1. There are two types of UEFI Intel x86 firmware, 32-bit or 64-bit. We need to know what type the target system has. Check what OS was originally shipped on the system. If it was a Windows 64-bit OS, then you have 64-bit UEFI firmware. If it was shipped with a 32-bit Windows OS, then you have 32-bit UEFI firmware. Note that the CPU inside the target system may be 64-bit, but the UEFI firmware may be 32-bit! Systems with limited internal storage tend to have 32-bit UEFI firmware because 32-bit OS's require less disk space than 64-bit OS's.

2. Once you know what type of UEFI firmware you have, you can select a compatible payload that is UEFI-bootable and supports the same UEFI type. For example, if your system originally came with Windows 8 32-bit, then you can use Windows 8/8.1/10 or linux 32-bit payloads but not 64-bit Windows/linux payloads. For your first test, I suggest you use a CloneZilla ISO because this contains both 32-bit and 64-bit UEFI boot files and so either type of firmware should boot from CloneZilla.

Note that many payloads do not support UEFI-booting at all (e.g. Hirens Boot CD)! Look for a \EFI\boot\bootx64.efi or \EFI\boot\bootia32.efi boot file inside the ISO - these are the 64-bit and 32-bit EFI boot files and at least one MUST be present if it supports Intel x86 UEFI-booting.

3. Convert the payload file (e.g. Clonezilla.ISO) to a .imgPTN file by dragging and dropping the file onto the MPI_FAT32 Desktop shortcut of your Windows system.

4. Copy the .imgPTN file to your E2B USB drive (e.g. copy it to the \_ISO\MAINMENU folder) and make it contiguous (run \MAKE_THIS_DRIVE_CONTIGUOUS.cmd).

5. Run \_ISO\SWITCH_E2B.exe, select the USB drive and double-click on the .imgPTN file - this will 'swap-in' the new .imgPTN file as a new FAT32 partition (the old E2B partitions will be replaced).

Alternatively, you can run the \QEMU_MENU_TEST (run as admin).cmd script and boot to the E2B USB drive using QEMU and then select the .imgPTN file from the menu to get to the E2B CSM Menu).

For the most flexible solution, I recommend creating a separate FAT32 USB flash drive containing WinPE. You can then boot to WinPE from any system (BIOS or UEFI) - run Switch_E2B.exe and 'switch' to any .imgPTN file on your E2B USB drive. See my blog post for more details.

6. Now connect the USB drive to your target UEFI system and boot from it (you may need to disable Secure Boot and Fast Boot in the firmware settings first, because not all OS payloads are signed for secure booting).

Restoring the E2B drive

Once you have finished, connect the E2B USB drive to a Windows (or WinPE) system and run the \e2b\SWITCH_E2B.exe utility and click on the 'Restore E2B Partitions' button to restore the original E2B partition.

Alternatively, you can boot it on an MBR\CSM system and choose menu #0 in the CSM Menu to restore the E2B partition.

Instructions for Surface 3 USB booting (video here)

When a USB Storage device is connected to a computer, it can be sent an 'Inquiry' command to determine it's capacity and type. One of the bits returned by the Inquiry command response is the Removable Media Bit. If this bit is set (RMB=1) then it signifies to the computer that the media in the device is removable - for instance an SD card in an SD Card Reader is removable by the user, but a hard disk inside a USB hard disk enclosure is not removable.

Because USB Flash drives are easily 'removed' by a user, the firmware inside most USB Flash drives was programmed by the USB drive manufacturers to return RMB=1 (i.e. Removable).

Microsoft Windows treats Removable media in a different way to non-removable media. Windows will only mount one drive volume on a Removable-type drive - typically this is the first Primary partition that it identifies as a valid Windows partition in the MBR partition table. Therefore, even if the Removable USB Flash drive has multiple partitions, Windows will only be able to access the first partition.

Window also treats Removable-media drives slightly differently during file I/O operation. Because the drive could be removed by the user at any time without warning, the default policy used by Windows is to not cache any file write operations, but to flush all file writes immediately to the USB drive. This has the side affect of marginally decreasing file write speed, but it helps to avoid potential file corruption. Windows also will not allow you to set up a swap file, hybernation file or page file on a Removable drive. Also, some Windows Updates may not install if Windows is actually running from Removable-media.

When WindowsToGo first arrived, the above mentioned limitations prevented WindowsToGo from correctly running on Removable-type USB Flash drives. Microsoft therefore asked USB Flash drive vendors to make USB Flash drives which had RMB=0 set in their firmware (i.e. non-removable). These drives could then be certified as 'Windows 8 Certified' drives. It also meant that they could have multiple partitions which were visible to Windows. WindowsToGo 8.1 and WindowsToGo 10 will not boot from a Removable USB drive (endless spinning circle of dots!) - however, if you use a VHD file instead of 'flat files', then these versions of Windows will fully boot from a Removable USB flash drive.

Even when a drive is of the Removable-media type, I recommend that you ALWAYS use the Eject or Safely Remove Drive Windows feature before you unplug the drive. If Windows happens to be writing to the FAT tables just as you unplug the drive, the drive could lose ALL of your files (e.g. if the controller is in the middle of a 'page read-erase-write cycle' just when you pull it out and thus remove the power!)

So today, we can purchase a USB Flash drive which may be of the Removable type or may be of the Fixed-disk type. There is no way to tell before we buy it, except that if it is 'Windows Certified' then it will be of the Fixed-disk type.

If you have an E2B USB Flash drive of the Removable-type, you can create an extra Primary partition (or extra Logical partitions) on the drive using a partition utility such as EaSeus Home Partition Master or linux pmagic. However, neither Windows or the Windows Installer (WinPE) OS will be able to 'see' and access the extra partitions. You can use RMPrepUSB - Ctrl+O  (or BootIce) to swap over the 1st partition with the 2nd partition, thus making the 2nd partition (only) accessible to Windows.

You can also install a special Windows 32-bit disk driver (e.g. cfadisk) which will trick Windows into treating a Removable-media drive as a Fixed-disk drive. However, if you are installing Windows from a Windows ISO, remember that the Windows ISO will not contain this driver and so will only be able to access the first partition on a Removable-media drive!

Some USB formatting utilities that are used to prepare bootable USB Flash drives will not 'detect' USB Flash drives if they are of the Fixed-disk type.

When installing Windows Vista/7/8 from an ISO file on E2B USB drive, E2B writes special instructions into the \AutoUnattend.xml file in the root of the E2B USB drive. Windows Setup will automatically find this file and read the instructions when it loads - but ONLY if the USB drive is of the Removable type! This is why, if you are using a Fixed-disk type of USB drive for E2B, you need to add an extra 'Helper' Removable-type USB Flash drive (or use a partition image instead of an ISO file).

The Lexar utility BootIt.exe can 'flip' the RMB bit and switch some types of flash drives between 'Removable' and 'Fixed' types. This works on some Lexar drives and some types of Netac and a few other USB 2.0 flash drives (depending on what controller and firmware is used). Generally, it is safe to try BootIt on any flash drive - it will either work or not. I do not  recommend trying to use a manufacturer's Flash drive reprogramming tool to change the RMB bit - it usually ends in 'bricking' the USB drive!

CSM = Compatibilty Support Module (a block of code added to the UEFI firmware which emulates an older-type MBR BIOS) - basically, it is a complete IBM PC-compatible BIOS!

Modern PCs have UEFI firmware (aka UEFI BIOSes) rather than the old IBM-compatible BIOSes.

Older BIOSes boot by running the code in the Master Boot Record (first sector) of the disk and uses Interrupt 13h calls to access the disk. The CPU is in Real Mode and not Long Mode or Protected Mode. It can only run code that was written to run in Real Mode.

Modern UEFI firmware can directly load and run code from a file (e.g. \EFI\BOOT\BOOTx64.EFI) from a partition on a disk - no BIOS Interrupt call mechanism is available. UEFI firmware is written in 64-bit or 32-bit Long Mode (depending on what UEFI firmware and CPU is present) - any code that it 'boots' to must be written to run in Long Mode. Therefore you cannot directly run old Real Mode code (such as DOS or grub4dos or Windows 98) when UEFI-booting.

CSM is a mode that you can enable on a UEFI system that will boot in the same way that the older BIOSes boot, thus allowing you to boot from disks which have been prepared with an MBR and that contain boot code which use Interrupt 13h for disk access and runs the CPU in Real Mode. CSM basically adds an IBM-compatible BIOS firmware module, so that your system will boot in the same way as the 'old' type of IBM-compatible systems.

For Intel x86 CPU architecture systems there are two types of UEFI firmware, 32-bit and 64-bit.

64-bit CPUs can run 8-bit, 16-bit, 32-bit and 64-bit code, however UEFI firmware contained in a system typically only supports a sub-set of these modes - either 32-bit or 64-bit.

• If a system contains a 32-bit CPU, then the UEFI firmware will only be capable of booting 32-bit UEFI OSs - typically it will start to boot from the \EFI\boot\bootia32.efi file.  The system may also support CSM booting which is the equivalent to MBR booting on older systems.
   
• If a system contains a 64-bit CPU, then the UEFI firmware will usually be capable of booting 64-bit UEFI OSs - typically it will start to boot, by default, from the \EFI\boot\bootx64.efi file. The system may also support CSM booting which is the equivalent to MBR booting on older systems. However, some UEFI systems that have a 64-bit CPU may contain 32-bit UEFI firmware (e.g. some Asus T100 Tablets - because a 32-bit OS takes up less disk space than a 64-bit OS) - so just because the CPU is 64-bit capable, it does not necessarily mean that the UEFI firmware is 64-bit. 

See here for details.

This is a common misconception!

GPT is a disk partitioning scheme that allows you to have partitions greater than 2TB.

UEFI is a new type of firmware (BIOS) that allows the computer to boot from a file or a selection of files on a FAT-formatted partition on a disk (an MBR disk or a GPT disk). It also allows you to add pre-boot drivers so that you can extend it's function (e.g. add NTFS or HFS drivers or mouse or network drivers). It also provides a Secure Boot mechanism so that only signed 'boot code' will be executed - thus preventing viruses or booting from different unsecure media.

So the two things are completely different!

The EFI Intel specification includes details of the GPT partitioning scheme because one of the main objectives of EFI was to support drives larger than 2TB and this is not possible using the old MBR partitioning scheme.

The reason that you see GPT and UEFI used together is that Microsoft Windows Setup.exe will insist on using a GPT partitioned disk as its boot disk, when you try to install Windows after booting  the Windows Setup Installer via UEFI. So people often think that GPT and UEFI must be used together. The fact is that UEFI systems just need a FAT partition of some sort on a disk - the EFI partition on a GPT disk will be FAT formatted and will contain the .efi boot file(s) but you can UEFI-boot from a single FAT-formatted MBR-style (non-GPT) partition as long as the OS that you are loading supports it. If you boot Windows 7 or later Windows OS's in the old MBR\CSM mode however, GPT partitions are not supported and Windows won't like it.

Windows 7/8/10 Installers

Boot in MBR mode - Windows uses MBR partitions and does not like or understand installing to GPT partitions

Note: If a GPT partition exists on the hard disk, Windows Setup will refuse to install Windows to it even if you delete all visible partitions. You must use Diskpart - select disk 0 - clean - convert MBR  to remove the GPT partitions and then you can install Windows and create MBR partitions.

Boot in UEFI mode - Windows uses GPT partitioning and does not want to install to an MBR partition

This is a restriction imposed by Microsoft (Setup.exe) in order to simplify installing Windows.

It is perfectly possible to boot Windows PE and Windows To Go via UEFI from an old-style MBR FAT partition (with an NTFS partition also present).

Note: Many Intel Mac systems do not contain a BIOS-mode\CSM USB driver and so can only boot from USB drives in UEFI-mode. Some people have reported that some systems will only UEFI-boot from a GPT disk (e.g. some VAIOs?). If this is true, then those systems are not fully UEFI compliant!

It is possible to MBR-boot to a GPT disk containing Windows 8/10.

UEFI and BIOS are both types of firmware. Many people believe that the two are completely different and you should never say 'UEFI BIOS'. However, Asus UEFI firmware actually displays it's Setup Menu as 'UEFI BIOS'.

To my mind, BIOS stands for 'Basic Input/Output System' and is firmware that allows basic input (i.e. keyboard input) and basic output (i.e. characters displayed on a screen, disk I/O, etc.), So modern smart phones or the old Altair 8800 both contain BIOSes. IBM also used the term 'BIOS' to describe it's firmware in the IBM PC and so many people think BIOS = IBM PC BIOS. The IBM BIOS used software interrupts as a means of accessing the keyboard, display and disks (e.g. Interrupt 13h was used for disk read/writes). I prefer to call the old type of PC firmware an 'IBM-compatible BIOS' and the new type of firmware a  'UEFI BIOS' because UEFI firmware is still a type of 'Basic Input/Output System'.

On this site however, I try to avoid using the term 'UEFI BIOS', as some people think that the two abbreviations are mutually exclusive.

Note that most UEFI firmware implementations also include the old IBM-compatible BIOS type of firmware - this extra 'bolt-on' code is called the Compatibility Support Module or CSM. In CSM-mode, the UEFI firmware will behave just like a real-mode IBM PC-compatible BIOS and boot from normal MBR partitions to run real mode code contained in the first sector of the boot disk using software interrupts (e.g. Int 13h). The CSM code is, in essence, a virtually complete IBM PC-compatible BIOS! 

In UEFI-mode, the CPU will run in 'long mode' and try to boot from a FAT partition containing an .efi boot file containing code written to run in 'long mode'.

• 32-bit UEFI-mode runs the CPU in 32-bit long mode and so can only execute boot code that is written to work in this mode. Software interrupts (e.g. Int 13h) cannot be used - 64-bit long mode code cannot be used.
• 64-bit UEFI-mode runs the CPU in 64-bit long mode and so can only execute boot code that is written to work in this mode. Software interrupts (e.g. Int 13h) cannot be used - 32-bit long mode code cannot be used.
• MBR BIOSes or UEFI systems in CSM-mode run in real mode on both 32-bit and 64-bit CPUs and can only execute real mode code. In this mode, CPU software Interrupts can be used (e.g. Int 13h is used to read or write sectors to a disk)

E2B does not add UEFI-boot files, the MakePartImage utility only uses the UEFI boot files that are already present in the payload itself.

So, you can only UEFI-boot a payload if the payload itself contains UEFI boot files. You cannot (easily) 'convert' a BIOS-bootable payload to a UEFI-bootable payload; older OS's like DOS and XP can never boot via UEFI because they rely on BIOS calls even when fully loaded and running. Some linux OS's and Windows OS's can boot both via BIOS and UEFI, but these OS's have been specifically written to include two different boot methods and once the kernel is loaded, the OS uses it's own drivers to access the disks, etc.

If the payload source does not already contain a \EFI\boot\bootx64.efi or bootia32.efi file, then it will not support Intel x86 UEFI-booting (however, it might be possible to load a UEFI boot loader such as grub2 and then load the OS - see the E2B grub2 menu system for more details).

With the old type of BIOS, operating systems such as DOS, Windows 95/98/XP/2003, etc. would load the operating system using BIOS calls. For instance, these OS's can read sectors from a boot disk into memory using BIOS Int 13h calls. The CPU is in 'Real Mode' and not in Protected Mode when booting via the BIOS. Using BIOS calls, the OS boot code can load the 'kernel' and drivers into memory and then, once the kernel code is running, the drive sectors can be accessed using the OS disk drivers rather than using BIOS calls.

So the boot code (and in many cases the OS 'kernel' code), actually depends on BIOS calls.

With a system that boots via UEFI, there are no BIOS calls available at all! Further still, the CPU is not even in Real Mode (UEFI uses Long Mode), so that the boot code must be written to use UEFI API calls to access the boot disk sectors (and files) and the code must be written to run in Long Mode. A further complication is that there are two sorts of UEFI Long Mode used, 32-bit or 64-bit - so 64-bit Windows 8 (for instance) cannot be booted from a 32-bit UEFI system and vice versa.

In the case of older payloads such as Hirens, it typically contains Windows XP, DOS and older linux payloads. DOS and Windows XP use BIOS calls, therefore there is no way that you can boot and run DOS or Windows XP from a UEFI system (unless you boot it in CSM\MBR\BIOS mode). To boot linux payloads, the linux boot loader must be written to support UEFI (i.e. not use BIOS calls) or switch the CPU into a different mode. Most (all?) Hirens versions do not contain linux distros that support UEFI booting.

The UEFI specification is not very explicit about how the firmware Setup interface should behave.

In order to boot via UEFI from a USB drive, the system needs to either be configured to boot from the USB device as the first boot device (not recommended) or you must press a special key (e.g. F8) at an early stage to get a pop-up boot selection menu (aka BIOS Boot Selection menu or BBS menu).

This menu will list the bootable devices available to the system.

Many UEFI systems have their own 'rules' for listing UEFI devices in the BBS menu for normally partitioned MBR disks:

1. May display one UEFI entry for each MBR partition (even if the partition is NTFS and does not contain a valid \EFI\Boot\bootxxxx.efi file) - e.g. Asus Z87
2. The BBS pop-up list does not display the disk+partition number, so you don't know which entry boots to which partition!
3. If any of the MBR partition table start values are out-of-order then you may not get any UEFI boot options listed for that drive (see Examples 1 and 2) - e.g. Asus Z87, Dell Venue 11, HP PC (Asus T100 will boot from any partition if it contains EFI boot files!)

If you are using .imgPTN files, and you are not seeing any UEFI boot option(s) for the E2B USB drive, check that the partitions are not out of order.

You can use the MOVE_IMGPTN cmd script to check and re-order them. SWITCH_E2B.exe will also attempt to re-order the partitions.

EFI boot files can prevent MBR-booting!

Yes!

You can add a grub2 menu to Easy2Boot. I have prepared over 60 menu entries for specific payload files (mostly linux ISO files) which can be booted using a grub2 menu on a second partition on your Easy2Boot USB drive. Grub2 menus must specify the exact filename of the ISO and also must use linux 'cheat codes' which vary from distribution to distribution.

The grub2 menu system can UEFI-boot some linux payloads that do not contain UEFI boot files and so cannot normally UEFI-boot (e.g. we can boot in all these additional modes: deftz EFI32, kali EFI64, kali light 32 EFI64&EFI32, nst EFI64&EFI32, ophcrack EFI64&EFI32, weakerthan EFI64&EFI32, debian EFI64, fedora EFI64, knoppix EFI64, systemrescuecd EFI32, zorin32 EFI32, avira EFI32, bitdefender EFI32, pwh32 EFI32, drweb EFI64&EFI32). Some other linux distros may just crash if you try them though!

The grub2 menu system can be easily expanded by adding your own .grub2 menu files. The grub2 menu system will dynamically collect and add all .grub2 menu files into the grub2 menu each time you boot.

When booting to grub2, a FAT32 boot partition is used so you can UEFI- or MBR-boot. The second partition on the E2B USB drive (which can be FAT32 or NTFS) will contain the ISOs. Using the grub2 menu, you can select and UEFI-boot from any of the ISO files in the menu.

Read more and view the full Excel spreadsheet of all supported ISOs at https://easy2boot.com/uefi-grub2-ptn2/

Note: OS's based on DOS or XP (e.g. Hirens boot CD) cannot boot via UEFI.

Newer computers, made since around 2008 include UEFI BIOS (Unified Extensible Firmware Interface). One of the new features of UEFI is ‘Secure Boot’ which does not allow loading of drivers, boot files or operating systems that do not have a valid digital signature. This stops malicious software and unauthorized operating systems from being loaded. All Windows 8/10 'logo certified' OEM computers are required to ship with Microsoft Secure Boot enabled, but most computer manufacturers allow secure boot to be disabled by allowing the user to change the BIOS settings.

Some modern 64-bit versions of Ubuntu, Fedora, CloneZilla (Ubuntu AMD 64-bit version only) and MemTest86 support Secure Boot.

Typically, most linux Secure Boot distros only support 64-bit UEFI Secure boot (not 32-bit UEFI Secure Boot).

Modern Windows OS's support both 32-bit and/or 64-bit Secure Boot and they contain signed boot files (\EFI\BOOT\*.EFI).

You can only boot using Secure Boot if the EFI boot files and drivers have been correctly signed or if you can 'validate' the boot file manually (e.g. by booting to a Shim and using a MOK Manager to register the EFI boot file on the particular UEFI-system that you are booting from).

To get EFI boot files signed by a trusted authority for Secure Booting costs quite a few $1000, so only large organisations tend to have OS's which support Secure Boot.

For a guide on how Secure Booting works, see here.

Add a payload to E2B

If the OS has these signed EFI boot files(s), you can usually Secure Boot from them by converting them to .imgPTN files (FAT32 format) and adding the .imgPTN file to your E2B USB drive. Then MBR\CSM boot and switch to the .imgPTN file or use SWITCH_E2B.exe to switch to the .imgPTN file. Then you can Secure Boot boot from the E2B USB drive on a UEFI system.

The grub2 menu system

E2B also allows you to use a grub2 menu system which is capable of MBR\UEFI32\UEFI64 and UEFI64Secure booting (but not on all systems).

For linux payloads, the E2B grub2 menu system will allow you to UEFI (and in many cases Secure UEFI) boot to over 60 different payloads all from the same menu. Note that UEFI booting to Windows Install ISOs is not included (but could be added manually).

The BIOS\Firmware 'Fast Boot' option, if enabled, prevents the BIOS from testing or checking for certain devices such as USB storage devices on switch-on or on a reset.

Some BIOSes all you to enable 'General', 'USB' and 'Video' fast boot optimisations separately.

The exact function depends upon how the BIOS developers have written the code, but usually you must not enable Fast Boot for USB, because then the BIOS will not check for the presence of any bootable USB devices that may be connected.

Fast Boot = Disabled   (for detection of USB boot devices)

Fast Boot is not only connected with the BIOS UEFI boot options, it applies to both CSM\BIOS\Legacy mode and UEFI-mode.

The answer is simple - the E2B menu system does not support UEFI booting.

E2B only supports UEFI payloads by 'switching-in' a .imgPTN partition image file so that you have a new FAT32 partition on your E2B drive.

You can however add a 2nd FAT32 partition to the E2B drive which contains WinPE boot files and this will allow you to UEFI-boot on any system and select any .imgPTN file - see here for more details.

The 'No MBR boot option' BIOS bug

The reason that E2B does not have a UEFI boot menu is that some system BIOSes have a very annoying bug - if a UEFI boot file is present on the USB drive, then that BIOS will not allow you to MBR\Legacy boot from the drive!

This means that if you wanted to boot to the E2B menu in Legacy\MBR\CSM mode and run any of the 100's of ISOs on it - you can't! The BIOS will only let you UEFI-boot. This is the reason that E2B does not contain UEFI boot files (and does not need to use FAT32).

If you want a multi-choice UEFI menu for mainly linux ISOs, you can configure the E2B drive for the grub2 menu system - however it is more complex and best suited for use with USB HDD drives. It also suffers from the 'No MBR boot option' BIOS bug.

As well as the E2B+2nd FAT32 partition scheme, some other multiboot solutions use a FAT32 partition (UEFI boots from FAT partitions) and contain MBR and UEFI boot files and so these solutions will also hit this BIOS bug issue with certain systems:

• SARDU
• WinSetupFromUSB
• Yumi U EFI (Beta)

Some 2018 or later BIOSes are 'UEFI-only'.

There may be an option to enable CSM in the BIOS settings, however this only allows you to MBR-boot from external devices.

The UEFI BIOS will not allow you to boot in Legacy mode from an internal drive.

This means you may not be able to 'see' any internal drives if you MBR-boot and try to install an OS to the internal drive, OR it may allow you to install an OS to the internal drive, but when you try to MBR-boot from the internal drive it will fail to find any drive! 

You must perform install an OS that will UEFI-boot. To do this, either UEFI-boot from the E2B USB drive (using a .imgPTN file) or MBR-boot and run WinNTSetup and ensure you install Windows to a GPT disk and enable UEFI-booting so that it will UEFI-boot to Windows from the internal hard disk.

Tip: Some modern BIOSes also require you to select ACHI mode rather than RAID 0 mode before you can access the internal SATA drives.