Here are some essential facts about USB drives, booting and other stuff which relates to BIOS and UEFI-booting.
Please ask if you would like something added to this section.
Useful things to know
MBR and PBR
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 <137GB)
Partition Start (LBA) - the disk sector where the partition starts and the PBR can be found (<2TB)
Partition Size - number of sectors in the partition (<2TB)
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.
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.).
However, most UEFI systems 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 and completely different from UEFI-mode.
New Windows 8 systems shipped by an OEM manufacturer will all be UEFI systems and they will boot in UEFI-mode. To boot from a disk in MBR\CSM mode you will need to disabled Secure Boot and enable CSM-mode (which may be called 'Legacy' mode in some Setup menus).
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.
How does BIOS\MBR booting work?
Hers is a typical boot sequence for a BIOS-based MBR\CSM system:
Switch on system
Firmware (BIOS) code inside the system executes
First sector (MBR) of each disk is read (order depends on how user has configured BIOS)
If the sector is a valid bootable sector, the sector is read into memory and executed by the CPU
Note: Some (bad) BIOSes will not run step 4 unless one of the partitions in the MBR is marked as Active.
From this point onwards, the BIOS has no control of booting. Normally the code in the MBR will do this...
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
Thus the code in a 'standard' MBR looks for a partition entry in the MBR which is marked as 'Active/bootable' and then loads the code from the first sector of that partition (the PBR).
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
The code in the PBR is usually responsible for booting from a file within the partition (e.g. ntldr or bootmgr). This code typically finds and loads more code, which is then able to understand the filesystem used in the paritition and thus access any of the files on the disk.
Note: Some 'bad' BIOSes use a different sequence (which is often incompatible and can cause boot issues!)
Switch on system
Firmware code inside the system executes
First sector of each disk is read (order depends on how user has configured BIOS)
If the sector is a valid bootable sector and contains a partition marked as Active, read the first sector of the Active partition (PBR) into memory and execute the code. Note that the code in the MBR is skipped completely!
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 of 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.
How does UEFI booting work?
UEFI systems boot in this sequence (if in UEFI boot mode):
Switch on system
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
Check for a valid filesystem in first partition (FAT12/FAT16/FAT32 or GPT EFI)
Look for the designated boot file (default = \EFI\boot\bootxxxxx.efi where xxxxx depends on the CPU architecture - see below)
Load the boot file into memory and execute the code
For a 64-bit x86 UEFI system, the default EFI boot file is \EFI\boot\bootx64.efi
For a 32-bit x86 UEFI system, the default EFI boot file is \EFI\boot\bootia32.efi
A UEFI system either has 32-bit UEFI firmware or 64-bit UEFI firmware - it cannot have both.
A few systems may have UEFI firmware which can access NTFS partitions, however this is not required by the UEFI standard specification and is rare.
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 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).
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.
How to boot E2B from a UEFI-only system (e.g. Surface Pro 3, Asus T100, T200)
Some systems do not have a Legacy\MBR\CSM option in their firmware (no '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!
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).
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).
Restoring the E2B drive
Once you have finished, connect the 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.
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!
What is CSM?
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.
About 32-bit and 64-bit UEFI and CSM\MBR booting
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) - so just because the CPU is 64-bit capable, it does not necessarily mean that the UEFI firmware is 64-bit.
Although a 64-bit system could (in theory) support both 32-bit and 64-bit UEFI-booting, it would need to contain almost twice as much firmware code. Because each mode would require separate UEFI modules', this would double the manufacturer's firmware development and testing process and double the expense. So, in practice, UEFI-enabled systems containing a 64-bit x86 CPU, usually boot 64-bit UEFI OS's via a bootx64.efi file - if however the UEFI firmware is a 32-bit version, it will only boot from a \EFI\boot\bootia32.efi boot file by default and run in 32-bit Long Mode.
UEFI systems may or may not contain support for CSM booting. This is the old 'legacy' mode which is compatible with (most) older versions of linux and Windows (e.g. Windows XP). As CSM mode is not mandatory, not all UEFI systems support CSM booting.
The UEFI specification states that it must be capable of loading an .EFI boot file from a FAT\FAT16\FAT32 volume. A few PCs are also capable of UEFI-booting from NTFS partitions, but this is an 'enhancement' and not typical.
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 GPT 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!
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 using software interrupts (e.g. Int 13h) contained in the first sector of the boot disk. 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)
It is not normally possible for UEFI-mode to run MBR\CSM boot code and vice-versa (unless a completely new 'BIOS' is loaded - e.g. you can MBR-boot and load Clover which is in effect a whole new UEFI 'firmware' that can then boot to and run the long mode type of code in .efi boot files).
Once a kernel is loaded, it is theoretically possible to put the CPU into a different mode, but this would require a new set of hardware drivers to be loaded first, and so this is rarely seen in UEFI OS's.
Why doesn't my Hirens payload boot on my UEFI system even though I converted it to a .imgPTN file?
E2B does not add UEFI-boot files, it can only use the UEFI boot files that are already present in the payload itself.
So, you can only UEFI-boot a payload if the payload itself supports UEFI-booting. 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). Most (all?) Hirens versions do not contain linux distros that support UEFI booting.
MBR partitions and UEFI boot behaviour
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:
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
The BBS pop-up list does not display the disk+partition number, so you don't know which entry boots to which partition!
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!)
Example 1: No UEFI boot option is displayed (ptns out of order)
TABLE SLOT 1: NTFS Start=8,194,236
TABLE SLOT 2: FAT32 Start=2048
TABLE SLOT 3: empty
TABLE SLOT 4: empty
Example 2: No UEFI boot option is displayed (2nd and 3rd ptns not in order)
TABLE SLOT 1: FAT32 Start=2048
TABLE SLOT 2: NTFS Start=8,194,236
TABLE SLOT 3: NTFS Start=4,098,048
TABLE SLOT 4: empty
Example 3: Three UEFI boot options displayed (even if partitions have no files)
TABLE SLOT 1: FAT32 Start=2048
TABLE SLOT 2: NTFS Start=4,098,048
TABLE SLOT 3: NTFS Start=8,194,236
TABLE SLOT 4: empty
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!
Some UEFI systems will not offer an MBR boot option to the user if there is an EFI boot file on a FAT32 partition. These systems only offer a UEFI boot option to the user.
This means that if you have a FAT32 E2B USB drive containg EFI boot files on these systems, you won't be able to MBR-boot.
This is the main reason why E2B does not contain any EFI boot files. This behaviour means that these system will not be able to MBR\CSM-boot from a FAT32 .imgPTN file to the CSM menu, if it contains an EFI boot file.
As I don't have one of these systems, I cannot fully investigate the exact 'properties' of this behaviour.
Can I boot some linux ISOs that do not officially support UEFI-booting?
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.