How E2B Works

Many multiboot solutions such as YUMI, Multisystem, XBOOT, etc. work by recognising what the payload/ISO file is (or you need to tell it what type it is) and then it will create it's own special menu which is specific to that version of linux ISO. They typically use special 'cheat codes' to boot directly from an ISO, or need to extract files from the ISO or re-make the ISO and patch the files. This means that these types of utilities need to be constantly updated by their authors, because linux distro versions continuously change. This also makes changing and deleting payloads from the menus difficult. E2B avoids this because, for linux ISOs, it uses a special grub4dos feature to map the ISO file as a special partition on the USB drive which linux can access as a 'CD filesystem'. You also get the full original linux boot menu - see below for more details and also 'How E2B was born'.

E2B is based on grub4dos batch files (.g4b files). Grub4dos can only be booted in MBR\CSM mode - E2B cannot be booted using GPT partitions or UEFI firmware (but E2B does support UEFI-booting by using partition images - see the end of this page for details). Grub4dos boot code can be installed to the first sectors of the USB drive (formatted with a MBR partition) or to the partition boot sectors or both. The boot code then loads the \grldr file which contains grub4dos. When grub4dos runs, it loads the \menu.lst file which then loads the \_ISO\e2b\grub\menu.lst file.

Easy2Boot then starts from \_ISO\e2b\grub\menu.lst. The number of ISO and .imgPTN files in the \_ISO\Windows folders are counted - if no files are found, then the 'Install Windows Menu' entry will not be displayed in the Main menu.
All files (except .cmd, .txt and . files) in the \_ISO\MAINMENU folder are then enumerated in alphabetical order and added to the E2B menu which is held in memory at memory 'sector' (md)0xa000 (all sub-folders under \_ISO\MAINMENU are also searched for all .mnu files and these are also added to the E2B menu)
As each file is added to the E2B menu file held in memory, any special 'Keywords' like $HOME$ and $$STRxxxx are translated\expanded ($$STRxxxx keyword text is obtained from a STRINGS.txt file - there is a different one for each language)
Sub-Menu folders are detected by the \_ISO\MAINMENU\ZZSubMenuAll.mnu file (the actual filename of .mnu files is not important)
If there is one or more .ISO or .imgPTN files in each of the \_ISO\WINDOWS\xxxx folders, the Windows Install menu entry is added to the Main menu.
If any of the sub-menu folders are completely empty of all files and folders, there will be no menu entry for that sub-menu in the Main menu.

To learn more about grub4dos and the wonderful things you can do with it, see the Tutorial here.

Techy Note: The Main Menu is stored in memory at (md)0xa000+0xA0 so that it can be quickly re-loaded whenever a sub-menu returns to the Main Menu. All Menus also use the same temporary memory area of (md)0x3000+0xA0.

Partitions

The Master Boot Record (MBR) is in the first sector on the USB disk. It contains a Partition Table which can hold a maximum of four Partition entries. It can therefore hold up to 4 Primary Partition entries or 3 Primary Partition entries and 1 Extended Partition entry (which is a special type of Primary partition). An Extended Partition can 'point' to many more Logical Partition tables which are elsewhere on the same disk.

Tip: Use RMPrepUSB - Drive Info - 0 to view the MBR on any disk.

E2B often uses the 4th MBR partition table entry to help when booting (linux) ISOs. Therefore the 4th partition table entry must be kept free (unused) so that E2B can write a partition table entry into it which points to the start of the ISO file that you want to boot from. E2B will warn you if the 4th partition is not empty and will not allow you to proceed until it is deleted. For this reason, only use E2B on USB drives and not internal hard disks!

For some functions, e.g. booting linux ISOs with Persistence using a special .mnu file, E2B also requires the MBR 3rd partition table entry to be free. If the 3rd partition table entry is not empty, then you will be unable to use these special .mnu files and E2B will warn you that the partition table is already in use if you try to run such a menu entry.

For these reasons, an E2B USB drive usually is comprised of one of these two partition arrangements (partition entries 3 and 4 should be unused):

1. Partition 1 = E2B files

Partition 2 = empty (or a 2nd Primary Partition)

OR (not recommended for Removable USB flash drives)

2. Partition 1 = E2B files

Partition 2 = Extended partition (which can point to any number of Logical partitions)

Since E2B uses grub4dos, the boot code in the Master Boot Record (and the Partition Boot Record) should contain the grub4dos boot code.

ptn1 = E2B files (recommended max. size 128GB)
ptn 2 = empty, or a Primary ptn, or an Extended ptn entry which points to one or more Logical partitions
ptn 3 = empty - used by some E2B .mnu files for persistence
ptn 4 = empty - E2B writes the ISO file start position here if booting from an ISO

About ptn 2

A typical E2B USB drive prepared using RMPrepUSB\RMPartUSB (or the Make_E2B_USB_Drive.cmd script) usually has a small ptn 2 (type 21h). This is not used by E2B at all - it is just there because some BIOSes will treat a USB drive as a floppy disk if only one partition entry is present and thus fail to boot to grub4dos (flashing cursor - black screen). For E2B to boot successfully on systems with buggy BIOSes, the BIOS must access the USB drive as a hard disk (hd0) and so a second small Primary partition is added when the E2B drive is made.

If you want to have two large partitions on the E2B USB drive, you can delete this small 2nd hidden partition and add your own larger partition.

Tip: Use RMPrepUSB - Drive Info - P1 to view the first partition sector (PBR).

If you are using a Removable USB Flash drive with two large partitions, it is best to use two Primary partitions (because using Primary plus Logical partitions can cause problems when trying to view and access the Logical partition(s) under Windows).

.MNU Files

.mnu files simply contain normal grub4dos menu entries which are collated and copied by Easy2Boot into it's temporary grub4dos menu which is held in memory. Note that folder paths must use the forward-slash symbol / (like linux) when using paths inside grub4dos .mnu files - grub4dos does not understand \ (backslash) as a path delimiter.

However, spaces in file paths/names should be preceded by a backslash \ symbol (e.g. /folder/a\ space.iso).

The following special 'words' are recognised by E2B and can be used inside .mnu files:

The %MFOLDER% variable will hold the current menu folder path (e.g. /_ISO/MAINMENU or /_ISO/BACKUP, etc.) so that a .mnu file which uses %MFOLDER% can be moved to any folder location and it will still work.

The $HOME$ keyword can be used in a .mnu file to represent the complete path of the folder that contains the .mnu file. It is preferable to place the .mnu file and payload file in the same folder (e.g. \_ISO\LINUX\MNU) and use $HOME$/ in your .mnu files, rather than, for example, use %MFOLDER%/MNU/.

$NAME$ is the filename of the .mnu file (without the file extension).

$$STRxxxx keywords are looked up by E2B in a STRINGS.txt language file and are subsitituted with the corresponding text from within the STRINGS.txt file. If a $$STRxxxx keyword is not found in the specified language file (which is set in the \_ISO\MyE2B.cfg file), then the keyword string will be searched for inside the English .\ENG\STRINGS.txt file.

The file name of your .mnu file does not matter and it can be changed to whatever you like - but all .mnu files are collected by E2B in alphabetical order, and all folders below the specified Menu folder ('MFOLDER') are searched.

MNU sub-folder and .mnu files

The folder names under the menu folders on the E2B USB drive (e.g. \_ISO\MAINMENU\MNU) have no particular significance - any folder name can be used - but most .mnu files are usually designed so that the payload file should be in the same folder as the .mnu file. Look at the .mnu files in the docs folder to see how they work. Also, in the \_ISO\docs\E2B Utilities folder there is a drag-and-drop cmd file tool to help you create .mnu files and .txt files.

Tip: It is best to use the 'iftitle' command inside .mnu files so that the user can delete the 'payload' file and just leave the .mnu file on the USB drive. Then at a later date, the payload file can be restored and the .mnu file will still be present.

GFXBoot menus do not support grub4dos hotkeys, so often you will see two 'iftitle' type menu entries for the same function in an E2B .mnu file, one menu entry will test for if GFX="" (normal grub4dos menu) and will define a hotkey, and the other menu will contain a test for if not GFX="" (in case the user has specified a GFXBoot menu using the GFX variable in the MyE2B.cfg file).

Windows Install ISOs

These should be placed under the \_ISO\WINDOWS\ folder in the correct sub-folder.

For example, Windows 8 install ISOs should go in the \_ISO\WINDOWS\WIN8 folder.

Windows Install ISOs do not need to be fully contiguous.

Do not confuse the \_ISO\WINDOWS folder with the \_ISO\WIN and \_ISO\WINPE folders which should not be used for Windows Install ISOs (though some may work in these or other menu folders, others may not!).

Unless E2B uses 'WIMBOOT', Vista and later OS Install ISOs also require an AutoUnattend.xml file to be on a removable drive (i.e. a USB Flash Drive which shows as the Removable type in RMPrepUSB). WinPE v2/3/4 (which is booted to from Windows Setup) picks up the AutoUnattend.xml file automatically - it searches all removable drives for that filename as soon as it has booted and the wpeinit.exe command is run. If your USB drive is not of the Removable type, you will need to convert the ISO to a .imgPTN file or add a WinHelper Removable flash drive.

Sequence for VISTA/Win7/8/10, etc. using a Removable E2B USB drive

1. Easy2Boot overwrites \AutoUnattend.xml with correct contents (and changes the Product Key if required). If a 'WinHelper' drive is present, the xml files on there are also updated.

2. E2B boots to Windows Setup (WinPE)

3. WinPE (windows Setup) usually automatically runs wpeinit.exe which initialises the network and looks for an \AutoUnattend.xml file on any REMOVABLE DRIVE (e.g. 'Removable' USB Flash drive or CD/DVD) - see here for details. If the WIMBOOT method is used, the \AutoUnattend.xml file on the E2B drive will be used, even if the E2B drive is a Fixed Disk type (E2B v1.A8+).

4. The WindowsPE - 'RunSynchronous' command inside the \Autounattend.xml file is found and executed (if not using WIMBOOT).

5. The file \_ISO\E2B\FiraDisk\LoadIso.cmd on the E2B USB drive is executed

6. Windows ISO is loaded as a new virtual DVD (e.g. U: ) by the code in Loadiso.cmd (using ImDisk)

7. The user is asked if they want to Repair Windows (answer N for Windows Install or just press ENTER key) - N just exits Loadiso.cmd and allows Setup to continue.
Note: You may be offered to run Startup Recovery (StartRec.exe), OS Repair (RecEnv.exe) or MSDart32 if they are present in the ISO.

8. Setup.exe continues to run

9. Setup can now find the \Sources\Install.wim file on the new virtual DVD drive and will list all OS versions inside the Install.wim (if not a 'Windows CD/DVD drive driver required...' message is displayed!)

10. Note that after a reboot and in the final 'Completing installation' phase - Setup will look for a \Unattend.xml in the root of all removable media. For this reason, the \Unattend.xml is filled with a blank but valid .xml entry. If an invalid or empty Unattend.xml is seen, Setup will complain about an invalid Unattend.xml file! Windows log files can be inspected - see here for details.

See Tutorial 43 for more details of Vista and later OS installs.

Windows XP 32-bit Install using DPMS

If you have the E2B+DPMS version, it works like this:

1. A grub4dos utility is run to obtain the PCI ID of the mass storage controller (e.g. AHCI or SCSI or RAID, etc.)

2. The XP 32-bit mass storage DriverPack.ini file is searched for a match to the PCI ID

3. Two floppy RAMDisk drives are created and the firadisk, WinVBlock and correct Mass storage drivers are copied to each one

4. The default driver in RAMDisk virtual floppy 0 is set to FiraDisk (or WinVBlock) and the other floppy drive 1 default driver is set to the mass storage driver

5. The XP ISO is then loaded into memory and run

6. XP Setup sees the two virtual OEM driver floppy disks and loads the default driver from each txtsetup.oem file in each floppy disk.

7. XP Setup switches to protected mode

8. The RAM driver (e.g. Firadisk) loads and detects the ISO already loaded by grub4dos into memory and hooks it as a virtual drive so it is accessible in protected mode.

9. The mass storage driver is loaded

10. XP Setup now has access to the ISO files in protected mode and can access the AHCI/SATA/RAID disks via the correct mass storage driver

11. The Firadisk INF file also contains registry entries which will cause XP to load the ISO file as a virtual drive after XP reboots (the ISO can be loaded to memory first in Step 2 by grub4dos and FiraDisk will find it in memory and create a virtual drive letter for it)

Windows XP Installs using the 2-Step + F6 method (non-DPMS)

Note: Your Windows XP Install ISO file must be in the \_ISO\WINDOWS\XP folder. If it is 64-bit Windows XP, ensure that the numbers '64' are used in it's name (e.g. XPProSP364.iso) - this will suppress the DPMS2 feature (DPMS2 only works for 32-bit XP/2k/2k3). If installing 2k or 2k3, ensure '2k' or '2k3' is used in the ISO filename.

When using the 2-Step XP install option (see here for more details).

The following instructions only apply if DPMS2 has not been added or you are using a 64-bit XP Install ISO (with '64' in the ISO name).
If you are using DPMS2 then please follow the instructions above instead of the ones below.

1. Boot from your E2B drive, press I for the Windows menu and then Alt+1 for Step 1

2. Choose from the list of XP ISOs

3. You will see some instructions about pressing F6 - on some systems pressing F6 during Windows XP Setup is not necessary. So try not pressing F6 first.

If you get a BSOD in Step 1 or XP cannot detect your internal hard drive, then reboot and press F6 and select FiraDisk32+WinVBlock32 (if installing XP 64-bit use the 64-bit drivers).
If you have a system which uses a SATA AHCI HDD controller, also add that driver too.

See Tutorial 30 for how XP ISO installs work using FiraDisk/ImDisk.
See here for a list of AHCI drivers included with the F6 XP install process used in E2B.

You can identify your AHCI controller using the List Disk Controller PCI IDs [L] menu.

For 64-bit XP, your system will need to contain an IDE\Legacy Hard Disk controller.

4. Continue with the text mode setup and allow the system to reboot after the copy-files stage has completed

5. Reboot back to the E2B USB drive (do NOT allow the computer to boot from the internal HDD). Select I and Alt+2 for Step 2.

6. The system should now boot from the internal HDD and continue the GUI Setup phase of the XP install. It may be necessary to confirm the loading of some drivers during this phase.

7. Once XP has been fully installed, you can delete the storage drivers which show up as errors in Device Manager and then install all drivers for your hardware in the usual way.

Windows XP ISO install using a Vista/7/8/10 WinPE 'Helper' ISO on an Removable USB drive

XP can be installed by booting to a Windows 7/8/10 ISO.

These XP installs work in a similar way to Vista/7/8/10 installs, but only ImDisk is used:

1. Easy2Boot overwrites \AutoUnattend.xml and \Unattend.xml with \_ISO\E2B\FiraDisk\auwinnt.xml

2. Windows Setup or WinPE boots

3. WinPE Setup looks for \AutoUnattend.xml file on any REMOVABLE DRIVE (e.g. USB Flash drive or CD/DVD) - WinPE looks for \Unattend.xml when wpeinit runs.

4. PE runs the WindowsPE RunSynchronous command from the .xml file which then looks for and runs LoadIsoW.cmd

5. \_ISO\E2B\FiraDisk\LoadIsoW.cmd loads the XP ISO as a virtual drive and then runs \_ISO\E2B\FiraDisk\RUNWINNT.cmd

6. RUNWINNT.cmd prompts the user and then formats, or wipes and partitions the target drive and runs winnt32.exe with the correct command line parameters.

For Vista/Win7 boot ISOs, use a USB 2.0 USB port for the E2B USB drive as modern chipset drivers are not included in Win7.

Tip: If you only have a USB 3 drive and USB 3 ports, using a USB 2 extension cable sometimes works.

Payload files (.ISO/.IMA/etc.) and booting using QRUN.g4b

Payload files (e.g. .ISO. .IMA, etc) which are placed in the \_ISO\MAINMENU folder (not sub-folders under \_ISO\MAINMENU) and in other \_ISO\XXXX folders (not sub-folders) are automatically listed in a dynamic menu which is made in memory. However, .txt, .cmd and . (no extension) files are not listed in the menu. If a .txt file exists that exactly matches the payload filename, the first line from inside the .txt file is used as the menu entry title instead of just the payload filename (so the text in the .txt file should always start with the word 'title' or 'iftitle' followed by the grub4dos menu text that you want displayed).

The grub4dos batch file \_ISO\E2B\grub\QRUN.g4b (.g4b = grub4dos batch file) is run when a payload file is selected by the user from the menu. The QRUN.g4b batch file looks at the file extension of the payload file and performs a set of grub4dos commands depending on the file extension. If the file extension is not recognised by the QRUN.g4b batch file, no action is taken (as the label will be missing from inside the batch file - see below).

There are code sections in QRUN.g4b which are run depending on the file extension. The most common action occurs when an ISO file is selected and the code section for .iso is shown below...
(a very simplified example):

:.iso

:.isoxx

partnew (hd0,3) 0x0 %1

map %1 (0xff)

map --hook

root (0xff) || rootnoverify (0xff)

chainloader (0xff)

exit

Line 1 - The batch file label - a colon followed by the file extension. You can have more than one label so that the same commands will be run if (in this example) the extension is .isoxx or .iso.

Line 2 - The 2nd batch file label

Line 3 - This is the main reason why lots of linux ISO files can be booted. The partnew command creates a new partition entry on the boot drive (in the last table position of the 4 available on the Master Boot Record). The start sector of the partition points to the start of the ISO file (which must be contiguous). When linux boots, it searches for filesystems to mount. Linux sees the 4th partition as a CDFS filesystem and so mounts the 'ISO' as a CD/DVD. Now when linux goes on to look for more files (e.g. squashfs, etc.) it will find the files it needs on the mounted CDFS filesystem and proceed just as if it had booted from a CD/DVD. The partnew command actually writes to the MBR sector and so physically alters the MBR sector. The 4th partition table entry is checked by the main Easy2Boot menu to ensure it is empty first - if it was not empty then the 4th partition would be destroyed by this command and all data in it lost! As physical drive writes need to work, some emulators or VMs may not boot linux ISOs successfully using this technique. Type 0x0 partitions are visible to most linux OS's, but are 'invisible' to grub4dos, DOS or Windows OS's.

Line 4 - This maps the ISO to BIOS device 255 which is a CD-type device.

Line 5 - The BIOS interrupt is hooked so that the mapping takes effect

Line 6 - The (0xff) CD device is set as the root device. This has the effect of setting some CPU registers which some ISOs may require. If the root command fails, the rootnoverify is used instead.

Line 7 - This loads the ISO bootcode at the start of the 'CD' into memory ready to boot

Line 8 - This returns back to the grub4dos menu that originally called the QRUN.g4b batch file - the next line in the Easy2Boot menu will be 'boot' in order to boot from the ISO.

If you wish, you can invent new file extensions (e.g. .iso_dave ) and add a new entry for it into QRUN.g4b! Do not change any existing code as this will affect all files that have the same file extension, so copy new code below your :.iso_dave label and ensure it ends with 'exit'.

This partnew method for booting linux ISOs was originally mentioned by 'cdob' on reboot.pro, tested by me and closely followed by a loud cry of 'Eureka' and other (unprintable) expletives of joy, as I realised this was an almost unversal way of booting linux ISOs from writable media!

If the ISO file is not contiguous, then it cannot be used with the partnew command. So, if a contiguous \_ISO\CONTIG.ISO file exists and it is larger than the ISO file, E2B will use the dd command to copy the non-contiguous ISO file contents to the CONTIG.ISO file and then use the CONTIG.ISO file instead of the original ISO.

Some types of files, e.g. Hackintosh .DMG or .HFSPTN files or linux .HAIKU files, will add a new 4th partition table entry (i.e. one that is not Type 0) - this will cause E2B to 'complain' when it is next rebooted because the 4th entry is not free. You can suppress the warning by using a \_ISO\MyE2B.cfg file which contains a partnew command to always delete ptn 4 on every boot.

ISOBOOT

E2B usually needs the payload (ISO) file to be contiguous. If it is not contiguous, then it will try to copy the whole ISO file to \_ISO\CONTIG.ISO which is an empty file that should be contiguous. However, if the CONTIG.ISO file is not present, not big enough or not contiguous, then if the file is an .ISO file, E2B will run it using the isoboot.g4b batch file. The code in isoboot.g4b will look at the file name of the ISO file and attempt to boot it by loading the file into memory and using special 'cheat code' parameters to tell the linux ISO where to find the ISO file.

Isoboot is a 'last ditch' attempt to boot from a non-contiguous linux ISO - it may not work very well and may only work on a small variety of common linux ISOs.

On E2B v1.62+ versions, you can test the isoboot function on any linux ISO by holding down the SHIFT key after selecting a linux ISO from the menu, and then pressing the ENTER key to run it - i.e. select the ISO from the menu, hold down the SHIFT key - press ENTER - keep SHIFT key held down until you see the isoboot messages.

Booting linux ISOs with persistence

I also discovered that you can map an ext2 file to a partition using partnew, so that linux will find and mount the ext2 file and use it for persistence (e.g. casper-rw) without needing to use special cheat codes. Some .mnu files use this trick and so the 3rd primary partition (hd0,2) is used for the ext2 file.

So, for this trick, Easy2Boot USB drives require both the 3rd and 4th partitition table entries to be unused. This also allows us to have multiple linux ISOs all using casper-rw as a persistent filesystem but actually using different files for each different persistent file.

For instance, we can use partnew (hd0,2) 0x0 /fileext2a for one ISO and partnew (hd0,2) 0x0 /fileext2b for a different linux ISO (or even use the same ISO but with a different persistence file!). As long as the ext2 files were created with the volume label of casper-rw (or whatever the linux version is looking for) then the linux ISO will mount the ext2 filesystem and use it.

Many linux editions will not automatically mount a persistent (e.g. casper-rw) file if it is on an NTFS filesystem volume. However, if you use this partnew trick then it will work and you can have persistence even on an NTFS or exFAT volume!

IMPORTANT: you MUST run WinContig (RMPrepUSB - Ctrl+F2 or \MAKE_THIS_DRIVE_CONTIGUOUS.cmd) before booting E2B. This is because the persistence ext2 (and .iso) files need to be contiguous - if they are not then the grub4dos partnew command will not work (you cannot have gaps in a partition!).

RMPrepUSB v2.1.711 and later versions allow you to specify the filename and the volume name of the ext2 file separately - e.g. you can specify the ext2 filename as say BT5-rw and the volume label as casper-rw. You can also use ext3 or ext4 instead of ext2.

Note that because grub4dos loads the initial ram drive files, and linux then mounts the new partition(s), even if the linux SKU that is being booted does not support the NTFS file system at all, this technique should still work if the ISO is also mapped to a partition using partnew. This means you can also boot linux ISOs from exFAT Easy2Boot USB drives too.

Here is the BackTrack 5 .mnu file for reference:

# For persistence, create an ext2 file called casper-rw in the root of the boot drive using the RMPrepUSB - Create ext2 FS button

# Then rename the file to BT5-rw (do NOT create a file called BT5-rw - you MUST create a file called casper-rw and then rename it!)

# Place ISO in \_ISO\Mainmenu\linux or \_ISO\XXXX\Linux (and this .mnu file too)

# Run WinContig after copying all files to the USB drive.

iftitle [if exist %MFOLDER%/Linux/BT5R2-GNOME-32.iso] BackTrack 5 (1024x768) Persistent\nType startx to run GUI once booted

#enable parttype output

debug 1

# make empty table entry in 3rd position in ptn table

parttype (hd0,2) | set check=

debug off

set check=%check:~-5,4%

if "%check%"=="0x00" partnew (hd0,2) 0 0 0

if not "%check%"=="0x00" echo WARNING: PTN TABLE 3 IS ALREADY IN USE! && pause

debug 1

#clear ptn 4

partnew (hd0,3) 0x0 0 0 0

if not exist (bd)/BT5-rw echo WARNING: /BT5-rw persistence file not found! && pause

errorcheck off

if "%check%"=="0x00" partnew (hd0,2) 0x0 (bd)/BT5-rw

errorcheck on

map %MFOLDER%/Linux/BT5R2-GNOME-32.iso (0xff)

map --hook

partnew (hd0,3) 0x0 (bd)%MFOLDER%/Linux/BT5R2-GNOME-32.iso

root (0xff)

kernel /casper/vmlinuz file=/cdrom/preseed/custom.seed boot=casper persistent text splash noprompt vga=791--

initrd /casper/initrd.gz

.imgPTN files and UEFI booting

All UEFI systems will boot from a FAT partition as long as the correct .EFI boot file is present. UEFI booting does not use the MBR or PBR sectors on a USB drive or run any sector boot code. Easy2Boot can replace the Easy2Boot partition entry (e.g. an NTFS partition) with a partition entry which points to a partition image file (an .imgPTN file).

An .imgPTN file is a sector-by-sector copy of a whole partition. E2B will replace the partition table on the USB drive with a single partition table entry which points to the .imgPTN file.

E2B USB drive - before switching (FAT32, exFAT, ext or NTFS E2B USB drive)
The example 2.5GB .imgPTN file is at about the 6GB position on the J: volume

After selecting the .imgPTN file in E2B

Once this is done, the E2B drive appears as a single FAT32 (or NTFS) partitioned drive. If it is a FAT32 partition and contains UEFI boot files then a UEFI BIOS will boot from it in UEFI mode. If you boot from it in MBR\CSM mode, the grub4dos menu will allow you to restore the original E2B partitions and thus return it to it's original state (or you can boot from the image in MBR mode).

Examples:

E2B USB drive in normal E2B MBR mode:

ptn 1 E2B (any format - FAT32, NTFS, exFAT or ext2/3/4)

ptn 2 User partition

ptn 3 empty

ptn 4 empty

After selecting a .imgPTN file from the E2B menu which has been formatted as FAT32 in E2B menu (CSM mode):

ptn 1 FAT32 Image (.imgPTN file set as partition 1)

ptn 2 empty

ptn 3 empty

ptn 4 empty

After selecting a .imgPTNLBA23 file from the E2B menu which has been formatted as NTFS (CSM mode):

ptn 1 NTFS Image (.imgPTNLBA23 file set as partition 1)

ptn 2 User partition

ptn 3 empty

ptn 4 empty

Using two partition image files:

If you have Ubuntuv1.imgPTN and another partition image named Ubuntuv1 in the same folder, we will get this arrangement:

ptn 1 FAT32 Ubuntuv1.imgPTN

ptn 2 empty

ptn 3 Ubuntuv1 image

ptn 4 empty

If you have Ubuntuv1.imgPTNLBA23 and another partition image named Ubuntuv1 in the same folder, we get:

ptn 1 FAT32 Ubuntuv1.imgPTNLBA23

ptn 2 User partition

ptn 3 Ubuntuv1 image

ptn 4 empty

In this way, we can boot to any bootable image. If you have a USB Flash drive that is bootable, you can easily make a .imgPTN file from it and add the file to E2B. You can add 100's of bootable images (including FAT32 UEFI-bootable images) to your E2B USB drive!

When you select a .imgPTN file from the Easy2Boot menu, it will replace the current partition table with one for the .imgPTN file. This requires you to boot in MBR\CSM mode first, however you can use the SWITCH_E2B.exe Windows utility to 'switch' partitions under Windows, or boot in MBR\CSM mode using QEMU or VirtualBox.

The MakePartImage.cmd file not only copies the files from the source (e.g. ISO), but if the source contains isolinux or grub configuration files, it looks for any references to 'labels', or 'UUID' or 'CD' references, etc. and changes them to work with a USB drive. Any isolinux files are changed to syslinux files and syslinux boot code is installed. This means that MakePartImage should be able to convert most linux ISOs to boot from a USB partition successfully and it does not need to know what type of linux it is dealing with.

I recommend you watch the YouTube videos to see how this works.

Note: Partition 2 can contain a FAT32 volume with UEFI boot files and WinPE OS files. This allows you to UEFI-boot from the E2B drive to WinPE and use SWITCH_E2B.exe to select any .imgPTN file you want to use - no MBR-boot is required. See here and eBook #3 for details.

Clover

Clover is a 'replacement UEFI BIOS' which can be loaded directly from a grub4dos menu. Clover can boot 32-bit or 64-bit UEFI files.

Clover is included in the MPI Tool Pack, so that when you convert a payload to a .imgPTN file, the resulting image file will also contain the Clover boot files. This means you can boot to Clover directly from the CSM (BIOS) Menu to a 64-bit or 32-bit UEFI boot file.

If the Clover boot option is in the CSM menu on a system containing a 64-bit CPU, there will be a \EFI\boot\bootx64.efi file present in the image. For instance, if you convert a 64-bit Windows 8 Install ISO to a .imgPTN FAT32 file, you can boot to Windows 8 Setup in UEFI-mode using the Clover menu entry in the CSM menu and install Windows via UEFI (with GPT partitions,etc.) - no need to directly boot via UEFI from the system's UEFI firmware.

You may see two Clover menu entries in the CSM menu, one for a 32-bit UEFI system and one for a 64-bit UEFI system when you have a 64-bit CPU present. If your system is a 32-bit UEFI system then only the 32-bit UEFI Clover option will work correctly. If your system is a 64-bit UEFI system, then only the Clover 64-bit option will work.

Clover is very hardware-dependant and so may not work on all systems. You can instead boot the system in UEFI-mode and your system's UEFI firmware should automatically boot to the UEFI payload without loading the CSM menu. If you see the CSM menu then it has MBR\Legacy booted!

Using NTBOOT to boot .WIM and .VHD files

The NTBOOT code comes from chenall (one of the major contributors to the grub4dos project) and some parts of it has been modified and added to E2B. It uses bootmgr to boot via a BCD file to a VHD or WIM file.

You may need to add the bootmgr file to the E2B USB drive, if it was not automatically copied when you made the E2B USB drive using MAKE_E2B_USB_DRIVE.cmd (due to copyright reasons it cannot be included in the E2B download).

NTBOOT contains a basic BCD file and it modifies the BCD file to contain the correct entries and paths for the WIM\VHD file. It then boots to bootmgr which reads the BCD and then boots to the WIM or VHD file.

Only WinPE (NT6) wim files which load the OS to RAM (X: drive) will work. NT6 VHDs can can contain a fully installed OS. The actual WIM and VHD files do not need to be contiguous and can be on another partition of the E2B USB HDD drive.

You can add any number of WIM and VHD files - just copy them all to the E2B drive (e.g. \_ISO\MAINMENU or \_ISO\WIN or \_ISO\WINPE) and boot!

WIMBOOT (E2B v1.A8+)

E2B will use the iPXE wimbo ot utility to boot Windows ISO files, if possible.

Wimboot allows E2B to inject a winpeshl.ini file and a batch fie into the WinPE ramdisk without needing to alter the boot.wim file which is inside the ISO file.

The batch file will then execute when WinPE runs and will load the ISO file as a virtual DVD drive (Y:) using ImDisk.

Because wimboot loads the boot.wim image into RAM, it requires twice as much memory for the boot.wim files and so requires at least 2GB of RAM.

Wimboot has the advantage that a Removable USB disk is not required, so a WinHelper USB Flash drive is not needed when WIMBOOT is used.