Why is it so difficult to boot .ISO files from a USB drive?

I was asked this question recently - Good question!  There is no 1 minute answer, but here was my reply (which may also help to explain how grub4dos works)...

Booting from an ISO is all about disk (Hard disk or Compact Disk) access. We read sectors of data from a disk into memory and then this data (code) is then run by the CPU.

The BIOS provides a Real Mode interface to read and write to sectors of a disk - the interface mechanism is via something called Interrupt 13h. For instance, this code is used to ask the BIOS to read 3 sectors (512 bytes per sector) into a specific memory address:

mov ah,2             ;move the value of 2 into register AH in the CPU, 2 means 'read sectors' in this case

mov al,3              ; 3=3 sectors

mov ch,10          ; track 10

mov cl,1             ; sector 1

mov dh,2            ; head 2

mov dl,80h         ;drive number 80h

mov bx,2000h     ;memory area to put data = 2000h

Int 13h               ; call the BIOS by generating an Interrupt 13h - the BIOS will read the sectors and put the data into memory at address 2000h

Note that Int13h originally (in IBM PC days!) only supported floppy disks (device 00h, 01h, 02h, 03h). Later, when hard disks (Winchesters!) were invented, it supported those (80h=hdd0, 81h=hdd1, etc. up to 9fh). Then later still, CDs were invented and people wanted to boot from them, so special boot code was added to BIOSes to allow device A0h and above to access CDs (but only if you asked the BIOS to boot from them - that is why if you boot to DOS from a floppy disk, it cannot access a CD without a CD driver being loaded).

Later still, USB drives were invented. If we boot from a USB hard disk, a BIOS will map a USB drive as device 80h = hdd0. The internal hard disk will be moved by the BIOS to respond to device 81h requests instead of the usual 80h id.

The most important thing to understand about booting Windows XP/Vista/7/8/WinPE and linux is that it boots in two (or more) stages:

1. Real mode - access to the source files on a disk is done using BIOS calls (Int 13h). DOS uses only this mode and so does Win95/98.

2. Protected mode - the operating system loads it's own driver code which accesses the disk controllers directly - the BIOS is not used because the BIOS only works in Real Mode and not protected mode. So linux/WindowsXP will load a 'kernel' and some mass storage drivers in Real mode (using BIOS calls) and then switch to protected mode. From this point onwards, the protected-mode drivers inside the OS access the hard disk and CD drives, etc. directly - if the wrong driver was loaded then the OS will not be able to access the hard disk that it booted from and you get a 'panic' or BSOD (usually 0x0000007b).

So now let's consider a linux OS booting from a 'flat' filesystem (i.e. not an ISO) - e.g. this could be a hard disk boot

1. Stage 1 - BIOS tells OS boot code that boot device is 80h - boot code loads the OS kernel code using BIOS calls to Int 13h (disk read/write interface to BIOS - hard disk 0 is device 80h)

2. Stage 2 - kernel switches to protected mode  - mount volumes

3. Stage 3 - directly access disk to load rest of the filesystem - more drivers, etc.

Stage 3 needs to have the correct drivers to access the hard disk (SATA/RAID/SCSI/IDE, etc.) and understand the drive filesystem (FAT16/FAT32/NTFS/ext2/ext3/ext4 etc.).

Now let's consider booting the same linux OS, but this time from a CD - this time we have some pre-boot things going on which the BIOS does for us to trick anything using Int 13h into thinking we are booting from a funny sort of hard disk:

pre-boot 1 - BIOS is asked to boot from the CD by user (e.g. F12 pressed or BIOS boot order preset)

pre-boot 2 - BIOS configures Int 13h so that any request made to device A0h reads sectors from the CD in the CD drive

1. Stage 1 - BIOS tells OS boot code that boot device is A0h - then boot code loads the kernel code using BIOS calls to Int 13h (disk read/write interface to BIOS requesting device=A0h)

2. Stage 2 - kernel switches to protected mode, accesses storage devices via drivers, mounts volumes, etc.

3. Stage 3 - kernel  loads rest of the files from the CD - more drivers, etc.

So you see that in Stage 3, the OS need to have drivers which can access CD controllers directly (which could be IDE or SATA devices) AND needs to understand how to read the filesystem on that CD/DVD.

Now consider what would happen if we have a USB drive that contains an ISO file.

BIOSes cannot 'mount' an ISO file or access an ISO file or know anything about ISO files, so we have to use a special boot loader which can 'mount' the ISO and load the files inside it into memory and then run the code in memory.

In this case we will use grub4dos.

grub4dos is a Real Mode boot loader. One thing it can do is 'map' the ISO file and add some code into the Int 13h BIOS code (patch the BIOS interrupt vector). For instance, we can tell grub4dos to map an ISO file as device A0h (any device between a0h and ffh is a 'CD/DVD' device). This means that if we then tell some OS boot code that it booted from device A0h, then the OS boot code will read from device A0h and boot just as if it was booting from a CD. We can do this in grub4dos with these commands  (comments in brackets):

title Boot from linux ISO     (this is the menu text)

map /linux.iso (0xA0)        (treat any access to device A0h as an access to this file - e.g. if boot code asks for sector 1, send back the first 512 bytes of the linux.iso file)

map --hook                      (patch the Int13h BIOS code so that this 'map' will take affect)

chainloader (0xa0h)         (load the first sectors of device A0h (i.e. the linux.iso file) into memory, set the boot device number to A0h and jump to that boot code)

As far as the linux boot code is aware, it is booting from device A0h  (i.e. a CD) and it will make calls to the BIOS Int13h to access device A0h and read any of the files it wants to from the 'CD'.

However, once the Stage 1 code of linux loads, it loads the linux kernel and drivers, etc. and then switches to protected mode. Now the protected mode drivers look at all the disk controllers and CD controllers in the system directly by accessing their I/O registers. It will look for all the storage devices it can find and 'mount' them as volumes (e.g. sda1, sda2, etc.). So now we have a problem, because we did not actually boot from a CD - we tricked the linux boot code - we actually booted from an ISO file on a USB drive called linux.iso - but there is no way that the linux boot code knows that - it needs to access more files from a mounted volume, but the only devices it has been able to mount as volumes are a USB drive and an internal HDD. Neither of these have the files on them it is looking for. So now the kernel 'panics' and it stops booting (typically we get a 'cannot find squashfs' message).

I hope this is clear enough for you so far because now it gets even more complicated! As you see, we can start to boot protected-mode OS's from an ISO using grub4dos, but as soon as it switches to protected mode we are LOST because it cannot continue booting as it cannot find the rest of the boot files on any volume that it can access! What we need to do is tell the OS the name of the ISO, so that it can mount the ISO as a volume and then load the rest of the OS files inside the ISO. With linux this is often done using specific 'cheat codes' or 'kernel parameters'.

e.g.

title LinuxMint 8

map /boot/LinuxMint-8.iso (0xa0)                 - map ISO as device A0h

map --hook                                                - hook the Int 13h interrupt so it takes affect

root (0a0h)                                                 - set root device as A0h - now if we say /casper we are referring to (0xa0)/casper

kernel /casper/vmlinuz iso-scan/filename=/boot/LinuxMint-8.iso file=/cdrom/preseed/mint.seed boot=casper                                                                     - load vmlinuz into memory - add cheatcodes into memory

initrd /casper/initrd.lz                                   - load the initrd.lz file as the initial ramdrive

boot                                                           - jump to the loaded code to start the linux OS  (note 'boot' is not needed as grub4dos automatically adds boot as the last command anyway)

In this way, when linux switches to protected-mode, it can look for the named ISO file on any mounted volume, mounts it as a CD filesystem and then can access the files on the newly mounted volume (the files 'inside' the ISO).

This 'mechanism' is non-standard though and different linux's have different cheat codes (or simply don't support this mechanism at all). Some use the UUID of the drive as a 'marker' so they can find the correct device that has the ISO file. That is the downside of having 100's of separately developed linux distributions - they all  use different cheat codes (kernel parameters) and many do not even support booting via an ISO file!

In Easy2Boot, I use a special feature in grub4dos (the partnew command) which actually creates a new partition table entry and maps the start of that partition to the start of the ISO file - so when linux switches to protected mode, it sees a valid disk partition table entry, mounts it as a cdfs filesystem volume and then finds the files on the volume - so there is no need for any special cheat codes. This works for 99% of linux ISOs really well! For more details see here.

With Windows Install ISOs it gets more complicated...

For XP-based OS's, we typically load a protected-mode mass storage driver like WinVBlock, ImDisk or FiraDisk in Stage 1 text-mode setup and then pass on to the driver, the name of the ISO. Then in Stage 2 (protected-mode) the driver runs and finds the ISO file (either on the USB drive or in memory) and mounts it as a virtual CD/DVD.

For Vista+ OS's, Easy2Boot uses the fact that Windows PE will look for an AutoUnattend.xml file on a 'Removable' device, such as a USB Flash drive, when it boots - so E2B adds a command inside the xml file to cause Windows PE to load the Windows ISO as a virtual DVD drive. In this way, Windows Setup 'sees' a virtual DVD drive and does not complain about a 'missing device driver for a CD'.

If you read some of my tutorials in my www.rmprepusb.com site, you will get an idea of the various tricks that can be used to get over this problem of getting an OS to mount an ISO as a volume once it gets to protected mode.

If it was easy, everyone would have done it years ago!

linux isoboot cheat codes

Here is a list of the many different cheat codes used by different versions of linux (where %ISOSCAN% is the path of the ISO file and %UUID% is the UUID of the partition):

iso-scan/filename=%ISOSCAN%  (fedora/ubuntu)

iso_filename=%ISOSCAN% 

isofrom_system=%ISOSCAN% (openSUSE)

isoboot=%ISOSCAN%  (gentoo)

iso-scan/filename=%ISOSCAN% 

isofrom_device=/dev/disk/by-uuid/%UUID% 

isofrom=%UUID%:%ISOSCAN% 

bootfromiso=%ISOSCAN% (PCLinuxOS)

findiso=%ISOSCAN%   (debian - may also need bootid=<volname>  boot=live and live-media-path=/xxx/yyy)

fromiso=%ISOSCAN% 

from=%ISOSCAN%

isoloop=%ISOSCAN% 

img_loop=%ISOSCAN% (arch)
livemedia=%imgdevath%:%isopath%  (slackware)

If you found this blog post useful, please tick one of the Reactions tick boxes below to let me know.

The RMPrepUSB Pre-Set Configurations feature

If you regularly use RMPrepUSB to make Easy2Boot USB drives, you can create a Pre-Set Configuration Menu so that when RMPrepUSB.exe is run, you are prompted with one or more Pre-Set Configuration options.

For instance, I have saved a single pre-set configuration for Easy2Boot USB creation so that when RMPrepUSB.exe runs, I am first greeted with the dialog box show below:

If I double-click on the 'Create Easy2Boot USB Multiboot Drive' (or select it and click OK), instead of the usual RMPrepUSB form with the options set to the same settings that I used last time, I get the following RMPrepUSB form:

Notice that a lot of buttons and the top menu bar is missing. Also notice that the '5 Copy OS files' field is set to .\Easy2Boot.zip - this is the Easy2Boot zip file which I have already copied to the same folder that RMPrepUSB.exe is in (and renamed). You can specify a full folder path if you like or an ISO file or any zip file instead.

Now, if I click on '6 Prepare Drive', I see this dialog box:

and when I click on 'Yes'  I see this final confirmation dialog box (answering 'No' will leave the Volume Label and Size as whatever is currently set by the user):

What happens next is that RMPrepUSB will:

1. Wipe the drive

2. Partition the drive

3. Format the drive

4. Extract the zip file contents to the drive

5. Install grub4dos to the PBR

... all automatically. It takes less than 40 seconds for the whole process if using the standard E2B file download (without the XP mass storage drivers).

You can add more menu Config items to the RMPrepUSB config menu and so you can have many choices. For instance, you could point option 5 to a folder, then the entire contents of the folder would be copied over after formatting and then grub4dos could be installed. You could have entries to make a DOS-bootable USB drive, an E2B drive with payload files, a Hirens Boot USB drive, a Windows 8.1 Install USB drive, etc. etc.

The buttons and menu topbar were removed by manually editing the RMPrepUSB.ini file after it had been made (using F9).

To create the RMPrepUSB.ini file in the first place, just start RMPrepUSB and set it as you want it and then actually run it to fully prepare your USB drive. If you want grub4dos (or syslinux) to be installed then install that too. v2.1.713 also records any ext2 filesystem parameters you use too. 

Once done, press F10 to add the settings that you used to the RMPrepUSB.ini file. You can then check it in NotePad and test it by quitting and re-running RMPrepUSB or pressing F12.

The actual settings in my RMPrepUSB.ini file for Easy2Boot were edited to be as follows:

TITLE=Create Easy2Boot FAT32 USB MultiBoot Drive

SIZE=MAX

LABEL=EASY2BOOT

OS=WINPE

FILESYSTEM=FAT32

BOOT_AS=HDD

USE64HD_32SEC=FALSE

FORCE_LBA=FALSE

COPYFILES=TRUE

COPYFOLDER=.\Easy2Boot.zip

BARTPE=FALSE

SUPPRESSPROMPTS=TRUE

BOOTABLE=TRUE

GRUB4DOS=PBR

USERPROMPT=Select your USB drive in the top box

SYSLINUX_OPT=

EXT2FNAME=

EXT2FSIZE=

EXT2VOLNAME=GRUBVISIBLE=TRUE

EXT2VISIBLE=FALSE

SYSLINUXVISIBLE=FALSE

INACTIVEVISIBLE=FALSE

BARTPEVISIBLE=FALSE

IMAGETOOLSVISIBLE=FALSE

SPEEDTESTVISIBLE=FALSE

SIZETESTVISIBLE=FALSE

CLEANVISIBLE=FALSE

QEMUVISIBLE=TRUE

MENUVISIBLE=FALSE

MINIMISEDESKTOP=FALSE

More information about RMPrepUSB.ini and how to make a configuration menu can be found here.

One good use of this Config Set feature is that you could distribute a self-extracting .exe file to all your technicians which contained the RMPrepUSB files and any USB payload folders you wanted. When the exe file was run by the user, it would launch RMPrepUSB and he/she would see the config set menu and then could choose any one of the configuration sets you have included. Then all they have to do is click on '6 Prepare Drive' and the USB drive will be made automatically for them with no extra steps or knowledge needed (you can also add some instructions for each configuration, if required). 

The QEMU button could have been made invisible, but I left it so the user can test the USB drive once it has been made. As the drive should be contiguous, it should not be necessary to run WinContig (but the Ctrl+F2 key will still work even though the menu bar is not displayed).

Note: Grub4dos installation is only run once when using a Pre-Set Configuration, so I used the PBR option to install grub4dos to my E2B drive. However for best 'bootability' you should also install grub4dos to the MBR after the USB drive has been made - that is why I left the Install grub4dos button visible ;-)

Understanding the Easy2Boot folder structure

It is difficult to understand the folder structure used in E2B and to know where to put your ISOs and .mnu files.

As there is so much to read in the E2B Tutorial, I thought I would try to explain it in my blog.

TWO GOLDEN RULES FOR E2B USER FILES

• E2B will only auto-detect payload files that are at the \_ISO\XXXXX folder level.
• E2B will auto-detect .mnu files that are at the \_ISO\XXXXX folder level AND also any sub-folders underneath that level.

'Payload' files are the files that you want to boot (e.g. .ISO, .IMA, .BIN, etc.).

.mnu files are grub4dos menu entry files (e.g. as required when booting linux from an ISO with persistence).

If you want to know more then read on, but if not, it would be worth re-reading the two rules above just to get them into your head before you close this browser tab and go and get that cup of coffee!

Add GeekSquad MRI ISO to Easy2Boot

I had a request today from Rob about how to add the GeekSquad MRI ISO to Easy2Boot. This is private s/w and is available to GeekSquad members.

I found that mostly it just worked as a .iso file added to E2B (after running WinContig to ensure it was contiguous). The menu system was checked and the results were as follows:

       1. System diag -     1 pc-check  RUNS OK

       2. Memory diag -     1 memtest86 4.2  HANGS!??
                                     2 memtest86+ 4.2 RUNS  OK
                                     3 windows memory diag 0.4 RUNS OK
                                     4 PC check mem diag  RUNS OK
                                     5 PC check diag RUNS OK

      3. Hard drive utils -   1 PC check RUNS OK
                                     2 Drive Fitness RUNS OK
                                     3 Seatools RUNS OK
                                     4 WD Tools RUNS OK
                                     5 Dariks Boot & Nuke OK
                                     6 MRI PE Utilities   - CANNOT LOCATE MRI DISK

     4. Password reset utils - 1 Samurai  RUNS OK UP TO CANNOT LOCATE MRI DISK
                                         2 Offline NT pwd RUNS OK

      5. MRI                         - CANNOT LOCATE MRI DISK

To fix the  - 'CANNOT LOCATE MRI DISK' issue I extracted the \sources folder and the \mri.exe file to the root of the E2B USB drive. Then I found that the MRI WinPE booted and ran the MRI.exe OK, but the menu had greyed out a lot of the utilities, to fix this I extracted some of the utility folders from the ISO.

This worked fine but left me with 1GB of folders on the E2B drive and a 1.2GB ISO!
To fix this, I ran Daemon Tools Pro and edited the .ISO file and simply deleted the first 7 folders in the list below to leave a <300MB ISO.

Note: For E2B v1.81+, try the .isoPECD file extension if you have a Removable USB E2B drive.

Instructions in a nutshell:

1. Extract using 7Zip and copy to root of E2B:

\Compression utilities\
\Diagnostics
\Disk Management
\Malware
\MRI
\Web Browsers
\Windows tools

\sources  (note: boot.wim seems to be needed or you get 'CANNOT LOCATE MRI DISK' error message)
\mri.exe

2. Run Daemon Tools Pro - Edit ISO - delete the first 7 folders in the list above - save ISO.

3. Copy the reduced ISO to \_ISO\MAINMENU and keep the file extension as .ISO

4. Run WinContig (RMPrepUSB - Ctrl+F2)

5. Boot E2B...

P.S. I found a real system worked better than Virtual Box which seemed to have some issues booting to MRI PE.


[Edit]
You can also convert the MRI ISO into a partition image using MakePartImage to make a .imgPTN image file. This saves having to edit the ISO file. This will allow you to boot the WinPE part.

If you also want to be able to boot some of the memory or HD diagnostics, you will need to add this menu to the bottom of the  menu.lst which is already inside the .imgPTN image (just switch to the CSM menu - unplug and reconnect the E2B drive and then edit the CSM menu.lst file.)
[Edit] or just SWITCH_E2B.exe to switch in the .imgPTN file.

To boot to the NT Offline Password Reset utility, use the Main or Syslinux menu entry which is already in the menu. To boot to WinPE, use the bootmgr menu entry.


iftitle [if exist /bootmgr] WinPE MRI \n Boot to WinPE
chainloader /bootmgr

iftitle [if exist /ezboot/gsdiag.ima] PC Check Diagnostic\n GSDIAG
set IMA=/EZBOOT/GSDIAG.IMA
map %IMA% (fd0)
map --hook
root (fd0)
chainloader +1

iftitle [if exist /ezboot/gsHD.ima] PC Check HD\n GSHD
set IMA=/EZBOOT/GSHD.IMA
map %IMA% (fd0)
map --hook
root (fd0)
chainloader +1

iftitle [if exist /ezboot/gsMEM.ima] PC Check Memory\n GSMEM
set IMA=/EZBOOT/GSMEM.IMA
map %IMA% (fd0)
map --hook
root (fd0)
chainloader +1

iftitle [if exist /ezboot/gsMEMALL.ima] PC Check Memory ALL\n GSMEMALL
set IMA=/EZBOOT/GSMEMALL.IMA
map %IMA% (fd0)
map --hook
root (fd0)
chainloader +1

iftitle [if exist /ezboot/PCCHECK.ima] PC Check \n PCCHECK
set IMA=/EZBOOT/PCCHECK.IMA
map %IMA% (fd0)
map --hook
root (fd0)
chainloader +1


iftitle [if exist /ezboot/MEMTEST.IMG] MemTest 86 4.0-4.2\n MEMTEST.IMG
set IMA=/EZBOOT/MEMTEST.IMG
map %IMA% (fd0)
map --hook
root (fd0)
chainloader +1


iftitle [if exist /ezboot/MEM TESTP.IMG] MemTest 86+ 4.20\n MEMTESTP.IMG
set IMA=/EZBOOT/MEMTESTP.IMG
map %IMA% (fd0)
map --hook
rootnoverify (fd0)
chainloader +1

iftitle [if exist /ezboot/DFT.IMG] Hitachi Drive Fitness\nDFT
set IMA=/EZBOOT/DFT.IMG
map %IMA% (fd0)
map --hook
root (fd0)
chainloader +1

iftitle [if exist /ezboot/DFT_NM.IMG] Hitachi Drive Fitness NM\n DFT_NM
set IMA=/EZBOOT/DFT_NM.IMG
map %IMA% (fd0)
map --hook
root (fd0)
chainloader +1


iftitle [if exist /ezboot/WMDIAG.ima] Windows Memory Diagnostic\n WMDIAG
set IMA=/EZBOOT/WMDIAG.IMA
map %IMA% (fd0)
map --hook
root (fd0)
chainloader +1

iftitle [if exist /ezboot/DLGDV415.ima] Data LifeGuard Diagnostic\n DLGDV415
set IMA=/EZBOOT/DLGDV415.IMA
map %IMA% (fd0)
map --hook
root (fd0)
chainloader +1

iftitle [if exist /ezboot/STDOSTXT.ima] SeaTools\n STDOSTXT
set IMA=/EZBOOT/STDOSTXT.IMA
map %IMA% (fd0)
map --hook
root (fd0)
chainloader +1

# new
#DLGDV522.IMA
iftitle [if exist /ezboot/DLGDV522.IMA] Data LifeGuard v522\n Diagnostics
set IMA=/EZBOOT/DLGDV522.IMA
map %IMA% (fd0)
map --hook
root (fd0)
chainloader +1

#STDOS.IMA
iftitle [if exist /ezboot/STDOS.ima] SeaTools DOS\n STDOS
set IMA=/EZBOOT/STDOS.IMA
map %IMA% (fd0)
map --hook
root (fd0)
chainloader +1


#DBAN.IMA
iftitle [if exist /ezboot/DBAN.ima] DBAN\n Nuke HDD!
set IMA=/EZBOOT/DBAN.IMA
map %IMA% (fd0)
map --hook
root (fd0)
chainloader +1

MRI 5.10.2 ISO

This version uses PC Doctor and has several WinPE menu entries.

You can use the menu below for a Removable USb drive:

title MRI 5.10.2\n Run MRI menu (WinPE only works if Removable E2B USB drive used)
/%grub%/QRUN.g4b  force.isope $HOME$/MRI_5_10_2.ISO
chainloader (0xff)
boot

or use the new .isoPECD file extension in E2B v1.81+ 

E2B v1.10a available

The only difference is revised sample .mnu files in the \_ISO\docs folder. If you are going to use any of the sample .mnu files then I suggest you download the new version and overwrite your current 1.10 version.
Note that the V1.10+MassStorageDriver 30MB download is not v1.10a - it is still v 1.10. It will be updated when 1.11 is released.

Universal USB Installer (also YUMI) USB Flash drive does not boot on EeePC

I tried the Universal USB Installer from pendrivelinux.com today to format and prepare a USB flash drive with Hirens Boot CD 15.1 ISO.

The USB preparation was pretty quick and I then plugged the flash drive into my trusty EeePC 904HA netbook to test it. Sure enough it started to boot... but then failed to show a menu and left me at the grub4dos command shell!
When I typed 'find' in the grub4dos command shell, the reason was obvious - the EeePC showed that a floppy disk was present (fd0) which was actually my USB flash drive!

grub> find
(fd0,0)
(hd0,0)
(fd0)
(fd0,1)
(fd0,2)
grub> ls (fd0)/
ldlinux.sys hbcd hbcd.txt HBCDMenu.cmd autorun.inf changes.txt syslinux syslinux.cfg Uni-USB-Installer-Copying.txt Uni_USb-Installer-Readme.txt license.txt

This is typical of many system BIOSes. If they see a USB Flash drive with only one partition, they treat the USB drive as a floppy drive (actually a ZIP drive). The problem is the menu system used by the Universal installer expects the USB drive to be hd0 not fd0 and so it does not find the menu.

One way to fix this is to format the USB drive first with RMPrepUSB and make sure you tick the 'Boot as HDD (C: 2PTNS)' checkbox. This puts a small hidden extra partition on the USB drive and so the EeePC will now treat the USB Flash drive as a hard disk. After formatting as 'FAT32+Boot as HDD', run the Universal Installer but do not tick the 'We will format Drive as FAT32' checkbox and all should be well. You should now have a USB Flash drive that will boot on a lot more systems.

P.S. If you like Hirens Boot CD, try FalconFour's Ultimate Boot CD (there is a .mnu file for it in Easy2Boot too!).

Test your SD memory cards (and USB Flash drives)!

I recently ordered a 32GB Class 10 micro-SD card from a UK seller on eBay (electronicmemory) and it arrived in the post 2 days later.
The first thing I do whenever I buy a new Flash drive or SD card is test it using RMPrepUSB - Quick Size Test. I wrote this test specifically to test for 'fake capacity' memory devices.
Fake capacity memory devices  are created by doctoring the controller firmware which has been deliberately altered to lie about the capacity of the memory. The SD card was only £8.99 and I had my doubts when I purchased it, mainly due to this text at the very bottom of the item description:
'When these brand new Micro SD cards devices have been tested they vary in storage capacity, but are all listed as good and are from 4GB UP TO 32GB.

 The same as pretty much all cheaper micro sd  memory on e-bay, they just don't tell you this.  

Please note that whilst these cards are brand new and have been shipped to me straight from the factory they are sold as upgraded cards and therefore the capacity and speed may vary for each card, (They may experience read/write errors once max capacity reached - The one I have in my phone is up to 4GB at the moment with no issues) hence the very low price and free 1st class delivery! Approximately a third of what you would pay for brand new perfect condition products. Once you receive your card it is always recommended that you format it in your device before use.'

So the devices have been tested and are 'good' (the pack was unopened when I received it!). It is advertised as 32GB and it is not at all clear if this is a 32GB card or what!

Apparently, it is OK to advertise a 32GB card but supply fake SD cards that really are only 4GB!

Another eBay advert from a differrent seller states:

'BY PURCHASING ONE OF THESE CARDS IT IS ON THE BASIS THAT YOU HAVE READ AND UNDERSTOOD THE FOLLOWING:

All cards are tested with results ranging from 4GB to 32GB in capacity. These are offered as upgraded cards, therefore the speed and capacity will vary with each card. Errors may be experienced once the maximum capacity has been reached. We suggest formatting the card in FAT32 format if problems occur'

Again, it seems it is fine to sell deliberately faked cards! How many cameras would format a 32GB card as anything other than 32GB! Cameras don't run a size test on the card to see if it is fake!

The Quick Size Test in RMPrepUSB (3rd button up on bottom-right - see below) took just 5 minutes to run (it would have been quicker if it wasn't faulty!). Note: It is a destructive test and so you need to format the memory after the test has passed. Here is a screenshot of the result I got on my '32GB' SD card (click to enlarge):

The UK seller offered me a full refund, but that is not the point! The seller is knowingly deceiving the public (he even admits it in the small print!). It is like being paid by someone with a counterfeit £20 note and then when it is pointed out that the note is counterfeit, saying 'oh yeah - sorry - here have a real one instead' and then they are allowed to go away free! Since this seller had 10,000 sales, I hate to think how many people he has conned into thinking that they were 'unlucky' and that the memory must have been 'faulty'! It is not 'faulty' - it has been deliberately faked in order to deceive you and once you fill it up past 3.8Gb it will totally corrupt all your precious photos!

The worrying thing is that these sellers seem to think it is OK to sell fake memory as long as they mention in the small print that they are 'upgrades' - whatever that means (reprogram them and stick a 32GB label on them perhaps?). The memory that they use in these products is usually reject memory too and so even the 4GB part that works could lose 'bits' at any time - they get this memory from the reject bins at the back of the memory chip factory - after all, if the chips were any good then they would be sold as 4GB memory chips by the original manufacturer and branded correctly!

One eBay advertiser even tries to explain that the memory compresses the data and so even if it formats as 4GB it actually can hold up to 32GB of data! Utter twaddle!

'electronicmemory' is still happily selling these fake SD cards today - even though I pointed out to them that these cards were fake and had been deliberately manufactured to deceive! They could 'legally' advertise them as '4GB SD cards pretending to be 32GB' in the subject title, but they choose to advertise them as '32GB SD cards' and add some 'doublespeak' in the text right at the bottom of the ad instead. What conclusions about the seller can we draw from this?

If you come across any similar companies selling fake products on eBay, please report them to eBay as selling counterfeit goods using the link on this page (use the Be sure to report listings that offer counterfeit items or replicas. link).

The Quick Size Test in RMPrepUSB is quick to run (unlike H2TESTW which takes hours) - so there is no excuse for you not to run it. Test your SD cards and USB Flash memory sticks NOW and remember to test any new ones as soon as you get them. If they fail, ask for your money back immediately (before the eBay time limit expires!), then give negative feedback (if you haven't already left +ve feedback!) and report them to eBay.
If you don't check your memory devices, you will lose all your data/photos when you least expect it!

Note: I have also written FakeFlashTest, which has a simple interface and two test options:
1. Quick Test - This is the same test as in RMPrepUSB (but improved/faster)
2. File Test - this is a similar technique to H2TESTW (i.e. non-destructive), it fills the unused filespace with large files, but is much quicker.

http://rmprepusb.blogspot.co.uk/2013/10/a-faster-test-for-fake-sd-cards-and-usb.html

Add the ESXi Installer ISO to Easy2Boot

I found today that the ESXi Installer ISO (I used VMware-VMvisor-Installer-5.1.0-799733.x86_64.iso) can be simply copied to your Easy2Boot MultiBoot USB drive and it will 'just work'. No doubt other versions will also work too.

To test it, I used Oracle VirtualBox + DavidB's 'Virtual Machine USB Boot' (VMUB) to install it to a virtual hard disk by booting directly from my E2B USB Flash drive using VMUB.

If you are using VBox, you will need these settings for the VM.

CPUs:   x2 or more (x64 + VT)
Memory: 2.1GB or more
Network: Host-only Adapter - VirtualBox Host Only Ethernet Adapter - Intel Pro/1000MT

More details here.

P.S. See Tutorial 4 if you don't know how to boot directly from a USB drive with Virtual Box and DavidB's great new utility which gives the VM full read/write access to the USB drive - great for testing Easy2Boot USB drives!

RMPrepUSB 2.1.712

Minor change
I got tired of having to untick 'No user prompts' when I wanted to install grub4dos to the MBR and then install grub4dos again to the PBR. Now if you have 'No user prompts' ticked, it will prompt for MBR or PBR, but there are no more prompts after that.

RMPrepUSB 2.1.711 now available

In previous versions of RMPrepUSB, if you wanted to make a file containing an ext2 filesystem that had a different volume name from that of the ext filename, you had to first create the ext2 file first and then rename it.

This is because when you specified the filename, the volume label was automatically set to the same name as the filename by RMPrepUSB.
i.e. if you set the Filename as 'casper-rw' then:

Filename = casper-rw
Volume Name = casper-rw

This meant that if you wanted a file called  'fred' but with a volume label of 'casper-rw' you first had to create the ext2 file with the filename (and volume label) of casper-rw and then rename the file to 'fred'.

This new version of RMPrepUSB prompts you for the Volume Label as well as the File Name, so you can now specify 'fred' as the filename and 'casper-rw' as the volume label before the ext2 file is made.
This means you don't have to rename the file after it is made.

Slax 7.0 with persistence for Easy2Boot

I spent a few hours today trying to get Slax 7 working with persistence on an NTFS USB drive.
It seems this does not work. I tried various switches/cheat codes but the closest I came was to make an ext2 filesystem file and copy the ISO contents to the mounted ext2 filesystem - then use a grub4dos menu and the partnew command to map the ext2 file as partition 3 and then boot Slax from that, this almost worked, persistence was set up on the ext2 volume and it almost fully booted to the Desktop but got some errors on the very last stage and stopped with I/O errors.

Here are the conclusions I came to:

• Slax recognises the source folder if it contains any *.sb file (the  .sb file can be any name but there must be at least one present in the 'source' folder that it looks at) and then mounts that folder. The folder path can be set using the from= parameter which can be the path to the source ISO file (in which case it will be read-only and so persistence will not be enabled), or the path to the source files which have been extracted onto a disk drive (which is what we need in our case). Slax then looks for a folder called changes under this folder. If it finds one, it tries to create a changes.dat file for persistence. If this fails then persistence is not enabled.
  Therefore - whatever source is used, Slax tries to create the persistence file on the same drive as the source .sb module files.
• Slax seems to fail to create a changes.dat folder on an NTFS volume - therefore your source boot files must be on a FAT32 (or maybe ext2/3/4) volume. It will boot from an NTFS volume (via ISO or flat files), but it won't enable persistence.
• Using the toram switch (to run Slax in memory) means that persistence will be temporarily disabled until it is run without the toram parameter.
• The changes=  cheat code did not seem to affect anything??
• Some USB devices are not detected by the Slax 9.11.00 boot kernel and therefore will not fully boot - e.g. SilverStone MS09. Try the 'fdisk -l' command if the kernel aborts to the console on booting and see if USB is listed.

In the end, this is the grub4dos .mnu file I came up with for Easy2Boot. It can be adapted for different versions of Slax each with a different persistence file by changing the slaxsrc folder location.

# Extract the iso \slax folder using 7Zip to \_ISO\MAINMENU\Linux and rename it to slax708_32  
#   (so, for example, the first file will be at \_ISO\MAINMENU\Linux\slax708_32\01-core.sb)
# Copy this .mnu file to \_ISO\MAINMENU\Linux
# The  \_ISO\MAINMENU\Linux\slax708_32\changes   folder must exist for persistence to activate
# Persistence does not work if the slax source folder is on an NTFS or read-only volume!

iftitle [if exist %MFOLDER%/Linux/slax708_32/01-core.sb] SLAX 7.0.8 32-bit persistent \n Run Slax with persistent changes (FAT32 ONLY)
if not exist %MFOLDER%/Linux/slax708_32/changes/changes.dat echo Info: Persistence file is not yet present... && pause --wait=2
set slaxsrc=%MFOLDER%/Linux/slax708_32
kernel %slaxsrc%/boot/vmlinuz vga=773 rw slax.flags=perch,xmode  from=%slaxsrc%
initrd %slaxsrc%/boot/initrfs.img

E2B v1.10 released (bug fix)

The DEFMENU=0 setting was not working (thanks to Sergei for pointing it out) - now fixed.
Also added a   'set NOUNIFONT=1' setting which disables the loading of the 1MB unifont.hex.gz file for people who do not need or want the non-ASCII character support.

new Video - Install Windows XP using Easy2Boot

E2B v1.09 released

This version has a few minor changes as described below:

v1.09 2013-09-14 Some sample .mnu files revised and added, .vhdmem, imz, imggz extensions supported, set DEFMENU=0 supported for no 'set default' menu item, .txt files now checked for 'title' keyword and user warned if missing.

If you set 

set DEFMENU=0

in your MyE2B.cfg file then the 'set default menu entry and timeout' menu item will not appear in the Main menu.

Also, if you accidentally create a .txt file for a payload file and forget to precede the entry with the word 'title' then E2B will warn you when it enumerates the files on boot. I have had several cases where users have forgotten to add the word 'title'.

.vhdmem will load the whole vhd file into memory.

.imz and .imggz are now recognised as valid fdd images.

I have also made available a 30MB download of E2B + the XP Mass Storage DriverPack files to make it easier to create an XP install E2B USB drive.

Add GeeXBox ISO to Easy2Boot

GeeXBox is an XBox Media Centre linux release (XBMC). You can boot it from an ISO file in E2B but you need to also extract and copy the rootfs file from the ISO and place it in the root of the USB boot drive.

e.g.
\_ISO\MAIMENU\GeexBox-3.0-i386.iso
\rootfs



Using the following .mnu file you can have persistence too but it seems to cause some problems which I haven't managed to solve yet.

# For persistence, create an ext2 file called casper-rw in the root of the boot drive using RMPrepUSB Create ext2 FS button
# Then rename the file to geexbox-rw  (do NOT create a file called geexbox-rw - you MUST create a file called casper-rw first and then rename it!)
# Place ISO in \_ISO\Mainmenu\linux or \_ISO\Linux\Linux (and this .mnu file too)
# Extract the file rootfs from the ISO using 7Zip and copy it to the root of the USB drive
# DOES NOT WORK UNDER NORMAL VM  (you can use VBox + DavidB's USB VM Starter app)!!!
# If it complains about broken repositories, do not disable them if prompted.

iftitle [if exist %MFOLDER%/Linux/GeexBox-3.0-i386.iso] GeexBox \n GeexBox using /geexbox as a persistence file
if exist CD echo WARNING: Cannot use partnew command! && pause && configfile (bd)/menu.lst
set ISO=GeexBox-3.0-i386.iso
#enable parttype output
partnew (hd0,3) 0x0 %MFOLDER%/Linux/%ISO%
# make empty table entry in 3rd position in ptn table
debug 1
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
if not exist /geexbox-rw echo WARNING: /geexbox-rw persistence file not found! && pause
errorcheck off
if "%check%"=="0x00" partnew (hd0,2) 0x0 /geexbox-rw
errorcheck on
map %MFOLDER%/Linux/%ISO% (0xff)
map --hook
root (0xff)
kernel /vmlinuz root=/dev/ram0 ro vga=789 persistent
initrd /initrd

RMPrepUSB v2.1.710 available

RMPartUSB code has been updated to v 2.1.710. RMPrepUSB has just had it's version number updated to match that of RMPartUSB.

When MAX size is specified in RMPrepUSB to partition and format a drive, RMPartUSB used all available drive space as reported to it by the drive's 'get-size' function call under Windows. However, some USB drives seem to report their size inaccurately (at least under Win7) leading to a partition being created by RMPartUSB that was actually slightly larger than the end of the physical drive. As a result the last few sectors of the partition could not be accessed and this seemed to cause very slow access (BIOS timeouts) when running the Easy2Boot 'check-access' test or in grub4dos when accessing some volumes when looking for the WINHELPER.USB file or in XP when booting from a vhd (and possible when booting from flat files too?) - but only on some BIOSes. It may be that some BIOSes set up the disk geometry as modulo 255*63 as they expect the partitions to be modulo 255*63 and then try to access the end of the disk (for some strange reason).
The new version of RMPartUSB now reduces the reported drive size to a whole cylinder (nearest 8MBish) and checks that the end is accessible (and reduces it further if it is still not accessible). This should reduce the occurrence of some strange 'slow' access problems occasionally seen in grub4dos and booting XP from a USB drive and with Easy2Boot on some systems.
I recommend updating to this new version which I will release as the standard version in a few days if no problems are reported with it. If practical, reformat your E2B flash drives with this new version if you were having any 'slow' or 'hanging' problems using E2B.
The DriveInfo command has also been tweaked to show the end LBA sector of each partition and to report the drive size as reported by the drive as well as the size that RMPrepUSB will use if you partition the drive using 'MAX' for the volume size.

Three new 'Tutorials' added

109 - USB Rubber Ducky Hack Device (Hak5)  (just information rather than a tutorial!)

110 - Run full Windows XP to Go! from a USB drive Install full XP to a VHD in 30 minutes (works on some systems but not all!)

111 - How to semi-automate and speed-up Windows driver installs (if you often manually re-install Windows using Setup.exe on the same model of system, why not semi-automate the driver installation and save time).

FAST! Windows NTFS file search of your entire system in a few seconds! - SwiftSearch

SwiftSearch requires Admin privileges, however, it is VERY FAST!
You can use regular expressions or use a search pattern like t*.xl??  to find Excel files beginning with t or T. On my 250GB nearly full C: volume it did this search in about 1 second (after reading the NTFS file table on the first search, which took about 5 seconds)!
Not only is it fast, but it actually finds the files I am looking for (even if it is a hidden or system file) unlike the next-to-useless Win 7 search engine! Finally you can disable the resource hungry and delay-causing Windows Search Service and no need for an enormous index file either. Shame MS couldn't do this!
SwiftSearch is a standalone executable and therefore is a portable application - it ran fine under a vanilla Windows 7 PE environment too. This means it could be very useful for booting a system to WinPE from a USB drive and then quickly using SwiftSearch to find and copy an important file (or all .doc files?) onto your USB drive. Unfortunately you can only select and copy one file at a time in the search results (no Ctrl+A function) but at least right-click works as expected on individual files. Maybe this will be improved soon?
See here for a forum thread on SwiftSearch and comments from the author of SwiftSearch about hidden (previously undocumented) features:

• F5 - re-index target volume (use this if you have copied files to the same volume since you launched SwiftSearch)
• Ctrl+Search = find all files included deleted files (right-click on result to see file number) - combined with DiskBuddy's ability to read the MFT, that should be enough to tell you where a file is located on the disk.
• Shift+Search = display all NTFS attributes
• ESC - minimise to System Tray (re-indexes every 15 minutes)

Easy2Boot v1.08 - few minor changes

v1.08 2013-09-04 bitdefender mnu file added to docs folder, Windows 8.1 temporary Product Keys added, master pwd option in MyE2B.cfg

Setting a master password prevents the user from running E2B unless they know the password.

Tested with Windows 8.1 x86 ISO (no E2B code changes were required but new Windows 8.1 keys need to be entered to install Win8.1).

Link for leaked Win8.1 ISOs is available in External Links page on www.rmprepusb.com site.

'Hide' grub4dos menu.lst and other 'sensitive' files

If you have made a grub4dos bootable USB drive and you have password protected the menu.lst (or maybe just some of the menu entries) using the grub4dos password command, it is really quite easy for someone to hack the menu.lst file and simply remove the password lines just by using Notepad.

Another scenario is that you have set up an expiry date in the menu.lst file, so that when the expiry date is reached, a message will warn the user that it has expired and it should be updated and you don't want this to be circumvented! . See here for details on how to set this up.

Here are two ideas which I use to deter the amateur hacker.

1. Use 7Zip to compress the menu.lst file (or any sensitive .g4b batch files or other files loaded by grub4dos) to GZip format. Ensure that the resultant filename and extension is not changed and grub4dos will still run it just fine.

2. Set the file attribute on the 'sensitive' files (e.g. menu.lst) to Hidden (right-click - properties - Hidden).
You could also set the file attribute to System+Hidden+ReadOnly to make it even more difficult to see in Windows Explorer. You can use the Windows command line and the attrib menu.lst +h +r +s command or use NirSoft BulkFileChanger to do this.

This (compression to Gzip +  attribute change) will also work on most of the grub4dos Easy2Boot files (e.g. all .g4b, .lst and .mnu files and even your \_ISO\MyE2B.cfg file). Just keep the filename and the extension the same. Any file loaded by grub4dos that is detected as being in compressed gzip format is automatically uncompressed by grub4dos when it is read.

Of course, now I have told everyone this, it is no longer a secret!


Footnote: Another format that grub4dos can read is lzma, but not the standard lzma compression used by 7Zip. This format is slightly better because if you open it in NotePad, you don't see any tell-tale header information. For this lzma compression which grub4dos understands, we need to use the Windows lzma.exe utility

1. Download lzma.exe from https://code.google.com/p/grub4dos-chenall/downloads/detail?name=lzma.exe
2. Open command prompt
3. Type
                  lzma.exe e J:\_ISO\MyE2B.cfg J:\_ISO\MyE2B.cfg.lzma
4. Delete the original file and rename the lzma so it is the same name as the original (e.g. MyE2B.cfg).

To decode the compressed file, use the d parameter:

              lzma.exe d J:\_ISO\MyE2B.cfg J:\_ISO\MyE2B.cfg.txt

P.S. 7Zip can also decode the compressed lzma files if you add the .zip extension - 7Zip lists them as LZMA:23 encoded files.

For more details and also a handy drag&drop utility to compress E2B files (without changing the original filename) see Tutorial 72a here. It also has a decompress drag&drop utility included too. Each file selected is checked first to ensure you don't try to double-compress a file by mistake!

E2B - bitdefender ISO + persistence now supported

You can run a BitDefender .ISO with persistence from an E2B USB drive which keeps AV updates on the USB drive's persistent ext2 filesystem. I have added a new .mnu file to the E2B download - look in the \_ISO\docs\Sample mnu files folder (as usual).

New Easy2Boot Intro Video

Easy2Boot v1.07 Video now on YouTube

Easy2Boot v1.07 now available

Download Version 1.07 here.

• Latest grldr gives better alphabetical sorting (e.g. _fred.iso now listed in E2B menu before afred.iso).
• .isope file extension support - if WinPE2/3/4 iso then when wpeinit runs, the iso will be loaded as a virtual CD/DVD.  See here for more info.
• WinPE ISOs (.isope) can mount the .ISO after booting and user can define any drive letter for the ISO and auto-run a post-cmd batch file once ISO is loaded. See here for more info.
• ISOASK variable supported (is set, will ask user how to run every .iso). See here for more info.
• Can force any .iso to run as if it had a different file extension by creating a .mnu file for the iso file. See here for more details.

E2B v1.07 Beta5

Another small change for Zalman ZM-VE200/300/400 CD emulator owners! You do not have to change the .iso file extension for E2B now.

This version allows you create a .mnu file for each .iso file that requires a different extension for E2B.

For instance, if you have a Hirens iso file and you want to run it with the .isowinvh file extension in E2B, but leave the hirens iso file with a .iso extension on the Zalman E2B drive, use this .mnu text:

title Hirens ISO\n Boot direct from Hirens ISO\n If running DOS utilities from an NTFS drive you may need to select the NTFS driver when offered a choice instead of AUTO
/%grub%/qrun.g4b force.isowinvh %MFOLDER%/Utility/Hiren's.BootCD.15.2.iso
boot

The force.isowinvh is a dummy filename (any filename will do!) followed by the extension that you want E2B to use. Whatever extension is specified in this first dummy parameter will be used to run the .iso file that is specified in the second parameter. So in this case, the Hirens .iso file will be run by E2B as if it had a .isowinvh file extension.

In the example above, the hirens iso file and .mnu file would be present in the \_ISO\UTILITIES\Utility folder or \_ISO\MAINMENU\Utility folder  (i.e. at the \_ISO\xxxx\Utility level).

E2B v1.07Beta 4 now available - BUGFIX!

bugfix for v 1.00 and all later versions - %MFOLDER% was set to ()/_ISO/xxx instead of /_ISO/xxx by AUTOMN.g4b. This meant that some sample .mnu files that used (bd)%MFOLDER% did not work and you needed to remove the (bd) portion to get them to work.
Beta4 fixes AUTOMN.g4b so that MFOLDER is now /_ISO/xxxx  as it was in most previous Beta versions.
If you are having problems getting the sample .mnu files to work, try this new version!
See Easy2Boot V1 Tutorial 72a  (bottom of page) for the download.

E2B v1.07Beta3 now available

If you add the line
set ISOASK=1
to your \_ISO\MyE2B.cfg file, then any ISO file listed in the E2B menus will run as if the extension was .isoask  (i.e. it will run the .iso and ask you to choose a way to run it).
This means if you have a Zalman CD/DVD  USB HDD caddy, you do not have to have duplicate copies of all the iso files (e.g. have hirens.isowinvH for E2B and hirens.iso for the Zalman). All your files can be .iso but when running E2B, it will ask you how to run them.

Easy2Boot 1.07 Beta 2 now available

This has enhanced WinPE2/3/4 ISO support.

If you place a file that is the same filename as the ISO in the same folder as the WinPE ISO, e.g.

\_ISO\MAINMENU\WinPEx86ABC.isoPE

\_ISO\MAINMENU\WinPEx86ABC.cmd

WinPEx86ABC.cmd
===============
set ISOLETTER=S:

then if no <isoname>.cmd file exists then Y: is used, otherwise the letter set in your .cmd file is used. If Y: is already used then the next free letter will be used to mount the WinPE ISO.

Now .cmd files as well as .mnu and .txt files will not be listed in the menu.

This version also supports the .isoPE01  extension. This has the same function as .isoPE but swaps hd0 and hd1 over before booting to the ISO. This may be useful for some repair ISOs that expect hd0 to be the primary internal system disk.

Beta2a has minor change to add double-quotes around the iso filename when ImDisk is called to load the ISO - this should (may) allow filenames with spaces in them to work (e.g. SVR2012).

Easy2Boot v1.07Beta now available

This version recognises iso's with a .isoPE extension.

This can be used with Vista/7/8 WinPE ISOs. If the extension is .isoPE then when WinPE runs and wpeinit starts, the .ISOPE file will be automatically loaded in WinPE as a virtual CD/DVD drive.
This means that once the WinPE is fully loaded, it will have access to all the files in the ISO as a virtual CD/DVD drive.
Note that this only works if you use an E2B USB flash drive, or use an E2H USB HDD + USB 'Helper' Flash drive, as the \unattend.xml file is required to be on a 'removable' USB drive for this to work.

This version is available from the downloads section of the E2B Tutorial here.

There have also been some minor changes to the LOADISOxx.cmd files used for Vista/7/8 install ISOs but hopefully this should not affect their function at all.

Easy2Boot v1.06

If you update your current E2B USB drive, it will make quite a few changes and you will need to delete some files from your existing E2B USB drive - otherwise you may get duplicate entries in the menu!

The big change in this version is that ALL files are sorted alphabetically. In previous versions you could either have all .mnu files listed in the menu first and then all payload (e.g. .iso) files OR all payload files first and then all .mnu files.

With version 1.06  .mnu and payload files are enumerated in one go, so the menu will list entries according to the files alphanumeric order. This means you can arrange the menu better (just sort the files by name in Windows Explorer to see what order they will be in). It also means that the boot is quicker as the whole \_ISO folder is only enumerated once instead of twice.

I have had to re-organise some files in the \_ISO\Mainmenu folder.  Mainmenu.mnu is gone and so are the SubMenuxxx.mnu files. Instead we have some ZZxxxxx.mnu files. Obviously these will be listed last in the main menu.

Although all menu entries will now be listed in the menu according to their filename, it is important to realise two things:

1. If a .txt file is specified for a payload file, or a .mnu file is found, then the actual text that appears in the menu is that contained in the file.
e.g.
a.mnu   (contains 'title X files')
z.iso  
z.txt     (contains 'title Runs z.iso')

then the menu will look like this

X files
Runs z.iso

2. Files in sub-folders will be listed alphabetically as each folder name is discovered. This means that a .mnu file entry from a file at \_ISO\MAINMENU\A\Zlot.mnu will appear in the main menu before a payload file at \_ISO\MAINMENU\backup.iso.



If you want to try the new version, you can download it here.

I recommend you make a new USB E2B drive and re-copy your payload files onto the drive.

If you want to just update your current E2B drive then you will need to delete the following files:

All \_ISO\MAINMENU\SubMenuxxxxx.mnu files
\_ISO\MAINMENU\mainmenu.mnu
\_ISO\e2b\grub\adf2mm.g4b (no longer required)

Note that you can now control the position of each individual menu entry (except F9 and F10 which will always be last in the menu) by renaming the payload and .mnu files.

Files in \_ISO\MAINMENU folder
=========================
ZZSubMenuAntiVirus.mnu
ZZSubMenuAuto.mnu
ZZSubMenuBackup.mnu
ZZSubMenuDos.mnu
ZZSubMenuLinux.mnu
ZZSubMenuUtilities.mnu
ZZSubMenuWinPE.mnu
ZZWindowsInstall.mnu

ZZZF7BootHdd.mnu
ZZZF8ReloadMenu.mnu

If you want the sub-menu entries for the sub-folders to be listed first in the main menu, just add $ in front of the first 8 ZZxxxx.mnu files.

Note that ZZZF7BootHdd.mnu and ZZZF8ReloadMenu.mnu must not be deleted and must be alphabetically last so that the F9 and F10 entries, which are automatically added to the end of the menu by E2B, will be listed in order and look nice!

Please add a comment if you have tried this and give me your feedback!

Easy2Boot v1.05

This version has a few minor changes:

1. Some more sample .mnu files added to the docs folder
2. A new 'Jolene' menu theme added to docs folder (see below) For Star Trek fans!
3. Ability to suppress the E2B file enumeration messages by setting a new grub4dos variable in your MyE2B.cfg file.

set redir=> nul

If you also want to suppress the E2B progress messages (not recommended as they may be useful on systems with bad BIOSes) then add this line:

set redirp=> nul

See the \_ISO\Sample_MyE2B.cfg file (end) for an example of these two lines (note there is a space between the > and nul).

New 'Jolene' sample background and borderless menu (also redir is also set, so silent file enumeration is enabled).