Jump to content











Photo
* * * * * 1 votes

Hack Bootmgr to boot Windows in BIOS to GPT

bios gpt bootmgr winload

  • Please log in to reply
362 replies to this topic

#351 steve6375

steve6375

    Platinum Member

  • Developer
  • 6682 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 11 February 2017 - 03:09 PM

I tried booting from the C: partition 4 with umbr + reg fix and same issue - no hibernate.  :(

 

I have written up experiments so far http://www.rmprepusb...s/bios_gpt_boot

 

Would be nice to get Hibernate working!



#352 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 406 posts
  •  
    India

Posted 11 August 2017 - 03:03 AM

AIO Boot now supports installing Grub2 on GPT disks including both HDD and USB. After installing Grub2, you can boot the GPT disk in Legacy BIOS modeWindows Boot Manager does not support booting into Legacy BIOS mode on GPT disks. AIO Boot uses wimboot, which consumes more RAM.

  1. Install AIO Boot to a partition on GPT disks.
  2. Grub2 requires a BIOS partition on GPT disks. We will create a small partition of 1 to 10MB. You do not need to format and do not need to mount the drive letter for this partition. For USB, you can use the MiniTool Partition Wizard to create a second partition. On Linux, this partition will be flagged as bios_grub. USB-multiple-partitions.jpg
  3. Run AIOCreator.exe, select Grub2 from Bootloaders. The tool will list the partitions that you created in step 2.
  4. Select the partition and click OK to install Grub2.

     

    install-grub2-on-gpt.jpg
  5. .Good luck!


#353 nightrain

nightrain
  • Members
  • 4 posts
  •  
    China

Posted 19 November 2017 - 04:24 AM

I tried booting from the C: partition 4 with umbr + reg fix and same issue - no hibernate.  :(

 

I have written up experiments so far http://www.rmprepusb...s/bios_gpt_boot

 

Would be nice to get Hibernate working!

I found a important registry value which controls BCD system store is vaild.

A dword named TreatAsSystem with value 1 in HKLM\BCD00000000\Description is very important.

After adding this value, bcdedit and all other BCD editors included built-in boot and failure recovery works.

But Hibernate is not working, wake PC with correct FirmwareBootDevice value will result in a clean boot, wake PC with unmodified FirmwareBootDevice value will result in a recovery screen(press enter is necessary to get a clean boot).

Now the only way to get hibernate working is vhd.(edit:maybe i should put boot files in a separate partition?)

 

UPDATE:

Hibernate is fully working after i put boot files in a separate partition with the modification of FirmwareBootDevice. No need to re set FirmwareBootDevice every wake up, only clean boot needs. Windows will not load BCD after wake up, you should load manually.

 

UPDATE2:
I found a interesting fact. while HKLM\BCD00000000\Description\KeyName was not BCD00000000 (usually bcdboot and bcdedit will set external BCD store's Description\KeyName to BCD00000001,BCD00000002..., and bcdedit will remove the TreatAsSystem value while the store is external store), you don't need to load BCD store manually after wake up while Description\KeyName is not BCD00000000.
Maybe windows will unload the bcd store with Description\KeyName=BCD00000000 while system goes into hibernate?

Edited by nightrain, 19 November 2017 - 05:22 AM.


#354 nightrain

nightrain
  • Members
  • 4 posts
  •  
    China

Posted 19 November 2017 - 05:36 AM

I found a important registry value which controls BCD system store is vaild.
A dword named TreatAsSystem with value 1 in HKLM\BCD00000000\Description is very important.
After adding this value, bcdedit and all other BCD editors included built-in boot and failure recovery works.
But Hibernate is not working, wake PC with correct FirmwareBootDevice value will result in a clean boot, wake PC with unmodified FirmwareBootDevice value will result in a recovery screen(press enter is necessary to get a clean boot).
Now the only way to get hibernate working is vhd.(edit:maybe i should put boot files in a separate partition?)

UPDATE:
Hibernate is fully working after i put boot files in a separate partition with the modification of FirmwareBootDevice. No need to re set FirmwareBootDevice every wake up, only clean boot needs. Windows will not load BCD after wake up, you should load manually.

UPDATE2:
I found a interesting fact. while HKLM\BCD00000000\Description\KeyName was not BCD00000000 (usually bcdboot and bcdedit will set external BCD store's Description\KeyName to BCD00000001,BCD00000002..., and bcdedit will remove the TreatAsSystem value while the store is external store), you don't need to load BCD store manually after wake up while Description\KeyName is not BCD00000000.
Maybe windows will unload the bcd store with Description\KeyName=BCD00000000 while system goes into hibernate?

UPDATE3:
KeyName=BCD00000000 is much safer than other value, if the bcd store in disk is different from in memory, system will not wake up and you need to use bcdedit (/store command) once to fix your BCD. In a nutshell, 3 registry values are important.
HKLM\BCD00000000\Description\KeyName=BCD00000000
HKLM\BCD00000000\Description\TreatAsSystem=(dword)0x1
HKLM\SYSTEM\CurrentControlSet\Control\FirmwareBootDevice=multi(0)disk(0)rdisk(0)partition(4)
(modify FirmwareBootDevice to yours)

Edited by nightrain, 19 November 2017 - 05:45 AM.


#355 IAmTheTrueMeaningOfCovfefe

IAmTheTrueMeaningOfCovfefe

    Silver Member

  • Advanced user
  • 607 posts
  • Location:In hiding
  • Interests:An investigation is underway to determine whether Trump has any ties to America.
  •  
    United States

Posted 20 November 2017 - 05:20 AM

Would hibernation work with the AIO method that @devdevadev posted about? Or is it untested as of yet? Would it be possible to test it in a VM instead of doing a real/live installation? I've noticed that whenever I install Windows to a VM hibernation doesn't seem to be available. I think maybe it's because Windows detects it's booted from a VHD, perhaps some other image type (like VDI or VMDK, etc) would work better. Then again, booting from a VHD in real/live mode doesn't seem to allow hibernation either. This is one of the few reasons why I would rather not boot from an image file on a real, permanent install.



#356 nightrain

nightrain
  • Members
  • 4 posts
  •  
    China

Posted 20 November 2017 - 10:40 AM

By the limitations of Microsoft VHD Controller driver, Windows do not support hibernate the system which stored to a vhd.

 

The only three ways to get hibernate working are:

 

1: Use the map command of GRUB4DOS, do not install Windows entirely to the VHD, install boot files to the VHD, when the VHD is attached, hibernate works.

If you use "VHD Attach" and make its service loaded before TrustedInstaller (by service dependencies), Windows Update works perfectly.

If you use "TotalMounter" to mount VHD and do not use Microsoft's driver. You can use every features in Windows included Metro Boot Selection Screen (but expect WinRE, WinRE need a custom WinRE.wim file to mount vhd, and modify winload.efi to winload.exe in BCD is necessary).

like this:

timeout 0

menu /bootmgr.vhd
  find --set-root /Windows/bootmgr.vhd
  map /Windows/bootmgr.vhd (hd0)
  map (hd0) (hd1)
  map --hook
  root (hd0,0)
  chainloader /bootmgr 

2: Use Firadisk driver, do not install Windows to a VHD, do not install Windows entirely to the VHD, install boot files to the VHD, everything works thanks to Firadisk driver(you still need a custom WinRE image), the only disadvantage of Firadisk driver is Firadisk driver has no digital signatures.

See my previous post below:

http://reboot.pro/to...ndpost&p=193161

 

3: Use superfloppy to get Windows booting, then load BCD hive and modify three registry keys to get BCD loaded properly:

To modify HKLM\BCD00000000\Description\*, you need to modify permission.

HKLM\BCD00000000\Description\KeyName=BCD00000000
HKLM\BCD00000000\Description\TreatAsSystem=(dword)0x1
HKLM\SYSTEM\CurrentControlSet\Control\FirmwareBootDevice=multi(x)disk(y)rdisk(z)partition(w)

You can not put boot files in system drive in this superfloppy way, otherwise you can not wake up. Ways 1&2 are OK in every situations.


Edited by nightrain, 20 November 2017 - 10:45 AM.


#357 luizluca

luizluca
  • Members
  • 2 posts
  •  
    Brazil

Posted 18 December 2017 - 01:03 AM

I managed to boot windows with all but "UEFI emulation" (I didn't try it). Updates do work with vhd (vhd attach) or external usb drive, but fails with wimboot. However, I could not apply a "feature update" like 1709, as it is really a system version upgrade.

When it reboots in order to apply update, it starts to rollback my system. It even messes with my BCD and I need to recover it (either install DVD or booting with wimboot).

It's this expected? Would it be any workaround?
It's there any manual way to apply this feature update? Something like boot winre and run c:\$windows.~bt\magic.exe?

I have 1709 iso, and long experience with both Windows and Linux.
My window was originally installed in MBR and mirrored to GPT

#358 cdob

cdob

    Gold Member

  • Expert
  • 1372 posts

Posted 21 December 2017 - 10:46 PM

However, I could not apply a "feature update" like 1709, as it is really a system version upgrade.

When it reboots in order to apply update, it starts to rollback my system.

Yes, a "repair installation" fails.
Actually I wonder, you got a rollback at all.
Windows setup refuses to upgrade at all here. Without UEFI firmware and GPT disk, setup refuses at online "feature update" 1709 or a <1709 DVD>\setup.exe.
.

Anyway let's compare a BIOS MBR upgrade example.

bootsequence {7254a080-1510-4e85-ac0f-e7fb3d444736}
device ramdisk=[C:]\$WINDOWS.~BT\Sources\SafeOS\winre.wim,{b9586286-e526-11e7-83f0-e946df80e7d6}

There is a file D:\$WINDOWS.~BT\Sources\SafeOS\ReAgent.xml
<OperationParam path="$WINDOWS.~BT\Sources\SetupPlatform.exe /execute Install:\$WINDOWS.~BT\Sources\SetupPlatform.ini"/>

And C:\$WINDOWS.~BT\Sources\SetupPlatform.ini

[Execute.PostOOBE]
0=\$WINDOWS.~BT\Sources\SetupHost.exe /Media /Success /ClientId Media360 /ReportId 0785d7a0-de3a-48b3-975a-2d98044a7705
[Execute.RollbackOnline]
1=\$WINDOWS.~BT\Sources\SetupHost.exe /Media /Rollback /ClientId Media360 /ReportId 0785d7a0-de3a-48b3-975a-2d98044a7705


I wonder, texted but not tested ;) set RollbackOnline to Success.
What happens at a BIOS GPT disk?

[Execute.PostOOBE]
0=\$WINDOWS.~BT\Sources\SetupHost.exe /Media /Success /ClientId Media360 /ReportId 0785d7a0-de3a-48b3-975a-2d98044a7705
[Execute.RollbackOnline]
1=\$WINDOWS.~BT\Sources\SetupHost.exe /Media /Success /ClientId Media360 /ReportId 0785d7a0-de3a-48b3-975a-2d98044a7705

Do you get a file SetupPlatform.ini at all?
Can you edit your local SetupPlatform.ini and set RollbackOnline to Success? What happens?


Or, there are anoter aproaches with a additonl real / fake / virtual UEFI hardware.
Attach a new GPT disk and the exiting hard disk to a virtual machine (VMware,Virtualbox).

#359 luizluca

luizluca
  • Members
  • 2 posts
  •  
    Brazil

Posted 22 December 2017 - 02:36 AM

Yes, a "repair installation" fails.
Actually I wonder, you got a rollback at all.


I really don't know for sure. The first reboot (after windows prepared the update), Windows starts and I can see just a flash of a windows terminal window before it reboots (the "working on updates" should follow).
After that windows reboots and it normally starts a rollback procedure. With VHD solution, my boot will loops trying to start installation or rollback. I need to rebuild BCD (either booting with ISO or inside normal Windows after booting with wimboot).
With external USB, it can rollback and return to Windows.
 

Windows setup refuses to upgrade at all here. Without UEFI firmware and GPT disk, setup refuses at online "feature update" 1709 or a <1709 DVD>\setup.exe.

Anyway let's compare a BIOS MBR upgrade example.

bootsequence {7254a080-1510-4e85-ac0f-e7fb3d444736}
device ramdisk=[C:]\$WINDOWS.~BT\Sources\SafeOS\winre.wim,{b9586286-e526-11e7-83f0-e946df80e7d6}

There is a file D:\$WINDOWS.~BT\Sources\SafeOS\ReAgent.xml
<OperationParam path="$WINDOWS.~BT\Sources\SetupPlatform.exe /execute Install:\$WINDOWS.~BT\Sources\SetupPlatform.ini"/>

And C:\$WINDOWS.~BT\Sources\SetupPlatform.ini

I wonder, texted but not tested ;) set RollbackOnline to Success.
What happens at a BIOS GPT disk?
Do you get a file SetupPlatform.ini at all?
Can you edit your local SetupPlatform.ini and set RollbackOnline to Success? What happens?

Or, there are anoter aproaches with a additonl real / fake / virtual UEFI hardware.
Attach a new GPT disk and the exiting hard disk to a virtual machine (VMware,Virtualbox).

 

I guess bootmgr was working fine for me. WIndows seems to be loaded. It is setup process that aborted my installation.

 

Sorry but I'll not be able to play args anymore as I got it working. I just adopted the UEFI emulation solution. It's quite simple and I think the cleanest of all. Windows works, all updates, including feature, works. I did not tested hibernation but it might work as well.

 

Thinking on using this same HD in a future PC (with UEFI), I created a UEFI SYSTEM partition.

It saved my day. On WIndows ISO installation, I just mapped this system partition (A:) using diskpart and installed the bootmgr to it forcing UEFI mode:

bcdboot C:\Windows /s a: /f UEFI

As I dual boot with Linux, I have grub2 as boot manager. I just created this simply entry: 

menuentry 'Tianocore' --class tianocore --class os $menuentry_id_option 'tianocore-memdisk' {
   insmod part_gpt
   linux16 /usr/lib/syslinux/memdisk
   initrd16 /boot/tianocore/tianocore.img
}

Where tianocore.img comes from this old repo (I really could not find a prebuilt image at the current repo). It boots, looks for an valid UEFI partition and boots windows (the only UEFI OS). It just works.

 

I just wonder why tianocore could not find my WIndows DVD. It did tested my USB devices for a storage, so it would only be a matter of copying all DVD files to a USB drive.

 

In summary (considering that I already have grub2 in use):

  • wimboot always booted a normal startup but any update that needs reboot will fail. "bcdedit /enum" always fails
  • VHD Boot image is equivalent to wimboot if not attached on every boot. "bcdedit /enum" always fails
  • VHD Boot image with VHD mounted using tasksched.exe works but any updates fails. Now "bcdedit /enum" works after VHD is attached.
  • VHD Boot image with VHD attach (loaded before trustedinstaller) works with everything but feature updates (and recovery)
  • USB Boot is equivalent to the previous one, except that a failed feature updates can update BCD in order to return to normal Windows boot cycle.
  • UEFI emulation (tianocore) makes everything work, except for installing from DVD (I might need an extra UEFI driver). It might work from a USB Storage but I did not test it.

I do recommend "UEFI emulation" for long-term installation (that will need feature updates). For temporary installations with short live that does not need updates, wimboot is very clean.



#360 cdob

cdob

    Gold Member

  • Expert
  • 1372 posts

Posted 22 December 2017 - 05:39 AM

I got it working. I just adopted the UEFI emulation solution.

Thanks for the feature upgrade example.
UEFI emulation (tianocore) is good at a feature upgrade.

#361 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 22 December 2017 - 09:15 AM

But, given that the Tianocore image works fine on your hardware (cannot say if it does on *all* hardware), if I get this right :unsure: one could boot "normally" from the BIOS and have the UEFI booting via Tianocore ready, using it only when an upgrade is *needed*? :unsure: :dubbio:

 

Kinda of an "emergency" alternative boot method?

 

:duff:

Wonko



#362 cdob

cdob

    Gold Member

  • Expert
  • 1372 posts

Posted 27 December 2017 - 09:16 PM

The loadable efi Clover may work at more hardware. Windows detect a UEFI environment.
http://www.rmprepusb...s/bios_gpt_boot


New game:
Kinda of an "emergency" alternative only BIOS boot method: temporary hybrid MBR

Use the GPT disk at daily usage.
Enable hybrid MBR temporary only: to install a OS. e.g install or upgrade Windows.
In that case, this is a MBR with the normal protective partition entry and one primary active partition.
Go back to GPT disk after install.
http://www.rodsbooks...isk/hybrid.html

Backup the disk first.

As for testing: given a 32 GiB GPT disk:
grub2 BIOS boot, memdisk boot.vhd
a NTFS Windows 10 partition, with \windows\boot.vhd
In addithion a EFI FAT32 system partition. Maybe useful at a UEFI hardware, holds /grub/ files too.
 
diskpart.exe
sel disk N
clean
convert gpt
create par efi size=100
format fs fat32 label="EFI"
create par prim
Remark:
The efi partition is not required currently.
It's prepared for future use, e.g. loaded UEFI firmware, ot at another UEFI hardware.

GParted DVD: https://gparted.org/
Install grub to the MBR and save grub BIOS files at the EFI system partition
(at multiboot: feel free to use another layout for the grub file)
sudo gdisk /dev/sda
n
3
34
2047
EF02

sudo mount /dev/sda1 /mnt
sudo grub-install --force --boot-directory=/mnt /dev/sda
.

Disk /dev/sda: 67108864 sectors, 32.0 GiB
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 67108830

Number Start (sector) End (sector) Size Code Name
1 2048 206847 100.0 MiB EF00 EFI system partition
2 206848 67106815 31.9 GiB 0700 Basic data partition
3 34 2047 1007.0 KiB EF02 BIOS boot partition


Backup the first hdd sector, the MBR.
 
Create the hybrid windows partition, remember a active one
sudo gdisk /dev/sda
r
p
o
h
2
y
Install Windows to the hybrid partition.
The MBR is overwritten, restore the first sector. It's a GPT disk now.

Boot a live CD, copy memdisk and set grub.cfg,
menuentry "GPT Partion boot: /Windows/boot.vhd" {
  insmod part_gpt
  linux16 /boot/syslinux/memdisk harddisk raw
  initrd16 (hd0,gpt2)/Windows/boot.vhd
}

menuentry "Win 10 setup /bootmgr - hybrided MBR partition required" {
  set root='(hd0,gpt2)'
  ntldr /bootmgr
  boot
}

menuentry "grub4dos" {
  linux16 /grub/grub.exe
}
.
Boot a Windows DVD. Create \Windows\boot.vhd
Boot from the GPT disk now.

Feel free to change partitons at the GPT disk. Add another OS, adjust boot.vhd, if appropiate.

If you like to upgrade Windows 10, create the hybrid MBR at current GPT partitions.
Adjust c:\boot\bcd, if partitions have been changed in between.
Make a Windows 10 Upgrade at MBR boot. Let Windows Update do this, or run <Install DVD>:\setup.exe.
Select the "Win 10 setup" entry at reboot several times.
Delete the hybrid MBR next and use GPT boot finally.

To clarify: there are two different \boot\bcd files used. Actually the (os)device entry is different
The one inside boot.vhd is used at GPT boot.
The other c:\boot\bcd is used at hybrid MBR boot.

Given a 64 bit Windows 7 and up:
http://www.msfn.org/...comment=1142954
should work at a 4 TiB disk, not tested. Remember to backup the disk.
Start within first 2 TiB LBA, partiton size below 2 TiB
67106815 - 206848 = 66899967
Grub4dos chainloaded:
partnew --active (hd0,0) 7 206848 66899967
Grub4dos writes the protective partition too.


Another idea: 'Setup /resizerecoverypartition disable' may be another precaution.
In cases the protective partition entry is missing/wrong, this should prohibit partition changes. Not tested.
https://docs.microso...nd-line-options

#363 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 28 December 2017 - 12:22 PM

@cdob

Semi-random idea, maybe useful, maybe not. :unsure:

 

How large is the .vhd? (like 100 Mb or so, but could be even less, right?)

Is it contiguous (or can it be made so)?

 

I mean, IF it is RAW AND IF it is contiguous, one could make a direct mapping in the (hybrid) MBR for the extents of the .vhd.

 

:duff:

Wonko







Also tagged with one or more of these keywords: bios, gpt, bootmgr, winload

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users