New Easy2Boot Forum

I have added a primitive User Forum to the Easy2Boot site.
E2B users can use this to ask for help from other E2B users or offer hints and tips, etc.

No login is required. Any 'inappropriate' posts will be removed without mercy! Please use it responsibly or I will remove the whole User Forum.

P.S. Checkout Frettts-Freeware for lists and descriptions of free software.



Please tick 'funny' 'interesting' or 'cool' or add a comment to let me know which posts you most enjoy.

How to boot Ubuntu via UEFI with persistence from Easy2Boot

You can fully-install many linux distros to a .imgPTN file (see blog post here), however I was asked recently how to boot Ubuntu 14.04 64-bit from an Easy2Boot USB HDD when using partition image files (.imgPTN files) so that you can UEFI boot with persistence.

Note: 14.04 and many later versions of Ubuntu (and linuxmate based on Ubuntu) have a bug! They do not fully boot and give an initramfs error if you use a casper-rw partition. It works OK with a casper-rw file, but not a partition. Sometimes it may work if the ext partition is located after the FAT32 partition - but this depends on the order of the two files (xxxx.imgPTN and xxxx.) so using a casper-rw partition cannot be guaranteed to always work! See later bog post here.

Easy2Boot 1.42 - now no need to defrag ISO files (sort of)

As I am sure you know, Easy2Boot uses a grub4dos feature which can map an ISO to a partition table so that when linux boots, it sees the partition table as a valid filesystem and thus linux can mount the 'ISO file' and be able to access the files inside it.

This feature uses the partnew command in grub4dos and the partnew command can only map a file as a partition if the file is contiguous (and exists on the same physical drive).

I have added a new feature to E2B v1.42 which will check to see if the ISO file is contiguous and if not, it will copy the contents of the whole ISO file using dd into a pre-existing CONTIG.ISO dummy file which is already contiguous (maximum size 3.999GB).

Note: v1.52+ now has a 500MB CONTIG.ISO file in the download.

To use the new feature, just download and update your existing E2B USB drive with the Easy2Boot_v1.42.zip file contents (available in the Google Drive Alternate Download area here).

The pre-existing file must now be created by you. It must be called \_ISO\CONTIG.ISO and needs to be as big as your largest ISO file (it must NOT exceed 3.99GB due to an issue with grub4dos). To make it, just copy your largest ISO file to the E2B USB \_ISO folder and rename it CONTIG.ISO. Alternatively, you can use the RMPrepUSB - Create Ext2 FS button to make a large empty file and then move and rename that file (it doesn't matter what the contents are inside the file). Once it is made, you must make sure it is contiguous (e.g. by using RMPrepUSB - Ctrl+F2 or DeFraggler, etc.).

Once you have made the CONTIG.ISO file contiguous, you can add your ISO payload files and you won't need to defragment them each time (though it will be much faster if you do!).

This new feature does NOT work for .imgPTN files or Windows Install ISOs and won't work for any .mnu files which use partnew such as linux+persistence menu files.

For ISO files, here are some timings for E2B to copy an entire ISO file to the CONTIG.ISO file using dd - I was using a Pretec USB 3.0 Removable-type Flash drive (write speed approx 17MB/s):

1. EeePC - USB 2.0 port - 25 seconds for 100MB ISO (104 seconds for 390MB ISO)
2. EeePC - USB 2.0 port - using the grub4dos 0.4.6a USB 2.0 driver - 6 seconds for 100MB ISO (23 seconds for 390MB ISO)

As you can see, if you use the grub4dos 46a driver, the time is largely dependent upon the write speed of the USB drive (or approx. 30MB/s for USB 2.0 if the media write speed is faster than 30MB/s).

Therefore, if you have a large ISO which is fragmented, it is probably quicker to first select grub4dos 0.4.6a from the main E2B menu and then select the grub4dos USB 2.0 Driver menu option to load the grub4dos driver first as it seems MUCH faster than the (Asus EeePC) BIOS USB 2.0 driver.

Larger files will obviously take several minutes to copy even if using the grub4dos USB driver. However, at least you can boot a fragmented file if you forgot to make it contiguous first! A USB 3.0 HDD will be faster, a USB 2.0 cheap flash drive will be slower.

If CONTIG.ISO is not present, then it will just behave as before (and warn you that the ISO is not contiguous).

As this change is very new (and I may have broken something - though I have tested it), I have not updated the links on the Easy2Boot download page yet. Please let me know if it works for you (or not)!
Note: a 500Mb CONTIG>ISO is now included in the E2B download zip file as standard!

Tip: To boot to grub4dos 0.4.6a automatically, copy the file from \_ISO\e2b\grub\grldr_046 to the root of the E2B drive and rename it to grldr to replace the 0.4.5c version of grldr - AND/OR - add a \_ISO\MyE2B.cfg file by copying the Sample_MyE2B.cfg file and uncomment the line 'set GRUB_USB=Y' to automatically load the 0.4.6a USB driver when E2B loads.

Please tick 'funny' 'interesting' or 'cool' or add a comment to let me know which posts you most enjoy.

RMPrepUSB v2.1.722 available

Pressing Ctrl+F2 was too much effort to run WinContig each time I added a file to my USB drive, so now I can just right-click on the drive in the RMPrepUSB Drive listbox to run WinContig immediately, or right-click on the Refresh button to run WinContig on the currently selected drive.

I have also updated the versions of WinContig and HashMyFiles.

The new version is here.

Increase the speed of your SD card or Flash drive by up to 10%

Just in case didn't know, if you format your SD card or Flash drive as FAT32  (which is used by many SD cards in cameras), then by formatting it using RMPrepUSB you can increase the write performance by up to about 10%.

This speed increase can only be measured when writing files - many benchmark tests will not show any increase in write speed because they do not write files when they run their tests. However, in real life, we write files to these devices and the files are written in groups of sectors called clusters to the FAT32 filesystem on the drive.

When you format a drive as FAT32 using RMPrepUSB, the clusters are aligned to start on a 1MB boundary. This is important for flash memory because in order to write sectors, a whole page of flash memory has to be erased first. RMPrepUSB ensures these 'erase-pages' are correctly aligned with the clusters to minimise the number of erase cycles that are required. This also has the side-affect of extending the life of your flash memory as it reduces the number of  read-erase-write cycles over it's lifetime.

If you want to read a discussion on reboot.pro about this, click here. The theory for how this works is explained in this post.

So if file-write speed is an issue for you (e.g. the delay after you press the camera button to take a picture or interval between a series of pictures, or when you copy lots of files to a FAT32 USB drive) try formatting the media with RMPrepUSB next time!

Since I 'discovered' this and added this enhancement to RMPrepUSB, it has been copied by a few other people/utilities. For instance, I believe BootIce now uses the same technique now too.



Please tick 'funny' 'interesting' or 'cool' or add a comment to let me know which posts you most enjoy.

Add MobaLiveCD.exe to your Easy2Boot USB drive

If you have RMPrepUSB or VirtualBox+DavidB's VMUB utility on a Windows system, you can boot from an E2B USB drive under a virtual machine and 'swap in' any image partition file you wish, so that you can pre-select it before you boot from that same E2B USB drive on a different 'target' system.

MobaLiveCD.exe (1.5MB) is a 'shrink-wrapped' version of QEMU and so will also allow you to boot your E2B USB drive via QEMU (similar to RMPrepUSB's QEMU F11 button in RMPrepUSB). The difference is that MobaLiveCD is designed to be portable and does not need to be installed on a Windows system first. Just copy the .exe file to your E2B USB drive and it is ready to use if you are away from your Windows system or don't have access to a VM (e.g. off-site or at a friends house).

For instance, you may have a server that has a UEFI OS pre-installed and the BIOS is in UEFI mode. You want to UEFI-boot the server from the E2B USB drive but in order to select the correct UEFI-bootable image (say MSDaRT or maybe an HP Utility) you need to boot E2B in MBR\CSM mode first. If you have MobaLiveCD.exe on the E2B USB drive, then there is no need to download and install RMPrepUSB (or QEMU manager or Virtual Box) onto a system...

1. Insert the E2B USB drive into any Windows system's USB port
2. Run MobaLiveCD.exe as Administrator directly from the E2B USB drive
3. Choose the 'Start directly from a bootable USB drive' option
4. Pick the USB drive's drive-letter
5. Say 'No' to the 'Do you want to create a hard disk image for your virtual machine?' question and allow it to boot to the E2B menu.
6. Pick the partition image file from the E2B menu and 'swap in' the new partition
7. Quit QEMU and MobaLiveCD - your E2B USB drive is now  ready for direct UEFI booting

You can also directly boot using MobaLiveCD from an ISO file (32-bit ISOs only).

Note: As an alternative, you can unzip the BOOT_ME_USING_QEMU.zip file from the Alternate Downloads Area to your E2B USB drive and then double-click on the BootUSB.cmd file to boot from the USB drive under QEMU. This should only be used for select .imgPTN files however as it does not create a virtual hard disk, does not lock the drive like RMPrepUSB does and uses a fixed memory size of 500MB.


Please tick 'funny' 'interesting' or 'cool' or add a comment to let me know which posts you most enjoy.

Microsoft is giving away Windows 8.1 for free!

Yes - that's right free! There were rumours that the price was going to drop significantly.

According to this article and recent reports in the Press, Microsoft will be giving device manufacturers 'Windows 8.1 with Bing' for free (sorry - not free for the general public!). I am guessing this will mostly apply to small device manufacturers producing tablets and phablets ('Windows Phones and tablets smaller than 9-inches in screen size'). I am also assuming that the OS will still be locked to the device by a Product Key embedded in the device's non-volatile RAM (usually an EEROM) and so will be pretty much identical to the normal Windows 8.1 core version.

So has Microsoft gone mad? Is android/iOS/ARM such a threat to it? My take is 'No - they haven't gone mad' and 'Yes - android/iOS is a threat'. See here for current usage (and compare with Desktop OS's).

There is a clue to the real reason (I think) in the link I provided above, namely:

'Additionally, as reach expands, the opportunity for developers and their apps also increases.'

This can be interpreted as 'Windows apps and the App Store just hasn't taken off - now maybe it will!'

The problem is one of momentum - if you were an mobile app developer, what platform would you choose to produce your first and seconds versions of  your new app? Not Windows, I am guessing! The reason is that there just aren't enough devices out there. Well, if Microsoft's gamble pays off, now there could be!

Money!

But with MS it's all about money - so how are they going to make money? The answer is hidden in that sentence about developers and apps.

MS make money on every app sold. They also want to make money from selling Office 365 subscriptions (and Office). The more people that have a Windows device, the more 'opportunity' there is to sell apps and Office. Once Windows 8.1 gains a foothold, they can always start charging OEMs for Windows 9!

OEMs

But why should an OEM (device manufacturer) choose Windows 8? Well, there are a few reasons:

1. It is now cost free
2. The OEM will get a cut from any apps that they choose to pre-install on each device (and possibly from any future apps bought by the end user via the App Store?)
3. The product may attract new business customers who value Windows\Office compatibility

But there are some downsides too:

1. For any current non-Windows OEM, the 'factory systems infrastructure' required to install Windows 8 and have it ready to be activated by the end user may be a cost barrier (the Product Key presumably needs to be embedded in the device which implies BIOS modifications and factory programming on an individual device level which presents a barrier for easy mass-production).
2. There is still a minimum specification for memory, storage, CPU speed/type and CPU power requirements which may prove challenging for a low-cost device manufacturer.
3. Would a 'Windows' customer really choose to buy a sub-£100 device with limited memory and storage?
4. Smaller variety and lower-quality Apps on Windows platform (MS hope this will change!)

Will it work?

If the 'free' offer applies to a wide range of devices, not only low-cost ones but all 'portable' devices, then I think it will work - but maybe not as much as MS hope. In the short term this may also harm MS's profits because their current OEMs that are already producing Windows devices will be switching to the new 'Windows 8.1 with Bing' OS pretty quickly and saving themselves a few $ in the process.

An increase in sales of Windows devices will eventually prompt the other non-Windows device manufacturers to compete and also offer Windows devices. It also means, if you are looking for a Windows device at the moment - I should wait a few months - prices should come down when the 'new' models start to hit the shelves with free Win 8.1. Non-Windows device manufacturers will need to compete with this and so they too should reduce their prices.

Note that before the new 'Windows 8 with Bing' Models start to appear, prices of the current 'Windows 8' stock will be reduced to clear before the new models start to come in. It is up to you whether to be tempted by the reduced price of these models or hold out for the new models (which should have an even lower price).

This move by MS should therefore lead to an increase in sales of x86-compatible CPUs (I am ignoring the RT version here as I think this new 'free' OS will pretty much kill it, if it wasn't already slowly dying) - so maybe time for me to invest in a few Intel shares (currently at time of writing this blog June 2014 - Intel shares = $26)?

Note: Dec 2014 - Intel shares = $36!

Boot partitions and system partitions

The term 'boot' in my mind has always been synonymous with 'bootstrap' - a process where code is pulled up by it's own bootstraps - i.e. loaded in stages, starting with a small piece of code which then loads in a larger piece of code which then loads in an even larger piece of code - etc. etc. until we get to a full Operating System. Many years ago, I used to key in the initial octal bootstrap code using the flip-keys on a PDP 8e, which then read in a bootloader from a paper tape reader which could then read in a programming language (e.g. Algol) which could then read in an Algol program from paper tape which could then read in a whole bunch of data from yet another paper tape and finally number-crunch and draw a nice graph and 'best-fit' curve on a giant pen plotter!

I always find the Microsoft-speak terms 'boot partition' and 'system partition' confusing. Even more so when GPT-partitioned disks came along. The first sector of a bootable hard disk (if an MBR style disk) contains bootstrap code in the Master Boot Record  (note the word 'boot' just appeared twice!) - so surely this is the 'boot partition' not the 'system partition'?

So it made me chuckle to find it in 'black-and-white' that even windows.microsoft.com admits it!

'These terms can be confusing because the system partition actually contains the files used to boot Windows 7, while the boot partition contains the system files.'

Which begs the question - 'if it is so obviously confusing, then why did you choose such stupid 'official' terms in the first place!'

Now bootmgr is what most Windows installations boot to first, and bootmgr is a 'boot manager'; so we have bootstrapped to a 'boot manager' and then the boot manager can load an OS. Therefore the partition containing 'bootstrap' code should be called the 'boot' partition and the partition(s) containing the operating system should be called the Operating System partition(s). 

So how should I refer to these partitions without ambiguity? Maybe I should use the terms 'bootstrap partition' and 'OS partition'? What is your opinion?

Trust MS to totally screw everything up!

E2B v1.41 available (bugfix)

tacovdveer pointed out that sub-folders under \_ISO\AUTO were no longer enumerated due to a bug I accidentally introduced in v1.40!

Now fixed in v1.41. If you are updating, just download the non-DPMS version and overwrite your existing E2B files.

Add Kali linux v1.0.7 + LUKS encrypted persistence to your E2B USB multiboot drive

Kali is the follow on from BackTrack for penetration testing. It provides a full linux development environment as well as pen-test tools. You can add Kali v 1.0.7 ISOs to your E2B USB drive and boot them with a LUKS encrypted persistence volume.

Kolibri - a successor to MenuetOS

A few weeks ago I mentioned MenuetOS in this blog post. This is an entire OS written in assembler which can fit on a 1.44MB floppy disk. This was discontinued in about 2004 but Kalibri is it's much-improved successor.

You can download either the ISO or .img file from here.
Full FAT12/16/32 support is implemented, as well as read-only support for NTFS, ISO9660 and Ext2/3/4. Drivers are written for popular sound, network and graphics cards and USB 1.0 and 2.0.
It has network drivers, text editor, file browsers and a basic text-only web browser. To run under VBox, I had to turn off VTx CPU acceleration, set a Sound Blaster 16 audio adapter and a linux 32-bit system type.
If you need to boot from a system and get a file from a non-GPT disk very quickly and save it to a FAT32 USB drive, this could be really handy!

MPI Tool Pack 035 available

Changes are:

1.  First time you ran the CSM menu you would get a 'syslinux alternative boot' menu entry - now fixed by changing PBR.BIN file which contained the 'SYSLINUX' text string.
2. Added new menu for NTFS+FAT32 dual partitions

If E2B is on a USB hard disk we can use:

• Partition 1 = FAT32  - for clover+E2B files
• Partition 3 = NTFS - for Windows files

When Setup/ WinPE boots, it will be able to access the files on the NTFS partition of the hard disk.

Change #2 allows you to easily make an NTFS partition image from any Windows Vista/7/8 ISO using large install.wim files, and boot to it via Clover in UEFI mode.  This is useful if you have E2B on a Removable USB Flash drive because Windows Setup can only access the first partition on a Removable UFD and so the first partition must be NTFS. Clover needs a FAT32 partition in order to boot, so this is on the 3rd partition.

To make the files you need to:

1. Drag-n-drop the Win7/8 ISO onto the MPI_NTFS Desktop shortcut
2. Drag-n-drop an empty folder onto the MPI_FAT32 shortcut
3. Copy the two files to your E2B USB drive and name the first one with a .imgPTNLBAa file extension and the second one with no file extension (the name should NOT contain a dot) using the same file name for both files - e.g.

\_ISO\MAINMENU\Win81_x64.imgPTNLBAa   - NTFS Windows Install image + MPI+Clover
\_ISO\MAINMENU\Win81_x64                          - blank image containing just MPI+Clover

When loaded by E2B you will have:

• Partition 1 = NTFS = Windows Install files and MPI+Clover files
• Partition 3 = FAT32 = MPI+Clover files

It will NOT be able to boot via the UEFI system firmware because the first partition is not FAT32, however it will boot to the grub4dos CSM menu and you can then boot via Clover (which will load from the FAT32 partition as it cannot 'boot' from an NTFS partition) to the \efi\boot\bootx64.efi Windows UEFI boot file and then install Windows in UEFI mode.

This method is very easy to set up as you don't have to swap files around between the two partitions or split the install.wim file if it is larger than 4GB. The downside is that Clover may not run on all hardware (as it is a 'replacement' UEFI BIOS and is quite hardware dependent) - in which case you cannot boot it via the UEFI system firmware.

I have outlined the 4 methods of adding large-file UEFI-bootable Windows installer images here. The most reliable\versatile method is Method 1 where we use a single FAT32 partition and split the install.wim into .swm files (if required).

Run OpenElec XBMC 2014 Live from Easy2Boot

I have updated the instructions in my previous blog with instructions for the new 2014 4.0.2 version of OpenElec XBox Media Centre. This can be booted directly from your E2B multiboot USB drive>

I tested it by booting from my Z87 system from a USB 3.0 port and video, internet and audio worked fine (I had to change the Audio device setting first though).

Please see the second part of the blog for 2014 version here for details.

P.S. The latest build from here worked under VBox when booting from Easy2Boot. I actually used OpenELEC-Virtual.i386-devel-20140317134709-r17946-gb27c946.tar. The x64 version runs better than the i386 version under VBox - enable 64-bit and configure multiple CPUs (no video stutter) with Video acceleration for best performance.

To watch Live TV programs such as BBC1/2 and other freeview channels, add TVCatchup. Download the repository zip file to the E2B USB drive and then boot XBMC and load it into XBMC - follow the instructions here. Using this and the VM x64 version of OpenElec, I am able to watch live TV having booted from my E2B USB drive under VBox with no stutter/lag!

MPI Tool Pack 034 - HP Utility ISOs now supported

There were a few issues with HP Utility ISOs and MPI.

First, it seems that even though I install syslinux into the PBR using the correct 3.75 version of syslinux, it will not boot the HP files and you get a 'boot:' message. The ONLY way I could get the files to boot correctly using v3.75 was to install syslinux to use -fm which installs to the MBR and the files had to be in the root of the drive. So instead I have used syslinux 4 and removed the troublesome hpbootxx.c32 module.

More details on reboot.pro here.

The second problem was that EFI booting did not work because it had some .cfg files which referenced \system and the boot files were moved by MPI to \syslinux.

These (hopefully) have now been fixed by keeping the \system folder where it is, using syslinux 4 and changing the syslinux.cfg file to remove hpbootxxx.c32.

I tested with SPP2014020B.2014_0421.2.iso (MBR and UEFI boot) and hpacuoffline-8.75-12.0.iso and both seem to work now when converting straight from an ISO to a FAT32 partition image using the AUTO FAT32 shortcut (although I don't have any HP kit to fully test it on!).

YouTube video here.

MPI Tool Pack 033 - Clover now works on Z87 Haswell systems

I changed the Clover config.plist file and now Clover boots on my Asus Z87 Haswell system. MPI Tool Pack v.033 is now updated with this new config file. The old one is called config.plist.ASUS in case you need it for older Asus systems..

The only change I made was to change:
<key>KernelAndKextPatches</key>
<dict>
<key>AppleRTC</key>
<true/>
<key>AsusAICPUPM</key>
<true/>
<key>Debug</key>

to

<key>KernelAndKextPatches</key>
<dict>
<key>AppleRTC</key>
<true/>
<key>AsusAICPUPM</key>
<false/>
<key>Debug</key>

This disables the patch for 'AppleIntelCPUPowerManagament.kext for ASUS Native PM'.
P.S.
I also found that adding
<key>KernelPm</key>
<true/>
to the old config.plist in the same section also worked. KernelPm is 'Kernel Power management'. As this sounded like it might affect other non-Asus systems, I chose to not use this patch.

MPI Tool Pack 032 allows Clover and syslinux

Previous versions would not allow you to boot to Clover (and then UEFI boot from Clover) if syslinux was present in the Partition Boot Record (PBR). This meant that you couldn't use Clover to directly UEFI-boot to linux. This restriction has now been fixed. You can now boot linux distros using Clover as well as other non-linux (syslinux) payloads.

MPI Tool Pack 032

My PC's Samsung 932GW monitor didn't work this morning!

It started off just as any other normal morning. Last night I switched off my new home-built Win 8.1 PC with dual (Dell+Samsung) monitors as usual, then went to bed as usual, and slept well (not always as usual!). This morning I switched on both monitors, the external speakers and then my PC as usual. When I came back from making a cup of Earl Grey tea (we drink tea in the morning, here in the UK!), there was no display on the Samsung 932GW display (connected via DVI-D) or the Dell monitor (connected to the VGA cable).

After a few panicky moments, I realised that just the Samsung monitor was not working. Even if I disconnected the DVI cable, there was no 'No monitor detected' floating message box like there usually is when the cable drops off! If I switched it off and then on again, I saw an on-screen pop-up box for about a second and then it all went black again.

On further inspection, when I connected it to the DVI cable and PC, I could just see a very faint image of the Windows login background, especially if I used a torch, shone at an angle to the screen.

At this point it looked like the backlight to the display was on the blink/fritz (technical terms for cream-crackered!). Since the backlight did come on for about 1 second immediately on first switch-on, it looked like the high-voltage CCFL inverter was the problem, rather than the high-voltage CCFL bulb(s).

I Googled for 'samsung 932GW backlight' and it led me to some discussion forums about 'bad capacitors'. I also found some 'Capacitor kits' being sold on Amazon.com for this exact model of monitor.

As a computer\electronics engineer, I am very familiar with this issue. As well as seeing bad capacitors on mainboards whilst working for RM, I have seen them in other products too. For instance, over the last 10 years or so I have bought 3 different D-Link routers. All three of them started to play up after a year or so. One seemed to work fine until my ADSL supplier upgraded my line for higher ADSL speeds - after that I kept getting a dropped ADSL connection. I initially blamed my phone company, but when I used an old USB ADSL modem, I had no problem. Sure enough, when I opened up the D-Link ADSL router, there was one large capacitor with a swollen top! I replaced it and the router worked fine from then on. The extra power demand to drive the ADSL line at higher speeds must have been too much for that poor swollen capacitor!

Since companies are selling 'capacitor kits' for this particular Samsung monitor, it leads me to believe that this monitor was built with sub-standard components. This leads to an interesting question. Samsung monitors have a 2 year warranty and mine was out of warranty. However. the Sale of Goods Act states that goods should be of reasonable quality, last for a reasonable time and be free from defect at the time of manufacture. This covers the product for up to 6 years from the time of purchase and is over and above any manufacturers warranty. Since my monitor was about 3 years old and was built with poor-quality capacitors, it could be argued that I am covered by the Sale of Goods act and EEC law to have my monitor fixed or replaced.

Since people are selling 'capacitor repair kits' for this exact model of monitor, surely this is proof that these monitors contained a defect at the time of manufacture? Also 3 years is a reasonable amount of time for a monitor to continue to work. So, I could go to the small claims court and claim against the retailer that I bought it from under the Sale of Goods Act regulations. Read here for more information about this.

In this case however, I just took the monitor apart and looked at the circuit board. You can plainly see that 3 capacitors (circled in yellow) out of the 8 electrolytic capacitors on the board, have tops that are 'buckled'. The tops are deliberately scored when made by the manufacturer, with a cross-cut, so that the tops will split rather than explode when/if the dielectric compound inside breaks down, becomes resistive, gets hot and starts to out-gas.

Electrolytic capacitors should last for many years. I am sure you have old TV sets and other appliances that have lasted for well over 10 years (some for 20+ years like my old Sony Trinitron TV!). So why have these capacitors blown?

The answer appears to be that these are cheap capacitors that are made in either China or Taiwan and the compounds used break down after a few years. In fact it is the power-on-time+heat that destroys the dielectric material, which is why things like monitors and routers suffer the most, rather than washing machines or other appliances that are only used for a few hours a day (most routers are left on 24x7!).

It is a basic rule-of-thumb that for every 10 deg C rise in temperature, the rate of a chemical reaction doubles. This is why manufactures (should) test components at raised temperatures - to increase 'ageing' of the components. Raising the temperature by 30 deg C whilst on, will have the same ageing affect as keeping it running for 8x as long.

Some capacitor manufacturers blame a certain supplier who 'stole a secret recipe' for making the dielectric compound more cheaply than other suppliers and then started to sell the compound as a cheaper alternative. The problem (apparently) was that the recipe they stole was inaccurate\incomplete and the dielectric degraded after a year or so. Other manufacturers copied this recipe too and soon millions of products were built using this compound or near relatives of it (psst.. wanna buy a secret formula?). This caused the infamous capacitor plague (which still seems to be going on even now!). This is why today you may see Power Supply and PC mainboard manufacturers boast that they use Japanese capacitors (rather than Chinese\Taiwanese ones).

One episode is reported to have cost Dell $300m!

Still, I guess every cloud has a silver lining, especially for people selling 'capacitor repair kits', e.g. http://www.badcaps.net.

If you are good with a soldering iron, before throwing away that router or monitor, have a look at the capacitors inside it,  then Google for a 'Capacitor Kit' for it! Follow this link for how to repair a monitor. You can order individual capacitors on eBay (but make sure they are good quality ones from a reputable supplier!). Tip: a pack of 5 capacitors of the same value is often only a few pence more than a pack of one or two.

MPI Tool Pack 031 with Clover now available

I have now added Clover Lite to the MPI Tool Pack v.031. It only adds 1MB.

If you don't want Clover to be added to your images, edit the MakePartImage.cmd files and add
set NOCLOVER=1
to the top of the file
OR make new .cmd files and add this:

e.g. MPI_No_Clover.cmd
set NOCLOVER=1
call MakePartImage.cmd   %*

or even simpler, just delete or rename the CLOVER folder.

v 031 also now includes a CreateDesktopShortcuts.cmd file which runs a vbs script to automatically add three Desktop shortcuts to your Desktop for drag-and-drop operation. The shortcuts will be set up with the Admin box already 'ticked'.

So just:

1. Download the Tool Pack
2. Double-click on CreateDesktopShortcuts.cmd
3. Install ImDisk

and you are good to go.

Drop an ISO file or folder or USB drive icon onto one of the three new Desktop shortcut icons to start the creation of an image partition file. The  FAT32 and NTFS shortcuts usually work with only 0-2 prompts needed (the .imgPTN file is created in the same folder as the Source).

MemTest86 v5.1.0 released by Passmark

Ric alerted me to a new version of Memtest86 now maintained by Passmark. There is a free edition and a Pro edition which has more features.

This will be in the next version of  E2B (with permission from Passmark) when I release it (v1.41). It uses a kernel file and a .mnu file only and so is much smaller than the previous ISO-based version.

The ISO or USB download also supports UEFI booting.

You can also make a .imgPTN partition image file from the ISO, however if you allow MakePartImage to install Syslinux to the Partition Boot Record (PBR), then you cannot boot from it using Clover (it will refuse to run).

I suggest you extract just the \EFI folder to a new folder on your hard disk and run MPI FAT32 AUTO on that folder. The .imgPTN file created will be bootable via Clover (if you added the Clover Pack) on 64-bit systems or you can boot via UEFI Firmware. For normal MBR\CSM booting, you can use the Utilities - Memtest menu entry in Easy2Boot.

This is the UEFI boot screen

P.S. In case you don't know - Passmark make some excellent software and I highly recommend having a look at their main website.

MPI_Clover_Pack_Lite_005 (bugfix)

If you are using two images at the same time, please update to Clover Pack 005 (menu.lst has changed)

There was a problem if using two image files at the same time.

For example:

You can quickly add multiple NTFS image partitions of Windows x64 ISOs   (useful for >4Gb install.wim AIO ISOs) to E2B for UEFI or MBR booting as follows:

1. Create a WINSTUB64 empty folder
2. Use this empty folder as the Source folder to create a FAT32 image partition using MPI  (e.g. WINSTUB64.imgPTN). e.g. drag-and-drop the empty folder onto your MPI AUTO FAT32 shortcut.

Now for each Win7/8 64-bit ISO that you have...

1. Use MPI to create an NTFS image from the ISO - e.g. drag-and-drop the ISO file onto your MPI AUTO NTFS shortcut.

To add these files to your E2B drive

1. Copy the large NTFS image file to \_ISO\MAINMENU (or \_ISO\WIN or \_ISO\AUTO)
2. Remove the file extension - the name must not have a . in it - e.g. change Win8.1.imgPTN to Win8_1
3. Copy the WINSTUB64.imgPTN file to the same E2B folder
4. Change the file name and file extension to .imgPTNLBAa  - e.g. Win8_1.imgPTNLBAa
5. (optional) add a .txt file - e.g. Win8_1.txt with a 'title' entry

e.g.
\_ISO\WIN\Win8_1.imgPTNLBAa      - contains CSM and Clover files
\_ISO\WIN\Win8_1                           - contains image of Win x64 ISO installer
\_ISO\WIN\Win8_1.txt                      - (optional) replacement title

When you boot from the .imgPTNLBAa file to the CSM Menu, it will have a Clover entry and a '3 Boot Windows on 3rd partition (MBR-mode) entry. The '1 BOOT  (MBR mode)' menu entry will not work unless you have also included bootable files in the WINSTUB image.

If you wish, you can edit the \menu.lst file to remove the non-working menu 1 entry by deleting the 20 or so lines below the # --- GENERIC BOOT MENU --- line.

You might also like to change the menu title to whatever is appropriate (e.g. set PAYLOAD=KonBoot and Win8.1 x64 Install).

Instead of the WINSTUB64 file having no payload, you could use any non-Windows Vista/7/8 payload (e.g. Rufus Windows XP flash drive image or KonBoot 2.4). Then the menu  1 BOOT option would boot to Xp install or KonBoot and you could also UEFI-boot to either KonBoot or Win7/8 install via the Clover GUI.

Note that because the Win7/8 install is on an NTFS partition, you cannot boot to it via rebooting from your UEFI system's firmware as that will only 'see' the FAT32 partition.

Why can't I boot from the USB 3.0 ports on my PCI add-in card?

I was asked this question today via email from Guptila. I thought I would share my reply here too.

The short answer is - you cannot boot via the BIOS on any device that is an 'add-in' device, unless it is a PCI card that also contains an option ROM.

BIOS Code

Think about how the BIOS works...

The BIOS knows that it's mainboard contains a certain chipset (it was designed for that chipset).

The BIOS contains the code required to access the registers on that chipset.

The BIOS has to have code which allow the operator to boot from devices connected to the chipset.

If the board has an ABC chipset, then the BIOS will contain code to access an ABC chipset with ABC-type USB registers.

Now you connect a PCI card containing a different (e.g. Renesas) chip. The BIOS will see a XYZ chip connected to the PCI Bus when you switch on the system, but the BIOS does not contain any code to access this XYZ chip - it does not even 'know' that the chip has USB 3.0 ports connected to it. In fact, when the BIOS code was written by the manufacturer, USB 3.0 chips probably did not even exist!

It would be the same even if you connected a USB 2.0 Renesas add-in card - the BIOS only contains code to boot from the chipset on the mainboard, it does not contain code for the 1001 different cards that could possibly be connected to the PCI bus.

So you cannot expect your system to boot from an add-in card... or can you...

So how can you add a SATA Add-in card to a system, and how come it can boot from SATA drives then?

You may well ask this question!

These add-in cards contain an option ROM - a chip that contains extra BIOS code. VGA (graphics) cards also contain these option ROMs so that you can see the BIOS text and setup menu etc when you switch on the computer. 

When the computer is switched on, it scans for Option ROMs and adds the code in the Option ROM to it's own BIOS code. In this way, the BIOS 'knows' about the extra chips that are now in the system.

Unfortunately, I am not aware of any USB 3.0 add-in cards which have their own Option ROMs that allow you to boot from their USB 3.0 ports. There are products such as 

http://www.amazon.co.uk/ASUS-U3S6-USB-SATA-PCIe/dp/B002VVQ58M/ref=cm_cr_pr_product_top

which contain an Option ROM, but this only allows you to boot from the SATA devices and not from the USB 3.0 devices.

You have these options available to you if you have an add-in USB 3.0 card:

1. Get a mainboard\system that has a USB 3,0 chipset and ports

2. Plug your USB 3 devices into your systems USB 2.0 mainboard ports

3. Use a Virtual Machine and connect your USB drive to the add-in card's USB 3.0 port - however anything you boot to will see the USB drive as a non-USB hard disk and not a USB 3.0 drive. It does mean that most things will boot at USB 3.0 speeds in the VM though (see RMPrepUSB - Tutorial 4 and the video).

Also bear in mind that many bootable OS's do not contain support for USB 3.0 chips, so even if you could boot from a USB 3.0 port, once you boot to an OS (e.g. plop, Vista\Win7 and many linux distros) the boot will fail because it cannot access the USB drive on a USB 3.0 port because the OS does not contain any USB 3.0 drivers.

MPI_Clover_Tool_Pack 004 now available

I have managed to get the Clover ntfs driver to automatically load and to get the GUI to show and correctly UEFI-boot from an NTFS partition.

To add drivers which will automatically load on a 64-bit system, just add them to the \EFI\CLOVER\drivers64 folder - so I just added the ntfs.efi file!

Even though I did this, there was no GUI icon for the NTFS efi boot file. It turns out that the default \EFI\CLOVER\config.plist file has entries to hide \EFI\BOOT\bootx64.efi files! I guess this is because the ISO contained this file which was the Clover UEFI boot file (i.e. if you booted the CD in UEFI mode, it used this to boot to Clover). Anyway, I edited the 'Hide' list as below:

<key>Hide</key>
<array>
<string>Windows</string>
<string>XXXBOOTX64.EFI</string>
<string>cdboot.efi</string>
<string>bootmgr.efi</string>
<string>bootmgfw.efi</string>
</array>

I just put XXX in front of the BOOTX64.EFI entry and added a few others that are not relevant. If you need the bootmgr.efi and bootmgrfw.efi options (e.g. to boot to an installed UEFI OS), just delete these lines from the file (or put XXX in front of them).

Now we can boot from Clover to a FAT32 or NTFS volume with no scripts or command lines to worry about!

grub4dos, Clover, UEFI-booting and NTFS - Tutorial 122

Tutorial 122 on www.rmprepusb.com

This new Tutorial allows you to have 64-bit Windows Install files (e.g. large All-In-One) on an NTFS partition and boot to it using Clover via a grub4dos menu.

Partition 1 = FAT32 grub4dos files, etc.
Partition 2 = NTFS containing Win7/8 AIO 64-bit installer files

Partition 1 MUST NOT contain a \EFI\BOOT\bootx64.efi file.
Partition 2 MUST contain both  \EFI\BOOT\bootx64.efi and \Sources\Setup.exe.

When you boot to grub4dos, you can choose to boot to whatever payload you have in the FAT32 partition (e.g. ISOs, Hirens, etc.) as usual.

To boot to the Win7/8 64-bit NTFS partition, run the Clover grub4dos option and then choose the EFI Shell 64-bit icon to get to the EFI shell. Then type WIN to boot to the NTFS \EFI\BOOT\bootx64.efi UEFI boot file to run Windows 64-bit  Setup in UEFI mode.

What happens is that when you boot to the UEFI shell from Clover, it runs startup.nsh which loads an NTFS driver. When you type WIN it runs win.nsh which looks for the Windows installer files on the NTFS volume and then boots to the \EFI\BOOT\bootx64.efi file.

There will also be a menu entry to boot from the NTFS Windows installer in MBR\CSM mode.

STARTUP.NSH

# UEFI Shell script to load NTFS driver and map new drives
echo -OFF
FOR %a IN fs0 fs1 fs2 fs3 fs4 fs5 
If exist %a:\Clover\NTFS.efi then
load %a:\Clover\NTFS.efi
endif
endFor
cls 1
echo " "
echo "TYPE WIN - to UEFI-boot from the volume containing \autorun.inf"
echo " "
# map the newly discovered drives (this script file path will be lost!)
map -r


WIN.NSH

@echo -OFF
FOR %b IN fs0 fs1 fs2 fs3 fs4 fs5 fs6 fs7 fs8 fs9 fs10
cd %b:
%b:
IF exist \sources\setup.exe then
goto act
endIF
endFOR

:err
cls 4
ECHO "Unable to locate \EFI\BOOT\bootx64.efi or \Sources\Setup.exe"
ECHO "Please check if windows installer has a EFI\BOOT\BootX64.efi"
goto xx

:act
IF NOT EXIST \EFI\BOOT\bootx64.efi THEN
goto err
ENDIF

cls 2
echo " "
echo "Found \EFI\BOOT\bootx64.efi"
echo "Press ENTER to UEFI boot or q to Quit"
echo " "
pause
cd efi\boot
bootx64.efi

:xx

For details of how to add Clover to your existing grub4dos menu - see Tutorial 122 here.

The MPI_Clover_Pack_Lite_003.zip download (Alternate Download Area) also includes these files.

Clover 'Lite' now available!

See previous blog for details.

MPI_Clover_Pack_002 for Easy2Boot now available

The next version of the Clover Pack is now available. The full 4.3MB Version 002 is available in the Alternate Download area here.
There is also a 1.3MB 'Lite' version which has some unneeded 32-bit and other files removed and uses a smaller 'theme' folder. I may add this Lite version as standard into the next MPI Toolkit Pack - so please let me know if you try it and find any problems!

By adding the files from the Clover Pack to your MakePartImage\CUSTOM folder, you will see an extra menu item on all FAT32 images you make, but only if they also contain a 64-bit default UEFI boot file.

Note: If you already use the CUSTOM folder for your own files, instead of adding the files to the CUSTOM folder under MakePartImage, you can add them to the csm folder (if you have a \CUSTOM\menu.lst file you will need to modify it to add in the new Clover menu entry though).

This means that you can make a Windows 7/8 install image and boot directly from MBR mode to Windows Setup in UEFI mode (without needing to reboot the PC and choose the UEFI: xxx option from the Boot Selection Menu). Cool eh?

Look at the ReadMe in the Clover Pack download to see how to add the files to MakePartImage. No new E2B version update is required. Just make your .imgPTN image file as usual - i.e.

1. Drag-and-Drop your Windows 7/8 64-bit ISO onto the MakePartImage shortcut you have made (or run it from an Admin command line and use the default values)
2. When prompted about EI.CFG, choose whichever option is appropriate for your usage
3. Rename the file with a .imgPTNLBAa file extension
4. Copy the file to your E2B drive (e.g. \_ISO\WIN folder)
5. Run WinContig  (RMPrepUSB - Ctrl+F2)

Now when you boot (Note: you must use a USB 2.0 port for Clover, not USB 3.0) you can switch to the new image and you should see a menu similar to this:

Note the Clover menu entry!

When you select this you will see the Clover Boot Selection GUI screen:

Note that the image has a volume label of LIVE as set by MakePartImage

This is the 'full-fat' version (black_green theme).

This is the 'Lite' version GUI (os_box theme)

Pick the 'Boot UEFI internal from xxxxx' to boot to Windows Setup in UEFI mode.

Note: Clover refers to MBR mode as 'EFI' (just to confuse you!)

You can change the volume label manually, so that it shows up as a Windows Installer image (e.g. Win8Inst) or specify the Volume label you want from the command line when you make the image.

Boot directly from grub4dos to UEFI using Clover!

Clover is a later revision of Tianocore. Both are 'firmware in RAM' replacements for UEFI firmware.
It allows you to boot in MBR\CSM mode and then run Clover which acts as a 'pseudo-UEFI boot manager', allowing you to boot to a UEFI OS from an MBR\CSM boot.

I would like to add this to the CSM menu of Easy2Boot so that users would not have to reboot the system and choose the UEFI: xxxxxx  boot option to boot from the E2B drive (when using .imgPTN image files).

First, I made a FAT32 USB Flash drive using BootDiskUtility.exe. This is a Windows tool that makes a Clover-bootable USB drive for you. Having done this, I found it would not boot under RMPrepUSB's QEMU (which doesn't support 64-bitness and just rebooted) or VirtualBox (text mode menu only) but did boot on a real system to the full GUI menu (see piccy below) - but only on a USB 2.0 port, Clover does not load on my Z87's USB 3.0 ports.

When is EFI not EFI?

Another important (and confusing!) point to note is that 'EFI booting' means MBR booting in 'Clover-speak' and UEFI booting means UEFI booting. If you see a Clover menu option to EFI-boot from a drive - it means MBR\CSM-boot!

This is the 'expected' full-GUI Clover Menu - select the UEFI option for UEFI booting as shown.

This is the text-mode screen I got!

Under VBox, I only got the 'text-mode' screen after making a USB Flash drive using BootDiskUtility.exe to make the USB drive. However, if I ran the USB drive on a real system, I got the correct GUI menu.

I later found that by pressing the 7 key after the first 2 seconds when booting from VBox, I managed to get the correct GUI menu!

To cut a long story short (essential data about Clover is hard to find!), here is how the Clover boot-chain works...

Master Boot Record (MBR)

First in the boot chain, we have the MBR. This is a normal MBR with a partition table, but the code in it seems to be 'special' (see PBR below for why I think this).

The MBR code can be found in a selection of boot0xxx files. You need to replace the boot code in your USB drive's MBR with the boot code from one of these files (but not the partition table).

The MBR code seems to look for and boot a Clover PBR. I found these files for the MBR code:

boot0af - looks for the active partition PBR
boot0ss - 'scan-signature' for AF type - MAC OS extended - seems to work best - no Active ptn needed.
boot0md - multiple drives - searches various drives for an HFS+/MAC OS extended partition - it seems to need the partition to be flagged as Active though!

see here for more (unclear) details! boot0ss still seems to boot from a FAT32 partition the best though!

Partition Boot Record

Moving on to the PBR - this code also seems 'special' in that we cannot just use chainloader ()+1 to boot from it in grub4dos. It seems we MUST go from the Clover MBR code to the Clover PBR code. Therefore both MBR code and PBR code are inter-dependent.

Again, various different Clover PBR code versions are available, these are prefixed as boot1xxx - the PBR code must be patched from byte 3 to byte 86 decimal. In the files produced by the BootDiskUtility, I had these files:

boot1f32 - understands the FAT32 filesystem
boot1f32alt - as above but waits for a key press for 2 seconds
boot1h - understands the HFS+ filesystem for MACs
boot1h2 - as above but waits 2 seconds for a key press

I used boot1f32alt for my experiments. See here for more PBR details.

The next stage in the boot chain is the file that is loaded by the PBR code. By default, this is a file in the root and is called boot.

• boot - (default) Clover, recent or testing version - rumoured to be the same as boot6 in released versions
• boot2 - Chameleon
• boot3 - Clover 32-bit, tested and working version
• boot6 - Clover 64-bit, tested and working version
• boot7 - Clover 64-bit with BiosBlockIO driver that works with any controller supported by the BIOS.

Now, here we have a FUNDAMENTAL FLAW (did you spot it?) - the default boot file is boot but Windows uses a folder called boot to hold it's boot files - we cannot have both a file and a folder with the same name on a FAT32 partition! Great thinking guys!

So, assuming I must keep the \boot Windows folder, I had to press 6 or 7 on a real system  to get it to boot to Clover. Eventually I found a way around this though, the PBR code had an ASCII string of
   BOOT<space><space><space> 
near the beginning of the code. I then found that if I modified this to
   BOOT7<space><space>  
it loaded the \boot7 file automatically! I am guessing that when a user presses 7 manually, it just adds the ASCII code for 7 to the end of the 'BOOT' string in memory, and then tries to load that file.

More Files!

Once the \boot(n) code runs, it loads up the rest of Clover from the \EFI\CLOVER folder starting off with
CloverIA32.efi or CloverX64.efi or CloverGUI. Note how these files have the .efi file extension but actually run in MBR mode, whereas normal files such as Microsoft bootx64.efi and bootia32.efi files have the same file extension but run in UEFI mode! Confusing huh?

It then accesses more files under the \EFI\CLOVER folder - see here for more details.

Putting it all together

So after all this - here is my boot chain that works for 64-bit UEFI Windows 8 booting from a single FAT32 partition:

MBR (using boot0md code) ->  PBR (using modified boot1f32alt code) -> \boot7 -> \EFI\CLOVER\CloverX64.efi  ->  Clover menu - \EFI\boot\bootx64.efi ---> Windows UEFI boot.

However, I found that if I chainloaded to /boot0md or /boot0ss in grub4dos, as long as the PBR  had the Clover code in it, it would boot (the md version also needed the partition to be Active too). This meant I can boot to grub4dos in MBR mode to the grub4dos menu and then, from that menu, run Clover - at last!

Grub4dos

So here is my current grub4dos menu for booting directly to UEFI via Clover from grub4dos:
Note it is for FAT32 only and has not been tested on linux, only Windows 8.1 x64 so far.

iftitle [cat --locate="FAT32" --length=10 --skip=0x50 ()+1 > nul] Run Clover UEFI Boot Menu\n Run this if you wish to use Clover to UEFI boot
set CL=0
## boot7 is default boot file
cat --locate="BOOT7" --length=10 --skip=0x58 ()+1 > nul && set /a CL=%CL%+1 > nul
if "%CL%"=="1" echo Information: Clover is already installed to the PBR
## configfile /menu.lst
echo ffffffffff > (md)0x350+1
dd if=(hd0,0)+1 of=(md)0x350+1 > nul
dd if=()/clover/boot1f32alt7 of=(md)0x350+1 skip=87 seek=87 bs=1 > nul
dd if=()/clover/boot1f32alt7 of=(md)0x350+1 count=3 bs=1 > nul
#cat --hex (md)0x350+1 && pause 
if not "%CL%"=="1" cat --locate="SYSLINUX" --length=10 --skip=0x2 ()+1 > nul && pause PROBLEM: SYSLINUX PBR DETECTED - Cannot install Clover to PBR... && configfile /menu.lst
if not "%CL%"=="1" dd if=(md)0x350+1 of=(hd0,0)+1 > nul && pause --wait=2 PBR updated with Clover boot code
chainloader /clover/boot0ss || chainloader /clover/boot0md || chainloader /clover/boot0af

# User can press 2 for 3 for 32-bit UEFI, 6 for 64-bit UEFI or 1 for Chameleon - within 3 seconds
# boot0md gives a boot0 message and is slower - boot0ss is silent with no message

It needs a bit more work and tidying up.

boot1f32alt7 is the modified PBR 512-byte file which will load \boot7 instead of \boot.
The grub4dos menu code works by permanently installing the Clover PBR code into the PBR (it must be FAT32 and it must not have syslinux in the PBR as I assume that if syslinux is in the PBR, it needs it in order to boot to linux - overwriting it would prevent it from booting via syslinux in MBR mode!)
I also moved the boot0xx and boot1xx files to a \Clover folder to keep it tidier.
The user can still press 2, 3 6 or 7 to boot to \boot2, \boot3, \boot6 or \boot7 as these are (currently) still in the root of the FAT32 partition (Edit: in Clover_Pack 002 only boot6 and boot7 are present!).

It would be nice to be able to run syslinux in MBR-boot mode (see below for how I got this to work too).

I now need to test this out on different platforms and different scenarios - hey ho...

A good source of info on Clover is here.

E2B .imgPTN images - boot directly from the CSM menu to UEFI

If you have booted in MBR mode to Easy2Boot, you can select an image partition file (.imgPTN family) and switch partitions to it immediately. However, now you have to reboot the system and select the UEFI firmware boot option for the E2B USB drive.

This is inconvenient and takes time (especially if you are on a server).

I have now added an experimental UEFI Clover boot option to the MakePartImage Tool Pack. Extra menu entries have been added to the CSM menu.lst file to boot Clover ISO files.

You will need MPI v030 and the MPI_Clover_Pack.zip files, available from the EasyBoot download page.

If you add the Clover ISO file(s) to the MakePartImage\Custom\e2b folder before you make your image file using MakePartImage, you will now see one or two extra menu options:

When you select this option it will load Clover. You then need to select the Boot Maintenance Manager option:

and then the Boot from File option:

After that you select the partition and then you need to select the .efi boot file (which will normally be \EFI\boot\bootx64.efi, or bootia32.efi for 32-bit UEFI payloads). It should then boot via UEFI to the efi file on the USB drive. In this way you can directly boot to say, a Windows 8 install image, in UEFI mode without needing to reboot the system and pick the UEFI: USB drive boot menu option.

As you can see, using the Clover menu to boot from, is not exactly convenient, which is why it is not included in the default MPI build. 

Clover is not included as standard because:

1. It doesn't work on all systems - e.g. Z87 systems.

2. It takes up space in the image (and will be in every image you create)

3. You have to go through several steps in the Clover menu to select and boot from an EFI file

4. It dramatically increased the size of the MPI Tool Kit download

This feature is still a work in progress. There are many drivers and other files inside the clover iso files which cannot be accessed via the Clover menu but they could be accessed if they were extracted to the image. I could also reduce the size of the ISO by removing unnecessary files, etc.  As I have only just tried Clover today, I have a lot more learning and experimenting to do!

If you have any suggestions and/or are experienced with Clover, please contact me. Ideally, I would like to be able to boot to the Windows efi files directly from the grub4dos menu...

E2B - MBR and UEFI booting of large All-In-One Windows Installers

For details about booting to Clover from grub4dos see here.

I was asked recently if it was possible to multiboot large >4GB All-in-One Windows installer ISOs using Easy2Boot in both MBR and UEFI mode.

After some work, I can now answer 'Yes - as long as you use a USB Hard disk for E2B'! - or a USB Flash drive of the 'Fixed Disk' type.

Note: Simone in the Comments below suggests splitting the install.wim file. If this is done with Win 8, you will need to add a special ei.cfg file too, in order to prevent a Microsoft 'licence' error (read the Comments for this blog post for details).

It has always been possible to directly use a AIO ISO on an NTFS-formatted E2B drive for normal MBR-type installs; the problem comes with UEFI installs. UEFI firmware can only boot from FAT filesystems and FAT32 has a 4GB file size limitation. If the Install.wim file is larger than 4GB then we have to place it on an NTFS filesystem.

The new procedure to work around this issue uses two partitions.

Partition 1 - FAT32 - contains all Windows Install files except the Install.wim file
Partition 2 - NTFS  - contains the large \sources\Install.wim file.

You must first make both partition images using MakePartImage. The partition 1 FAT32 image file should be given a filename extension of .imgPTNLBAa. The partition 2 NTFS image file should be given an identical filename but with no file extension at all - e.g.

\_ISO\WIN\Win8AIO.imgPTNLBAa
\_ISO\WIN\Win8AIO

Only the Win8AIO.imgPTNLBAa file will be listed in the Windows menu, but when it is run, the Win8AIO file will be mapped as (hd0,2) and the Win8AIO.imgPTNLBAa file will be mapped as (hd0,0).

In this way, you can boot via MBR or UEFI and install Windows even from an install.wim file larger than 4GB. The latest E2B versions include this feature.

Full step-by-step instructions on how to make the image files are here (scroll down to 'How to add Windows 7/8 installers with >4GB install.wim files').

Some UEFI systems may not like seeing two partitions - please let me know if you try this and what systems you tried it on!

Easy2Boot v1.39 - small bugfix

If you had a FAT32 E2B USB drive and you created a folder with a .  (dot) in the folder name, E2B would give an error during file enumeration. This is now fixed. Thanks to Chase for reporting it!

MPI Tool Pack also has been updated to v1.29. Small fixes for some syslinux ISOs.

New PCLinuxOS ISOs and adding an Answer file to Windows Installer .imgPTN images

It seems that PCLinuxOS has had a major Update - see here for details.

There are KDE, LXDE, Full Monty and Mate Desktop versions as well as a KDE MiniMe version - see the downloads page here to download an ISO and try it out on your Easy2Boot USB drive.

If any of you are using .imgPTN partition image files with Easy2Boot of Windows Vista/7/8 installers and want to add an answer file for automated installs, I have added instructions to the Easy2Boot website here (scroll to the bottom of the page).