Adding ESET SysRescue (WinPE-based 2013) ISO to Easy2Boot

Kart3 on reboot.pro recently asked how to boot the ESET System Rescue ISO on an Easy2Boot drive as it BSOD's.

Note: eset-sysrescue.1.0.9.0.enu.iso will 'just work' as an ISO file on E2B as it is based on linux!

On investigation, I found that the ISO contained a WinPE 'flat file' boot folder structure. So I could have suggested that he extracted all the files to the E2B USB drive and then just used a grub4dos entry to chainload bootmgr after using EasyBCD to change the \boot\BCD file so it boots from the USB drive. But this would mean we could only have one 'windows' flat-file installation on the E2B USB drive. It is far more preferable to boot from an ISO...

Vista/7/8 WinPE (not XP WinPE) usually boots in one of two ways (see here for more details):

Flat File Boot - This is the same way as a normal Windows Vista/7/8 system boots. There is the BCD which is loaded by bootmgr and the BCD points to C:\Windows\System32\Winload.exe and a source Drive of C: . All the files and folders (e.g. \Windows, \Program Files, \Users, \ProgramData, \Boot) are present.

Ramdisk Boot - This is typical of the way a Win7 Install ISO boots and many WinPE implementations. There is a BCD on the DVD which is loaded by bootmgr and the BCD points to \windows\system32\boot\winload.exe and the boot device is [boot]\sources\boot.wim. Notice that there is no drive letter specified in the BCD, the 'source' device is the boot device and the 'id' is just {default} and not a specific drive letter or partition. This means the BCD can be used with any boot device (there are also {7619dcc8-fafe-11d9-b411-000476eba25f} 'ramdisk' entries in the BCD).

BCD entry for a ramdisk version of WinPE:
Windows Boot Manager
--------------------
identifier              {bootmgr}
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {default}
displayorder            {default}
toolsdisplayorder       {memdiag}
timeout                 30

Windows Boot Loader
-------------------
identifier              {default}
device                  ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
path                    \windows\system32\boot\winload.exe
description             Windows Setup
locale                  en-US
inherit                 {bootloadersettings}
osdevice                ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
systemroot              \windows
detecthal               Yes
winpe                   Yes
ems                     Yes

The OS files are actually in \sources\boot.wim. A ramdisk is made by bootmgr and the contents of the boot.wim is copied into the ramdisk. The rest of the OS is then booted from the files on the ramdisk. This makes for faster operation.

'Flat File WinPE' is typically used in situations where they is less than 512MB of memory in the computer. 'Ramdisk WinPE' requires a ramdisk to be made in memory and the contents of the boot.wim file are expanded into the ramdisk. Consequently we need  enough space for this and free memory for the OS to use.

So one way to get the System Rescue ISO to work would be to convert it to a ramdisk ISO. These can be booted directly from an ISO file.

After a little effort, I wrote Tutorial 115 which describes how I went about it. The steps are basically:

1. Take an existing working 'ramdisk' based WinPE ISO
2. Make a new boot.wim from the ESET SysRescue ISO files
3. Replace the boot.wim in the WinPE ISO with the SysRescue boot.wim file.

However, not everyone will have a Vista/7/8 WinPE ISO laying around, so I wrote the tutorial so that it could be adapted by most people.

I decided not to provide instructions on how to create a ramdisk-bootable BCD from scratch as this relied on using bcdedit which could be dangerous (you could find that your system no longer booted the next day due to a corrupt BCD) and was also complicated (though I could have scripted it to make it easier). It was easiest just to 'borrow' the BCD from an existing WinPE ISO.
I wanted to avoid having to download and install the WAIK too, so I have shown how to download just the parts of the WAIK needed, by using JFX's GetWaikTools utility (Tutorial 83).

The end result is an ISO that we can now add to Easy2Boot (or any multiboot solution).

Since some other 'rescue' ISOs use WinPE Flat File booting (so they can be used on low-ram systems), this conversion process may prove useful for them too!

FakeFashTest updated

I found some bugs in the early versions FakeFlashTest when using the Test Empty Space test and testing large drives.
Please check you have the latest version now or it may report false fails!

V 1.0.7 has been tested on a good 76GB drive and works.
V .1.0.8 is even faster!



FAKEFLASHTEST v1.0.7  [SSi]

Warning: Testing 76297MB out of reported drive size of 76317MB
Writing 381 x 200MB files...
00:00:00 Writing H:\FAKETEST1.tmp
00:00:05 Writing H:\FAKETEST2.tmp, 00:24:45 remaining
00:00:10 Writing H:\FAKETEST3.tmp, 00:31:43 remaining
00:00:15 Writing H:\FAKETEST4.tmp, 00:35:10 remaining
00:00:19 Writing H:\FAKETEST5.tmp, 00:35:31 remaining
00:00:24 Writing H:\FAKETEST6.tmp, 00:37:08 remaining
00:00:29 Writing H:\FAKETEST7.tmp, 00:38:16 remaining
00:00:33 Writing H:\FAKETEST8.tmp, 00:38:03 remaining
00:00:38 Writing H:\FAKETEST9.tmp, 00:38:47 remaining
00:00:43 Writing H:\FAKETEST10.tmp, 00:39:21 remaining
00:00:48 Writing H:\FAKETEST11.tmp, 00:39:49 remaining
00:00:52 Writing H:\FAKETEST12.tmp, 00:39:29 remaining
00:00:57 Writing H:\FAKETEST13.tmp, 00:39:50 remaining
00:01:02 Writing H:\FAKETEST14.tmp, 00:40:08 remaining
00:01:07 Writing H:\FAKETEST15.tmp, 00:40:22 remaining  Checking... OK
00:02:22 Writing H:\FAKETEST16.tmp, 01:16:07 remaining
00:02:27 Writing H:\FAKETEST17.tmp, 01:14:06 remaining
00:02:32 Writing H:\FAKETEST18.tmp, 01:12:18 remaining
00:02:37 Writing H:\FAKETEST19.tmp, 01:10:41 remaining
00:02:42 Writing H:\FAKETEST20.tmp, 01:09:13 remaining
00:02:47 Writing H:\FAKETEST21.tmp, 01:07:53 remaining
00:02:52 Writing H:\FAKETEST22.tmp, 01:06:40 remaining
00:02:57 Writing H:\FAKETEST23.tmp, 01:05:32 remaining
00:03:02 Writing H:\FAKETEST24.tmp, 01:04:30 remaining
00:03:07 Writing H:\FAKETEST25.tmp, 01:03:33 remaining  Checking... OK
00:04:02 Writing H:\FAKETEST26.tmp, 01:17:26 remaining
00:04:07 Writing H:\FAKETEST27.tmp, 01:16:00 remaining
00:04:12 Writing H:\FAKETEST28.tmp, 01:14:40 remaining
00:04:17 Writing H:\FAKETEST29.tmp, 01:13:25 remaining
00:04:23 Writing H:\FAKETEST30.tmp, 01:12:30 remaining
00:04:28 Writing H:\FAKETEST31.tmp, 01:11:24 remaining
00:04:33 Writing H:\FAKETEST32.tmp, 01:10:21 remaining
00:04:38 Writing H:\FAKETEST33.tmp, 01:09:22 remaining
00:04:43 Writing H:\FAKETEST34.tmp, 01:08:25 remaining
00:04:49 Writing H:\FAKETEST35.tmp, 01:07:46 remaining
00:04:54 Writing H:\FAKETEST36.tmp, 01:06:55 remaining
00:04:59 Writing H:\FAKETEST37.tmp, 01:06:06 remaining
00:05:05 Writing H:\FAKETEST38.tmp, 01:05:32 remaining
00:05:10 Writing H:\FAKETEST39.tmp, 01:04:48 remaining
00:05:15 Writing H:\FAKETEST40.tmp, 01:04:06 remaining
00:05:21 Writing H:\FAKETEST41.tmp, 01:03:36 remaining
00:05:26 Writing H:\FAKETEST42.tmp, 01:02:57 remaining
00:05:32 Writing H:\FAKETEST43.tmp, 01:02:30 remaining
00:05:37 Writing H:\FAKETEST44.tmp, 01:01:54 remaining
00:05:43 Writing H:\FAKETEST45.tmp, 01:01:29 remaining  Checking... OK
00:07:33 Writing H:\FAKETEST46.tmp, 01:17:30 remaining
(some text deleted!)
00:11:14 Writing H:\FAKETEST82.tmp, 01:00:02 remaining
00:11:21 Writing H:\FAKETEST83.tmp, 00:59:47 remaining
00:11:28 Writing H:\FAKETEST84.tmp, 00:59:33 remaining
00:11:35 Writing H:\FAKETEST85.tmp, 00:59:19 remaining  Checking... OK
00:19:30 Writing H:\FAKETEST86.tmp, 01:35:41 remaining
00:19:36 Writing H:\FAKETEST87.tmp, 01:34:51 remaining
(lots of text deleted!)
00:50:18 Writing H:\FAKETEST376.tmp, 00:17:40 remaining
00:50:27 Writing H:\FAKETEST377.tmp, 00:17:32 remaining
00:50:36 Writing H:\FAKETEST378.tmp, 00:17:24 remaining
00:50:45 Writing H:\FAKETEST379.tmp, 00:17:16 remaining
00:50:50 Writing H:\FAKETEST380.tmp, 00:17:07 remaining
00:50:55 Writing H:\FAKETEST381.tmp, 00:16:58 remaining
Writing last file (97.56MB)
00:51:01 Writing H:\FAKETEST382.tmp, 00:17:00 remaining
Verifying 381 files...
Verifying file 382...
-----------------------
TEST FINISHED
76298MB of filespace was tested.
Total Time = 01:30:03

PASSED: 76298MB tested and OK.

Deleting test files - please wait... Finished.
Note: 76298MB out of 76317MB were tested.
The unused file space on this drive volume seems good, however to ensure the memory is not faulty, I recommend you run the Quick Size Test.

A faster test for 'fake' SD cards and USB Flash drives!

Please note: FAKEFLASHTEST.EXE and RMPREPUSB.EXE DO NOT CONTAIN ANY VIRUSES,
even if Windows Defender tells you they are unsafe!

RMPrepUSB tutorial on Fake Flash devices

Download Windows fast FakeFlashTest.exe

Watch my YouTube video

Why should I use FakeFlashTest?

RMPrepUSB and E2B updated

RMPrepUSB v2.1.713 - change for Config Set feature and auto-ext2 volume creation.
E2B v1.11 - bugfix - Autounattend.xml and Unattend.xml should have been cleared on booting but there was a typo in the menu.lst (probably for last 6 or so versions!). This means that you may have found your PE ISOs mysteriously loading the ISO as a virtual drive once they had finished booting!

Download link for zip file for E2Bv1.11+DPMS2 Mass Storage drivers is now fixed - please try again if all you got was aac.cat a few hours ago! I use DropBox to provide direct downloads of larger files because 30MB is too large for Google Sites.

P.S. If you don't use DropBox I recommend it. Just keep any important files that you would hate to lose if you had a disk crash or a fire, in a DropBox folder on your hard drive. I keep my development folders in a DropBox folder, that way if the program crashes and corrupts my source files (which has happened!) I still have the older versions stored on the DropBox Server. It is also great to be at work or a friend's house and log onto DropBox and get access to all my files without having to remember to copy them to 'cloud storage' first before I left! Use this link to register with DropBox (free!) and get an extra 250MB of storage.

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!