Monday 7 October 2013

RMPrepUSB and FastFlashTest versions updated

Just a quick note to say that RMPrepUSB has been updated to v2.1.714 and FFT to v1.0.8.

RMPrepUSB 2.1.714 now uses 7zG, the windows GUI version to extract files after the drive has been formatted instead of the console version 7z.exe. Also the 'Make ISO from grub4dos USB drive - Ctrl+M' function has been improved so that the ISO made from a WinPE USB drive will now boot correctly if your USB drive contains \boot\BCD or a boot.wim file (auto detected). You can also add the oscdimg.exe file to the RMPrepUSB\QEMU folder and the Ctrl+M function will automatically use oscdimg to make the ISO file instead of using mkisofs. For instance, if you have a bootable WinPE (Win7/8) USB drive that uses the grub4dos bootmanager to load it, the Ctrl-M function will now make a bootable ISO from it.

FFT 1.0.8 - Quick Test is now even faster at testing fake flash devices (my 'Fake' 16GB now tests in only 27 secs instead of 46 secs for v1.0.7, a good 8GB USB pen now takes 6 minutes instead of 9 minutes).

Saturday 5 October 2013

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!







Friday 4 October 2013

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.



Wednesday 2 October 2013

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!




Watch my YouTube video

Why should I use FakeFlashTest?

Saturday 28 September 2013

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 ;-)



Thursday 26 September 2013

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+ 

Wednesday 25 September 2013

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.