374 replies to this topic

[steve6375]

I am told that some UEFI systems do not offer an MBR-boot option if there are valid default EFI boot files on the drive and the firmware can understand the filesystem - e.g. if there is a \EFI\boot\bootx64.efi on a FAT partition, then some 64-bit UEFI systems will not offer an MBR-boot option even though the drive is both EFI and MBR-bootable.

[Advanced Shutdown]

 

type "cd oobe"

type msoobe.exe

 

that will start the out of the box experience and you can then put your username password etc, but won't be able to reach the desktop

Thanks Pockets69, but I already did that and also enabled the Administrator account. This didn't help in my case.

[Pockets69]

Strange it fixed mine.

 

what happened though? did you not see the oobe start? could you not put your username password, configure updates and all that?  when you reboot did it not go to the login screen?

 

The hell? well you can try regedit, try the following:

 

boot back in the instalation that should fail, shift + F10 again, regedit go to this path: HKLocal machine/SYSTEM/SETUP/STATUS/ChildCompletion

change oobeldr.exe setup.exe and setupfinaltasks to 2 once done reboot. you should (hopefully) be greeted by the login screen

[Advanced Shutdown]

did you not see the oobe start?

I did.

 

could you not put your username password, configure updates and all that?

I could.

 

when you reboot did it not go to the login screen?

It didn't. Instead the same message box with error appeared ("Windows could not complete the installation. To install Windows on this computer, restart the installation.").

 

 

The hell? well you can try regedit, try the following:

boot back in the instalation that should fail, shift + F10 again, regedit go to this path: HKLocal machine/SYSTEM/SETUP/STATUS/ChildCompletion

change oobeldr.exe setup.exe and setupfinaltasks to 2 once done reboot. you should (hopefully) be greeted by the login screen

I'll note that down for future reference but I already re-imagex-ed W7 using the spare flash drive as an MBR disk with boot files. This turned out without a hitch.

[cdob]

Use a virtual hard disk /Windows/Boot.vhd at boot and at running windows.
Windows default drivers are used to mount the image.
Runs at Windows 7, 8, 10.


Create a BIOS bootable GPT disk.

grub4dos added to existing windows default GPT disk
#209 http://reboot.pro/to...e-9#entry193659

menu.lst, windows at first disk

menu /windows/boot.vhd
  set vhdfile=/windows/boot.vhd
  find --set-root $vhdfile
  map $vhdfile (hd0)
  map (hd0) (hd1)
  map --hook
  root (hd0,0)
  chainloader /bootmgr

.
Grub2 https://wiki.gentoo....2#BIOS_with_GPT
crub.cfg

menuentry "(hd0,gpt3)/windows/Boot.vhd - memdisk" {
 linux16 /boot/syslinux/memdisk harddisk raw
 initrd16 (hd0,gpt3)/Windows/Boot.vhd
}

menuentry "search /windows/Boot.vhd - memdisk" {
 set vhd_file=/Windows/Boot.vhd
 search --file $vhd_file --set=vhd_part
 linux16 /boot/syslinux/memdisk harddisk raw
 initrd16 ($vhd_part)$vhd_file
}

menuentry "/windows/boot.vhd loaded with grub4dos" {
  set vhdfile=/windows/boot.vhd
  linux16 /grub/grub.exe --config-file=find --set-root $vhdfile\; map $vhdfile (hd0)\; map (hd0) (hd1)\; map --hook\; root (hd0,0)\; chainloader /bootmgr
}

.
.
Apply a windows

imagex.exe /apply E:\sources\install.wim 1 E:\
or
DISM.exe /Apply-Image /ImageFile:E:\sources\install.wim /Index:2 /ApplyDir:E:\

.
Run

mount_vhd.cmd /install E:

this creates a image E:\windows\Boot.vhd and adds boot files
adjust CmdLine: mount \windows\Boot.vhd at first boot asynchronous and continues setup
creates a task to mount \windows\Boot.vhd at regular boot

A Windows repair installation dosn't work.
Online update Windows 7 to Windows 10 won't work.
.
 mount_vhd.zip   3KB   624 downloads

Edited by cdob, 29 February 2016 - 03:02 PM.

[Wonko the Sane]

Create a BIOS bootable GPT disk

#96 http://reboot.pro/to...e-4#entry186656
or #172 http://reboot.pro/to...e-7#entry192974

Why not #209?
http://reboot.pro/to...o-gpt/?p=193659
(it should be easier and more "user friendly" )


Wonko

[cdob]

Why not #209?

Thanks, link adjusted.

[Advanced Shutdown]

cdob, thanks for the script. I've slightly adjusted it to my preferences and it helped complete the installation of W7 without problems.

Also, why is it necessary to mark the vhd as fixed in registry during every mount? Isn't it enough to create it with type=fixed parameter?

[cdob]

complete the installation of W7 without problems

Thank's for the report.
 

why is it necessary to mark the vhd as fixed in registry during every mount? Isn't it enough to create it with type=fixed parameter?

type=fixed refers to fixed volume size. This is not the issue.

The setting is about fixed disk against a removable disk. Most USB flash are removable disk.
Windows 7 marks a VHD as removable disk at every mount.
You may remove the VHD disk at user permission by mistake.
A fixed disk VHD isn't presented to remove.
http://www.sevenforu...ched-media.html

It's not required at Windows 8 and 10, but won't harm.
My simple approach: use always.

[Wonko the Sane]

 
type=fixed refers to fixed volume size. This is not the issue.

To be picky (as I am) type=fixed refers to the type of .vhd, a .vhd can be fixed, dynamic (or "sparse") or differencing (or "redo"), the "fixed" type is a RAW image with a single sector appended (footer) and it is the only type that can be mounted/accessed/mapped by grub4dos or memdisk (that only deal with RAW images, the .vhd in this case is treated as a RAW image and the last sector is simply ignored).

 

Wonko

[beroal]

Thanks to everyone who made this possible. "Grub2/Syslinux Memdisk/VHD/Windows 7" works okay. I noticed that "bcdedit" finds BCD only if the VHD file is attached, so I wrote a task that attaches it at Windows startup. There is an issue that is not directly related to this thread but is very important. The permissions of the VHD file and drives showing its partitions must be such that only administrators may access them.

[Fuzzo]

 

I've managed to boot Windows under BIOS + GPT setup with a small virtual MBR disk image (can be as small as 10 MiB, because NTFS needs to be at least 8 MiB).

 

Project Syslinux developed a module called MEMDISK, it's just a 26 kB small file, but is capable of loading disk images, including floppy image, (raw) hard disk image and iso image. This module can be involed from multiple bootloaders, such as GRUB Legacy, GRUB, Grub4Dos, and Syslinux of course.

 

I used to install Windows boot files (bootmgr and Boot\BCD) on a seperate physical USB drive with MBR layout. However carrying a USB drive to boot Windows is inconvenient.  So I tried to make a disk image of it and it worked. Here is how it works:

 

First, boot into Windows PE and use diskpart to prepare your disks.

# To see what disks you have
DISKPART> list disk
# System disk is disk 0 (to which Windows itself will be installed on)
# Windows PE disk is disk 1 (ignore it)
# The to-be-created VHD is disk 2 (to which Windows boot files will reside)
DISKPART> select disk 0
DISKPART> list partition
DISKPART> select partition 4
DISKPART> format label="Windows 8.1" quick
DISKPART> assign letter=c
# ^ Formatting Windows partition and assign letter C:
# Create and attach VHD
DISKPART> create vdisk file=c:\bootmgr.vhd maximum=32 type=fixed
DISKPART> attach vdisk
# Create and activate boot partition in VHD
DISKPART> select disk 2
DISKPART> create partition primary offset=1024
DISKPART> active
DISKPART> format label=bootmgr quick
# Assign a letter B:
DISKPART> assign letter=b
# Exit diskpart
DISKPART> exit

 

Second, install Windows and Windows boot files:

# Extract install.wim to C:
X:\> imagex /apply install.wim 1 c:
# Write boot sector and BCD
X:\> bootsect /nt60 b: /mbr
X:\> bcdboot c:\Windows /s b:

Now we've got a normal (without PBR, without BCD, without special partition flag) partition with Windows files in it, and a small (32 MiB) VHD file with Windows boot files (bootmgr, Boot\BCD, et cetra) in it.

 

I used to think that I need to convert VHD into raw image with "VBoxManage clonehd --type raw bootmgr.vhd bootmgr.img", but the good news is, when created with "type=fixed", the vhd file is no more than a raw image file + 512 Bytes footer, which will be recognized as "unpartitioned space" and will be ignored. So "type=fixed" vhd file can be directly fed to MEMDISK without convertion.

 

So here is how to load the small virtual boot disk in Grub4Dos:

 title bootmgr.vhd
   kernel /path/to/memdisk harddisk
   initrd /path/to/bootmgr.vhd

And here is my GRUB example:

menuentry "bootmgr.vhd" {
  linux16 /boot/syslinux/memdisk harddisk
  initrd16 /boot/bootmgr.vhd
}

 

Enjoy your Windows in BIOS + GPT.

 

Here is my original blog post (in Chinese): https://wzyboy.im/post/1049.html

 

 

Hello to all!

Thank you all for these intresting readings.

 

I've a BIOS-based system running Windows 7 on a MBR partitioned 1TB HDD (MB is an Intel D510MO with last BIOS)

This 1TB HDD is partitioned as following:

 

 - P0: 60 GB NTFS for Windows and Program files

 - P1: 940 GB NTFS for data

 

As this disk is going to be full, my pourpose is to migrate the existing installation to a new 3TB HDD, with following partitions:

 

  - P0: 60 GB NTFS the same as 1TB/P0

  - P1: 2940 GB NTFS with the content of 1TB/P1, plus more free space

 

As this partition is > 2TB, MBR cannot handle them well and i switch the 3TB HDD partition table to GPT but:

 

  - Windows 7 cannot boot from BIOS+GPT systems

 

Seems that GRUB is able to boot Windows 7 from GPT disks with a trick (see quote): a virtual HDD file (VHD) with MBR partition scheme that contains a partition with the Windows boot files that, once loaded, are able to load Windows from a GPT partition.

 

So i did the following:

 

  - P0: special GRUB 1MiB partition for GPT systems (see https://wiki.archlin...ic_instructions), installed by grub-install from a live Linux image)

  - P1: 128MiB ext2 partition to host GRUB files (grub.cfg f.e.) and the bootmgr.vhd file

  - P3: 60 GB NTFS partition where i copied all 1TB/P0 files

  - P4: 2940 GB (or a bit less) NTFS partition where i copied all 1TB/P1 files

 

In the VHD there is a MBR NTFS partition with the Windows boot files generated with commands:

    bootsect /nt60 b: /mbr
    bcdboot c:\Windows /s b: (NOT with /mbr flag as it's a GPT disk)

where B is the VHD file and C is a clean Windows 7 x64 installation running on a VM.

The VHD partition is set as primary and active. Needs also a kind of boot flag?

 

To avoid also some other issues, i generated also in the new 3TB/P3 the boot files with:

    bootsect /nt60 e:
    bcdboot c:\Windows /s e:

Where E is the 3TB/P3 partition.

 

Grub ls command show me the following:

• (hd0) - the whole disk
• (hd0,gpt4) - the 3TB/P3 filesystem
• (hd0,gpt3) - the 3TB/P2 filesystem, with Windows directory
• (hd0,gpt2) - the 3TG/P1 ext2 fs with Grub stuffs
• (hd0,gpt1) - the 3TB/P0 BIOS_GRUB special partition

 

I tried booting with grub using this manually edited grub.cfg:

    menuentry "Win7 root+chain no vhd" {
    	set root=(hd0,gpt3)
    	chainloader +1
    }
    
    menuentry "Win7 vhd+chain" {
    	loopback loop (hd0,gpt2)/boot/bootmgr.vhd
    	chainloader +1
    }

The first give me a Windows Boot Manager message: 

    "Error 0xc000000e File:\Boot\BCD Message: An error occoured while attempting to read the boot configuration data"

The second seems a Grub message 

    "Invalid signature"

May you please help me? I'm doing something wrong with Grub? VHD generation? Partition flags? Missing some BCD configuration?

Thanks in advance

 

Edit (more info):

• No /boot/syslinux directory exists in ext2 partition
• Grub version is 2.02 beta2 installed from a live Linux

Edited by Fuzzo, 12 December 2016 - 03:48 PM.

[Wonko the Sane]

 

Hello to all!

Thank you all for these intresting readings.

...

May you please help me? I'm doing something wrong with Grub? VHD generation? Partition flags? Missing some BCD configuration?

Thanks in advance

 

You simply cannot use the loopback device of GRUB2 as a replacement for Syslinux memdisk or for the grub4dos mapping, or other methods tested and reported as working.

 

Why don't you make it simpler and just follow this (making use of memdisk as kernel with GRUB2)?

http://reboot.pro/to...-10#entry197386

http://reboot.pro/to...-14#entry198148

 

Wonko

[Fuzzo]

Thanks for reply, one step ahead!

 

My last grub2 entry with memdisk copied from my Linux VM into my (hd0,gpt2):

menuentry "Windows 7 memdisk" {
  linux16 /boot/syslinux/memdisk harddisk raw
  initrd16 (hd0,gpt2)/boot/bootmgr.vhd
}

The bootmgr message is changed, now says:

File: \Windows\system32\winload.exe
Status: 0xc000000e
Info: Missing or damaged application

But the file exists

MintVM Windows # find . -iname winload.exe
./System32/Boot/winload.exe
./System32/winload.exe

Is it possible that the bootmgr look for winload.exe inside the VHD file where does not exixts?

May it depends because i'm using my old C partition in the new drive instead of imagex install.wim?

 

This is the BCD in (hd0,gpt3):

 

Thanks

[Wonko the Sane]

I don't know.

You may need to "correct" disk order (this is actually one of the reasons why grub4dos may be more handy, as it allows to remap disks or at least see which is which) i.e., it is possible that your "real" disk which is \Device\HardiskVolume2 in the BCD (and (hd0,gpt3) in GRUB2 notation) becomes - due to the "inserted" memdisk device (hd1,gpt3) or *whatever*?

Try making a "generalized" \boot\BCD entry with "locate"?

Some background:
http://www.multiboot...uk/cloning.html

http://www.multiboot...dows_seven.html

Some more recent notes:
http://reboot.pro/to...ch-using-linux/

 

 

Wonko

[cdob]

bcdboot c:\Windows /s b:

where B is the VHD file and C is a clean Windows 7 x64 installation running on a VM.

File: \Windows\system32\winload.exe
Status: 0xc000000e
Info: Missing or damaged application

The VHD BCD file refers to a partiton at a VM, not to the new hard disk.
Bootmgr can't find the partition at the new hard disk.

Boot a WinPE at real hardware with the new real hard disk.
Mount the VHD image at diskpart.
Run bcdboot again and create new boot files at the VHD image.

Added:
bcdboot c:\Windows /s b:
b: refers to the partition at the mounted VHD image
c: refers to the windows partitoin at the new real hard disk

Edited by cdob, 15 December 2016 - 04:58 AM.

[Fuzzo]

Hello,

i tried with your suggestion but i got an error: "cannot open BCD templates".

 

Later, i've found some bios updated that let my MB Intel D510MO to boot in UEFI mode so, with a GPT enabled Windows 7 USB key, i was able to install Windows 7 from scratch.

 

Thank you all for the help!

[steve6375]

I am not sure if this has been discussed before, but here is a way to MBR-boot to a Windows 10 GPT hard disk (even a bitlocker disk) from grub4dos without needing any floppy images or patching. You do need a way to boot to grub4dos though (e.g. USB drive).

 

I installed a UEFI-bootable version of Windows 10 using Setup.exe with GPT partitions and Bitlocker (optional).

You could boot using Clover if you had a non-UEFI system so that you can install and boot via UEFI without a UEFI-capable system (use E2B and a .imgPTN file containing the Windows 10 Install files made from the ISO).

 

1. Create a non-bitlocker partition on the hard disk if you do not have one already. I already had a Recovery Partition so I did not need to do this. You can instead use the EFI FAT partition if you wish. I tested both options.

2. Assign a drive letter to that partition using Diskpart if it does not have one

3. Run bcdboot c:\windows /s X: /f BIOS     where X: is the HDD partition

4. I then booted to a grub4dos USB drive (E2B of course!) with this menu.lst

iftitle [if exist (hd1,0)/bootmgr if exist (hd1,0)/boot/bcd] Boot to GPT disk
# map partition with boot files as floppy
map (hd1,0)+1 (fd0)
# hook BIOS interrupts
map --hook
# set floppy as root
root (fd0) || rootnoverify (fd0)
# make sure BIOS sees 1 floppy in system
map --floppies=1
# load bootmgr and boot
chainloader /bootmgr
boot

I also used BCDBOOT to add bootmgr and \boot\bcd to the USB drive and used a similar menu to boot from the USB drive - so no hdd partition was used.

 

If WEE or Grub4dos could be made to boot from the HDD, this would be a relatively easy process...

 

P.S. If creating a new partition on a drive of >2TB capacity, make sure the partition with the boot files is before the 2TB point so it can be accessed by the BIOS.

Edited by steve6375, 10 February 2017 - 01:32 PM.

[Wonko the Sane]

If WEE or Grub4dos could be made to boot from the HDD, this would be a relatively easy process....

Well this is more or less what has been already done in this thread, half-@§§edly by yours truly and in a much proper way by the good grub4dos developers, JFYI, the Chenall's UMBR:

 

http://reboot.pro/to...-11#entry197690

 

 

 

 

I think Windows can work fine with BIOS+GPT, no need to hack anything.
 
http://chenall.net/post/grub4dos_umbr/
 
UMBR is a one-sector mbr code, able to load a sector sequence(e.g., for grldr).
 
The idea is:
 
UMBR installed on the MBR(i.e., the LBA 0 of the GPT drive).
It will load sectors for GRLDR.
GRLDR load BOOTMGR
OK, Windows booted fine and desktop appears normally(according to user report).
 
Note that GRLDR works fine with GPT.

 

http://reboot.pro/to...-11#entry197691

 

 

 

Well, very nice , but this is more or less the same thing we did some time ago (in a sllightly different way) and that we are "revolving around":
http://reboot.pro/to...o-gpt/?p=193659
http://reboot.pro/to...o-gpt/?p=193947
the above approaches work fine and Windows boots seemingly "normally" BUT a few "features" are not working because of *something* in the BOOTMGR/boot\BCD\/Winload.exe etc. "hook" differently the BCD in the Registry.
Obviously this work of Chenall will be better , but it has to be tested to see if by using thins newish UMBR it is possible to bypass the mentioned issues .
 

Wonko

Then having a "hidden" partition to be mapped as (fd0) or using instead another (pre-existing or expressly made) partition, (or using the EFIBoot one) is just a matter of personal preferences.

 

 

 

The original approach was about making an existing GPT disk boot in BIOS in such a way that no modifications are made to it that are visible/accessible when normally booted in UEFI/GPT, but there is of course no real *need* to have the "hidden" partition, as while it was more or less a "requisite" in my original approach that it is not anymore so with the UMBR.

 

What you should test is whether with the existing partition (let's say the EFIboot one which should be "universal") the issues about locking the BCD, etc.

 

Wonko

[steve6375]

I can confirm that chenall's umbr utility worked.

I used a fresh Windows 10 UEFI install and the EFI partition to hold the boot files (see previous post) and \grldr and the \menu.lst file

 

In grub4dos I ran 

umbr -d=1 (hd1,1)/grldr

to install the MBR code

 

The \menu.lst in the EFI partition contains

# map partition with boot files as floppy
map (hd0,1)+1 (fd0)
# hook BIOS interrupts
map --hook
# set floppy as root
root (fd0) || rootnoverify (fd0)
# make sure BIOS sees 1 floppy in system
map --floppies=1
# load bootmgr and boot
chainloader /bootmgr
boot

@Wonko - what post should I be looking at to test for the problems you mentioned ??? There are too many posts in this thread!

[Wonko the Sane]

 

@Wonko - what post should I be looking at to test for the problems you mentioned ??? There are too many posts in this thread!

 

Hard to say.

There are n related posts, go around page 6 or 7, 8 look for posts by cdob, he made a lot of experiments with "FirmwareBootDevice" and "SystemBootDevice" (and Power Saving and Sleep/hybernation) and whether the \boot\BCD is mounted as BCD0000000 or not, but they were for 8/8.1, and - if I remember correctly - the "better" working approach was in the end using a VHD , then more tests by cdob on page 11 and the  - I believe at the moment "last suggested" - still via VHD here :
http://reboot.pro/to...o-gpt/?p=198148

and still update and repair won't work.

 

Wonko

[steve6375]

Using EFI partition for \boot\BCD, it boots and shuts down OK.

 

I think BCD in EFI partition is OK  (If I load HKLM\BCD00000000 it is correct).

 

But, I cannot make Hibernation work.

On boot I get in Registry

FirmwareBootDevice = multi(0)disk(0)fdisk(0)

SystemBootDevice = multi(0)disk(0)rdisk(0)partition(4)

 

If I set FirmwareBootDevice to same as SystemBootDevice it still will not Hibernate.

I tried partition(1),(2),(3) and none worked  (though partition(3) did try to hibernate and hung or reset)!

Any ideas?

[Wonko the Sane]

No particular ideas , only a few doubts.

 

How come it gets partition(4) in SystemBootDevice?

Aren't you mapping the EFI system partiton as (hd0,1)?

And isn't normally the EFI system partition the first one?

And isn't normally the "main" (or %SystemRoot%) the second one?

 

cdob when using the same values for both has the actual \boot\BCD on the "main" %SystemRoot%:

http://reboot.pro/to...o-gpt/?p=192902

 

Maybe it is a FAT32 vs. NTFS issue?

I.e. in your setup the partition(3) may be "right" but the hybernating fails because it is not NTFS? (and maybe lacks permissions, owner, *whatever*)

 

Wonko

[steve6375]

Windows Setup when booted via UEFI creates on a clean disk the following ptns:

ptn 1 - Recovery (hd1,0)  winpart 1  450MB NTFS

ptn 2 - EFI \System  (hd1,1)  winpart 2  100MB FAT

ptn 3 - Reserved MSR (hd1,2) winpart 3  16MB

ptn 4 - Windows  (hd1,3)  winpart 4   MAX NTFS

 

I also tried adding a 5th primary ptn to use for FirmwareBootDevice and that didn't work either.

[Wonko the Sane]

Windows Setup when booted via UEFI creates on a clean disk the following ptns:

ptn 1 - Recovery (hd1,0)  winpart 1  450MB NTFS

ptn 2 - EFI \System  (hd1,1)  winpart 2  100MB FAT

ptn 3 - Reserved MSR (hd1,2) winpart 3  16MB

ptn 4 - Windows  (hd1,3)  winpart 4   MAX NTFS

I see .

 

The most probably the only way is the one cdob used, having the \bootmgr and \boot\bcd on the same ptn 4 and setting both FirmwareBootDevice and SystemBootDevice to: multi(0)disk(0)rdisk(0)partition(4)

 

Or have you tried that and it doesn't work in that setup?

 

Wonko