Jump to content











Photo
- - - - -

Boot windows 10 vhd from usb (also ramboot)


  • Please log in to reply
34 replies to this topic

#1 favorinus

favorinus

    Member

  • Members
  • 38 posts
  •  
    Argentina

Posted 01 August 2020 - 01:31 PM

Hi,

 

I am trying to make a stripped down windows 10 vhd for booting from USB.

My goal is to have a small windows 10 running in RAM loaded from USB. I have done this with XP and windows 8, but now I am stuck with windows 10.

 

steps I made: 

 

removed the useless things from windows 10 with Winreducer. 

install the produced ISO with mode: LZX into VHD with WinNTsetup 4.2.1

 

run the vhd in virtuablx to check anything running smooth and install svbus 1.1 while in virtualbox running.

 

prepare usb stick for BIOS booting: format it one partition NTFS with grub4dos booting.

 

title W10Q1900.vhd  RAMDISK  - 2 GB
find --set-root --ignore-floppies /W10Q1900.vhd
map --mem /W10Q1900.vhd (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr
 
title W10Q1900.vhd    FILEDISK  - 2 GB
find --set-root --ignore-floppies /W10Q1900.vhd
map /W10Q1900.vhd (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr

 

the RAMdisk is booting fine, the pendrive is also mounted 

 

the FILEDISK gives me an inaccessible boot device BSOD

 

what can I do to correct this, seems like a mass storage driver problem ? How to check and correct.

 

thank you!


Edited by favorinus, 01 August 2020 - 01:32 PM.


#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 01 August 2020 - 02:21 PM

It's strange, SVbus has been developed exactly because previous drivers had sometimes those issues with Windows 10:

http://reboot.pro/to...b4dos/?p=207138

 

I cannot see anything that is not "as it should be" in the procedure you report for the creating of the image. :unsure:

 

The "inacessible boot device" (0x0000007b) BSOD is definitely connected to the mass storage drivers in use, but if there was some sort of incompatibility with SVBUS, it would have probably created the same issue also as Ramdisk. :dubbio:

 

Can you try (only for the sake of the experiment) to copy the W10Q1900.vhd to the internal hard disk (still booting from the pendrive, i.e. leaving the grub4dos on the USB stick, but removing - or renaming - the W10Q1900.vhd in the pendrive)?

 

Maybe the issue is in the USB drivers, this way they are outside the protected mode part of the booting.

 

:duff:

Wonko


  • antonino61 likes this

#3 favorinus

favorinus

    Member

  • Members
  • 38 posts
  •  
    Argentina

Posted 01 August 2020 - 03:20 PM

I have copied the vhd to a hdd and now it's booting fine with filedisk booting.

so the issue is with the usb mass storage drivers, they are install but not loaded early enough? 

 

what can I do now?



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 01 August 2020 - 04:05 PM

I don't know.

 

Windows 10 should have "native" and "working everywhere" USB (3.0) drivers :unsure:

 

Could it be - for some reasons - that your "passing through" VirtualBox has changed some settings related to the USB bus?

 

Now that you are filedisk booted from the .vhd on hard disk can you check that everything related to USB is OK?

 

Or maybe it has been already "fixed" by booting on the "real hardware".

 

I.e. if you now switch off the PC, reboot to your normal OS and copy back the booted .vhd from disk to USB stick, is it still the same?

 

You can also try (but I don't think it will make any change) to use the grub4dos USB stack ( add "usb --init" as first line in your tiltle(s) in menu.lst).

 

:duff:
Wonko 



#5 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 02 August 2020 - 06:01 PM

@ favorinus

 

This are examples for Wimboot VHDs as filedisk or Ramdisk having SvBus driver installed (only required for Ramboot), using grub4dos 0.46a last version:

 

Ramboot from internal disk:

title 10x64-WB.vhd - SVBus  RAMDISK  - map as (hd) for WIMBOOT
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

Filedisk booting from internal disk:

title 10x64-WB.vhd - SVBus  FILEDISK - map as (hd) for WIMBOOT
find --set-root --ignore-floppies /10x64-WB.vhd
map /10x64-WB.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr


Ramboot from external disk:

title 10x64-WB.vhd - SVBus  RAMDISK - map as (hd-1) for WIMBOOT

find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr


Filedisk booting from external disk:

title 10x64-WB.vhd - SVBus  FILEDISK - map as (hd-1) for WIMBOOT
find --set-root --ignore-floppies /10x64-WB.vhd
map /10x64-WB.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

Booting Wimboot VHDs has extremely precise requirements to first find the info into the new virtual drive (the VHD during booting) and also let the pointers inside the VHD find the source.wim coupled to it, (located on the USB device).

 

About your issue:

 

FILEDISK gives me an inaccessible boot device BSOD

 

This is caused when during boot the internal info contained into the VHD or the associated Wim file is not found, and may happend during RAMboot and/or filedisk booting that's the reazon to use root (hd-1,0) line on previous examples, and then avoid this issue in all cases:

 

Use yor actual titles.

Adapt previous commands with your VHD name.

 

Where using:

root (hd-1,0), the USB device is hd0, and the virtual disk is or will be hd1

 

Actually you have root (hd-0,0) on all your commands.

 

If this don't solve your issue, it is also possible you have something wrong on the internal BCD of your VHD (I really don't think it is the case). But it is better to give you also following info:

In that case you could also use UEFI_MULTI or VHD_WIMBOOT from wimb, if using a NT 6.x  MBR on your USB, both make  entries on BCDs + an entry for grub4dos grld.mbr and add it and grld, and make also requiered entries to menu.lst for filedisk and Ram booting, and additionaly make an enty into the VHD internal BCDs.

 

EDIT: See attached photo (as a guide) of the generic BCD valid when the VHD is on the root of a drive, wich is good when filebooting or rambooting from internal and external mass storage devices.

 

alacran

Attached Thumbnails

  • BCD into the VHD.png


#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 03 August 2020 - 08:20 AM

@alacran

Ramdisk booting already works just fine.

 

The filedisk booting from USB (but not from internal disk) is the issue at hand.

 

Now you explain to me which differences there are between:

 

 

Filedisk booting from external disk:

title 10x64-WB.vhd - SVBus FILEDISK - map as (hd-1) for WIMBOOT
find --set-root --ignore-floppies /10x64-WB.vhd
map /10x64-WB.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

and:

 

 

title W10Q1900.vhd FILEDISK - 2 GB
find --set-root --ignore-floppies /W10Q1900.vhd
map /W10Q1900.vhd (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr

 

As I am completely missing them.

 

:duff:

Wonko



#7 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 03 August 2020 - 11:49 AM

My suggested commands for Ramboot and for filedisk boot, have proven to be reliable on all scenarios to boot any VHD, including standard VHDs, Wimboot VHDs and Compact installed VHDs, and so far are same used into UEFI_MULTI and WIMBOOT_VHD programs by wimb for any kind of VHDs.

 

In fact they are based on karyonix info.

 

Then I could say with no dubt they are the only fullprove option valid for any kind of VHD.

 

Unfortunately the info is in several parts on some post located on this topic, where you and I were involved too:

 

http://reboot.pro/to...e-8#entry209770

 

Also this were my finding during my test:

 

http://reboot.pro/to...s-svbus-driver/

 

EDIT: also don't forget the final comment on my previous post:

 

If this don't solve your issue, it is also possible you have something wrong on the internal BCD of your VHD (I really don't think it is the case). But it is better to give you also following info....

 

 

alacran



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 03 August 2020 - 01:27 PM

I don't want to be grumpier than usual, but the OP issue is NOT about Ramdisk booting that works just fine. (so it makes no sense to post a solution about a non-issue).

 

The issue is about Filedisk booting (and Filedisk booting from USB ONLY).

 

You cannot (actually you can just fine :)) post a suggestion that is (seemingly) functionally IDENTICAL to what the OP is already using (and failing with) unless you explain in what it is different (and hopefully better).

 

The point (there and in a different context) was about assigning something to (hd) (next disk drive) and chainloading (hd-1) i.e. last drive before the next one:

In this post you are suggesting to assign something to (hd-1) and then chainloaing the same (hd-1), so it seems to me very, very like using in both lines (hd0).:dubbio:

 

:duff:

Wonko



#9 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 03 August 2020 - 03:45 PM

 

In this post you are suggesting to assign something to (hd-1) and then chainloaing the same (hd-1), so it seems to me very, very like using in both lines (hd0).

 

Agree.

 

The idea was to let favorinus know this general use commands, without looking/analyzing very carefuly he should get similar results with hd0, on standard VHDs.

 

Then the only other possible cause of the issue should be on the BCD of the VHD.

 

I'm going to edit that post and add a picture of the generic BCD valid when the VHD is on the root of a drive, wich is good when filebooting or rambooting from internal and external mass storage devices.

 

Thanks for your comment into my quote, it was the key that made me look the similar results, on standard VHDs.

 

It is good someone let you know when you misslook something.

 

alacran



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 03 August 2020 - 04:34 PM

Then the only other possible cause of the issue should be on the BCD of the VHD.
 
I'm going to edit that post and add a picture of the generic BCD valid when the VHD is on the root of a drive, wich is good when filebooting or rambooting from internal and external mass storage devices.

I don't know. :dubbio:
 
The error is a 0x0000007b, which should happen post BCD and definitely is related to mass storage device (or its drivers).

If you prefer, the chainloading of BOOTMGR must be working (itherwise he would have a grubdos error), then the BCD must be found (otherwise he would have a "missing BCD" error 0xc0000034, "The Boot Configuration Data file is missing."), but it goes a bit further, either WINLOAD.EXE is also found (or he would have a 0xc000000f "The selected entry could not be loaded because the application is missing or corrupt.") or - and this is what I believe - the issue happens within BOOTMGR but post BCD the sheer moment the devices are re-enumerated due to the "switch" between real and protected mode, i.e. between BCD and WINLOAD.EXE.

 

Of course it doesn't happen on Ramdisk (as the whole stuff is already loaded in memory and mapped correctly by grub4dos) and - less obviously but still making sense - it doesn't happen if the VHD is on the internal disk (surely accessible).

 

So what remains is something connected to the BIOS (these days unlikely), to USB drivers (more likely) or to the particular stick used (rare but possible[1])

 

There was something "loosely" similar to this related to installing XP from USB:
https://msfn.org/boa...er-d-and-not-u/

 

:duff:

Wonko

 

[1] Anecdata, many years ago I removed the serial number from a USB stick while making an unrelated experiment with it, then several weeks later tried a particular software (sort of portable dektop/environmentm cannot really remember the name) and there was no way I could install/run it on that particular stick (but it worked just "fine" - actually it was essentially some crappy stuff - on *any* other stick I tested it on). Long story short, after I re-used the stick "Manufacturer Tool" to re-assign to the stick a serial, the program started working even on that stick.  



 



#11 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 03 August 2020 - 06:22 PM

 

The error is a 0x0000007b, which should happen post BCD and definitely is related to mass storage device (or its drivers)...

 

So what remains is something connected to the BIOS (these days unlikely), to USB drivers (more likely) or to the particular stick used

 

What I would do then (free options first, starting with possible human errors):

 

It doesn't hurt to verify the BCD first, just to descart that something is wrong in it.

 

Check current Bios settings related to USB, just to descart that something is wrongly selected.

 

Try same USB on all MBR USB port available, usually they supply better Volts, Ampers and transfer speed than front ports.

 

Try booting on another PC with current USB device.

 

Check MB/PC manufacturer page to see if there is a new Bios version, and install it if available, even if there is no mention related to USB, (sometimes they don't mention all changes/improvements).

 

Try using another USB device (preferable new and a reputable brand), to discart incompatibility.

 

If nothing on this list solves the issue buy a new PC (just joking).

 

alacran



#12 favorinus

favorinus

    Member

  • Members
  • 38 posts
  •  
    Argentina

Posted 03 August 2020 - 09:52 PM

thank you all for the replies, but still no joy,

 

the internal bcd is the same as posted by alacran,

I will try another usb stick

 

the bsod also occurs on an another PC.


Edited by favorinus, 03 August 2020 - 10:22 PM.


#13 favorinus

favorinus

    Member

  • Members
  • 38 posts
  •  
    Argentina

Posted 03 August 2020 - 11:29 PM

As a work-around I tried to boot the  vhd as FILEDISK using windows 10 native vhd boot.
 
first boot to grub4dos
 
then
title Windows 10 native VHD
chainloader /bootmgr10
 
this loads  /boot/BCD
 
which will look for W10Q1900.vhd 

 

this results in a
 
VHD  BOOT INITIALIZATION FAILED

 

????



#14 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 04 August 2020 - 02:46 AM

After reading again your first post looking very carefuly if I missed some info, this are my findings.

 

From your fist post:

 

 

My goal is to have a small windows 10 running in RAM loaded from USB. I have done this with XP and windows 8, but now I am stuck with windows 10.

 

Does the 8 VHD boots fine as filedisk and ramdisk on your current USB device?

 

If the answer is NO, your USB maybe is not working fine or is not fully compatable with your PC under certain circunstances.

 

If the answer is YES, then the problen could be related to the following:

 

 

steps I made: 

 

removed the useless things from windows 10 with Winreducer.

install the produced ISO with mode: LZX into VHD with WinNTsetup 4.2.1

 

run the vhd in virtuablx to check anything running smooth and install svbus 1.1 while in virtualbox running.

 

If you installed the Virtual Box additional package it has its own drivers and other things to improve the VM funcionality, perhaps this overwrited the original USB drivers, part of them, or the services required to start the driver, the entries on the reg file controling the timings of this service, etc

 

About SvBus driver, on post No. 115 the author says:

 

 

SVBus V1.2 Virtual SCSI Host Adapter for GRUB4DOS

Today we present the new virtual SCSI driver SVBus version 1.2 for use with GRUB4DOS. SVBus V1.1 was not working correctly in combination with Windows 10 x64 Build 1803 and later. This could lead to a system crash with BSOD and the error CRITICAL_PROCESS_DIED. We discovered a Microsoft bug in esent.dll, which lead to these critical errors. Details are listed in the ReadMe.txt topic named "Application and Service Crashes on Windows 10 x64 Build 1909 with SVBus version 1.1".

In addition we added mode page caching for the MODE SENSE (6) command. The virtual HDD needs MODE PAGE CACHING to display the tab Policies in the Properties of the HDD in device manager.

 

To download the newest version use the link in my first post.

 

Much respect go out to all the heroes who work very hard in hospitals all over the world at the moment to fight COVID-19.

Keep up your amazing work and spirit!

 

Greets
Kai Schtrom

 

Better use SVBus version 1.2 on a new build, and better don't use any Virtual Machine, you don't need it, create the VHD on a partition of your PC, WinNTSetup will create the entry on your PC BCD to let you boot from it.

 

I noticed in your last post you followed more or less the instructions from SVBus author, they are not bad but in my next post (to not miss the target of this post), I will suggest you my manual  way, or the automated way using WIMBOOT_VHD by wimb.

 

For next comment I will consider the USB device is OK:

 

Abut the use of Winreducer: as the 10 OS on the VHD boots fine when loaded on RAM (by grub4dos) and only fails when starts file booting there is also the possibility the USB funtions are not working to its full capacity because some part of the driver, the services required to start the driver, the entries on the reg file controling the timings of this service, etc were affected during the reduction with Winreducer.

 

alacran



#15 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 04 August 2020 - 03:48 PM

I recommend you to start from scratch a new build.

 

The procedure made by SVBus author Kai Schtrom is not bad, but I have the opinion the procedures here on reboot.pro are better, as give the user more booting alternatives (MBR & UEFI), using Windows bootmanager + grub4dos and also grub (optional) to let the user include (boot) also Linux distros on same USB device, and do not modify/delete files related to Windows boot files/folders, not only using grub4dos alone as boot loader (good only for MBR).

 

My topics related to Wimboot and Compact Installs (manual procedures)

 

Read this first:

Following topic has info related to Compact Mode Installs: (basically same applies for Wimboot Installs too):http://reboot.pro/to...-mode-installs/

 

You can skip this, but it has all procedure in detail for Wimboot installs and has good info and test done:

Long topic about Wimboot Installs: http://reboot.pro/to...vhd/?hl=wimboot

 

 

Wimb programs to automate Wimboot and Compact Installs:

 

USB Format Tool and UEFI_MULTI: http://reboot.pro/fi...and-uefi-multi/

 

VHD_WIMBOOT - Apply and Capture of WIM Files for OS in VHD: http://reboot.pro/fi...-for-os-in-vhd/

NOTE: Good for Standard, Wimboot and Compact installs. Into this download is included a pdf file with recommended procedure.

 

Let us know latter if this helped you to solve the issue.

 

i wich you good luck in your builds

 

alacran



#16 favorinus

favorinus

    Member

  • Members
  • 38 posts
  •  
    Argentina

Posted 06 August 2020 - 03:32 PM

thank you .

 

I am doing a lot of trial and error looking for a solution.  I started all over again with an untouched windows 10 iso: 2016 LTSB version

first format the pendrive with rufus 3.11  MBR partition NTFS and let rufus install grub4dos 0.4.6a on it. 

 

with winntsetup 4.2.1 create an 11GB vhd  

rightclick "add drivers" to active unsigned drivers and select svbus 1.2 

install the windows 10 into de vhd and reboot on my pc.  As the vhd is added to the  BCD I booted into the new created windows 10 and it's working fine, I see the svbus 1.2 installed.

 

rebooted back into my every-day-use windows 8.1 and copy the vhd into my pendrive with this menu.lst: 

 

title Windows10.vhd - SVBus  FILEDISK - map as (hd)

find --set-root --ignore-floppies /Windows10.vhd

map /Windows10.vhd (hd)

map --hook

root (hd-1,0)

chainloader /bootmgr

 

 

title Windows10.vhd.vhd - SVBus  RAMDISK - map as (hd-1)

find --set-root --ignore-floppies /Windows10.vhd

map --top --mem /Windows10.vhd (hd-1)

map --hook

root (hd-1,0)

chainloader /bootmgr

 

and guess what: BSOD inaccessible boot disk on my projected computer, and on my laptop infinity dots rotating.

 

can it be that the BIOS mode is some sort of buggy?

I will try the suggested UEFI_MULTI posted here above.  grub2 can also boot windows 10 as ramdisk ?

 

ps: how can I add pictures to the post?



#17 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 August 2020 - 04:13 PM

I still am not convinced of the menu.lst you used.

 

Can you try on command line? (press [Enter] after typing each line to issue the command)



find --set-root /Windows10.vhd
root 

This root command should output either (hd0,0) or (hd1,0) a result, 

 

If the output of root is (hd0,0), run these commands:



map (hd0) (hd1)
map --hook
find --set-root /Windows10.vhd
root

If the above is (hd1,0), then run:





map /Windows10.vhd (hd0)
map --hook
root (hd0,0)
root

If the above is (hd0,0), then run:



chainloader /bootmgr

you should get a message simillar to "Will boot ntldr from drive=0x80, partition=0x0 (hiden sectors=0x800)..."

Now issue:



boot

:duff:

Wonko



#18 favorinus

favorinus

    Member

  • Members
  • 38 posts
  •  
    Argentina

Posted 06 August 2020 - 04:39 PM

Hi wonko,

 

I have done all you descripted and the result is the same as your.

It is showing the dots for some 10 seconds and then BSOD INACCESSIBLE BOOT DEVICE



#19 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 August 2020 - 06:06 PM

I forgot to put the "--set-root" in the commands.  :blush:

 

I just corrected them.

 

Can you try again?

Not that it will probably change anything, but the commands (as I posted them earlier, wrong) should have not worked at all, so there must be some  :wodoo: involved.

 

And you cannot have possibly done all I described, as they were a set of conditional commands, please describe EXACTLY what happens (and which commands you use) while in grub4dos.

 

:duff:

Wonko



#20 favorinus

favorinus

    Member

  • Members
  • 38 posts
  •  
    Argentina

Posted 06 August 2020 - 08:22 PM

Ok here we go:

 

now I am in the grub4dos 0.4.6a commandline

 

grub> find --set-root /Windows10.vhd

  (hd0,0)

grub> root

  (hd0,0) Filesystem type is ntfs, partition type 0x07

  Volume Name is "Radio"

grub> map (hd0) (hd1)

 

floppies_orig=0, harddrives_orig=1, floppies_curr=0, harddrives_curr=2

grub>map --hook

grub>find --set-root /Windows10.vhd

   (hd0,0)

grub>root

  (hd0,0) Filesystem type is ntfs, partition type 0x07

  Volume Name is "Radio"

grub> chainloader /bootmgr

 

  Error 15:  File not found

grub>

 


#21 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 07 August 2020 - 09:08 AM

USB-Stick is too slow for booting Win10 VHD as FILEDISK

Your VHD is booting OK from RAMDISK and as FILEDISK when located on internal Harddisk.

Both cases are much faster.

 

Try the very fast USB Portable SSD for booting Win10 VHD as FILEDISK.

 

More Info:



#22 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 August 2020 - 09:25 AM

I will try again, because it's so easy to make a mistake   :blink:

Yes, you missed a step, and I possibly made some confusion, it is difficult to suggest a sequence of commands remotely, let's see if I can clear the idea with a more verbose example:

find --set-root /Windows10.vhd <- this finds the vhd and sets root to the disk/volume
root <- this confirms that the vhd is on (and you are root on) (hd0,0)
map (hd0) (hd1) <- this map the first disk to second disk
map --hook <- this hooks the mapping
find --set-root /Windows10.vhd <- this is the same of the previous one, you can omit that as - in this moment - you should have the same disk mapped as both (hd0) and (hd1) do the find command will find the .vhd on first volume it scans (hd0,0)
root <- this is the same of the previous one, you can omit that, as it will still result as (hd0,0)
map /Windows10.vhd (hd0) <- this maps the .vhd to (hd0)
map --hook <- this hooks the mapping
root (hd0,0) <- this moves the root to the just mapped (hd0), i.e. the .vhd 
root <- this should have different results from the previous one as this is now the .vhd

 

find /Windows10.vhd <- this should result in (hd1,0)

geometry (hd0) <- this should confirm that (hd0) is now the .vhd 

geometry (hd1) <- and this should confirm that the USB stick is now (hd1)

 

root (hd0,0)<- this is unneeded as root shoiuld be already (hd0,0) but better be sure

chainloader /bootmgr <- this chainloads the bootmanager inside current root (hd0,0), i.e. the one inside the .vhd
boot <- this passes control to the chainloaded bootmgr and boots

 

All the above basically is about mapping the .vhd to first disk AND keep the USB stick available at BIOS level as second disk.

 

If it doesn't work, try doing the opposite, i.e. leaving the USB stick as first disk and map the .vhd to second disk, i.e.:

 

find --set-root /Windows10.vhd <- this finds the vhd and sets root to the disk/volume
root <- this confirms that the vhd is on (and you are root on) (hd0,0)
map /Windows10.vhd (hd1) <- this maps the .vhd to (hd1)
map --hook <- this hooks the mapping
root (hd1,0) <- this moves the root to the just mapped (hd1), i.e. the .vhd 
root <- this should have different results from the previous one as this is now the .vhd

 

find /Windows10.vhd <- this should result in (hd0,0)

geometry (hd0) <- this should confirm that (hd0) is the USB stick 

geometry (hd1) <- and this should confirm that the .vhd is now (hd1)

 

root (hd1,0)<- this is unneeded as root shoiuld be already (hd1,0) but better be sure

chainloader /bootmgr <- this chainloads the bootmanager inside current root (hd1,0), i.e. the one inside the .vhd
boot <- this passes control to the chainloaded bootmgr and boots

 

:duff:

Wonko



#23 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 August 2020 - 09:40 AM

USB-Stick is too slow for booting Win10 VHD as FILEDISK

Your VHD is booting OK from RAMDISK and as FILEDISK when located on internal Harddisk.

Both cases are much faster.

Sure they are much faster but also BOTH do not use the USB driver/stack of Windows 10.

If you suspect a timing problem, maybe it can be fixed *somehow*?. :unsure:

 

 

Try the very fast USB Portable SSD for booting Win10 VHD as FILEDISK.

In exchange for a mere 100 bucks or so ...  :rolleyes:

 

:duff:

Wonko



#24 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 07 August 2020 - 10:37 AM

In exchange for a mere 100 bucks or so ...  :rolleyes:

 

 

USB Portable SSD 500 GB - now in my country for € 89,-

 

@favorinus

What kind of USB-Stick Make and Type are you using 2.0 or 3.0 ?

 

Your Windows 10 VHD  has Compact Install with LZX Compression.

Booting such LZX Install as FILEDISK on USB requires fast USB medium connected through USB 3.0 and powerful computer

 

EDIT:

What is the WOF Status of your VHD Internal files bootmgr and Boot\BCD ?

Try WOF_Compress and use WOF_Compress_Trusted.cmd to UnCompress these files.

 

Download from wimb GitHub - WOF_Compress

 

Also use BOOTICE to view if VHD Internal Boot\BCD is present and OK or has <unknown> entry .....that does not work ....

VHD_WIMBOOT and UEFI_MULTI take care to make Boot\BCD and bootmgr inside VHD,

whereas WinNTSetup does not do this ....and grub4dos booting will fail ....

 

Also VHD_WIMBOOT after wimlib Capture in WimBoot mode followed by wimlib Apply will use WIM file Windows\System32\WimBootCompress.ini

with \bootmgr and \Boot\BCD in [PrepopulateList] section so that these files will be Normal instead of may be LZX Compressed in your case ..... giving grub4dos Boot failure.

 

For booting as FILEDISK it is preferred to useinstead of SVBus the Microsoft vhdmp.sys driver and have Boot entry in Windows Boot Manager menu as made by UEFI_MULTI or VHD_WIMBOOT



#25 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 August 2020 - 11:18 AM

USB Portable SSD 500 GB - now in my country for € 89,-

Right now:

https://www1.oanda.c...ency/converter/

89 € are 105,62 US$

 

I stand by my "mere 100 bucks or so ...".

 

Now 90 € or 105 US$ are not - in my personal book - "peanuts".

 

Isn't it funny that an Italian tells a Dutch how unneeded expenditures should be carefuly evaluated? :unsure:

 

Please also consider that the OP comes from Argentina, where AFAIK the minimum salary is around 300-350 USD and the average is around 500-600 USD.

 

And where that T5 thingy seemingly sells for 15.000-20,000 pesos:

https://tiendamia.co...?amz=B073GZBT36
https://www.mercadol...l/p/MLA9282793?

i.e.  more than double the EU price, like 205-275 US$

 

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users