Jump to content











Photo
* * * * * 1 votes

Hack Bootmgr to boot Windows in BIOS to GPT

bios gpt bootmgr winload

  • Please log in to reply
374 replies to this topic

#226 cdob

cdob

    Gold Member

  • Expert
  • 1438 posts

Posted 20 January 2016 - 10:19 PM

but then how can Sascha Weaver succeed as he described here? I've been around long enough to know the devil is in the details

Clarify your details, your requirements.

Booting a installed windows from a GPT?
Which windows version, 7,8,10 behave different in details
OS access to boot\bcd file from running windows? Store boot\bcd settings for next boot?
Installing to a GPT partiton? Setup is a addional task. A temporarily used second internal disk or USB disk may come handy. A image file can replace the second disk after installation.

Often you'll read messages describing parts only.
Try different approaches yourself.

A booted Windows dosn't require access to the boot\bcd file.
The file boot\bcd can be at a virtual floppy image or hard disk image.
If you like to have access to boot\bcd file, you have to mount the image.
 

MacBook Pro

Well, may be you are the first human to try this. Expect troubles.
Do not expect a exact process description.

Go for: use a hard disk image and mount the hard disk image at windows

By the way:
did you used a 34nm or 25nm flash vertex 2?

#227 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 20 January 2016 - 10:59 PM

From the comments on Sascha Weaver's superuser post:

 

 

In fact, BCD/Bootmgr will never be found by Windows, since it resides inside a floppy/disk image. So no question of auto-updating it. Auto-repair will not work. Anything related to microsoft tools related to your bootup will likely not work. – Milind R Sep 12 '14 at 11:57

 

It occurs to me that to work around this issue you could create an "alternate" boot folder in the SYSROOT, and this could be referenced within the running OS. The .vhd image could be updated to (may not be a trivial undertaking, in order to preserve the correct actual boot parameters invoked by memdisk) with the changes on the SYSROOT\Boot\BCD files.



#228 cdob

cdob

    Gold Member

  • Expert
  • 1438 posts

Posted 20 January 2016 - 11:13 PM

You have to differ:

there are early boot windows disk drivers: firadisk or wimvlbk: these can mount a disk image at boot time: the booted windows will detect \boot\bcd and can save settings to \boot\bcd.

there are non boot windows disk drivers. The disk image is mounted after boot, e.g. diskpart.exe and win7 native vhd drivers. The running window MAY save settings to \boot\bcd.

#229 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 20 January 2016 - 11:46 PM

Clarify your details, your requirements.

Booting a installed windows from a GPT?
Which windows version, 7,8,10 behave different in details

Yes. I detailed all of that in the background posts I linked, but my main concern right now is Windows 7. I'll get around too Win 10 once 7 is working.

OS access to boot\bcd file from running windows? Store boot\bcd settings for next boot?
Installing to a GPT partiton? Setup is a addional task. A temporarily used second internal disk or USB disk may come handy. A image file can replace the second disk after installation.

Again, my goal is ONLY GPT physical drives. I posted about keeping the .vhd image uptodate with any changes. I'm not as concerned about the at the moment.

Often you'll read messages describing parts only.
Try different approaches yourself.

I have, I am. Thx, that never occurred to me  :clap:

A booted Windows dosn't require access to the boot\bcd file.

Oh no? Try changing the boot menu without access to the BCD store. Concerns have been raised so I thought perhaps there are other situations where it is needed to be accessed.

The file boot\bcd can be at a virtual floppy image or hard disk image.
If you like to have access to boot\bcd file, you have to mount the image.

Yes, as Sascha Weaver explained. Have you read my posts on sevenforum?
 
Well, may be you are the first human to try this. Expect troubles.
Do not expect a exact process description.

I'm just looking for a few clarifications to what people have said they were able to do in this thread. I haven't been able to duplicate Sascha's results and boot Win 7 as he described using grub2--> memdisk --> bootmgr. I've seen your posts here in this thread, so I'm very surprised by your response to mine. Plus you state some pretty basic things as tho they would be revelations. I've spent hours reading this thread, which I think I stated up front. It's big and I may have missed something, but if so I suspect it will be a subtly, a detail left out or that the poster assumed would be known, such as the version of various things used. Results can vary significantly depending on what versions of grub and grub4dos are used.

Go for: use a hard disk image and mount the hard disk image at windows ??? Context please - I don't know what this is in regards to. BTW - I looked at your profile but don't see your native country. Sorry if English is not your 1st language or if cultural differences are an issue in our communications here.

By the way:
did you used a 34nm or 25nm flash vertex 2? It was a 2.5 inch, not a 3.5 inch drive. Also covered in my previous posts, tho on sevenforum. I did provide links to them tho.

Thanks for responding cdob!



#230 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 20 January 2016 - 11:49 PM

Weird forum response!  Too bad it doesn't provide a "Remove" button. When I clicked submit I saw the ajax spinner but no post appeared, it was as thos it went to the bit bucket. Some odd caching issue. Sorry for the duplicates. :whip:



#231 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 21 January 2016 - 12:09 AM

What is this forum notice about, saying: "You can make 13 more posts until 21 January 2016 - 12:56 PM." ?



#232 cdob

cdob

    Gold Member

  • Expert
  • 1438 posts

Posted 21 January 2016 - 03:38 PM

for a mixed OS BIOS multiboot system using only GPT drives and no USB boot required (virtual MBR is ok

Can you use USB boot as for installation time, not for daily boot?
 

then how can Sascha Weaver succeed as he described

It's not described: what to do after apply install.wim? How to boot next?
I expect setup to fail, if you boot from internal disk next: setup likes to write to \boot\bcd
I guess Sascha Weaver used his USB drive at the first two boot: setup can write to \boot\bcd
And Sascha Weaver did boot from the internal disk the next times.

Try to add Memdisk "raw" parameter.
http://reboot.pro/to...e-6#entry192051

Again, my goal is ONLY GPT physical drives.

Try the other approach: install windows to virtual MBR disk, capture this and apply to GPT physical drive.
 

Context please - I don't know what this is in regards to

The file boot\bcd is writable at running windows.

#183 http://reboot.pro/to...e-8#entry193161
nightrain uses firadisk to mount the VHD image at boot. No USB drive is required.
Unfortunately the driver is not signed.

Finally windows can boot correctly and recognize BCD correctly because the boot disk is "real" to windows.


#186 http://reboot.pro/to...e-8#entry193317mount the VHD image using windows default drivers

powershell.exe Mount-DiskImage -ImagePath c:\windows\boot.vhd -NoDriveLetter

#187 http://reboot.pro/to...e-8#entry193407This works at Windows 8.1
#216 http://reboot.pro/to...e-9#entry193939Windows 7 works at another approach.

 

It was a 2.5 inch, not a 3.5 inch drive.

nm not inch. https://en.wikipedia.../wiki/Nanometre
The question was NAND size. Hence about speed, possible write cycles and lifespan.
http://www.storagere...oczssd22vtxe60g
At second glance: the manufacturer described the 60GB and 120GB drive only, not he 80GB one. May be there exist no 80GB 25nm NAND model.
https://web.archive....-OCZ-SSD-drives

#233 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 21 January 2016 - 05:01 PM

Hey thanks for the tips, especially the one concerning the "raw" parameter. Those concerning Windows 8, grub4dos or MBR USB/HDD complicate things and are not where I want to go. I did some of that earlier, but seeing posts like Sascha's tells me there's a better way.

 

You say Sascha Weaver did NOT describe complete procedure, I disagree. You can believe what you will.

 

#183 - What are the ramifications of an unsigned driver? If it works I certainly don't care. I suspect the answer (besides corp. concerns), is that Windows has conditions around unsigned drivers, else they wouldn't have put the "Allow unsigned drivers" option with the F8 boot choices. If that is the only issue, can the BCD be fixed to always supply a "Yes" to that boot question?

 

I didn't look at the silicon tech for the old Vertec. It's definitely broken now, and it's out of warranty by age & ownership (I was not original buyer). Not worth discussing now.

 

If you want to talk about the Sandisk Plus 120GB, I'm all ears. It's not high end or newest tech, but it was cheap and about all I could afford. 



#234 cdob

cdob

    Gold Member

  • Expert
  • 1438 posts

Posted 21 January 2016 - 06:24 PM

What are the ramifications of an unsigned driver?

A watermark is displayed on dektop, can be hidden by third party tool.
 

can the BCD be fixed to always supply a "Yes" to that boot question?

https://msdn.microso...e/ff544880.aspx
http://www.ngohq.com/?page=dseo

#235 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 22 January 2016 - 01:55 AM

Try to add Memdisk "raw" parameter.
http://reboot.pro/to...e-6#entry192051

 

That was the crucial parameter Sascha Weaver left out which did the trick and allowed bootmgr to start. Awesome, progress! :good:

 

Until now I haven't done an installation using imagex /apply install.wim, so I had no idea what to expect as it began to run. I had what I think are the standard setup messages (for a sysprepped wim image?), to the effect of "Windows is setting up devices", all black background, simple animated graphic, kindof a line with a sunburst blooming in the middle.

 

After a short while it gave up and said: "Setup can't install Windows on this computer's hardware."

 

So I opened a command prompt with shift-F10 and used diskpart to mount the bootmgr.vhd file to V: (which I also I copied to the SYSROOT partition as well as the grub2 /boot partition that memdisk uses), then I copied the contents to C:\ with xcopy V:\*.* C:\ /E /H.

 

Using bcdedit I looked at the BCD contents on C:\boot\BCD and saw the {bootmgr} was set to V:\, so I set it to C:\ with:

 

 

bcdedit /set device hd_partition=C:

 

Then I rebooted. When setup resumed it popped up a similar (tho not exactly the same) dialog saying it could not install windows on this computer. I may also try removing the hd_ which according to the bcdedit help says that tells bootmgr to look only on hard drives and bypass vhd files. I don't think the vhd files are visible after bootmgr takes over, so I doubt this matters.

 

Not sure, but I wonder if I have now encountered a bootmgr issue others have seen that prompted milindsmart and others to go down the "modify bootmgr" trail. If so perhaps due to the complexity and length of this thread I missed the connection to this issue, and Sascha Weaver's reports of "success" were only to arrive at the setup screens, proving that bootmgr ran and actually launched Windows, but not going as far as having a running Windows you can login to.

 

So now I have several other ideas to check out:

  1. use bcdboot instead of bcdedit to fix the boot drive.
  2. wipe c:\ and go thru the imagex /apply step again, this time copying the modified BCD store to the root of the target partition (C:) as I have there now, basically a standard BCD pointing to C:\ as the {bootmgr} AND SYSROOT.
  3. restore a backup of a working system to the C:\ partition on the GPT drive, made from an MBR installation with Macrium.

 

If these fail and I discover bootmgr must be modified for this scheme to work completely, I'm not sure I want to do that, even if I learned how it could be done to facilitate BIOS booting Windows 7 on a GPT disk.

 

I also wonder if Wonko's approach, tho less elegant IMO, suffers from this same limitation (failure to get us all the way to a functional, repeatably bootable Windows 7 installation on a GPT drive).

 

That's what I know and where I'm going next. Comments welcome.



#236 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 22 January 2016 - 04:21 AM

I tried all of the options I described, all failed to produce a functional system I could login to.

 

  1. When I used bcdboot I could no longer open the BCD store with bcdedit. It produced an error saying: the boot configuration store could not be opened. The requested system device cannot be found. However, the folder and all of the files were indeed created.
  2. This produced the same result, but this time it made all the way through setting up devices. The sequence was:

               A. Setup is updating registry settings

               B. Setup is starting services

               C. Setup is installing devices

               D. Setup is applying system settings

               after this the popup appeared that said: Windows setup could not configure Windows to run on this computer hardware.

  3. Right after the windows boot menu was displayed the error page appeared from winload.exe: 0xc0000225

 

BTW, it didn't matter if the memdisk invocation was memdisk <file> harddisk raw or just raw, both worked the same.



#237 cdob

cdob

    Gold Member

  • Expert
  • 1438 posts

Posted 22 January 2016 - 04:48 AM

Applying Win10 install.esd or install.wim into a GPT partition, then booting as suggested in Sascha Weaver's post does not work for Win10. I tried this in several configurations and each time the partition would boot, and after a while report "Windows Setup could not configure Windows on this computer’s hardware".

Windows setup could not configure Windows to run on this computer hardware.

Setup expect a writable file boot\bcd in both cases.

Compare the "FirmwareBootDevice" at memdisk boot.
http://reboot.pro/to...e-6#entry192570

#238 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 22 January 2016 - 05:01 AM

Setup expect a writable file boot\bcd in both cases.

Compare the "FirmwareBootDevice" at memdisk boot.
http://reboot.pro/to...e-6#entry192570

 

Good idea. I made a half assed attempt to find those in the registry but gave up to move on to other things to try. I'll need to reapply the install.wim image but that's very easy and fast to do, then I can compare those 2 reg emtries.

 

Now that you mention serpens post I recall it too, however I was thinking it was only a Win 10 problem. Obviously not just Win 10.



#239 cdob

cdob

    Gold Member

  • Expert
  • 1438 posts

Posted 22 January 2016 - 05:20 AM

The idea was: set "FirmwareBootDevice" using unattended Windows setings.
http://www.sevenforu...-files-etc.html
https://technet.micr...y/cc722359.aspx
RunSynchronous commands run in the user context: this won't work here
Another unattended setting is required. No idea, if this works at given case.

#240 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 22 January 2016 - 07:33 PM

The idea was: set "FirmwareBootDevice" using unattended Windows setings.
http://www.sevenforu...-files-etc.html
https://technet.micr...y/cc722359.aspx
RunSynchronous commands run in the user context: this won't work here
Another unattended setting is required. No idea, if this works at given case.

 

Wow, the rabbit hole just keeps getting deeper.

 

I am looking over the autounattend.xml file from the thread you linked. I am only familiar with WAIK at a surface level. My exposure to it is quite limited and rather general.

 

I'm looking at the MS docs to get up to speed on the different "phases" of installation, and there's a great deal to digest. However, the crux of my understanding so far is to simply create an autounattend.xml file in the root of the target drive I /apply the install.wim to with imagex. The key is the correct "guts" of the xml file, and that's where understanding the details of the deployment phase is important.

 

Looking at this diagram, it would seem that setting the FirmwareBootDevice = SystemBootDevice could be done best in the windowsPE stage. The assumption being tested here is that will allow setup to proceed to completion on the GPT installation.

 

Only the general concept of the links you provided above seem useful here cdod, and unless I'm mistaken (quite possible) the Run*** commands will not work in the windowsPE section. If they do, I could construct an xml file, and refer to a .reg file to set the FirmwareBootDevice and SystemBootDevice entries based on your post here. The very link you provided on technet clearly states the RunSynchronuos is valid only in the later stages (auditUser / specialize).

 

Exactly what does Windows expect to see in the FirmwareBootDevice and what conditions does bootmgr require of it to allow setup to process the GPT resident Windows installation fully? If all that is required is to have a valid %SYSROOT%\Boot\BCD and FirmwareBootDevice = SystemBootDevice = %SYSROOT% I could make that happen, once I figure out the autounattend.xml contents.

 

Hey - just went to export a baseline .reg file to get the FirmwareBootDevice & SystemBootDevice values. Granted this is on a Windows 7 VM, but those values are NOT present. The cdod post did say they were on a 8.1 system, so is that why they're not present on my Win 7 VM or b/c it's a VM? I'm pretty confident it's NOT b/c it's a VM, so this entire train of thought may not be applicable to Win 7 at all. I'd potentially call this a red herring for my Win 7 efforts, tho it may come into play for Win 10.



#241 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 23 January 2016 - 03:25 AM

OK, ok, I'm at my breaking point, throwing in the towel and reverting to my plan for booting from an MBR SSD.

 

I cannot spend anymore time trying to get BIOS booting of Windows 7 on a GPT drive working. I really wanted to get this done, to implement the Rubic's Cube solution as it were, but as Wonko pointed out to me I can achieve all but 1 of my desired goals so why bother with GPT on a small SSD? That one goal was to rid my system of all MBR partitioned drives. That appeals to me and it would be nice, but not necessary. I have reached my threshold of effort to get this done. Good luck to those of you who continue to try. I will be keeping my eye on this thread, for sure.

 

I thought with all the reports of "success" I read in this thread (and some on sevenforums) it wouldn't be so difficult, but my conclusion is just the opposite. This topic has been around quite a long time now, so if all these efforts have led to even 1 solid, acceptable, repeatable solution why has nobody summarized the process into a list of steps to follow?

 

Wonko commented to me that I was trying to mix too much together, yet his approach to booting Windows on a GPT HDD requires much deeper technical prowess than my use of existing elements in a typical manor (i.e. grub2, memdisk, vhd virtual drives), and is also far more complex than Sacha Weaver's.

 

Had it not been for the lack of the "raw" memdisk parameter which cdob pointed out to me I would have gotten to the Windows setup screens with relative ease (Weaver documented the process quite well), succeeding in grub2-->memdisk-->bootmgr.vhd( bootmgr/BCD )-->setup.exe on a GPT drive. I thought I had it made in the shade when I saw the familiar "Starting Windows" fireflies, but noooooooooooooooo!!! Windows was not happy with that boot sequence and refused to complete the setup process. The impression I got from Weaver was his approach was a final solution. It wasn't that much different than milindsmart's, yet I didn't see others claiming they were able to repeat his success. Was it a one off? Did he leave off another crucial step? Perhaps he too assumed complete success when he saw the fireflies and was embarrassed to post a clarification. He was far more comprehensive in describing what he did than many other posts in this thread, but can it be repeated? I have my doubts. I know I wasn't able to with the steps he provided, but I did get close!

 

Is that why this thread is titled "Hacking bootmgr..." rather than "What it takes to boot Windows from BIOS on GPT without UEFI" ? How could I have missed that? Perhaps b/c only a small minority of posts in this thread actually deal with "hacking bootmgr" and instead deal with alternate boot methods to reach bootmgr (transcending real to protected mode), of which I myself can claim success, using Sascha Weaver's approach. But so what? Once bootmgr runs and launches the setup for the install.wim deployed by imagex, it fails in a bright ball of flames and results in a useless, incomplete installation.

 

It's really easy to get lost in this discussion, but my conclusion is that no summary or tutorial exists yet b/c the process is still elusive. Does it require hacking bootmgr (i.e. disassembly, hex editors, patching or reverse engineering etc) to be able to boot a fully functional non-UEFI Windows 7 with a legacy BIOS resident on a GPT disk, or, is it a matter of tricking the bootmgr with some script, registry change or unattend.xml to satisfy it's overly restrictive conditions that prohibit setup to complete and lead to a functional system (or allow a previously installed and functional installation to run properly) when it's %SYSROOT% is on a GPT drive?

 

I will admit my lack of recent professional experience when it comes to Windows IT, I'm near retirement age. I may be drawing a wrong conclusion, and someone with detailed understanding of sysprep and enterprise deployment will look at this and point out a simple solution to the incomplete installation, and if so great, but I can't wait around for that. I've spent too much time chasing this tiger as it is.

 

It will be interesting to see what comes.

 

Thanks for all your efforts!



#242 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 23 January 2016 - 08:48 AM

Once said that (obviously) I find my (rather automated and easily reproduced) approach much simpler than anything else, I cannot but underline how there is a basic misunderstanding. :w00t: :ph34r:

 

The origin of this thread was about booting from a BIOS an ALREADY installed on GPT disk (recent) Windows OS, the idea of installing a new instance of windows on a GPT disk on BIOS is relatively recent, and this is what we are discussing tentatively about modifying the "FirmwareBootDevice" value, see also this newish (and related) thread:

http://reboot.pro/to...able-usb-drive/

particularly this reply by cdob:

http://reboot.pro/to...drive/?p=197237

 

If one is determined to use a GPT disk to install to it a (recent) Windows OS from BIOS, the easiest would probably be that of making a "normal" GPT disk, then (temporarily) make it a MBR disk by replacing the protective partition entry with a partition entry for just the (NTFS) volume where the Windows is to be installed, then install the windows, restore the previous GPT protective partition entry and apply any of the methods discussed to allow the BIOS to boot the already installed windows.

 

:duff:

Wonko



#243 cdob

cdob

    Gold Member

  • Expert
  • 1438 posts

Posted 23 January 2016 - 08:59 AM

In addition, change to Sascha Weaver approach: mount the vhd image
And with Windows 7: http://reboot.pro/to...e-2#entry184489

Apply a default Windows 7 install.wim to a drive, as example to drive C:\
DISM.exe /Apply-Image /ImageFile:E:\sources\install.wim /Index:3 /ApplyDir:C:\

Use a boot image:
%SystemRoot%\boot.vhd, hence C:\windows\boot.vhd
boot this boot.vhd at grub2 memdisk raw
menuentry "(hd0,gpt3)/windows/boot.vhd" {
 linux16 /boot/syslinux/memdisk harddisk raw
 initrd16 (hd0,gpt3)/Windows/Boot.vhd
}
Adjust (hd0,gpt3) to local partitons.

Add a batch C:\windows\mount_vhd.cmd

There is a timing issue: vhd drivers are not avaible right after Apply-Image install.wim reboot: the vhd drivers are loaded later by detault.
No idea, how to do this clean at a unattended installation. Contrary a quick and dirty approach:

Reboot to internal hard disk. And wait for devices install to appear.
Press shift F10 and run mount_vhd.cmd once, twice or more times.
Bcdedit.exe should list options.

[boot.vhd]\boot\bcd should be loaded to HKLM\BCD00000000
And setup can write to [boot.vhd]\boot\bcd

Run mount_vhd.cmd at each boot. https://technet.micr...y/cc754995.aspx
And you may like to hide the boot.vhd partition at diskpart: atrributes volume set hidden

Windows 7 installation does works here. Bcdedit and msconfig have access to boot\bcd.

Be aware, it's experimental still.
.
mount_vhd.cmd
rem adjust Windows 7 BIOS to GPT: 
rem mount %Systemroot%\boot.vhd to V: and import V:\boot\bcd
rem created by cdob

cd /d %~dp0

(echo select vdisk file="%SystemRoot%\boot.vhd"
echo attach vdisk
echo list partition
echo select partition 1
echo assign letter=V
echo exit) >mount_vhd.txt
diskpart.exe < mount_vhd.txt
if not exist V:\boot\bcd (echo error: V:\boot\bcd not found &pause)

reg.exe load HKLM\BCD00000000 V:\boot\bcd
reg.exe add  HKLM\BCD00000000\Description /v KeyName /t REG_SZ /d "BCD00000000" /f
reg.exe add  HKLM\BCD00000000\Description /v System /t REG_DWORD /d 0x1 /f
reg.exe add  HKLM\BCD00000000\Description /v TreatAsSystem /t REG_DWORD /d 0x1 /f

bcdedit.exe


#244 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 23 January 2016 - 05:06 PM

Once said that (obviously) I find my (rather automated and easily reproduced) approach much simpler than anything else, I cannot but underline how there is a basic misunderstanding. :w00t: :ph34r:

Well of course you would, you created it, wizard that you are :clap:  Yet I saw few of your apprentices  (cdob the exception) exclaim in excitement they found nirvana in it, nor did you or anyone else take it to the next level and document ALL of the steps necessary for a reasonably competent professional such as myself to replicate it without the need to invest hours. I've seen worse documentation and outlines, but yours was terse enough that I couldn't follow it sufficiently. AND, as I said, the combination of tools you employed were far more complex and non-mainstream that other approaches described here. 

 

I'm belaboring the point, I explained my perspective above. I can live with a difference of opinion on that and respect your efforts.

 

The origin of this thread was about booting from a BIOS an ALREADY installed on GPT disk (recent) Windows OS, the idea of installing a new instance of windows on a GPT disk on BIOS is relatively recent, and this is what we are discussing tentatively about modifying the "FirmwareBootDevice" value, see also this newish (and related) thread:

http://reboot.pro/to...able-usb-drive/

particularly this reply by cdob:

http://reboot.pro/to...drive/?p=197237

 

The focus of the OP was how to get around bootmgr limitations. It said nothing about pre-installed or new installations, he simply provided a very short description of a totally normal, mainstream boot sequence with MBR disks. Then he asks: "Is it not possible to modify bootmgr to be able to read GPT?" Again, the focus was on altering the bootmgr, a point I admitted above I had missed. That's why I also said it was "really easy to get lost in this discussion".

 

If one is determined to use a GPT disk to install to it a (recent) Windows OS from BIOS, the easiest would probably be that of making a "normal" GPT disk, then (temporarily) make it a MBR disk by replacing the protective partition entry with a partition entry for just the (NTFS) volume where the Windows is to be installed, then install the windows, restore the previous GPT protective partition entry and apply any of the methods discussed to allow the BIOS to boot the already installed windows.

 

:duff:

Wonko

 

Perhaps, but it has also been stated (perhaps elsewhere, perhaps here) of the issues with using the hybrid protective MBR on a GPT drive. I went down that road on my MacBook Pro some time ago, Rob's gdisk was new at the time but we discussed the merits and downsides of the Apple approach. Since then I see many more issues with using the makeshift protective MBR so I avoid it like the plague.

 

It's a shame that nobody besides serpens has been willing to discuss in any significant manor Sascha Weaver's approach, it's merits and it's limitations. Unfortunately for me neither of them stay in touch here, or perhaps are too busy with other maters at the moment. Milindsmart did PM me but he is swamped at the moment.

 

I would be remiss if I didn't once again extend a sincere thanks for the discussion and best wishes in where ever you all decide to take this thread. The discussion is great, but unless it culminates in a step by step process or outline one can follow without the need to research every step to achieve the goal (booting either a preinstalled or new Windows 7, non-UEFI on a legacy BIOS machine), it's not practical and only academic in value (notice I did NOT say it had NO value).



#245 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 23 January 2016 - 05:46 PM

 

There is a timing issue: vhd drivers are not avaible right after Apply-Image install.wim reboot: the vhd drivers are loaded later by detault.
No idea, how to do this clean at a unattended installation. Contrary a quick and dirty approach:

Reboot to internal hard disk. And wait for devices install to appear.
Press shift F10 and run mount_vhd.cmd once, twice or more times.
Bcdedit.exe should list options.

 

Sounds plausible, IF the setup process is indeed interrupted by the cmd.exe process started with shift-F10, which I don't know. If it does your quick & dirty method may work, otherwise it depends on how fast one can type or effectively mount the vdisk relative to speed setup processes devices (asynchronously to cmd) and tries to access the BCD. Even if it's asynchronous, if setup's first access of the BCD is near the end of device setup it could work if the mounting was in a batch file like the one in your post. It would take only seconds to pop open cmd and run it.

 

Thinking this over I actually have serious reservations it could work. Have you looked at the BCD00000 tree in regedit? It has many entries, which may in fact be set by setup at install time as it sets up devices.

 

If it DOES work, then it should be possible to mount the vdisk in unattend.xml or autounattend.xml and also fix the registry. Like you cdob I don't have the knowledge of how to accomplish that. My brisk walk down that trail left me with more questions than I had time to learn.

 

As I said, if access the the BCD is all that is missing for bootmgr to be satisfied, why can't that (a copy of \Boot\BCD) be placed on the root of the target %SYSROOT% right after using imagex or dsim to creates the install image, before first boot, where bootmgr could see it? If bootmgr is capable of seeing the image installed on GPT by imagex, why can't it mount the BCD on that same partition? Perhaps it ONLY a matter of getting the registry's BCD000000 entry set to point to \Boot\BCD. Granted, mounting the actual vdisk for setup to access is a cleaner, better approach, but it's a matter of how tot accomplish that. I think it can be done via autounattend.xml but I don't know, or know how.

 

On a normal MBR installation using dsim or imagex, does it set the BCD000000 registry, or is that done on first run of setup at initial boot? My educated guess is that is done at first run of setup on target hardware.

 

One more thought - the lack of access to the BCD is not the reason for the 0xc0000225 error thrown by bootmgr when trying to boot a previously installed and functional (on an MBR HDD) Windows 7 installation moved to a GPT partition. Don't know for sure the exact cause of that error - could it simply be a mismatch of the drive's UUID / GUID, or do other conditions come to bare? Perhaps that's an easier nut to crack than a new install is. But again, beyond my current level of knowledge to answer.


Edited by thomnet, 23 January 2016 - 06:28 PM.


#246 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 23 January 2016 - 06:45 PM

Please note how I did not suggest the use of a hybrid MBR :no:, the idea was to (temporarily) replace the protective MBR partition table entry with one (or more) plain partition table entries pointing to the actual volumes, for the time needed to install Windows.



Quick recap (if needed, since I have been already accused enough of not documenting things/ideas):

A volume is a contiguous area on a mass storage device to which a filesystem is applied.

The volume extents, in the form of a Start LBA address (or "sectors before") and Num LBA (or "sectors in partition) can be indexed (or addressed) by two different "schemes".

Let us for the moment set aside the workaround consisting into the implementation of the Extended partition (and of logical volumes inside it) and let us limit ourselves to "primary partitions" only.

If you use the MBR partitioning scheme the Start LBA and Num LBA for the four available partition slots are on first sector of the device (or LBA0) at offsets:

1st partition 454 length 4 bytes and 458 length 4 bytes

2nd partition 470 length 4 bytes and 474 length 4 bytes

3rd partition 486 length 4 bytes and 490 length 4 bytes

4th partition 502 length 4 bytes and 490 length 4 bytes



If you use the GPT partitioning scheme the "protective" partition entry with ID 0xEE is in the first partition table slot and covers the whole device from LBA 1 to the whole extent of the device, while the actual Start LBA and Num LBA for the first four partitions are on third sector of the device (or LBA 2) at offsets:



1st partition 32 length 8 bytes and 40 length 8 bytes

2nd partition 160 length 8 bytes and 168 length 8 bytes

3rd partition 288 length 8 bytes and 296 length 8 bytes

4th partition 416 length 8 bytes and 424 length 8 bytes

(there is a backup of the whole stuff at the end of the disk, but this isn't relevant)



Due to the notation used, up to 0x00000000FFFFFFFF, i.e. up to 4,294,967,295 the first (left) four bytes of the 8 bytes field hold the same value as the whole 8 byte field.

On a smaller than roughly 2.2 Tb device there won't be values exceeding this value.



An additional consideration is that on recent Windows OS the Partition ID field on MBR disks is also a protective ID.

And the CHS values in MBR partitioning are currently ignored when booting by most BIOSes and booting code.



So the experiment would consist in:

  • partition a disk (smaller than 2.2 Tb) device "normally" in GPT, creating just one "Microsoft Data" partition large enough as you see fit to install the Windows
  • format this partition as NTFS
  • backup the first sector of the device
  • copy the Start Lba (4 bytes) from disk offset (1024+32)=1056 to offset 454
  • copy the Num Lba (4 bytes) from disk offset (1024+40)=1064 to offset 458
  • write 0x07 to offset 450
  • write the "standard" Windows MBR code to the disk (like using bootsect /mbr)



At this point you have (temporarily) a single partition MBR disk to which you can install normally your Windows.



Once you have installed the windows, you simply restore the first sector you backed up earlier and you have re-transformed the disk into a GPT disk.



At this point you can install GRUB2 and follow Sascha Weaver's way of making it actually boot again.



Most probably (but needs to be tested) a single grub4dos partnew command could do to write the MBR style partition entry, i.e. supposing you booted the system from a USB stick to grub4dos and thus the "target" GPT disk would be (hd1), you could backup the first sector to (say) sector 62 with something *like*:
WARNING NOT TESTED COMMANDS ONLY some hints, NEED to be checked and tested:

dd if=(hd1)0+1 of=(hd1)62+1 bs=512 count=1

then create the new partition table entry (it has to be seen if this is currently allowed directly)
partnew --active (hd1,0) 0x07 (hd1,0)+1

do the windows install, and then restore the original GPT first sector :
dd if=(hd1)62+1 of=(hd1)0+1 bs=512 count=1

 

and finally do the whatever you wish to do (installing GRUB2, making the .vhd file. etc.)

:duff:
Wonko



#247 cdob

cdob

    Gold Member

  • Expert
  • 1438 posts

Posted 23 January 2016 - 09:45 PM

Even if it's asynchronous, if setup's first access of the BCD is near the end of device setup it could work

It's run asynchronous, and setup tries to write this settings at the very end. There is plenty of time even at a SSD.

Thinking this over I actually have serious reservations it could work

It's working here.
 

As I said, if access the the BCD is all that is missing for bootmgr to be satisfied, why can't that (a copy of \Boot\BCD) be placed on the root of the target %SYSROOT%

Windows does mount \Boot\BCD to BCD000000 by default. Bootmgr(.efi) reads .\Boot\BCD.
The location of .\Boot\BCD is tranfered to windows. The booted windows finds .\Boot\BCD. The details are unknown.
Windows does not search target %SYSROOT%

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

Windows remembers \boot\bcd device. And reloads the file automatically!
Windows store boot disk configuration somehow.
I suspect MBR signature and checksum still

The previous mentioned assign letter=V and reg load is not required at mount_vhd.cmd.
 

On a normal MBR installation using dsim or imagex, does it set the BCD000000 registry, or is that done on first run of setup at initial boot? My educated guess is that is done at first run of setup on target hardware.

There dosn't exist a registry at dism or imagex. There are hive files at this level, e.g. system32\config\system. At each boot the files are loaded together to the registry.
 

the 0xc0000225 error thrown by bootmgr

The (os)device matches a non existing disk. Run bcdedit and adjust file bcd.
Or use bootice http://reboot.pro/to...-v078-released/
  • thomnet likes this

#248 thomnet

thomnet

    Member

  • Members
  • 62 posts
  •  
    United States

Posted 23 January 2016 - 11:57 PM

thomnet, on 23 Jan 2016 - 11:46 AM, said:snapback.png

Even if it's asynchronous, if setup's first access of the BCD is near the end of device setup it could work

It's run asynchronous, and setup tries to write this settings at the very end. There is plenty of time even at a SSD.

I just used fujianabc's "fast installer" to reimage C: based on a PM Wonko sent me, so I can't get to cmd window now due to the 0xc0000225 issue (the attempt to bypass stage 1 failed). To try this I'll need to restore install.wim by imagex.
 

thomnet, on 23 Jan 2016 - 11:46 AM, said:snapback.png

Thinking this over I actually have serious reservations it could work

It's working here.

Good to know BCD is written to at the end.
 

thomnet, on 23 Jan 2016 - 11:46 AM, said:snapback.png

As I said, if access the the BCD is all that is missing for bootmgr to be satisfied, why can't that (a copy of \Boot\BCD) be placed on the root of the target %SYSROOT%

Windows does mount \Boot\BCD to BCD000000 by default. Bootmgr(.efi) reads .\Boot\BCD.
The location of .\Boot\BCD is tranfered to windows. The booted windows finds .\Boot\BCD. The details are unknown.
Windows does not search target %SYSROOT%

Don't understand - if "The booted windows finds .\Boot\BCD" then it must search the SYSROOT, as that is normally where it is if you have only a single partition and no MSR, which is a configuration I have used many times.

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

Quote

Windows remembers \boot\bcd device. And reloads the file automatically!
Windows store boot disk configuration somehow.
I suspect MBR signature and checksum still

The previous mentioned assign letter=V and reg load is not required at mount_vhd.cmd.

Hmmm... I made an assumption that upon reflection may have been wrong. The "/boot" folder in the grub2 menu is probably not referring to the partition (either 2 or 3) used for grub files (not talking about the core.img written to grub_bios but all the other grub files like grub.cfg), but rather the C:\Windows\Boot folder. The process Weaver documented doesn't provide any details about where grub2 is installed. That was my first question in this post on sevenforum.

 

The question is which partition is his grub2 referencing in this menu definition, there is no context given to know:

 

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

I could load an ntfs module in grub2 and use the vdisk image file created on the C:\ and mounted on B:, so THAT is the actual disk memdisk loads, rather than the copy of it I put in /boot/syslinux on the btrfs partition I used for the grub2 files. That still doesn't get the vdisk file mounted as drive B: when setup starts, but if mounted by a system startup script it would be the one used by both grub2 and windows at boot time.

 

According to Wonko the B: drive (the vdisk file drive with bootsect and BCD) won't be visible to bootmgr, which I think is pretty clear or setup would find it and there would be no problem. Therefore it seems like a startup script is necessary to mount it. I just don't see how Sascha's approach could work as documented, if the B: drive is not within bootmgr / setup.exe scope.

 

thomnet, on 23 Jan 2016 - 11:46 AM, said:snapback.png

? that version of bootice doesn't appear to work on GPT.

On a normal MBR installation using dsim or imagex, does it set the BCD000000 registry, or is that done on first run of setup at initial boot? My educated guess is that is done at first run of setup on target hardware.

There dosn't exist a registry at dism or imagex. There are hive files at this level, e.g. system32\config\system. At each boot the files are loaded together to the registry.

Yep, as I suspected.
 

thomnet, on 23 Jan 2016 - 11:46 AM, said:snapback.png

the 0xc0000225 error thrown by bootmgr

The (os)device matches a non existing disk. Run bcdedit and adjust file bcd.
Or use bootice http://reboot.pro/to...to work on GPT.

That version of bootice doesn't appear to work on GPT.

 

As for mounting the vhd file, I don't think the system startup scripts will be run until after setup completes. The link you posted about that is a group policy and those directions assume the system is installed and operational. We need a way to run a script within the setup process, such as unattend.xml, but we've been over that.


Edited by thomnet, 24 January 2016 - 12:06 AM.


#249 cdob

cdob

    Gold Member

  • Expert
  • 1438 posts

Posted 24 January 2016 - 10:21 AM

then it must search the SYSROOT,

Well, I disagree.
Read the XP example: The loader ntldr passes boot disk to the kernel using Signature Method.
http://www.911cd.net...showtopic=21242
I bet: bootmgr passes boot disk to the kernel in a similiar way.
The kernel dosn't search the boot disk, because it's known at that level.
And the Fake Signature Method approach may work at BIOS GPT disk too. Most likely has to be adjusted to bootmgr requirements, the details are unknown.
 

as that is normally where it is if you have only a single partition and no MSR

The kernel may find boot\bcd at another approach, the kernel dosn't have to search SYSROOT.
 

I could load an ntfs module in grub2 and use the vdisk image file created on the C:\ and mounted on B:, so THAT is the actual disk memdisk loads

Yes, that's the way to go.

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

Use a boot image:
%SystemRoot%\boot.vhd, hence C:\windows\boot.vhd

Use one file both for grub2 medisk and for windows mount. Windows msconfig can write to boot.vhd, changes are available at next boot.
 

I just don't see how Sascha's approach could work as documented, if the B: drive is not within bootmgr / setup.exe scope.

Again, what's documented and what's not? Sascha didn't described how to boot after imagex apply. I's documented Sascha pocess a bootable USB MBR to local GPT disk. Sascha may have used this USB disk at first boot.
 

that version of bootice doesn't appear to work on GPT.

Well, that version of bootice lists Windows Boot manager "ApplicationDevice [C:\]Windows\Boot.vhd"
It works at GPT. And it works at BIOS GPT hard disk image approach.
 

The link you posted about that is a group policy and those directions assume the system is installed and operational.

This part is for daily usage, after windows got installed. Mount boot.vhd always at statup at each boot.
 

We need a way to run a script within the setup process, such as unattend.xml, but we've been over that.

Yes, this is the missing part.
Or we can use firadisk.
If we like testmode, we can keep firadisk.
If we don't like testmode, we can swap to native drivers at end of installation. E.g. at setupcomplete.cmd

#250 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 24 January 2016 - 03:18 PM

According to Wonko the B: drive (the vdisk file drive with bootsect and BCD) won't be visible to bootmgr, which I think is pretty clear or setup would find it and there would be no problem. Therefore it seems like a startup script is necessary to mount it. I just don't see how Sascha's approach could work as documented, if the B: drive is not within bootmgr / setup.exe scope.

 

I don't think that Wonko ever said that.

 

:duff:

Wonko







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

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users