Hello !

We are the developpers of MobaLiveCD, a little app that allows users to run their LiveCD from Windows without burning them to a DVD (using qemu).

We just developped a little portable utility called MobaLiveUSB, that allows you to test your USB multiboot from Windows, without rebooting your computer, in a single click. We wanted to share it on this forum as we made it initially in order to test our thumb drive boot menu (made with grub4dos, thanks to the suggestions found here).

You just have to

1. Download MobaLiveUSB from here: http://mobalivecd.mobatek.net/MobaLiveUSB_0.1.exe

2. Copy the EXE file to somewhere in your USB flash drive

3. Run MobaLiveUSB from your USB flash drive.


We really appreciate this forum and we wanted to share this tool. It has not been released publicly, because we thought that you might have some interesting ideas of features to add before releasing it. So please, don't hesitate to give us any suggestion in order to improve this little tool!

We hope that you will find this little app usefull!

Bye

Nice little tool! tried it out and it seems to work great, great for the comptuers where i dont' have vmware to test

~Fizz

FYI - you can't test USB-boot in VMware - so if this tool does what it claims it does, it is the only tool to test this I ever heard about.

When I tried it I got:
The application was BartPE and it's I:\MININT\SYSTEM32 folder contains a RPCRT4.DLL, but no RPCRT4.dll.

Test was on a XP SP3 machine.

And the USB boots BartPE just fine.

This is not anything new and I know of a tool that does the same thing.

You also have to worry about us testing this for free for a few months and then it turning into paid software.

You can boot a pysical usb drive with QEMU using \\.\PhysicalDrive? where "?" is the drive number.


I've had a "Test Boot" option in my UBUSB (Ultimate Boot USB) utility for quite awhile now.

@SteelTrepid: You are right, this is not something new, but we didn't find any other program that made it easy like it :
- this utility automatically creates an emulation environment with the appropriate amount of RAM and the best parameters for your computer
- it automatically chooses the Physical drive number, depending on the partition you are running it from
--> it really is a single click testing program in a single portable and small executable...

Of course some advanced users may already use another trick to test their USB multiboot thumb drives, but we thought that this one might be of some interest, especially for users who want to put a portable testing utility directly into their thumb drive...

I should have mentionned that this program is free of course and it will remain free. Sorry for not precising this point...

Anyway, I hope that even if it is not a very innovative tool, it will be of some help for you, and I still hope to receive some suggestions in order to improve it!

Bye

I think it's clever. I just wish it worked for me.

Thank you Ed_P!

About the issue you have, could you tell me if the error message "STOP: c0000135 [...]" occurs after seeing the bootloader or if it occurs immediately and you don't even see the bootloader? Also, can you tell me which trick you used to put BartPE onto your USB drive (PeToUsb, Grub4Dos with ISO emulation, etc...)

I am currently building a BartPE CD-ROM in order to test and hopefully fix this issue...

Bye

Seems to work fine,
but missing network support , well did'nt expect that.

Regards Gray.

Well strange things happened,
second time I booted the USB stick , the network worked.

This utility is perfect to test USB booting will work.
Until now I have been using Vmware.

Regards Gray.

@MobaTeam
Ed's issue is with FiLeCaSe.

RPCRT4.DLL is not RPCRT4.dll

This could be part of text mode setup, or a simple overlook on the part of your program concerning file case issues.
I dont use usb booting, so I can't test this one, but it does haver merrit, even if not an original idea.

Sorry, I should have included that. It occurs after the bootloader runs. BartPE was put on the stick using PEtoUSB and in that it boots BartPE fine normally I was surprised to see the error.

I don't recall if the error occurred before the Windows screen came up or not and will retest and report back later.

You don't need to burn a CD PEtoUSB builds from the BartPE folder that would go into building the ISO.

@hilander999 good to see you back.

@gray: thank you very much for your tests. I will try to use another network option in the next build in order for the network detection to be safer.

@hilander999: Thank you for your help: it seems that I did not read Ed_P's previous post carrefully... It's a strange behaviour as MobaLiveUSB should not wonder whether file names are uppercase or lowercase... In fact, with a FAT/FAT32 or NTFS formatted drive, the BartPE startup should not complain about file case as it is case insensitive...

@Ed_P: I just generated a basic BartPe and copies it to my thumb drive with PeToUsb and it worked correctly, so this is bad news for me as it seems that it will not be easy to reproduce the bug you are encountering...

Where the file system is case insensitive, textmode setup (txtsetup.sif) is case sensative as designed by the mighty MS.
There are several things that could be to blame and reproducing the error is the hard part.

@Ed
Check your plugins for one copying that file with the wrong filecase because by default it does get copied in upper case.

he USB is formated as NTFS, I used the PEtoUSB utility found here: http://ezyuzin.livejournal.com/2729.html

All BartPE file casing is handled by infCacheBuild and using the filecase.ini file shown here: http://www.911cd.net/forums//index.php?sho...mp;#entry132958

I'm off to retest now.

Strange results:

My 1st test went past the boot window, the Windows booting window and the BartPE window before ending with this:



My next try went all the way with BartPE booting successfully and my seeing that I have a X:, B: and CD drives available.

RPCRT4.DLL is still uppercase.

On my next test the booting screen completes



then QEMU disappears. And I recall this happened initially when I tested yesterday.

And on my last test everything came up again.

Either there is memory corruption or things are getting changed on the USB to cause the inconsistent results.

BTW BartPE's System Property display shows that QEMU is running with RAM of 256, this on a 1GB RAM system. A slightly larger QEMU allocation might stablize the results. Allowing MobaLiveUSB to accept startup arguments could make testing quicker and make the utility more useful.

And asking the user if they want KQEMU installed might be nice, and wise, also.

Hello !

@Ed_P: Thank you for all your tests: your results are really helpfull!

I think that you found the problem: the uncertain results that you obtain (sometimes it works and sometimes not) are caused by the amount of memory that is allocated for qemu.

In fact, when you start MobaLiveUSB, it will calculate your free RAM (this number can change from time to time!) and it will allocate half this free RAM to your virtual machine. I like the idea of not setting the RAM amount for the VM manually, so I will perhaps put a sort of warning if it is lower than 512MB.

About Kqemu, for the moment, MobaLiveUSB detects if you have admin priviledges on your computer, it runs it, then after emulation is stopped, it stops it. I will add a popup for asking whether to use or not kqemu, thank you for this suggestion!

Thank you again for your tests, I'm really happy to see that this little program could be of some interest!

I will send you the 2nd version in a moment.

Bye

Why not have both an automatic calculation for free RAM & a way to set it manually?

@hilander999: Ooops, I saw your last post too late: I already uploaded the 0.2 version of MobaLiveUSB with the changes of kqemu and RAM calculation...

You are right, I didn't want to put any interface to this app in order to make it easy to use, but at last, it seems that it will be better to add a little main window in order to choose the amount of RAM to use, the use of kqemu and also the creation of a virtual hard-drive (for those who want to test an XP installation from USB drive for instance).

For the moment, the 0.2 version without your last suggestion included (sorry) is available here: http://mobalivecd.mobatek.net/MobaLiveUSB_0.2.exe

Bye

@MobaTeam
I haven't tested the app, but from what I have seen in the thread, it seems to me like this app is a "wrapper" around Qemu that mounts the USB device as \\.\PHYSICALDRIVEn and attempts booting from it, i.e. something similar to this:
http://www.msfn.org/board/Adding-QEMU-func...ul-t112746.html

Am I correct in this assumption?

jaclaz

Yes why not set it , and give the users the possibility to change it within a few minutes.

Have testet it on 3 different XP systems and and two different ways of USB booting.
Works fine, but all of these have a lot of ram.

Regards Gray.

Hello!

@jaclaz: Yes, you are totally correct and this app exactly corresponds to the topic that you linked. I just wanted an automated "wrapper" for qemu that determines the current PhysicalDrive number and the appropriate RAM to allocate... The only hard part to code was to determine this physical drive number.

By the way, I don't know if this could be of some interest for you or anyone else, but I could also generate a simple commandline EXE that will output the corresponding PhysicalDrive number for a given partition letter...


@gray: thank you for your tests. I am currently working on a simple interface for setting these basic parameters. I will keep you informed!

I would like this utility, it is not so easy to obtain the phys. drive number.
I am thinking of writing a utility which will implement the cfadisk driver
for USB flash devices automatically, Then partitioning the device and
transferring boot loaders , bartpe o.a to the USB device.
This would be easy below Vista but not so easy running below XP.
And i could use the phys. drive number.

Well just tried your utility booting a 2GB Verbatim Store and Go Pro , which was write ptotected,
worked fine.
I edit this post , a little to fast , the system was booting when I wrote this, and it seemed to work,
but NO, PNP detecting are going into some sort of loop, and QEMU stops responding for some time,
then resumes and stops again, this is NOT working.
This stick will normally boot even if write protected, but not running in this environment.


Regards Gray.

I would directly have use for such a small app ...

Sure, it would be interesting.

BTW,
this has been experimented a bit, see here:
http://www.msfn.org/board/compatible-batch...-o-t124539.html

Most notably, waiting for Victor888's new batch, using the "dd for Windows" by John Newbigin with the --list parameter:
http://www.msfn.org/board/compatible-batch....html&st=24
gives you all needed data to "couple" drive letters to Physicaldrives

jaclaz

Ooops, it seems that it was already made in the VBScript from your link... I should have asked you before!! In fact, I'm a newbie in PE environment creation and I should have search more for some existing solutions...

Anyway, the EXE file is available from here: http://mobalivecd.mobatek.net/MobaGetPhysicalDrive.exe (22KB)

---
Here is the little help:
Use "MobaGetPhysicalDrive.exe -h" for help

MobaGetPhysicalDrive.exe [<Drive_Letter>] [NumberOnly]
- Drive_Letter: the letter assigned by Windows to the partition (without the ":")
If you ommit this parameter, it defaults to the current partition.
- NumberOnly: Returns only the number of the PhysicalDrive, instead of the full path

Example: MobaGetPhysicalDrive.exe F
---

I also forgot to say that if you need some little developments (GUI for commandline tools, system apps, etc...), I would be happy to help. For the moment, I am considering developing a little app which aims to convert any picture files to a Grub4Dos-compatible xpm picture. Do you know if this already exists (I prefer asking before starting to work this time )?

Thanks will try it and cross-post on MSFN.



You mean you offer yourself to "work" for me?
I sure have a lot of "missing programs" and noone willing to write them....

The "reference" tool is image-magick, see here:
http://www.msfn.org/board/Multiple-Partiti....html&st=14
which is scriptable.
Maybe a better algorithm to convert from whatever to 14 colours may be useful, but, if I am allowed to make a suggestion about what is missing for grub4dos is a new gfx patch and build:
http://www.911cd.net/forums//index.php?showtopic=21641

jaclaz

P.S.: quickly tested program, it does not work for devices such as CD (it's all right, CD's have NO physicaldrive assigned ) or Removable media like SD cards adapters, prompts for inserting the media, but actually for these devices physicaldrive and drive letter are assigned even if media is not present

Well in fact I don't think that I have enough knowledge to help on a project like the gfx patch: I love grub4dos and I worked a lot with grub too, but I know only a very few things about BIOS, bootloaders and operating systems! I will read carrefully the post you linked and ask a friend (in fact the nickname "MobaTeam" stands for my 2 friends and I) for some information...
Thanks again!

A thought or two about KQEMU:

If the host already has it installed you don't need to install it. By the same token if the host has a version installed when MobaLiveUSB exits it should not delete the host's version.

If MobaLiveUSB installs KQEMU and QEMU aborts, the KQEMU is left on the host. Rerunning MobaLiveUSB needs to take that into account when starting, and I think it should delete it if it's the MobaLiveUSB version before continuing. If the user then selects not to run with KQEMU it will not be gone.


I like the concept of simply clicking the exe and it runs with no input required. I also like the idea of being able to tweak the options to fit my needs. A GUI is nice but I prefer blind options like those found in a ini file, you set them once and are done. If the exe finds a ini file it uses it else it uses default values.

OK, so given these suggestions, I propose the following compromise:

If there is no INI file found, the EXE file starts a little window with the following settings:
- amount of RAM allocated to the virtual environment
- use a virtual hard drive
- use kqemu (with the fixes suggested)
- enable audio
- enable networking

Of course, you can save these parameters into an INI file or use them one-time.

If an INI file is found and if it has been created on the same computer, then the emulation starts without asking anything (if you run it on another computer, the RAM settings will need to be changed)...

At last, this is cool, it can become a useful little utility!

I suggest that the ini be created with the option/parameter values used if an ini is not found.

If you are going to keep the values specific to each machine you could make the ini's name include the machine id.

But a default ini should also be an option. Thus when used on a new machine a user's specific set of options can be used rather than requiring the GUI screen each time.

Hi MobaTeam



Thanks for the MobaGetPhysicalDrive , works perfect.

And perhaps a change request for Mobalive (QEMU) if possible.
If you dont activate the mouse in the emulator when booting , it will close down.
Maybe this could be changed.

Regards Gray

Is MobaLiveUSB still being developed/supported? Is there a version .3 somewhere with ini support?

When I use MobaLiveUSB .2 to boot my BartPE system on a USB stick BartPE boots OK but there is no network connectivity. Older versions of QEMU needed a network TAP to support networking? Does MobaLiveUSB need one also and if so where do we get it?

Wow, this MobaLiveUSB_0.1.exe util is perfect for testing my syslinux.cfg menu changes. I've searched high and low for a syslinux bootmenu previewer/editor, and now I've found one!

Hmm.. Virtual box seems to also allow this if you edit the VMDK in order to point back to the USB drive, shouldn't the same method work for VMware as well?

http://www.opticality.com/blog/2009/01/12/...-multiboot-usb/ (read last paragraph)

Very nice tools and version 2.1 is out

MobaLiveCD_v2.1



MobaLiveCD key features:

Any updates to MobaLiveUSB??

Likely the MobaLiveCD_v2.1 including the function of MobaLiveUSB, start "MobaLiveCD_v2.1.exe", click on the button of "Run the LiveUSB", select the correct USB thumb drive , then