This is a new utility that puts BartPE/UBCD4Win on your USB drive and can also make a small 40MB iso image used to boot your USB drive on systems that can't boot from USB otherwise.

Screenshot

Download it from HERE and extract it to your plugin folder (you can actually run it from anywhere now, read below) then run UBUSB.exe and click "Go" to have UBCD4Win written to your USB drive and a matching iso image made that can be burned to cd to make a "kicker" cd to boot your usb drive on older computers that can't normally boot from usb.

History:

http://www.911cd.net/forums//index.php?showtopic=21242

s4e discovered that the disk signature and mbr checksum is recorded during the first stage of the boot process and at the start of the second stage it checks to make sure that it can still connect to the original boot device.

How-It-Works:

The concept is to boot a small "kicker" image from cd into ram via grub4dos that contains critical boot time drivers (including usb) then when the second stage of the boot process is entered, it needs to verify that a driver has been loaded and that it can still communicate with the device that the boot loader passed to it as the boot device. Just before this check is done, communication with the ram loaded image is lost but since our usb drive has the exact same disk signature and mbr checksum as the boot device, it knows no different and continues booting from it.

Benefits of USB Booting vs. CD/DVD Booting:

1. Once it's booted it's lightning fast since it doesn't have to spin up the drive constantly.

2. No need to build and burn a new cd everytime you want to add/delete/modify a file.

3. You can save/recover data directly to the system drive while booted to PE/UBCD4Win

4. Easier to carry in your pocket (If you use a SD Card to USB adapter you can carry several cards in your wallet)

Drawbacks of USB Booting vs. CD/DVD Booting:

1. Slow boot times on machines with USB 1.0 or 1.1

2. Some machines will boot at 1.1 speed even if it supports 2.0

3. Some older machines don't natively support booting from USB

4. Some older machines don't have a usb port.

How can we overcome the drawbacks?:

1. Use a 2.0 pci/pcmcia/pci-e usb adapter

2. Use the "kicker" cd made with this new utility to speed up the initial boot phase. After booting is passed to the usb drive then it should use 2.0 speed.

3. Use the "kicker" cd...

4. See #1 and #3...

*******************************

How to prepare your usb drive for booting:

The first time you prepare your drive you'll need to make sure that nothing is checked except for "Quick Format" and "Create CD Image..." (if desired) so that a partition table and MBR code can be written to it, the partition will be formatted and have the file/folder structure copied to it from your existing BartPE output folder.

About This Utility:

It is considered BETA so USE AT YOUR OWN RISK!!!

Multiboot options have been disabled for now Multiboot support is now enabled for both Grub4dos and Syslinux

It will create a single partition on your usb drive (support for multiple partitions might come later).

USB-Copy.cmd is courtesy of cdob USB-Copy.cmd is no longer used

The CD image will be mounted via VDK.EXE on drive Z: and no checks are done to make sure that Z: isn't currently being used before formatting it and copying files to it so BE CAREFULL!!! The image is no longer statically mounted to Z: (it now uses the last available drive letter)

vdk.sys, vdk.exe, grldr, mkisofs.exe and USB-Copy.cmd need to be in the same directory as USB-Boot.exe if you want to create a "kicker" image and they need to reside in a sub-directory in your "plugin" folder. All required dependancies are now embedded in the exe and it can now be ran from anywhere on your hard drive as long as you manually "browse for" and direct it to your BartPE folder. It should automatically find your BartPE folder if you run it from somewhere in your build folder.

I have alot more to say about this new and revolutionary boot method but I don't want cloud this first post too much. Have fun testing and please report back with your experience and/or thoughts (good or bad)...

Tom

I have tried Ultimate Boot USB and I can say it works.
Booting with the kicker.img CD on a system without BIOS Boot USB-support, I was able to boot UBCD4WIN from USB.

But booting with the kicker.img CD is for the DVD-drive a rather heavy task and rather slow
as compared to booting smooth in 70 sec with UBCD4WIN from RAMDISK using a NTFS Compressed BartPE.img file
which is made with BOOT_IMG.cmd of the USB_XP_Setup package.
http://www.boot-land.net/forums/?showtopic=5306
BOOT_IMG.cmd makes a boot entry in boot.ini Menu and in GRUB4DOS menu.lst Menu on C-Harddisk,
so that you can also boot with UBCD4WIN without USB-support but now from RAMDISK.

I would like to try this out, but you didn't include usb-boot.exe or usb-boot.cmd. Can you please give me a link, or email me?

Thanks,

thesimpleone

@thesimpleone
pcuser named already ftp://toms.homelinux.org/ubcd4win/UBUSB.zip
Can't you download this file?

@pcuser
USB boot without bios support does boot. Thanks.
Sorry, haven't tried format part so far.

I've made a few updates to the program and uploaded the new v1.0.6 version (same link as first post).

Better error handling has been added.

The format routine has been reworked.

Various other updates have been done to improve the GUI.

Love the idea of this! I've got my USB and KickerCD ready... now to find some non-USBbootable systems to test it on...

v1.0.7 has been uploaded with Syslinux and Grub4dos multiboot support added.

We can now have our Syslinux or Grub4dos multiboot menus (using either Fat16 or Fat32) while still having a matching kicker cd for the usb drive.

UBUSB pulls the bootsector from your usb drive to create UBCD4Win.bss and cmdc.bss (used for booting UBCD4Win and the Recovery Console with Syslinux) so they'll always match the filesystem you're currently using on your usb drive. cmcd.bss does not use the hacked setupldr.bin/rcldr method, it uses the method of renaming the CMDC directory to CMDCONS and changing MSDOS5.0 in cmdc.bss to CMDCONS(0).

I've successfully booted UBCD4Win with these configurations from a usb drive (and then also booting again using the kicker cd) on a computer that supports usb booting and the same configurations using the kicker cd on an old computer that can't natively boot from usb.

Fat16/Syslinux
Fat32/Syslinux
Fat16/Grub4dos
Fat32/Grub4dos
Fat16/Standard
Fat32/Standard
NTFS/Standard

If you're using Syslinux and there's no Syslinux directory at the root of your usb drive with a syslinux.cfg file present then a generic one will be created, same goes for a menu.lst file at the root of the drive if you're using Grub4dos. Even if a UBCD4Win.bss and cmdc.bss file exist in the syslinux directory, they'll be overwritten with new ones that match the current configuration of your usb drive.

I don't know how many people have noticed but I added multiboot support for both Syslinux and Isolinux in the last UBCD4Win release (Grub4dos didn't make it in time). My goal is for all multiboot plugins to support BCDW/Isolinux when booting from cd/dvd and support Syslinux/Grub4dos when booting from hdd/usb. This will enable us to have the same multiboot plugins available whether we're booting from cd/dvd or usb.

NTFS isn't compatible with Syslinux or Grub4dos and NTFS is still not supported for a kicker cd (yet). NTFS is also not supported on removeable usb drives but is supported on fixed usb drives using a Standard XP mbr and boot sector.

It's still pretty ugly to look at but I really like what it does so far...

Vista anyone?

@Ben, I expect some testing and feedback on this...

Seriously though, the only configurations currently known to work under Vista are Fat16 or Fat32 using Grub4dos as the bootloader and a kicker cd cannot be made.

If you want to test this while running vista then you have to right click and choose "run as administrator".

Helo,
1- I've NOT successfully booted UBCD4Win from a usb drive (4GB) on a computer that SUPPORTS usb booting.

2 - Booting using the kicker cd take 15 minutes to load. CPU 3.0 GHz and memory 2 GB

3 - I got message error: "An unexpected error (769) ocurred at line 5182 in D:\XPSPRTM\BASE\BOOT\SETUP\SETUP.C Press any key to continue."

4 - After load usb drive, ubcd4win worked perfectly and much more fast than CD.

5 - How can I boot direct from usb drive?

Thank you,

Does it give you an error message? What configurations have you tried? Will the same usb drive boot on another computer? What kind of usb drive is it?


I get this too on systems that natively support usb booting and hitting any key lets it boot to the desktop without problems. I'm not sure of a way to surpress it.

Drive speed, read access time - not max speed, does set boot time.
15 minutes are very long.

That's not a error message.
That's a friendly reminder: you change boot drive at a machine with BIOS support.

Use grubinst and apply grub4dos to MBR. http://nufans.net/grub4dos/grubutil/
Add grldr, menu.lst and chainboot image to usb drive.

I fixed a small error that I found in my logic when testing with a plain pebuilder install today. It now doesn't create cmdc.bss or create an entry in syslinux.cfg for the recovery console if a folder named CMDC or CMDCONS doesn't exist and syslinux is used for the boot loader.

It wasn't anything major but I still uploaded a new v1.0.8 version...

Hello, thanks for your help.


Disk error
Press any key


FAT 32 syslinux, grub4dos and standard


I want use ubcd4win just in my computer, I don't have another computer to try.


USB Flash memory PNY 4GB


I don't know how to do I'm not programer...
Can you explain step-by-step, please?

Thank you again

Make sure that nothing is checked (except for Create CD Image... if not on vista) when you run the program, so the usb drive can be properly prepared.

Can you produce a working usb drive using FAT16?

What OS are you building on?

I just check "Quick Format" and "Create CD Image".


I will try FAT 16, but before I need search google.com to learn what is FAT 16 LBA and CHS


Win XP SP2

Sorry... I tried all options:
FAT 16 LBA and CHS
FAT 32 LBA and CHS
syslinux, grub4dos and standard

Bios:
Boot from mass storage
Forced FDD, HD...
Nothing happening

@Ricardo NYC, I just uploaded a new version (1.0.0.9) that should hopefully fix the "Disk error, Press any key" issue.

The issue only existed on usb flash drives and not on usb hard drives. The problem was that when we boot from USB we boot as USB-HDD but when we format drives of "Removable" type, Windows wants to format it that way so an additional byte needs to be set in the bootsector after formatting to satisfy the bios making it think that it's a usb hard drive. UBUSB was already doing this but I needed to add a 2 second delay between formatting the drive and writing the additional byte.

Please let me know if this solves your problem.

I just uploaded 1.0.0.10 with some nice new features.

It now supports usb drives up to 2TB in size and 2 new cmd buttons have been added, "TestUSB" and "TestISO" so you can now test boot your usb drive in Qemu and then test boot the iso image for your kicker cd in Qemu before burning it to cd.

I did notice a couple of small issues when booting with Qemu. If the usb drive's NTFS formatted then Qemu doesn't seem to want to boot it and fails with "A disk read error occurred" but it still boots on a real computer and the other issue is that the RocketDock icons and GeoShell bar don't appear when booted to UBCD4Win via Qemu.

Congratulations.
Given a 4 GB USB flash drive:
that's the first application creating a bootable version. XP MBR and ntldr boot code used.

"TestUSB" and "TestISO" does work too.

BTW: There is a updated chainboot copy cmd
http://www.911cd.net/forums//index.php?s=&...st&p=149797

Thank you cdob, I'll update it for the next version.

This has worked for me and its the first time a kicker has done its job, but at first the old Fuji i was using as a test would not boot - untill i changed to a different set of usb ports( both onboard ).

I don't fully understand how this works so here is a couple of questions to help me.

1) Is the real usb device's info cloned into the fake or is the fakes info cloned into the real device?

2) Do i assume correctly that each kicker / real usb device pair are unique, IE: different kicker images for a stick and a hard disk ?

3) Is any of the actual data on the real device used by this proccess? IE: can i update the bartpe stuff without redoing the kicker image?

4) the kicker seems to start the loading of ubcd4win itself, is there a way of just kicking to a menu system on a usb device so i can use the tools that i have in my multiboot section(aoss and kaspersky)?

Thanks for any info and for the tool.
Paul

Thanks for report.

Disk signature is set to UBCD at real device. Device info is cloned to fake image.

Yes, by design pair are unique. Use different kicker images for a stick and a hard disk.

However it maybe possible to prepare stick and hard disk first.
Kicker image my match both stick and hard disk.
That's not supported. This may cause confusion too. That's not recommended.

Yes and no. Kicker image contain early boot definitions. If you change early boot environment, create a new kicker image.
Contrary if you change application slightly, IE add new virus scan definitions, you may keep kicker image.

No, that's not possible.

Hi,

Thanks for the info.

Is there a way to add the kicker.img file into a ubcd4win multiboot menu? Maybe i could include several different versions to support my stick and HD devices.

Thanks
Paul

UBCD4Win uses BCDW for multiboot and the kicker cd needs Grub4dos. You can make a cd that has multiple images by creating a custom menu.lst and manually creating the iso.

menu.lst


Add menu.lst, grldr and your image files to C:\iso_root then run this command.

I made a few improvements to the program and uploaded 1.0.0.11

I added support for windows recovery console when using Grib4dos as the bootloader.

Two new buttons now appear in the sector editor, "Save to File" and "Load From File".

"Save to File" saves the current sector to a file in the same directory that the program's running from. The name of the file depends on the sector that's currently being edited. If you're editing sector 0 then the filename will be sector0.bin, if you're editing sector 63 then the filename will be sector63.bin, etc...

"Load From File" will only load a file name that matches the current sector being edited. This should hopefully eliminate the possibility of loading the wrong file to the wrong sector by accident.

When is this sector editing required? I think there needs to be a little more documentation or examples.

Also could you include a version number in the program, i can't tell if ive got the new one or not.

Sorry if i have missed something.

Paul

It's not required. I made it mostly to help me while developing and kept it included because many advanced users will find it usefull as well.


I agree but I haven't got that far yet.


Yes, I was getting ready to announce a new version but I'll add that first.


Either hold your mouse over the program while in windows explorer or right-click over it and choose properties then version.

1.0.0.12 has been uploaded.

There's now a sub-directory called "special-files". From the README.txt file:


The version number is now printed next to the main caption (thanks to PaulDG for the suggestion).

Looking good.

Along the lines of one of my earlier questions, you could add a folder that we could place our menu.lst files and maybe other images into so that it gets incorparated into the build.

Also is there a way to include a method to reuse a current img file, so i dont have to generate a new cd all the time, the main use for usb for me is to cut down on crateing a cd every time i update my antivirus and malware programs. being able to re-use current kicker.img files would help alot. obviously it would only apply to devices that are compatable.

Also: Although you warned about the lack of error checking on Z drive, i managed to fall foul of this because i mapped it to a network share and forgot to remove it, the actual error i got was an unable to format drive that left me thinking it was refering to the usb stick that could not be formated, only when i realised it was talking about the 40mb fake drive did the penny drop.

That leads me to ask if that drive had been formatable (not locked by the network share) would the format have been successful.............

Paul

I've added Grub4dos support to the default UBCD4Win multiboot plugins (Syslinux support was added prior to the 3.20 release). I planned on including this in the next UBCD4Win release but since you asked... You can download it from HERE. Download it to your plugin folder and replace your existing Multiboot-003 folder. Look at the format of the *_grub4dos.ini files and then look at how they're called from the multiboot plugin's main inf file and you'll see how to add your own images. I think this is a more modular design because you'll end up with a menu.lst that already includes all of your enabled multiboot plugins then you can edit menu.lst and add any customizations later. Do you agree?


Your kicker cd only has to match the MBR of your USB drive so the only time you should have to make a new cd is if you change between Fat16 and Fat32. You can modify the contents of the drive and even switch between Syslinux, Standard and Grub4dos bootloaders without having to create a new cd, as long as you don't switch between Fat16 and Fat32.


OUCH!!! When you see "WARNING..." (especially when beta testing software), please pay attention to what it says Paul! It would've formatted Z: if it could.

I'll get this fixed ASAP, thanks for bringing it up.

Different Day - more questions

This new Grub4dos support for ubcd4win that you have kindly supplied, is it intended for the usb implimentations only? or is it also for the standard ubcd4win cd version? if so how do i activate/switch to it?

Where is the "multiboot plugin's main inf file" located?

Thanks for the clarification of the kicker cd and usb device matching.

WARNING... Shmorning, that never happens to me..... Oh wait!!! I was lucky this time, the share was RO and it was a cd drive. But no pain no gain!

ATB
Paul

It's only for the usb drive.


The main inf file for memtest86 is memtest.inf, the main inf for dban is dban.inf, etc...

Ok Thanks for the clearup.

Can we get a switch to leave the kicker.img on disk after the iso has been compiled so i don't have to mount it and pull it everytime i make a new one. I can then write a tool that compliments this to create my custom cd and add all the other menu options into menu.lst

Below is what i am trying to achive. using tools and programs as ill forget what i was doing when i move on to something else

A cd that contains the standard ubcd4win installaton enviroment with any multiboot options i may add (aoss, kaspersky and memtest) that also can start the kicker and a usb stick/hd that complements this.

On a modern bios i would boot from the usb - after updating all the antivirus and malware utils.
On a old bios without usb support i would boot from the cd and use the kicker to load the ubcd4win enviroment from the same usb device as above
and on a real nasty bios i would fall back to the same cd and use the utils from the time i created the cd - maybe with an alternate usb device containing updates.

Paul

Sure. I'll get it added

1.0.0.13 has been uploaded.

It now leaves kicker.img after creating the iso image. I've also made a plugin for adding your kicker image(s) to your UBCD4Win multiboot menu, you can download it from HERE (extract it to your plugin\multiboot-003 folder).

The plugin is disabled by default because you have to build UBCD4Win atleast once before running UBUSB and creating your kicker.img

Your kicker images go in the "kickers" folder and you'll need to edit kicker_grub4dos.ini if you want to include other images besides the default "kicker.img" (or if you change the name of it). Don't forget to enable the plugin before building UBCD4Win again to include your images!

Thanks for the reports and good suggestions Paul, please keep them coming

Now thats what i'm talking about.... Thanks for this, i'll check it out tomorrow, need sleep now.

Paul

okeydoky - 1 Question and 1 observation.

Why does the kicker plugin boot to grub4dos first and then loads the kicker image when you select it, instead of directly booting the kicker img via the std menu?

Also the menu.lst file presented to the above loaded grub4dos contains all the other multiboot options instead of just the kicker but they dont work.

Oh and its possible that the UBUSB.exe program has lost its "done/completed msg" though it was late when i tested last and i might have lost it in the 15 windows i had open.

Paul

The kicker.img needs to be chainloaded via Grub4dos but the initial UBCD4Win bootmenu is BCDW so we call GRLDR from BCDW to load Grub4dos. Does that make sense?


That's because of the added Grub4dos support in all of the other multiboot plugins and the fact that there can only be one menu.lst file. The only workaround that I know of is to use the original multiboot set or comment out the "*_grub4dos.ini" line in the affected multiboot plugins.

and visa versa, the menu.lst presented to grub4dos on the actual usb device contains the kicker option, but it does work!!!

That's an interesting side affect! I've noticed that some computers with native usb boot support can take a long time to boot but using the kicker cd makes the boot alot faster. This could be a nice feature?

I'm going to do some tests on a Dell that normally gets the 0x7B BSOD unless I use the 2k3sp1 files and see if I can boot using the kicker from the usb drive.

Maybe a usb 1 vs usb 2 thing, bios support is only usb1 and im guessing your kicker.img is using 2

Drum roll... It worked!!! I booted the kicker image from the usb drive on that same Dell and it booted straight to the desktop (without the need for win2k3sp1 files) and rather quickly too!

Thanks for confirmantion: No BSOD 0x7b with the Kicker image.

Ktp reported faster boot speed at USB1.1 BIOS too
http://www.911cd.net/forums//index.php?s=&...st&p=149295

First test: Dell Dimension 2400. Can natively boot from USB but fails with 0x7B BSOD

Booting UBCD4Win from USB: 7 minutes 35 seconds before 0x7B BSOD
Booting UBCD4Win from CD: 5 minutes 45 seconds before completely booted (rocket dock icons appeared)
Booting kicker image from CD: 8 minutes 50 seconds before completely booted
Booting kicker image from USB: 3 minutes 25 seconds before completely booted

I'll have to do more testing but based on these results it looks like booting the kicker image from usb might be the best way to go, even if the computer can natively boot from usb.

Thats good news, obviously booting on a very modern board with native usb2 support for usb booting should not produce the same results.

I have a brand new Asus P45 system downstairs waiting to be assembled, ill get some testing done on that in the next few days.

I am going to try and figure out a way to tidy up the other side affect first.

I just booted a on a Gigabyte P35-DS3P / Core2Dou E6750 / 4GB 800Mhz Ram that normally takes about 12 to 13 minutes to boot UBCD4Win from USB and booting kicker.img from USB takes about 3.5 minutes. Same thing on a Compaq presario SR1303WM / Sempron 3000+ / 512MB Ram, it usually takes around 15 minutes to boot from USB but booted in about 3.5 minutes booting kicker.img from usb.

Another nice thing I noticed is that booting kicker.img from usb doesn't produce the message "An unexpected error (769) ocurred at line 5182 in D:\XPSPRTM\BASE\BOOT\SETUP\SETUP.C Press any key to continue." like it does when booting kicker.img from cd on a system that natively supports usb booting.

The tests I've done today are enough to convince me that booting kicker.img from usb should be included by default when Grub4dos is selected as the bootloader. I can have UBUSB copy kicker.img to the images folder on the usb drive (if it doesn't already exist) and put an entry in menu.lst

1.0.0.14 has been uploaded.

A new boot option called "PE-Boot (Compatibility Mode)" is now created by default if Grub4dos is selected for the bootloader and %USB%\images\kicker.img doesn't already exist.

This method seems to boot much faster than standard usb booting and can boot on computers that normally stop at 0x7B BSOD

This works great on my system as well. Also using a Gigabyte MB ( GA-M55PLUS-S3G ) .

I tested the Grub4Dos method and the boot time difference is just great. If this also ends up addressing USB boot compatibility issues as well as the boot speed... I'll be switching to USB finally from the CD/DVD boot methods.

hi there

ive followed your method and have some questions

there are 2 iso's produced "kicker" and "no usb" which one do i use, also

on clicking "test kicker" and pressing enter in qemo i get the following error "The file i2omp.sys cannot be found"

i used fat32 with grub4dos method

regards