beep! beep! (in grub4dos)

I had a request today from a blind person who wanted the grub4dos menu to beep when it loaded so that he would know when the countdown timer had begun. He was following my 'Tutorial 89 - Automated Windows partition backup\restore boot menu using CloneZilla' and wanted to be able to hit F4 and automatically restore his system.

Unfortunately not all hardware is fitted with a small internal speaker or internal 'beeper'. Most PCs are however - this is the thing that you may hear beep when you switch on your PC or it may beep several times if you have dislodged the DIMM memory cards!

Assuming that your PC does have an internal beeper, we can make it beep by sending a Ctrl-G character to the 'console'.

In grub4dos, we can use the internal function Fn.2 to send Ctrl-G to the 'display' as follows:

call Fn.2 7

This will work if you place it at the top of your menu before any graphicsmode or splashimage calls are made, because the display must be in low-res text mode (CGA) for this to work. So if you want to try this make sure you type graphicsmode 3 first if you are already in hi-res mode after loading a hi-res background bitmap! Of course, as this is a hardware 'beep', it won't work in an emulator or VM either.

We can flash the screen white and beep 3 times using the code below, as long as it is at the start of our menu.lst file (all one line).

color standard 0xF1 && clear && call Fn.2 7 && call Fn.2 7 && call Fn.2 7 && pause --wait=3 > nul && color standard 0xf && clear

If you don't want to see a flashing cursor use:

call Fn.5 0 128 

after the first 'clear' command, this sends the cursor off the screen to row 128! It will also mean that if the calls to Fn.2 produces any odd characters, they won't be seen.

However, once we have switched to a hi-res graphics mode, this trick of sending Ctrl-G to the 'display' will no longer work. Instead we will have to call the BIOS directly to output Ctrl-G to the console.

We can do this using the nice little grub4dos executable 'bios' from Chenall (download the bios.zip from here).

To make 3 beeps, each one second apart in any resolution screen mode, we can use this (assuming the bios executable is in the root of the drive):

/bios int=0x10 eax=0xe07 ebx=0x0 > nul
pause --wait=1 > nul
/bios int=0x10 eax=0xe07 ebx=0x0 > nul
pause --wait=1 > nul

/bios int=0x10 eax=0xe07 ebx=0x0 > nul

Most notebooks and many 'All-in-One' PCs are not fitted with an internal speaker though, so we can't make an annoying noise on every system that we boot from...

Easy2Boot - How to add specific Win7/8 Install ISO entries to the E2B Main Menu

Recently, I was asked if E2B could just jump straight to the Windows menu as he just wanted to use an E2B USB Flash drive for Windows installs. He also wanted to have the different individual ISOs listed in the Main menu.

The best way to just show a 'Windows Install' menu is to de-populate the Main menu by removing all the \_ISO\MAINMENU\*.mnu files that you don't want to be listed in the Main menu, and then add one or more .mnu files for your specific Vista/7/8 Windows Install ISO files using the type of menu entry described in my E2B Tutorial page here (or see below for an example). You can also add the Win XP options too.

You can also specify an XML file using a .mnu file.

In this way we avoid the Windows sub-menus and just use the Main menu. The \_ISO\MAINMENU\ZZWindowsInstall.mnu file is the one responsible for the Windows sub-menu entry in the Main menu, so this can be removed if you don't want it in the Main menu.

If you remove the files and folders in the other \_ISO\xxxx folders, then the DOS, BACKUP and UTILITIES, etc. menus won't be listed in the Main menu as only populated folders are listed. Other entries in the Main menu (set default, F8-10) can be disabled by using a MyE2B.cfg file (see the Sample_MyE2B.cfg file for the available options - use v1.13 or later!).

An example of a .mnu file is shown below:

# Use this for Vista/SVR2K8R2/Win7 ISOs

iftitle [if exist /_ISO/WINDOWS/Win7/Win7_32_SP1.iso] Install Win7 SP1 32-bit \n Install from the ISO

set MFOLDER=/_ISO/WINDOWS/Win7

set ISO=Win7_32_SP1.iso

/%grub%/RunVista.g4b  Win7

boot

# use this for Win8/8.1/SVR2012 ISOs

iftitle [if exist /_ISO/WINDOWS/Win8/Win8.1_32.iso] Install Win8.1 32-bit \n Install from the ISO

set MFOLDER=/_ISO/WINDOWS/Win8

set ISO=Win8.1_32.iso

/%grub%/RunWin8.g4b  Win8

boot

iftitle [if exist /_ISO/WINDOWS/Win8/Windows_8.1_EN-US_x86.ISO] Install Win8.1 32-bit \n Install from the ISO

set MFOLDER=/_ISO/WINDOWS/WIN8

set ISO=Windows_8.1_EN-US_x86.ISO

set XML=

# Specify XML file in MFOLDER folder (e.g. Win8\ has\ spaces\ in\ name.xml)

# OR to choose XML or Product Key, comment out next line

set XML=Sample.xml

set NOWMENU=1

/%grub%/RunWin8.g4b  %MFOLDER% %XML%

boot

Read more: http://www.easy2boot.com/configuring-e2b/add-windows-install-isos-to-the-main-menu/

Have you tried WinMerge?

WinMerge is great for comparing source code and other text-based files (like E2B files!). It is similar to WinDiff but better, IMHO!

If you have two different versions of a bunch of files and folders, WinMerge will list all the different files for you. Then double-click on the file and it will display the two versions of the file in two side-by-side Windows and highlight the differences. You can copy individual lines from one file to the other or just copy the whole file to the other folder. It works on all files and so will show non-identical binary files too.

It is great for comparing two versions of E2B (or any text-based files).
If you download the latest version of E2B to a folder and then compare that folder with your E2B USB drive, it will highlight the changes and you can decide what to update and what to leave alone (or just copy over a few lines inside a file).

A must-have for anyone who works with code source files or wants to compare two different versions of a bunch of files!

Easy2Boot v1.13

There were some small issues with v1.12 like pausing if a gfxmenu was loaded, global hotkeys not being active on all menus and the NoF8B variable not suppressing the F8 entry in Vista/7/8 menus. The new sample theme TextMinimal has also been changed.
Please update to v1.13!
See here for the latest version.

Easy2Boot v1.12 available

Changes are:
1. If E2B boots as a floppy disk, grub4dos 4.6.a is then loaded which has USB drivers and may treat the USB as hd0 and so work as the great BIOS god in the sky intended!
2. 100K spaces.txt file now removed as no longer required.
3. Global hotkey function added using chenall's great new hotkey version - you can define hotkeys without needing to have a  menu entry for it. See \_ISO\Sample_MyE2B.cfg for details.
4.  Warning message shown if an .iso file is not contiguous.
5. Fix for .iso files hanging - in previous version some HP systems hang when booting an .iso file - this was due to the loading of a firadisk floppy disk image in the E2B QRun.g4b code which seemed to cause the problem, so that line has now been removed (thanks to Colin for reporting and debugging with me to find this issue)
6. Startup message suppression using redir and redirp improved - can now have silent startup.
7. NOF7HD variable will suppress Boot from hd0 menu entries.
8. NOF8B variable will suppress the 'Return to Main Menu [F8]' menu entry in the Windows menu (delete MAINMENU\ZZZF8ReloadMenu.mnu if not wanted in Main menu).

See here for this version.

If you update your version to v1.12, you can delete the \_ISO\e2b\grub\spaces.txt file as it is no longer required.

Tip: If your system has slow USB boot speeds, try using the latest version of grldr (get file from \_ISO\e2b\grub\grldr_46a and copy to root of E2B drive and rename to grldr).

If you try this new v1.12 version of E2B please let me know if it works for you (better or worse) or if it has a problem. It should look the same as the previous version but work on more systems and report any errors better. I will leave v1.11 on the site so you can go back to it if there is a problem.

If you want to replace \grldr with the 0.4.6 version, please give it a try. As it is new, I have not fully tested it...

Tutorial 72a Easy2Boot v1 web page has been updated to add v1.12 features. For example, I show how to just skip the Main menu and show the Windows Install menu on startup.

cheers
Steve

P.S. There were a few small issues with 1.12 so please upgrade to 1.13!

Swap partitions in Easy2Boot

In my previous blog entry I described how you could create a USB Flash drive with two partitions. The E2B menu will work when it is on the 2nd partition and run linux ISOs, etc. but the E2B partition will be ignored by Windows and thus not visible to the user.

However, this also means that Windows based Operating Systems, once they have booted from the USB drive, will not be able to see any files on the 2nd (E2B) partition. This means that Windows Vista/7/8 Install ISOs will not work because they won't see the AutoUnattend.xml file on the 2nd (E2B) partition.
Also, several versions of Windows PE, once they have booted, will try to access files and folders on the boot drive. A typical example of this is MiniXP on the Hirens Boot CD and spin-offs such as DLC.

Apart from copying these files (AutoUnattend.xml and \HBCD folder, etc.) to the 'user' visible partition, the other alternative is to swap partition 1 with partition 2 before we run Hirens or the Windows Install ISOs.

This can be done by adding a .mnu file to E2B.

I have added E2B_PTN_SWAP.mnu to the \_ISO\docs\Sample mnu Files folder in the E2B download files. Just add this .mnu file to your \_ISO\MAINMENU folder.

You should now see a new menu entry in your menu. If Easy2Boot is detected on the first partition then the menu entry will be

• Hide E2B Partition 

If Easy2Boot is detected on the 2nd partition, then the menu entry will be:

• Unhide E2B Partition

When you run the menu entry, it will swap over ptn1 and ptn2 and then reload the main menu.

So before running a Windows Install you can Unhide the E2B partition and then Hide it again afterwards. The same applies when you want to run Hirens MiniXP or MiniWin7.

Make a 'secret' Easy2Boot USB Flash drive

Krishna wanted a USB Flash drive with Easy2Boot on it, but he wanted it to appear as a normal flash drive if anyone looked at it in Windows. This was mainly to prevent others from seeing and changing the E2B files and 'breaking' it.

The way this can be done is quite simple actually, and I have added a section to the E2B Tutorial here to explain how to do it. Basically you just make an E2B USB Flash drive in the normal way but create a smaller partition to leave room for a 2nd partition. Then, when E2B is all working correctly, add the second Primary partition using the spare space on the drive and then use RMPrepUSB to swap over the two partitions (using Ctrl+O). Now Windows will only see the second partition and you cannot access the E2B volume.

[Edit]Note: This only works on pre-1607 Win 10 (Creator) versions. Later versions of Win10 can access all primary partitions on a Removable USB drive now!

The USB Flash drive will still boot to E2B just fine though!

To gain access the the E2B partition, just run RMPrepUSB to swap the partition order back again.

E2B also allows you to add a master password to prevent it from being run by just anyone and you can also 'encrypt' many of the files in E2B by compressing them so that they are not easily read by curious users using Notepad. You can also change the file attributes of all E2B files to Hidden+System to further obscure them if you wish!

P.S. Note that if you are booting E2B to Vista/7/8 or WinPE, then those OS's will also not be able to access the USB E2B partition. This means that Vista/7/8 Installs from ISO will not work. Also any PE 2/3/4 (e.g. Hirens Mini Win7) will not be able to see any files on the E2B 2nd partition, so you will need to place those files and folders (e.g. \DLCD) on the non-E2B visible partition.

Note: Add a menu entry to E2B which will swap over the 2 partitions so that Win Installs and Hirens, etc. will work and you won't need an extra USB Flash drive, see here for details.

Later versions of E2B can 'super-hide' the E2B partition by making it unaccessible to Windows.

Run OpenELEC LIVE from your Easy2Boot USB drive

You can also run OpenElec Live (i.e. run XBox Media Centre - XBMC, and play video, music and internet TV, etc.) directly from your Easy2Boot USB drive.

See below for 2014 version - the next instructions are for the 2013 version.

----- 2013 version -----

If you have a FAT32 E2B USB drive, then download the appropriate version (I used Generic i386 Version 3.2.2) and extract the KERNEL and SYSTEM files from the target folder and place them in the root of your E2B drive (actually you could move the KERNEL file if you changed the path in the .mnu file).

Then make a .mnu file for E2B as follows:

title OpenELEC
uuid () > nul
set UUID=%?%
kernel /KERNEL boot=UUID=%UUID% disk=FILE=STORAGE,512

This will cause OpenELEC to make a 512MB ext4 file called STORAGE on the root of the E2B USB drive when it first boots. This is used to hold all the OpenELEC downloaded files, changes, etc.

Adding OpenELEC to an NTFS E2B Drive

If your Easy2Boot USB drive is formatted as NTFS however, you need to follow these steps:

1. After downloading the OpenELEC .tar file, unpack it to a folder on your Windows hard disk.

2. Copy the KERNEL and SYSTEM files to a spare, freshly formatted FAT32 USB Flash drive - this should be formatted as the size of the two files + 512MB + 10MB. Don't make it any bigger as this will make the final image file bigger and waste space.

3. Add the following menu.lst file

uuid () > nul
set UUID=%?%
kernel /KERNEL boot=UUID=%UUID% disk=FILE=STORAGE,512
# if it exists, change the type 0C 4th ptn entry to 0
cat --locate=\x0c --number=1 --length=1 --skip=0x1f2 --replace=\x00 (hd0)+1

4. Install grub4dos (use RMPrepUSB - Install grub4dos - Yes=MBR).

5. Boot the spare USB flash drive on a real system - it should create a 512MB STORAGE file (or less than 512MB if there is not enough room on the USB drive) and then run XBMC. Test it out and check add-ins are working and remembered when you reboot.

6.  Make an image of the partition on the USB drive using RMPrepUSB - Disk->File - choose P1 for Start, P1 for End and 0 for the File Start position.
I will assume the file created is called Open_Elec_LIVE.img

7. Now copy the Open_Elec_Live.img file to your E2B NTFS USB drive's \_ISO\MAINMENU\Linux folder. Then create an Open_Elec_Live.mnu file in the same folder as below:

title OpenElec LIVE \n This runs OpenElec from an image file
# Write a permanent new entry into the E2B partition table pointing to the OpenElec partition
partnew (hd0,3) 0x0 %MFOLDER%/Linux/OpenElec_LIVE.img
root (hd0,3)
chainloader (hd0,3)/grldr

8. Run WinContig (RMPRepUSB - Ctrl+F2).

You should now be able to boot and run Open_ELEC XBMC from the image file.

This worked a treat on my Asus EeePC 904H when booting from my E2B NTFS USB hard disk!

P.S. Rather than run grub4dos twice, you could combine the two menus into just one menu for the .mnu file:

title OpenElec LIVE \n This runs OpenElec from an image file
# Write a permanent new entry into the E2B partition table pointing to the OpenElec partition
partnew (hd0,3) 0x0 %MFOLDER%/Linux/OpenElec_LIVE.img
root (hd0,3)
uuid () > nul
set UUID=%?%
kernel /KERNEL boot=UUID=%UUID% disk=FILE=STORAGE,512
# if it exists, change the type 0C 4th ptn entry to 0
cat --locate=\x0c --number=1 --length=1 --skip=0x1f2 --replace=\x00 (hd0)+1

or load the 2nd menu directly, by using this .mnu code:
title OpenElec LIVE \n This runs OpenElec from an image file
# Write a permanent new entry into the E2B partition table pointing to the OpenElec partition
partnew (hd0,3) 0x0 %MFOLDER%/Linux/OpenElec_LIVE.img
root (hd0,3)
configfile /menu.lst

----- 2014/2015/2016 versions -----

Tested on:

• OpenELEC-Generic.x86_64-6.0.3.tar
• v 5.0.6
• OpenELEC-Generic.x86_64-4.0.2

This assumes you have the MakePartImage Tool Kit folder present on your system and you have installed ImDisk and made the Desktop Shortcuts (as in the ReadMe file).

Instructions:

1. Download the OpenElec .tar file

2. Extract the Target folder containing the kernel and system files to a folder on your system hard disk - e.g. C:\temp\target

3. Drag-and-Drop the C:\temp\target folder to the MPI FAT32 Desktop shortcut - when prompted, specify the target as C:\temp\OpenElec.img

4. Run RMPrepUSB with the E2B USB drive connected and selected.

    Make a \OpenElec-rw Ext3 Filesystem file with a Volume Label of DATA. The size is up to you!

5. Copy the OpenElec.img file to the \_ISO\MAINMENU\MNU folder of your E2B drive.

6. Create a .mnu file in the same folder with the following contents (this file can also be found in \_ISO\docs\Sample mnu files\OpenElec\OpenElec_LIVE_2014_NTFS.mnu on your E2B drive):

# For NTFS E2B USB drive (or FAT32)
# Create a FAT32 partition image file from a folder containing the kernel and system files from OpenElec using MPI Tool -> OpenElec.img
# Make ext2 FS file in root of E2B drive - FileName=OpenElec-rw  VolumeName=DATA
# Copy this .mnu file and OpenElecUSB.img to \_ISO\MAINMENU\MNU folder

iftitle [if exist not /system if not exist /kernel] OpenElec Live\n Boot OpenElec with persistence

set IMG=$HOME$/OpenElec.img
set PER=/OpenElec-rw

if "%E2BDEV%"=="" set E2BDEV=hd0 && pause E2BDEV forced to hd0!
if exist CD echo WARNING: Cannot use partnew command! && pause && configfile (bd)/menu.lst
partnew (%E2BDEV%,3) 0x0c %IMG%
debug 1
parttype (%E2BDEV%,2) | set check=
debug off
set check=%check:~-5,4%
# make empty table entry in 3rd position in ptn table
if "%check%"=="0x00" partnew (%E2BDEV%,2) 0 0 0
if not "%check%"=="0x00" echo WARNING: PTN TABLE 3 IS ALREADY IN USE! && pause
debug 1
if not exist %PER% echo WARNING: %PER% persistence file not found! && pause
errorcheck off
if "%check%"=="0x00" partnew (%E2BDEV%,2) 0x0 %PER%
errorcheck on

root (hd0,3)
uuid () > nul
set UUID=%?%
echo %UUID%
kernel /kernel boot=UUID=%UUID% disk=LABEL=DATA quiet
# if it exists, change the type 0C 4th ptn entry to 0
cat --locate=\x0c --number=1 --length=1 --skip=0x1f2 --replace=\x00 (hd0)+1

7. Run WinContig on the E2B drive (RMPrepUSB Ctrl+F2)

Notes:

• When booting from VBox, OpenElec fails to start Xorg and said 'Is your GPU supported'. Use a Nightly-build that will work on Virtual Box - the stable versions don't run on VBox.
• Error in check_disks: could not repair filesystem - If OpenElec started to boot OK but then failed, and now does not start at all and gives this error message immediately - re-make the OpenElec-rw file - it may have been corrupted due to an untidy shutdown/reset.
• When booted from my Z87 mainboard using a slow USB HDD drive, it failed to find the system file and did not mount the USB HDD drive. However, a USB Flash drive in the Z87 USB 3.0 port did work. I booted it on my Asus Aspire 7741G notebook from the same USB HDD, and it did work.

If your E2B drive is a FAT32 volume, then you don't need to make a .img file, you can just copy the system and kernel files to the root of the E2B USB drive and modify the menu as follows:

# --- FAT32 E2B USB DRIVES ONLY ---

# Just copy \system and \kernel files to root of E2B USB drive
# Make ext2 FS file in root of E2B drive - FileName=OpenElec-rw  VolumeName=DATA
# Copy this .mnu file to \_ISO\MAINMENU\MNU folder

title OpenElec Live\n Boot OpenElec with persistence
set PER=/OpenElec-rw

if "%E2BDEV%"=="" set E2BDEV=hd0 && pause E2BDEV forced to hd0!
if exist CD echo WARNING: Cannot use partnew command! && pause && configfile (bd)/menu.lst
debug 1
parttype (%E2BDEV%,2) | set check=
debug off
set check=%check:~-5,4%
# make empty table entry in 3rd position in ptn table
if "%check%"=="0x00" partnew (%E2BDEV%,2) 0 0 0
if not "%check%"=="0x00" echo WARNING: PTN TABLE 3 IS ALREADY IN USE! && pause
debug 1
if not exist %PER% echo WARNING: %PER% persistence file not found! && pause
errorcheck off
if "%check%"=="0x00" partnew (%E2BDEV%,2) 0x0 %PER%
errorcheck on

uuid () > nul
set UUID=%?%
echo %UUID%
kernel /kernel boot=UUID=%UUID% disk=LABEL=DATA quiet

P.S. The latest build from here worked under VBox when booting from my Easy2Boot USB drive. I actually downloaded OpenELEC-Virtual.i386-devel-20140317134709-r17946-gb27c946.tar.

UEFI-booting

See the instructions at the end of this LibreELEC blog post.

How to add OpenELEC XBMC Installer to Easy2Boot

The OpenElec x86_64 installer is based just on two files from the \target folder, KERNEL and SYSTEM. The KERNEL can be loaded by grub4dos but then it will look for the SYSTEM file on the boot volume. This works fine if we just copy these two files from the OpenElec x86_64 download to the root of our FAT32 Easy2Boot drive and then use a simple .mnu file:

title OpenElec Flat-File boot from FAT32
uuid () > nul
set UUID=%?%
echo UUID=%UUID%
kernel /KERNEL boot=UUID=%UUID% installer

However, there is a problem if we have an NTFS Easy2Boot USB drive because the KERNEL does not appear to be able to access the NTFS filesystem to find the SYSTEM file.

See here for OpenELEC Live.

Method 1 - use MakePartImage

1. Use RMPrepUSB - File->Drive and write the  OpenElec.img file to a spare USB Flash drive (this will destroy all contents on the USB drive).

2. Drag-and-drop the USB drive Explorer icon (e.g. J:) onto the MPI_FAT32 desktop shortcut (after installing the MPI Tool Kit).

3. Copy the resulting OpenElec.imgPTN file to your E2B USB flash drive

You can now MBR boot or UEFI boot.

Method 2 - the harder way!

After some trial and error, here is the way I found around this.

1. On a spare USB Flash drive, format it with RMPrepUSB as FAT32 and make the partition size just large enough for the two files + about 10MB. e.g. if the files add up to 92MB make a 110MB FAT32 partition. We need to keep this as small as possible as we are going to create an image from it.

2. Install grub4dos to the MBR

3. Add the two OpenElec boot files, SYSTEM and KERNEL.

4. In RMPrepUSB, press F4 to create a menu.lst file and add these 5 lines

uuid () > nul
set UUID=%?%
kernel /KERNEL boot=UUID=%UUID% installer
# if it exists, set the type 0C 4th ptn entry to 0
cat --locate=\x0c --number=1 --length=1 --skip=0x1f2 --replace=\x00 (hd0)+1

We should have these files on the FAT32 grub4dos Flash drive:
\grldr
\SYSTEM
\KERNEL
\menu.lst

5. Test that it boots to the OpenElec installer by pressing F11 in RMPrepUSB

6. In RMPrepUSB, click on the Drive->File button, choose a destination to save the file (OpenElec.img) and enter P1 for the Start Position on the drive, then P1 for the End Position and then 0 for the File Start position. This will create an image of the entire partition.

7. Copy the OpenElec.img file to \_ISO\MAINMENU\Linux folder of your E2B drive (or any \_ISO\xxx\Linux folder if you want it in a different menu).

8. Create in the same folder  an OpenElec.mnu file containing these contents (cut and paste the 5 lines):

title OpenElec Installer \n This installs OpenElec to a drive
# Write a new entry into the E2B partition table pointing to the OpenElec partition
partnew (hd0,3) 0x0 %MFOLDER%/Linux/OpenElec.img
root (hd0,3)
chainloader (hd0,3)/grldr

Now Run WinContig (RMPrepUSB - Ctrl+F2) and we should now be good to go!

We should now have present on the E2B drive:
\_ISO\MAINMENU\Linux\OpenElec.img
\_ISO\MAINMENU\Linux\OpenElec.mnu

Select the OpenElec Installer entry in the Easy2Boot Main Menu and it should boot.

The trick here is that partnew is used to create a type 0C partition entry in the E2B USB drive partition table so that we do have a real partition on our E2B drive when OpenElec boots, however once it boots to the image and we have loaded the kernel in grub4dos, we can set the partition type to 0 because linux does not look at the partition type number. This means that when E2B reboots, it will not complain about the partition table Entry #4 being in use and refuse to load the main menu. If E2B sees a Type 0 in ptn #4 it will clear the entries for us.

Neat eh!

The installer seems to install OK on a VM hard disk, but the VM seems to fail to fully boot to OpenElec (probably wrong hardware?) and I haven't tried it on a real system as it will trash the system's hard disk.

Raspberry Pi netbook for £100(ish) !

I have had my Raspberry Pi for a while now and after getting XBMC running on it, I have not really used it for much. I recently saw on YouTube that people have been connecting the Pi to the Motorola lapdock accessory for the Motorola Atrix 4G smartphone (really smart, RRP was over £300 but now reduced to £70 on eBay due to the phone being discontinued by Motorola!).

If instead of the Atrix 4G (which is no longer made), you plug in your Raspberry Pi and you now have a Raspberry Pi netbook with an 11.5" screen, internal battery, speakers, touchpad, keyboard and 3 spare USB ports all for about £100! Add a wifi dongle and you have a wireless Pi.

I have written a few notes on this here. There seem to be many YouTube videos describing how to split and solder special cables for the Pi<->lapdock connections, but this is not necessary. You can power the Pi straight from the USB cable if you have a later revision of the Pi. If you have an earlier Pi, simply solder two wires across the two 500mA fuses F1 and F2 (these are not fitted on later versions anyway, so you are actually upgrading your Pi!):

Pi mod. - Click to enlarge.

This bypasses the 700mA fuse in the mini-usb power in connector on the Pi, but the lapdock has it's own protection built into the USB ports.

BTW - Fuses should be used safety reasons and not for limiting the current; why the Pi has a 700mA fuse in the supply power input to supply power to the Pi circuitry + two 500mA USB ports baffles me - the main fuse in the Pi should be 1.5A at least! There also should be larger reservoir capacitors to allow hot-plug of USB devices!

After doing this mod to F1 and F2, I had a nice working Pi netbook. Unfortunately, I discovered that the brand new lapdock I got from Mobilepartz on eBay had a faulty trackpad button and so I have had to return the lapdock for a replacement, which they kindly agreed to, without any fuss or problem.

When I get the new one back, I will add some pictures of my setup and probably a few more notes/tutorials on the Pi.

Update: Steve of Mobilepartz sent me a replacement on the same day that he received it and rang me to confirm. The new one works perfectly and is now running raspbmc and playing live TV nicely - it seems I was just unlucky with the first one (both were brand new). Great service Steve, thanks!

My WiFi-enabled PiDock!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FakeFashTest updated

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

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



FAKEFLASHTEST v1.0.7  [SSi]

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

PASSED: 76298MB tested and OK.

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

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

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

RMPrepUSB tutorial on Fake Flash devices

Download Windows fast FakeFlashTest.exe

Watch my YouTube video

Why should I use FakeFlashTest?

RMPrepUSB and E2B updated

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

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

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

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

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

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

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

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

mov al,3              ; 3=3 sectors

mov ch,10          ; track 10

mov cl,1             ; sector 1

mov dh,2            ; head 2

mov dl,80h         ;drive number 80h

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In this case we will use grub4dos.

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

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

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

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

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

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

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

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

e.g.

title LinuxMint 8

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

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

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

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

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

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

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

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

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

With Windows Install ISOs it gets more complicated...

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

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

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

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

linux isoboot cheat codes

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

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

iso_filename=%ISOSCAN% 

isofrom_system=%ISOSCAN% (openSUSE)

isoboot=%ISOSCAN%  (gentoo)

iso-scan/filename=%ISOSCAN% 

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

isofrom=%UUID%:%ISOSCAN% 

bootfromiso=%ISOSCAN% (PCLinuxOS)

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

fromiso=%ISOSCAN% 

from=%ISOSCAN%

isoloop=%ISOSCAN% 

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

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