Boot a bootable USB through Virtual Machine, What are the options? Options

[kokuhorice]

Are there any Virtual Machine programs which allow to boot from Bootable USB flash drives.
I tried qemu, Virtualbox, Parallels, Microsoft Virtual PC but it seems none of them allow booting from bootable USB flash drives.

They allow to boot an iso or any image file from a USB flash drive, but don't allow booting from a bootable USB flash drive.

[ktp]

VMware allows this.

This post has been edited by ktp: Apr 1 2008, 09:39 AM

[jaclaz]

I tried qemu,....

Did you try this? :
http://www.msfn.org/board/Adding-QEMU-func...sb-t112746.html

jaclaz

[kokuhorice]

I forgot to mention one thing - I am trying to run the Virtual Machine programs on WinXP, I am not an advanced user.

@jaclaz
I had tried exactly what you have mentioned....but failed
I had read the official qemu documentation but wasn't able to understand which command to use or what patches to use (if any). The best I could understand was the command

CODE

qemu -hda //./PhysicalDriveN (where N is the drive number found in the disk manager)

got from here
http://calamari.reverse-dns.net:980/cgi-bi...3bbb75619b572be

The follwing is what I tried in qemu on Windows v0.9.1.
I unzipped the downloaded file to a folder "qemu" in C:/
My UFD is mentioned in the Windows disk manager (Start->Programs->Administrative Tools->Computer Management->Disk Management) as "Disk 6", so I entered the command as

CODE

C:\qemu\qemu -hda //./PhysicalDrive6

I got the error message

CODE

Could not open '\\.\kqemu' - QEMU acceleration layer not activated: No error
qemu: could not load PC BIOS '/c/Program Files/Qemu/bios.bin'

I am not sure if I understood the meaning of "PhysicalDriveN" ....or may be I did something very stupid.

My UFD label is G:. So I also tried the command

CODE

C:\qemu\qemu -boot G

On pressing Enter I got a help file instead.

I don't know what to do.

Also to try VMware do I need to install both VMware Workstation and VMware Player?

This post has been edited by kokuhorice: Mar 31 2008, 09:00 AM

[jaclaz]

You have something "wrong" in how you start Qemu (there is no reason why the bios should be searched for in "/c/Program Files/Qemu/" unless you missed specifying the right command line) AND there is a small "glitch" in the referenced comand line:

qemu -hda //./PhysicalDriveN ...

should be:

qemu -hda \\.\PhysicalDriveN

(forward slashes are used in Unix/Linux, while DOS/Windows uses backwards slashes)
EDIT: though the above is generally correct, Qemu, EVEN in DOS/WIndows uses forward slash!



You should try getting QemuManager:
http://www.davereyn.co.uk/

that includes latest Qemu AND an install routine.

Then either try starting Qemu from commandline or create a new Virtual Machine in QemuManager, without any hard disk, and add "-hda //./PhysicalDriveN" as "Optional Launch Data" (Qemu Manager v. 5) or in last tab "Advanced" as "Specify Optional Command Line Parameters" (Qemu Manager v. 4).

A "full command line" for Qemu is something like:

qemu -M pc -hda //./PhysicalDriveN -m 256 -localtime

jaclaz

This post has been edited by jaclaz: Mar 31 2008, 06:51 PM

[kokuhorice]

Thanks for the help jaclaz

I tried both the commands

CODE

qemu -hda \\.\PhysicalDrive6

and

CODE

qemu -M pc -hda \\.\PhysicalDrive6 -m 256 -localtime

In both cases I got

CODE

qemu: could not open disk image \.PhysicalDrive6

Will try out Qemu Manager and let you know

[ilko]

Here is what I am using having 3 internal hard drives, and one USB stick, which is PhysicalDrive3 according to windows:

qemu.exe -L "D:\Qemu\qemu-0.8.2-windows" -boot c -m 512 -hda //./PhysicalDrive3

or for 0.9.1:

qemu.exe -L "D:\Qemu\qemu-0.9.1-windows" -boot c -m 512 -hda //./PhysicalDrive3

-L specifies where the BIOS file can be found.
Mind you successful booting in QEMU does not guarantee you successful USB boot on real hardware.

Thanks to Jaclaz for the tip.

ilko

edit:
other possible syntax pointing the BIOS file bios.bin is:
qemu.exe -L . -boot c -m 512 -hda //./PhysicalDrive3

I guess . stands for "current folder".

This post has been edited by ilko: Mar 31 2008, 01:20 PM

[jaclaz]

@ilko
Then I was wrong?
Does Qemu still use forward slash even in 2K/XP?

jaclaz

[ilko]

Yep, using forward slash, backward slash is not accepted.
Using XP SP2, QEMU 0.8.2 and 0.9.1.

[jaclaz]

Yep, using forward slash, backward slash is not accepted.
Using XP SP2, QEMU 0.8.2 and 0.9.1.

Thanks, corrected previous post

@kokuhorice
Sorry if I misled you with the backward/forward slashes comment....

jaclaz

This post has been edited by jaclaz: Mar 31 2008, 06:54 PM

[kokuhorice]

Thanks a lot to ilko & jaclaz

I was able to partially boot my UFD in command mode. The trick was to add "-L <path to bios.bin>" and use forward "/" slashes. Omitting "-boot c -m 512" worked too. Even omitting "-hda" worked!

I was also able to partially boot my UFD using Qemu Manager. Qemu Manager is really simple and straight forward to use. Strangely Qemu Manager uses backward "\" slashes

The problem in both the cases was that it never booted completely to the Linux OS desktop that I was trying to boot from the UFD. It always hung up in the last step. I tried several Linux distros and it was same with all of them.
I don't understand why.
But at least now I am able to boot my UFD in Qemu.....I have moved one step ahead

[jaclaz]

You should try making an image file (.iso if a cd or .img if partition) of a (smallish) distro and see if the VM can boot properly from it.
If yes it means that something is "wrong" with the emulation of the USB stick/HD as PhysicalDevice, or may be some more tricks need to be used....

jaclaz

[kokuhorice]

I figured out the booting would hang up at the point when it tried to autoconfigure Xwindow system.
Whenever there was "autoexec=xconf" command in boot, the booting would hang up at the Xwindow autoconfiguration point.
So I removed that part from the boot command and was able to boot completely into the Linux desktop. Obviously removing "autoexec=xconf" had own its effects, but now I know the reason what caused it.
In Virtual Desktop mode Linux is not able to autoconfigure the virtual monitor resolution or something. I thought the reason may be because its trying to boot in the small Qemu Window, so I tried to boot in Full Screen...but still the problem persisted.

Now what to do about it is the question.

[jaclaz]

Now what to do about it is the question.

Try (Qemu Manger v.5) in the "Advanced" tab to set:
1) Standard VGA ->Yes
2) Disable ALL accelerator support ->Yes

(second item should be irrelevant, but having a try is cheap enough)

jaclaz

[kokuhorice]

I tried all four combinations of 1)Standard VGA & 2) Disable ALL accelerator support [(Yes, Yes) (No, No) (No, Yes) (Yes, No)]
None of them helped

[jaclaz]

NO more ideas.

You can try booting this one:
http://www.erikveen.dds.nl/qemupuppy/
this distro is tested under Qemu

Maybe it's just the "xconf" that makes troubles, cannot say if there is a workaround....

Manually creating a xorg.conf should be it, and I read somewhere that some newish releases of SLAX do not use xconf;startx anymore, but cannot say what they se instead of it....


jaclaz

This post has been edited by jaclaz: Apr 1 2008, 08:50 AM

[kokuhorice]

I tried with another distro which I had and which does not use "autoexec=xconf" in its boot command. It worked in qemu.
I guess Slackware based distros that use "autoexec=xconf" command will not work. I have tried "autoexec=startx" which does boot completely but it again it has its own effects.

One more thing that ilko mentioned is true.

Mind you successful booting in QEMU does not guarantee you successful USB boot on real hardware.

I have a distro on a UFD which doesn't boot (due to misconfigured bootcode) in a real machine, but it booted perfectly in Qemu.

Actually my main purpose is to test bootcodes in bootable UFD. Its very painful to restart my pc every now & then to see how the UFD boots with the modified bootcode, so I was looking for a Virtual Machine solution.
But now that the booting may be different in Qemu and real machine, that purpose is not achieved.

I will give a shot at my last hope which is VMware which unfortunately seems too bloated for my job. VMware (330 MB) Vs Qemu (12.5 MB) !!

This post has been edited by kokuhorice: Apr 1 2008, 09:38 AM

[jaclaz]

I have a distro on a UFD which doesn't boot (due to misconfigured bootcode) in a real machine, but it booted perfectly in Qemu.

Actually my main purpose is to test bootcodes in bootable UFD. Its very painful to restart my pc every now & then to see how the UFD boots with the modified bootcode, so I was looking for a Virtual Machine solution.
But now that the booting may be different in Qemu and real machine, that purpose is not achieved.

Well, the only difference in booting "normal" MBR's/bootsectors between Qemu and "real" hardware is that Qemu bios is very "accurate" and uses normally CHS values "proportional" to size of the stick (or disk image), thus a small image/stick may be recognised with a different geometry, LBA based addresses will NOT be addressed by this issue.

Typically Qemu uses a mx16x63 geometry instead of usual nx255x63 one for drives smaller than the 8Gb barrier, but also a number of actual motherboard BIOS do the same....

Read this:
http://www.boot-land.net/forums/?showtopic=1339
(the part that should be of interest to you is near the end of the thread, around post #24 and later)

jaclaz

This post has been edited by jaclaz: Apr 1 2008, 11:55 AM

[hilander999]

One more thing that ilko mentioned is true.

Mind you successful booting in QEMU does not guarantee you successful USB boot on real hardware.

I have a distro on a UFD which doesn't boot (due to misconfigured bootcode) in a real machine, but it booted perfectly in Qemu.

Also keep in mind that the opposite can also be true. We have seen many "Special" configurations over the last few years that will never boot in any virtual machine, but they work perfectly on a real syytem. This is especially true with certain driver configurations due to miss-matched driver loading on virtual hardware.

[jaclaz]

Also keep in mind that the opposite can also be true. We have seen many "Special" configurations over the last few years that will never boot in any virtual machine, but they work perfectly on a real syytem. This is especially true with certain driver configurations due to miss-matched driver loading on virtual hardware.

Yes , but I may add that Qemu has the advantage that has a BIOS that simulates a "legacy" PC, a common used NIC, standard VGA, etc., unlike VMware that has it's own "simulated" peculiar devices, that need extra/different drivers.

WIth this respect, Qemu is "better" than VMware, though, expecially in the early boot phase, is a bit more "picky" than VMware, or at least than the VERY old version I have.

jaclaz