22 replies to this topic

[videoguy]

Hi

I have a USB stick with custom winre image that boots fine as a EFI system. I am trying to boot this using Hyperv on a Win10 host (RS1). But it is not going as planned.

This is how I am doing it.

 

1) I created a Hyperv Gen 2 VM pointing to 100GB expanding .vhdx file.

2) Then attached the vhd on the host win10 using diskmgmt applet

3) Created a EFI partition of size 200MB

4) Created a primary partition of 1GB. Lets call this tools partition. I left the remaining space unallocated for the time being.

 

Then copied the content from usb stick to these partitions.

 

The EFI partition ends up with:

 

EFI\Boot\

     bootx64.efi

     bootmgrfw.efi

     BCD

     boot.sdi

 

The tools partition has:

sources\

    boot.wim

    boot.sdi

 

Then I ran few BCDEdit commands to make {default} entry osdevice and device options load the boot.wim from tools partition.

No matter what I tried, the boot manager always failed saying unable to find boot device. I was stuck on the page that prompts me to run windows recovery or mem diags.

 

After trying every option (using drive letters, \device\harddiskvolumeX style paths), I gave up on that approach. When I copied \sources folder from tools partition to EFI partition and going back to the original BCD from the USB stick, I was able to boot the winre in hyperv.

 

Is there a tutorial or gotchas with the setup that I am trying to use?

 

Thanks

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[steve6375]

Did you try original BCD but wim file in Tools partition?

[videoguy]

I didn't because it used "boot" as the device (ramdisk=[boot]\sources\boot.wim...). My understanding is that this device is the partition from where the bootmgr is found.

Let me give that a try. Please stay tuned.

[steve6375]

I usually use BootIce to edit the BCD - much easier!

[videoguy]

I created two partitions and tried it again. No luck! It didn't work.
BootICE is neat. Just downloaded it.

Below is output of "BCDEDit /enum all" on this BCD
++++++++++++++++++++++++++++++++++++++++++++++

Firmware Boot Manager
---------------------
identifier {fwbootmgr}
displayorder {bootmgr}
timeout 1

Windows Boot Manager
--------------------
identifier {bootmgr}
device boot
path \EFI\Boot\bootmgfw.efi
description Windows Recovery Environment
locale en-US
inherit {globalsettings}
highestmode Yes
flightsigning Yes
default {default}
resumeobject {default}
displayorder {default}
toolsdisplayorder {memdiag}
timeout 30

Windows Boot Loader
-------------------
identifier {default}
device ramdisk=[boot]\sources\boot.wim,{492933ee-cd0d-11e1-9b66-d4bed91b7fc5}
path \Windows\system32\winload.efi
description Windows Recovery Environment
locale en-US
inherit {bootloadersettings}
recoveryenabled No
testsigning No
highestmode Yes
isolatedcontext No
allowedinmemorysettings 0x15000075
osdevice ramdisk=[boot]\sources\boot.wim,{492933ee-cd0d-11e1-9b66-d4bed91b7fc5}
systemroot \Windows
nx OptIn
bootmenupolicy Standard
winpe Yes

Windows Memory Tester
---------------------
identifier {memdiag}
device unknown
path \EFI\Microsoft\Boot\memtest.efi
description Windows Memory Diagnostic
locale en-US
inherit {globalsettings}
badmemoryaccess Yes

EMS Settings
------------
identifier {emssettings}
bootems No

Debugger Settings
-----------------
identifier {dbgsettings}
debugtype Serial
debugport 1
baudrate 115200

RAM Defects
-----------
identifier {badmemory}

Global Settings
---------------
identifier {globalsettings}
inherit {dbgsettings}
{emssettings}
{badmemory}

Boot Loader Settings
--------------------
identifier {bootloadersettings}
inherit {globalsettings}
{hypervisorsettings}

Hypervisor Settings
-------------------
identifier {hypervisorsettings}
hypervisordebugtype Serial
hypervisordebugport 1
hypervisorbaudrate 115200

Resume Loader Settings
----------------------
identifier {resumeloadersettings}
inherit {globalsettings}

Device options
--------------
identifier {492933ee-cd0d-11e1-9b66-d4bed91b7fc5}
description Windows Recovery
ramdisksdidevice boot
ramdisksdipath \sources\boot.sdi

Edited by videoguy, 19 October 2017 - 05:23 PM.

[Wonko the Sane]

In case of need (maybe starting with a brand new BCD store might be easier):

http://www.mistyproj...Edit/index.html

http://www.mistyproj...s/examples3.htm

 

Wonko

[videoguy]

In my case, the tricky part is that I am booting a VHD with multiple partitions using hyperv. The usual drives like C: or D: etc didn't work as there is no drive letter assignment done to any partition. Trying to do that from host OS makes sense to the host OS, but not to the guest VM when it is booting up. A G: drive in host mean nothing to guest VM when it finds "partition=G:" in BCD.

 

Is there a way to identify a partition within the VHD in host OS agnostic way inside BCD?

I tried many combinations of \Device\HarddiskVolumeX type names. They didn't work.

[videoguy]

Wonko

Thanks for those links. I created a batch file using scriptlet on these pages to gen a BCD at will instead of typing bcdedits at command prompt now.

[cdob]

A G: drive in host mean nothing to guest VM when it finds "partition=G:" in BCD.

What's G: drive? Is this the mounted partitition inside the VHD image?

http://www.mistyproj...t/files/bcd.htm
Partitions are described by the disk signature and partition offset.
A G: drive host OS can be a C: drive PE OS.

Mount the VHD file first (attach at diskpart). Then run bcdedit next.

Edited by cdob, 20 October 2017 - 04:58 AM.

[cdob]

1) I created a Hyperv Gen 2 VM pointing to 100GB expanding .vhdx file.
2) Then attached the vhd on the host win10 using diskmgmt applet

Running bcdedit at host OS, I get boot error too. Hyper V dosn't find the partiton.
The host .vhdx disk is slightly different than the Hyper V virtual disk. No, I don't know the details.

Next I booted a Windows installation DVD at Hyper V.
And configured the virtual machine hard disk bcd file: run bcdedit to adjust osdevice and device options
Hyper V does boot from the hard disk now.

There are different results running bcdedit at the host OS or inside the virtual machine.

[Wonko the Sane]

There are different results running bcdedit at the host OS or inside the virtual machine.

Which - when and if you have time - you could actually detail ...   

 

Wonko

[videoguy]

I wish if there is OS agnostic way of identifying the partitions in BCD. Something like "\Disk0\Partition1". All I see in the examples are drive based paths (like partition=C:) or Volume path based (like \Device\HardDiskVolume5). Both those paths are local to Windows OS environment. When the boot loader is looking at BCD, how can you expect it to understand paths that are meaningful inside running Windows OS instance?

It doesn't make sense.

[cdob]

There is no partition=C: or \Device\HardDiskVolume5 inside the BCD file.
partition=C: or \Device\HardDiskVolume5 is the bcdedit.exe human translation.
The bcdedit examples uses the bcdedit syntax.

http://www.mistyproj...t/files/bcd.htm

[Wonko the Sane]

I wish if there is OS agnostic way of identifying the partitions in BCD. Something like "\Disk0\Partition1". All I see in the examples are drive based paths (like partition=C:) or Volume path based (like \Device\HardDiskVolume5). Both those paths are local to Windows OS environment. When the boot loader is looking at BCD, how can you expect it to understand paths that are meaningful inside running Windows OS instance?

It doesn't make sense.

As cdib explained above, a volume is actually identified in the BCD with the SAME (actually very similar) way it is identified in "MountedDevices" in the Registry (and how a drive letter is assigned to it) aka by using the Disk Signatire and the offset (in bytes) to the beginning of the volume (basically data that you can get from the MBR of the disk device hosting the volume).

 

the assignment of a drive letter (the C: in your case) depends on the automount features and/or on the contents of MountedDevices keys in the Registry, while the syntax like \Device\HardDiskVolume5 is entirely "volatile", and you need to run dmdiag or Winobj (or similar) to get them, but they are only valid "per session", compare with the old:

http://reboot.pro/to...emount-ramdisk/

and (related):

http://reboot.pro/to...ve-information/

http://reboot.pro/to...command-prompt/

 

While unless you manually change the disk signature (or you have the very extreme and rare case of a signature collision ) the Disk Signature+Volume Offset remains "fixed" across *any* system.

 

 

Wonko

[videoguy]

Does BCDEdit take disk signature + offset as allowed input when setting ramdisk options?

 

Those links have hundreds of posts. I started reading and stopped in the middle. I got distracted.

How do I dump disk signature for a .vhdx file?

 

Does BCD Edit accept \\?\Volume{374c5c0f-a628-4782-8149-66b66cde30ab}\ type paths to identify partitions?

 

Thanks

[Wonko the Sane]

Does BCDEdit take disk signature + offset as allowed input when setting ramdisk options?

 

Those links have hundreds of posts. I started reading and stopped in the middle. I got distracted.

How do I dump disk signature for a .vhdx file?

 

Does BCD Edit accept \\?\Volume{374c5c0f-a628-4782-8149-66b66cde30ab}\ type paths to identify partitions?

 

Thanks

No.

 

Too bad for you.

 

You access the MBR (when mounted or when offline) and check the Disk Signature (Offset 446) and - in the partition table corresponding entry the LBA start address in the relevant partition entry, (in case of logical volumes inside extended it is a little more complicated as you have to follow the chain of EPBR's and add the offset to the Extended Partiton begin) or more simply mount the volume and check values in DosDevices for the used drive letter see:

 

https://web.archive....t=0#entry130963

 

No. (technically those GUID's are linked in MountedDevices in the Registry to - guess what? - DIsk Signature +Offset)

 

You are welcome.

 

Wonko

[videoguy]

Sorry for not mentioning this before. This is a GPT formatted .vhdx disk. The MBR stuff above don't apply in this case right?

 

This link https://blogs.techne...ure-collisions/has good pointers. Now I am understanding how the BCD manages partition info. It is smart. The confusion I had was because of "user friendly translation" that bcdedit does when it dumps entry info.

 

I copied everything (efi\boot and sources\ dirs) to esp partition of the vhd. Boot into that winre. Launched BootICE portable app and edited the BCD pointing the ramdisk to \sources dir on 2nd partition. Renamed sources\ dir on esp to sources.bak\. Now when I reboot this VHD, it is booting fine. The reason is that I edited BCD from the running instance of WinRE.

Edited by videoguy, 26 October 2017 - 04:17 AM.

[cdob]

Yes, the MBR stuff dosn't match exactly.
However there are GUID and partition offset at a GPT.
There are MountedDevices in the Registry still.
The BCD entry 1100001 contains parts from MountedDevices still. A similar approach is used at a GPT disk.

No, bcdedit dosn't support t \\?\Volume*.

[videoguy]

cdob

Please check my edited post above. I think I posted it while you replied.

[Wonko the Sane]

On GPT the Disk Signature should remain the same (offset 446 of the MBR), whilst of course the offset will come from the GPT partition table, which is in the following sectors, and still the data in MountedDevices remains the same.

The ESP partition (since it is not normally mounted) may be more difficult to identify, but one can always mount it temporarily assigning to it a drive letter to get the data.

 

Anyway I see that the problem at hand is solved, good.

 

Wonko

[cdob]

Which - when and if you have time - you could actually detail ...

Let's make small steps

Windows remembers partitions at GPT.

Matches Windows registry HKLM\SYSYTEM\MountedDevices\DosDevices blob to libguestfs GPT partition device.
For GPT disks, the blob is made of "DMIO:ID:" prefix followed by the GPT parition GUID.
https://www.redhat.c...y/msg00052.html

GUID Partition Entry
Offset 0x10 Length 16 bytes
Unique Partition GUID. A unique ID created for each partition entry.
https://technet.micr...y/cc739412.aspx


Back to real world testing:
The host OS Windows 10 uses GPT too.
The image VHD\HyperV1.vhdx is mounted at the host OS. T: is assigned to the tools partition.

bcdedit.exek /store bcd /set {default} device ramdisk=[T:]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}

The bcd 11000001 entry contains the host OS partiton GUID and the name VHD\HyperV1.vhdx

If you boot vhdx at a virtual machine, then there is no host OS hard disk anymore, only the virtual local one.
The virtual local hard disk uses another partiton GUID. Hence \sources\boot.wim is not found.

If bcdedit is run inside the virtual machine, then the local hard disk partiton GUID is set.
It's possible now to boot the virtual machine.

This arises new questions.
Bcdedit is designed for vhd boot, this is about vhd file booting, not vhd inside the virtual machine. Therefore Bootmgr seems to read boot.wim from a vhdx file nowadays, t To be tested.
Which entry sets bootice, if run from the host OS and connected to the mounted vhdx image?
One week vacation, to be continued after.

[cdob]

Bcdedit is designed for vhd boot, this is about vhd file booting, not vhd inside the virtual machine. Therefore Bootmgr seems to read boot.wim from a vhdx file nowadays, t To be tested.

Bootmgr (up to Windows 10 1709) does not load a boot.wim embedded in a VHD(x) file.


A Windows 7 (and up) bootmgfw.efi loads a boot.wim embedded in a VHD(x) file.
The VHD is not mounted at the running PE.

The running PE lists a vdisk SystemStartOptions.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control]
"SystemStartOptions"=" MININT RDIMAGEOFFSET=8192 RDIMAGELENGTH=3161088 RDPATH=MULTI(0)DISK(0)VDISK(0)PARTITION(1)\\SOURCES\\BOOT.WIM"

[Wonko the Sane]

The running PE lists a vdisk SystemStartOptions.

Which looks curiously similar to a mix of good ol' "ramdisk options" of PE 1.x (in WINNT.SIF) and BOOT.INI entry, as a side note.

 

 

 

Bootmgr (up to Windows 10 1709) does not load a boot.wim embedded in a VHD(x) file.

 

But (in the case of a "plain" .vhd, not vhdx) is it enough to map the .vhd in grub4dos or not?

Or is it "lost" in the switch after bootmanager?

 

And/or, can the mentioned key be added to the BOOTMGR initiated PE?

 

I.e. is the difference due to an "added" capability of BOOTMGR.EFI (to mount/attach a .wim) when compared to BOOTMGR, or is it simply an added "switch" to create the mentioned key in the Registry?

 

Wonko