307 replies to this topic

[Blackcrack]

nice

need only to say in the description maybe to be need a driver/USB-Storage-bugfix-package if used WinXP on usb

(maybe want create anyone it for that )

if it's offizially on the File-download and in the Destription is write a need only a fixpack for XP for installing.. because XP it's realy small and perfectly as win32 NT for usb by side of Linux i586

 

thank you very mutch for this Final

 

best regards

Blacky

[Zoso]

hi David, Im trying to figure out how to make VB boot a USB Flashdrive prepared by rufus or Winntsetup with W7.ISO and install W7 to a USB HDD.

since W7 refuses to install on USB HDD Im trying to figure out a workaround. I was using .vhd for install but I dont know how to image the VHD and restore that image on USB HDD.

is there a way your tool can add both USB drives and select boot order to specify which one boots?

also do you know if I can make VB think the USB HDD is not a USB like Qemu does?

I may try it with Qemu and your tool again but from past experience Qemu is very very slow doinga windows install.

nice job on the icon! I was thinking about a combat boot image with a USB symbol on it LOL but I havnt had my graphics software installed in ages.

edit: DUH.. I see the latest has exactly what I mentioned (add another USB) testing now..

edit#2: Dude! its working! installing w7 directly to USB now..

[DavidB]

Hi, Zoso.

I was about to answer when I saw your 2 edits.

Glad that you found how to add the second drive. If later you want to change the boot order you can swap them in the Edit window.

Regarding "if I can make VB think the USB HDD is not a USB" I don't think that would be a problem as long as you don't check the USB drive in VirtualBox Manager >> VM Settings >> USB >> Add filter from device.

[Zoso]

installing from USB Flash to USB HDD worked on without a hitch! Im using VB on W7 on this and will test the same procedure on XPx64 later.

When I will find some time and energy to make a presentation I will publish it at http://reboot.pro/files

seems to be ready for prime time! its very easy and intuitive program to use.

makes VB 10x more useful! Thanks again.

[DavidB]

installing from USB Flash to USB HDD worked on without a hitch! Im using VB on W7 on this and will test the same procedure on XPx64 later.


seems to be ready for prime time! its very easy and intuitive program to use.

makes VB 10x more useful! Thanks again.

 

You're welcome

[DavidB]

New version and thread:

 

http://reboot.pro/fi...chine-usb-boot/

 

http://reboot.pro/to...-boot/?p=174939

[Blackcrack]

Hi,

oh nice, a News in an German ComputerNews COM!




best regards
Blacky

[steve6375]

Please add to WishList - A way of starting VBox and specifying the 2nd Hard disk as the boot disk.

 

The Problem

Normally, when booting from a USB drive, the USB drive is hd0 in the BIOS, but once an OS has booted, the internal hard disk is HD0 and the USB drive is seen as 2nd (or later) drive. With VMUB, the first drive is the USB drive in all situations:

 

Result

When installing an OS to the VBox virtual hard disk and booting from VMUB in VBox, the boot files are placed on the USB drive by the OS installer (because it is seen as the 1st hard disk). This makes the USB drive unbootable (or at least it doesn't boot as expected any more) !

 

 

If only VBox had a way of specifying booting from the 2nd hard disk - we could boot set up VBox so that it boots like a normal system

 

 

An alternative would be to have an option in VMUB to swap over the two drives - i.e.

 

hd0 - Vdisk

hd1 - USB vmdk

 

Then display a message telling the user they must select 2nd drive in VBox BIOS manually as the boot device, in order to boot from USB drive.

 

P.S. Congratulations DavidB on getting into Com! magazine

 

P.P.S Only problem is grub4dos USB drive gives a 'missing MBR Helper' if it is not drive 0 when booting in VBox! Is this a bug in VirtualBox BIOS or grub boot code?

[eblip]

Please add to WishList - A way of starting VBox and specifying the 2nd Hard disk as the boot disk.

 

The Problem

Normally, when booting from a USB drive, the USB drive is hd0 in the BIOS, but once an OS has booted, the internal hard disk is HD0 and the USB drive is seen as 2nd (or later) drive. With VMUB, the first drive is the USB drive in all situations:

 

Result

When installing an OS to the VBox virtual hard disk and booting from VMUB in VBox, the boot files are placed on the USB drive by the OS installer (because it is seen as the 1st hard disk). This makes the USB drive unbootable (or at least it doesn't boot as expected any more) !

 

 

If only VBox had a way of specifying booting from the 2nd hard disk - we could boot set up VBox so that it boots like a normal system

 

 

An alternative would be to have an option in VMUB to swap over the two drives - i.e.

 

hd0 - Vdisk

hd1 - USB vmdk

 

Then display a message telling the user they must select 2nd drive in VBox BIOS manually as the boot device, in order to boot from USB drive.

 

P.S. Congratulations DavidB on getting into Com! magazine

 

P.P.S Only problem is grub4dos USB drive gives a 'missing MBR Helper' if it is not drive 0 when booting in VBox! Is this a bug in VirtualBox BIOS or grub boot code?

 

 

Even though I used the VHD method you recommended over a year ago as a work around for this issue, I've always wanted to come back to this post and thank DavidB and everyone else for their amazing work with the vBox USB boot tool.  I've used it dozens of times and it's been incrededibly useful.

 

So I'd too like to congratulate DavidB on getting some attention to your hard work in the Com! magazine.

 

Sorry it took me so long to express my thanks.

 

Steve, your work is amazing as well.  RMPrepUSB is one of my favorite tools.  Keep up the great work.

[sebus]

Any plans to have 

Virtual Machine USB Boot

ported to Mac?

 

sebus

[DavidB]

Well, couple of times I tried to port VMUB from Delphi 7 to Lazarus. This way you can compile it to Linux and Mac.
The problem is VMUB uses many API Windows functions which need to be replaced with Linux/Mac functions.
But I couldn't find any decent help/documentation for Linux/Mac in Lazarus.
Delphi has great help files (detailed explanations and examples) plus you can find many sites with informations + many forums.
Lazarus has poor help files + their forum is not that good. I posted there a few times and... nothing useful.

Just an example: Total Commander. It was developed in Delphi 2 and recently it was ported into Lazarus (for the 64 bit version). But the author never released a Linux/Mac version (same problems).

[sebus]

Pity, it would be very handy

 

sebus

[erwan.l]

To compile to other platforms you could have a look at deplhi xe or crossfpc.
I am currently moving my sources to xe to be able to compile for x64.

[DavidB]

For VMUB it won't be much improvement if it's made 64 bit. The main reason is because it's not using more than 5 MB of RAM.
About half a year ago I started testing a conversion for Delphi XE5 but I concluded it's not worth the work.
Reasons:
1. No speed improvement + increased RAM usage. For VMUB anyway, I noticed speed improvements for other apps using a lot of RAM.
2. XE5 is about 100 times the size of 7 plus it has a "heavy" interface. There is a noticeable drop in the speed and the stability of the OS after installation.
3. I don't have a few thousand Euro to buy a license.
4. I don't even have money to buy a Mac to test. And, since I have an AMD processor, I can't even use VirtualBox or VMware to emulate one.
5. Since you can't compile for Linux also, the potential "market" is only half.
6. The Mac source compilation is relatively new (added to the XE versions only in the last few years), so less support, fewer forums.

And Crossfpc has its own limitations...

[Gerolf]

In post #14, DavidB suggests "a solution: Using mountvol command to dismount USB drive's volume(s) before starting the VM and to mount them again after closing the VM. All can be done in a batch file so it will be very easy to use..."

 

I tried to write such a script (for booting Qemu, not VBox). Basically it works, but the main problem remains: Writings done to the pendrive from within the virtual machine are still not permanent and thus unvisible to the host system afterwards. Where is my mistake?

 

Best regards,

 

Gerolf

 

-------------------

 

QemuBoot.cmd

@echo off
:: QemuBoot.cmd revision 1 by Gerolf D. Brettschneider (2018/09/17)
:: http://reboot.pro/topic/18217-booting-virtualbox-with-usb-workaround/

:main ------------------------------------------------------------------------
setlocal
if "%1"=="/?" (echo.
  echo QemuBoot, called without arguments, will temporarily dismount current
  echo volume %~d0, map the physical drive it resides on to a virtual hard 
  echo disk and boot the latter in Qemu, setting the virtual machine's RAM
  echo size to 512 MiB and searching the Qemu binary ^(from WeilNetz.de or
  echo RMPrepUSB.com^) in its default location. QemuBoot must be run in ad-
  echo ministrator mode: Copy it to the target drive and right-click on it.
  echo.
  echo Three optional arguments are supported for elevated command prompt:
  echo %%1: drive letter ^(with colon^) of bootable ^(USB^) drive,
  echo %%2: Qemu memory size ^(integer^),
  echo %%3: Qemu binary ^(including path^) & goto :EOF)
if "%1"=="" (set logdrv=%~d0) else (set logdrv=%1)
if "%logdrv%"=="%SystemDrive%" echo Cannot QemuBoot system drive && goto :end
call :wwmic %logdrv% physdrv
if "%physdrv%"=="0" echo Cannot QemuBoot physical drive 0 && goto :end
if "%physdrv%"=="-1" echo Cannot QemuBoot logical drive %logdrv% && goto :end
REM echo Logical drives:
REM wmic logicaldisk get caption, description, freespace, size, volumename
REM echo Physical drives:
REM wmic diskdrive get caption, deviceID, partitions
if "%2"=="" (set mem=512) else (set mem=%2)
setlocal enabledelayedexpansion
  if "%~3"=="" (set bin="%ProgramFiles%\qemu\qemu-system-x86_64.exe"
    if not exist !bin! set bin="%ProgramFiles%\qemu\qemu-system-i386.exe"
    if not exist !bin! set bin="%ProgramFiles(x86)%\RMPrepUSB\QEMU\qemu.exe"
  ) else (set bin="%~3")
endlocal & set bin=%bin%
if not exist %bin% echo Cannot find Qemu binary. && goto :end
echo. & echo About to QemuBoot physical drive %physdrv%, temporarily
echo dismounting current volume %logdrv% that resides on it. 
echo Press Ctrl+C to cancel or any other key to continue . . . & pause > nul
call :wqemu %physdrv% %logdrv% %mem% %bin%
:end
set mem=& set bin=& set logdrv=& set physdrv=
endlocal & pause
goto :EOF

:wqemu :: Wrap "qemu" and "mountvol" -----------------------------------------
:: %1: physical drive number, %2: volume letter (with colon), 
:: %3: Qemu memory size (integer), %4: Qemu binary (including path)
set script=%TMP%\QB%RANDOM%.cmd
:: https://stackoverflow.com/questions/4051883/
::   batch-script-how-to-check-for-admin-rights/27083926#27083926
net session >nul 2> nul
if _%errorlevel%==_0 (  
 (echo @echo off & echo pushd %TMP%
  echo set volID=%TMP%\QB%RANDOM%.tmp
  REM Save volume ID:
  echo mountvol %2 /L ^> %%volID%%
  REM Two ways to dismount the volume (the first ignores other partitions):
      echo mountvol %2 /P
  REM echo ^(echo select volume=%2 ^& echo remove all dismount^) ^| diskpart
  echo set arg=file=\\.\PhysicalDrive%1,if=ide,index=0,media=disk,format=raw
  echo %4 -L . -boot c -m %3 -drive %%arg%%  
  echo set /p test=^<%%volID%%
  echo mountvol %2 %%test%%
  echo if exist %%volID%% del %%volID%%
  echo set arg=& echo set test=& echo set volID=
  echo popd) > %script%  
  REM echo. & type %script% & echo. & pause
  echo.
  echo Volume %logdrv% was unmounted. Please close QEMU before continuing
  echo and wait for volume %logdrv% to be remounted. Do not cancel this batch
  echo process now. Otherwise drive %logdrv% remains inaccessible, and it is
  echo necessary to reassign a drive letter to it in Windows Disk Management.
  echo. 
  %script%
  REM start %script%
  echo Done. & echo.
) else (echo. & echo Please restart QemuBoot in administrator mode.)  
if exist %script% del %script%
set script=
goto :EOF

:wwmic :: Wrap "wmic" to get physical drive number ---------------------------
:: %1: drive letter with colon, %2: variable name for returned physical drive
:: https://msfn.org/board/topic/
::   174825-get-disk-number-from-drive-letter-in-cmd/?
::     do=findComment&comment=1112752
set LDTP=Win32_LogicalDiskToPartition& set %2=-1
for /F "tokens=2 delims=#," %%? in (
  'wmic Path %LDTP% Get Antecedent^,Dependent ^|find /I "%1"') do (set %2=%%?)
set LDTP=
goto :EOF

[Wonko the Sane]

I am not sure to understand.

 

Besides mounting an unmounting, the data seemingly needs to be flushed to the USB device, see post #19 by DavidB.

 

So, I believe you need to use *something like* Uwe Sieber's FFB:

https://www.uwe-sieb...ivetools_e.html

 

Maybe that is the issue?

 

But what is the problem using the tool by DavidB?

 

Wonko

[Gerolf]

I am happy that DavidB provided a working solution for the non-writing problem, but if possible I would prefer a light-weight script using Windows tools that are already present. Does this need a justification? I do not need a GUI for my purposes, I want to understand what happens here, and I am more familiar with scripting languages.

 

I see that Steve Si tried to flush data to the USB device in his StartFromUSB.cmd script for RMPrepUSB:

...
REM Flush cache (esp. if NTFS filesystem still writing cache to slow disks)
sync 2> nul
...

Obviously this does not help as you can see when you stop suppressing the error message generated by sync.exe (at least on Windows 10, 64 bit). DavidB uses this code for flushing (found in start_VM.dpr within "QEMU Starter source.zip", post #44):

procedure FlushToDisk(sDriveLetter: Char);
var
   hDrive: THandle;
begin
   hDrive := 0;
   try
      hDrive := CreateFile(PAnsiChar('\\.\' + sDriveLetter + ':'), GENERIC_READ or
         GENERIC_WRITE, FILE_SHARE_READ or FILE_SHARE_WRITE, nil,
         OPEN_EXISTING, 0, 0);
      FlushFileBuffers(hDrive);
   finally
      CloseHandle(hDrive);
   end;
end;

I do not understand why this flushing should be required (except for safety) as USB devices by default are not cached (see Device Manager). Moreover, it is not the host machine's writes to the USB device that always get lost but those of the virtual machine. Okay, I will spend some time investigating this, in the hope I can find a Windows command for flushing, but at the moment I wonder whether DavidB's dismounting routine does some magic the mountvol or diskpart commands omit:

function DismountVolume(ADrive: char): Boolean;
const
   FSCTL_DISMOUNT_VOLUME = (9 shl 16) or (0 shl 14) or (8 shl 2) or 0;
var
   VolumeName: string;
   BytesReturned: Cardinal;
begin
   Result := False;
   VolumeName := Format('\\.\%s:', [ADrive]);
   SetLength(VolumesHandles, Length(VolumesHandles) + 1);
   VolumesHandles[High(VolumesHandles)] := CreateFile(PChar(VolumeName), GENERIC_READ or GENERIC_WRITE,
      FILE_SHARE_READ or FILE_SHARE_WRITE, nil, OPEN_EXISTING, 0, 0);
   if VolumesHandles[High(VolumesHandles)] = INVALID_HANDLE_VALUE then
   begin
      LastError := GetLastError;
      Exit;
   end;
   Result := DeviceIoControl(VolumesHandles[High(VolumesHandles)], FSCTL_DISMOUNT_VOLUME, nil, 0,
      nil, 0, BytesReturned, nil);
   if not Result then
      LastError := GetLastError;
end;

At least I haven't studied yet what must be known about the FSCTL_DISMOUNT_VOLUME stuff. Is there a kind of device lock if no flushing was done before dismounting?

 

Gerolf

[Gerolf]

In the meantime I downloaded a newer sync.exe (the one shipped with RMPrepUSB dates from 1999) from live.sysinternals.com. (The new one, called without arguments, doesn't give an error message and positively lists which volumes are being flushed. The USB volume is missing unless its drive letter is given as argument.) Next I downloaded FFB.exe from uwe-sieber.de. In both cases I tested the 32 and 64 bit versions and also inserted a "timeout 2", but results are the same: It doesn't help. So I'm getting the impression that a missing cache flushing is not the issue.

 

Gerolf

[Wonko the Sane]

I am happy that DavidB provided a working solution for the non-writing problem, but if possible I would prefer a light-weight script using Windows tools that are already present. Does this need a justification? I do not need a GUI for my purposes, I want to understand what happens here, and I am more familiar with scripting languages.

Of course you don't need any justification and - from my personal point of view - using scripting language is a very good thing, I asked to understand if you had found a particular issue/problem bug in the existing solution, possibly using it under a newish Windows version.

 

Wonko

[cdob]

So I'm getting the impression that a missing cache flushing is not the issue.

No solution, more questions:
Does win 10 rescan the USB file system, if the USB device is reconnected after qemu run?
Or does win 10 restore the file system, before qemu did run?

What happens, if you run mountvol disconnect, qemu, close qemu.
Disconnect the USB device physically and reconnect the USB device?

Next step: run mountvol disconnect, qemu, close qemu,
Goto device manager, disable the USB drive and enable the USB drive.
What happens?

[Gerolf]

Just returning from my jogging tour, and this comes close to what I decided to investigate today. I saw that FFB.exe also offers support for "-d -f" switches to "force dismount" - but then fails to do this here. So I wonder if there are different states of being dismountable or dismounted a USB device might get into - or if my script, already being too complex, just imposes a kind of nesting error.

 

Gerolf

 

 

[Gerolf]

As you can see in the :wqemu routine, my QemuBoot.cmd script mainly generates a temporary batch file named %TMP%\QB%RANDOM%.cmd that gets executed afterwards. It resolves a few variables for the particular machine it runs on. On my old desktop PC which has several hard disks it looks like this (removing "@echo off" at the beginning, a pushd-popd pair, and three variable unsets at the end):

set volID=C:\Users\Gerolf\AppData\Local\Temp\QB884.tmp
mountvol O: /L > %volID%
mountvol O: /P
set arg=file=\\.\PhysicalDrive7,if=ide,index=0,media=disk,format=raw
"C:\Program Files\qemu\qemu-system-i386.exe" -L . -boot c -m 512 -drive %arg%
set /p test=<%volID%
mountvol O: %test%
if exist %volID% del %volID%

So everything strips down to just eight command lines that can be run as a batch file from the system drive at an elevated command prompt. I see the "-L ." must be removed as argument here to let Qemu start. The "mountvol O: /P" can be replaced with "(echo select volume=O: & echo remove all dismount) | diskpart" or "FFB O: -d -f", the latter at least working here. But the non-writing error already appears at this point.

Going to bed now...

 

Gerolf

[steve6375]

Presumably the USB drive has only one volume/partition and it is an NTFS volume?

[Gerolf]

Couldn't sleep, your questions still being unanswered. Yes, my USB drive has one single NTFS partition, and I made it Grub4DOS bootable using Rufus. The newer versions of Windows 10 again are able to assign drive letters to more than one partition on such a device, I guess, like it was the case in the days of Windows 98/ME, but I havent't tried this yet. So the "remove all dismount" method using diskpart will be the best to deal with this option, and more care must be taken then to reassign multiple drive letters. This would be a problem to solve later.

"Does win 10 rescan the USB file system, if the USB device is reconnected after qemu run? Or does win 10 restore the file system, before qemu did run?" - If I cancel the batch file to kill the Qemu process, my drive O: remains inaccessible, and I have to restore the drive letter using Disk Management; but if I finish Qemu itself, the batch run continues, and "mountvol O: %test%" gives access to the drive. I think a rescan takes place then, not a restore, but how could I test? Maybe I do not understand your question. By the way, this mountvol command and the previous "mountvol O: /P" are audible, letting the mechanical drives rumble.

I split up my eight-liner into three parts to follow your suggestion of unplugging or disabling the USB device temporarily. I added pause commands so that I can start these batches via right-clicking in Windows Explorer and still read the command lines and possible error messages (mountvol says "access denied" if no administrator privileges are given, dismounts the drive anyhow, but Qemu cannot start then, and remounting fails):

 

unmount.cmd:

set volID=%TMP%\QB884.tmp
mountvol O: /L > %volID%
mountvol O: /P
REM (echo select volume=O: & echo remove all dismount) | diskpart
REM FFB O: -d -f
pause

qemurun.cmd:

set arg=file=\\.\PhysicalDrive7,if=ide,index=0,media=disk,format=raw
"%ProgramFiles%\qemu\qemu-system-i386.exe" -boot c -m 512 -drive %arg%
pause

remount.cmd:

set volID=%TMP%\QB884.tmp
set /p test=<%volID%
mountvol O: %test%
if exist %volID% del %volID%
pause

Now I can run these batch files one after another and also temporarily unplug or disable the USB device, either before or after executing qemurun.cmd, but whatever I do, I cannot write a file to the USB device from within Qemu. Onto a VHD, I have installed MS-DOS 5.0, which quickly boots up into DOSSHELL. When I press Alt+F4 to exit, a message windows pops up that I had never seen before, saying: "Initilization File Error. There was an error writing the file DOSSHELL.INI; changes were not saved to disk at this time." And now this happens again and again.

Gerolf

[Wonko the Sane]

... and, if you repeat the attempt with exactly the same stick, the same OS and the same Qemu command, but using the original tool by DavidB it works?

 

Wonko