362 replies to this topic

[thomnet]

I don't think that Wonko ever said that.

 

Wonko

 

Oh no? How else would you interpret this (emphasis mine):

 

Wonko the Sane, on 12 May 2015 - 11:24 AM, said:

I am not implying anything.

 

I am plainly stating that a virtual disk temporarily mapped through memdisk, grub4dos or any other "real mode" loader/pre-boot environment will vanish as soon as "protected mode" is reached as any Windows NT OS will re-scan the system to load the available media through the HAL and related drivers, so if you want to have that virtual disk available also in the Windows NT OS you need to map it at boot time through an appropriate driver (which at the state of the art means either Firadisk or WinVblock, not because there are not other suitable drivers, but because these two provide mechanisms to "hook" Syslinux/memdisk or grub4dos mapped virtual disks).

 

Whether this will help in solve the "sleep" issue or not or if this will open another can of worms is another thing.

 

Wonko

 

Sleep issue aside it sure sounds to me like you're now changing your tune. I think an explanation is in order b/c what you said makes sense and it was quite unambiguous and indeed "plainly stated".

[thomnet]

I started Wonko's experiment by first making a backup of the 1 TB GPT HDD that I installed grub2 on according to Sascha Weaver's example (post #45). I figured I would restore partitions from that later to regain grub_bios and grub partitions, the later which would need to be located elsewhere on the GPT disk. Here are the partitions in that backup:

gpt1: 960K  grub_bios
gpt2: 500MB btrfs for grub2 files and config, memdisk
gpt3: 128MB MSR
gpt4: 80GB  C:\Windows (partially installed Win7 using fujianabc's fastInstaller)
gpt5: 200GB HPS+ partition to save some files off my MacBook Pro

I used diskpart under Macrium PE, 32 bit:

select disk 0
clean
convert gpt
create partition primary size=80000
format quick fs=ntfs label="Win 7 Ultimate"
assign letter="C"

I made a backup of MBR, actually the entire first sector

Not surprisingly, diskpart still sees the disk as GPT. A reboot should fix that.

Then I rebooted into Linux and ran:

dd if=/dev/sda of=/dev/sda bs=1 count=4 skip=1056 seek=454
dd if=/dev/sda of=/dev/sda bs=1 count=4 skip=1064 seek=458

Which copied the GPT partition info as Wonko described into the MBR.
I used a disk editor later to change MBR offset 450 from EE to 07.

I then rebooted back into Macrium (version 6.1, buid 1023, 32 bit PE).
Diskpart now sees the disk as MBR. I used fujianabc's fast installer script to apply install.wim to C:. (Note to self: use starter edition for testing to speed up installation)

Before rebooting the new installation I made a backup of the entire disk with Macrium.

The first boot of the target started with fireflies, looked good, but never progressed. Rebooted into safe mode and it hangs at disk.sys driver.

Retried the experiment by using imagex /apply instead of fast installer. Exact same results. Booted Win 7 DVD and ran repair, which failed. Rebooted and ran install off of DVD. After the setup finished the list of checkmarks it rebooted itself. I instead booted off the USB HDD and ran Linux to snag a copy of the first 34 sectors of the drive.

My conclusion is you can't convert between GPT and MBR this way. You can see the remnants of the GPT table, which really shouldn't matter after changing LBA0 offset 450 from EE to 07, but apparently it does.

Although I said I reached the limits of my endurance to find a solution to boot Windows 7 from BIOS to GPT disk yesterday, I thought the experiment sounded reasonable and worth a try, since it came from Wonko. So now I truly am moving on, back to MBR boot land. Bye for now.
 

I guess it's sevenforum that uses attachments to post screenshots.

 

 

 

 

Edited by thomnet, 24 January 2016 - 06:49 PM.

[cdob]

So now I truly am moving on, back to MBR boot land. Bye for now.

Do you refuse a temporarily used USB disk still?
This helps to survive first boot after imagex/dism apply. It's not required later.

[Wonko the Sane]

Well, if the remnants of the GPT table are actually "seen", one could backup first three sectors, modify/copy the partition entry and wipe clean sectors LBA1 and LBA2 and then restore them.

It sounds like something else was the issue, however.

 

 

Wonko

[thomnet]

Well, if the remnants of the GPT table are actually "seen", one could backup first three sectors, modify/copy the partition entry and wipe clean sectors LBA1 and LBA2 and then restore them.

It sounds like something else was the issue, however.

 

Wonko

 

I concur, and that something is Micro$oft being overly rigid. Just used the fast installer and the Macrium PE to do an install onto the MBR SSD. Nice tool, was not only fast but easy. Now I'm moving \Users, Program Files***, and ProgramData to a GPT drive. Taking a break to grab a bite to eat. 

 

Another rabbit hole I don't have the time for but at some point my give a go is using Win 8.1's wimboot to install Win 7. If that works very well it's a nice way to save drive space with limited impact on performance.

 

Now I know how they've been able to reduce RAM requirements too. Thought it was odd that tablets could run Win 8 fairly well on only 2 gigs of RAM. I suspect the same compression technology is used in the .NET engine and elsewhere to accomplish that.

Edited by thomnet, 24 January 2016 - 09:49 PM.

[Wonko the Sane]

Oh no? How else would you interpret this (emphasis mine):

 

Wonko the Sane, on 12 May 2015 - 11:24 AM, said:

 

Sleep issue aside it sure sounds to me like you're now changing your tune. I think an explanation is in order b/c what you said makes sense and it was quite unambiguous and indeed "plainly stated".

Sure , the misunderstanding is about the sheer moment the switch happens.

As I see it BOOTMGR is running in "real mode" (and as a matter of fact can see the virtual disk fine, finding the \boot\BCD alright) but when control is passed to WINLOAD.EXE, the virtual disk is lost.

To be even more accurate in some stage of the booting process (and there are different opinions whether this happens still within BOOTMGR - but anyway AFTER the \boot\BCD has been accessed and read - or once WINLOAD.EXE has been loaded and is running or possibly even later) the HAL re-enumerates hardware devices and since the virtual disk is not a "real, hardware" disk it is ignored (unless a driver *like* Firadisk, Winvblock or the built-in in some Windows "native" .vhd booting "hooks" it).

 

Wonko

[thomnet]

Sure , the misunderstanding is about the sheer moment the switch happens.

As I see it BOOTMGR is running in "real mode" (and as a matter of fact can see the virtual disk fine, finding the \boot\BCD alright) but when control is passed to WINLOAD.EXE, the virtual disk is lost.

To be even more accurate in some stage of the booting process (and there are different opinions whether this happens still within BOOTMGR - but anyway AFTER the \boot\BCD has been accessed and read - or once WINLOAD.EXE has been loaded and is running or possibly even later) the HAL re-enumerates hardware devices and since the virtual disk is not a "real, hardware" disk it is ignored (unless a driver *like* Firadisk, Winvblock or the built-in in some Windows "native" .vhd booting "hooks" it).

 

Wonko

 

OK, thanks for that explanation.

 

I don't mean any disrespect, truly I don't but your post was rater emphatic about being explicit and the point of it was to remove ambiguity. Here you add further details which actually are mostly conjecture (about which component, bootmgr or winload) has access to the BCD and when and under what conditions the vhd device disappears.

 

My only point in saying all this is that this is a very intricate and nuanced process, and we can only observe it from the outside. If anyone from M$ with insider info is participating in this convo I would be surprised and I would highly suspect if they were their agenda is more for disinformation than enlightenment. 

 

I am engaging here with far less knowledge of Windows than many here in this thread have demonstrated through their posts, yet I am no spring chicken. Nevertheless my focus is more practical than philosophical. In engineering design discussions I often play the other role, but I'm here to learn what I need (actually I have learned much more on this forum than my goals require) to reach an objective.

 

There are some really great minds participating on this forum and working on this puzzle, that's easy for me to see.

 

Pls forgive me if my injection into this thread has been disruptive or unhelpful. I'm just trying to get at the truth of the matter and reach my goals. You can say those goals are silly and not worth spending time on, but technical puzzles like this intrigue me and are a splinter in my mind. Oddly enough I'm not really a "puzzle solving" kind of guy, but technical puzzles are somehow different for me.

[cdob]

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.

Let's try it: Kansas City Shuffle from boot.vhd to GPT partition
Let's assume a simple case: a small boot.vhd

W: offline GPT windows at partiton 3.

Create a boot.vhd

diskpart.exe
create vdisk file="W:\windows\boot.vhd" maximum=64 type=fixed
attach vdisk
create par prim size=1
create par prim size=1
create par prim
active
format label=bootmgr
assign letter=S
exit

.
bcd at #SystemRoot# and boot.vhd created

bcdboot.exe W:\windows /s W:
bcdboot.exe W:\windows /s S:

.
The checksum adjusted http://www.911cd.net...ndpost&p=145456

copysgcs \\.\physicaldrive3 J:\Windows\Boot.vhd 0x1B0
src signature=44434241  checksum=C307325A
copy signature
copy checksum (offsetcs=01B0)
dst signature=44434241  checksum=C307325A

.
The booted windows list

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control]
"FirmwareBootDevice"="multi(0)disk(0)rdisk(0)partition(3)"
"SystemBootDevice"="multi(0)disk(0)rdisk(1)partition(3)"

.
boot.vhd is not mounted.
bcdedit.exe dosn't find bcd.
No, Kansas City Shuffle dosn't work at that idea.
The details are unknown still.

[Wonko the Sane]

@thomnet

No, this is clear enough.

BOOTMGR is chainloaded (normally by the MBR code, or by a loader such as grub4dos) then the \boot\BCD is accessed by BOOTMGR (in practice it is the \boot\BCD that "tells" BOOTMGR which WINLOAD.EXE to load and which parameters to pass it).

Until the \boot\BCD is accessed the system is definitely in "real mode" as the \boot\BCD is found even if residing in a virtual disk.

The not entirely ascertained thing is whether BOOTMGR is "entirely" in "real mode" and the "switch" between "real mode" and "protected mode" happens when Winload.exe is running, or if it happens "before" (i.e. while BOOTMGR, after having read the \boot\BCD, is stillrunning) or if it happens "after" (i.e. when the *something else* that Winload.exe invokes is running).

Not that it would make any practical difference, only your summing up of my statement delivered the "opposite" message

"According to Wonko the B: drive (the vdisk file drive with bootsect and BCD) won't be visible to bootmgr"

the \boot\BCD is actually visible by BOOTMGR and is lost after BOOTMGR has parsed it.

 

Anyway AFAICT most of the people involved like these "technical puzzles" (just like you) and any idea/report/test is welcome as it may represent a part of the solution...

 

@cdob

Which re-mapping you did in grub4dos before?

Something *like*

map --mem /boot.vhd (hd0)

map --hook

right?

 

Maybe setting hard disk num at 1?

Or passing an edx= parameter *like* :

http://reboot.pro/to...d-boot-problem/

http://reboot.pro/to...s-7-unbootable/

 

Wonko

[serpens]

 

• 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". 

 

Well, it seems that I'm not entirely out of the woods. I don't use my Win 10 partition very often, and when I started it up recently I discovered that it would not apply an update. That update turns out to be Windows 10 1511 Build 10586. The symptom is very similar to the installation problem I described in my original post. The update says that it is preparing to be installed, the machine reboots, proceeds through what seems to be 100% of the post-boot update, then says that it cannot complete and must be backed out. Checking the event log yields the error message:

Installation Failure: Windows failed to install the following update with error 0x800F0922: Cumulative Update for Windows 10 for x64-based Systems (KB3124266).

It could be that the error is actually generated much earlier, but is only reported at the end of the procedure, then causing the update to be backed out.

 

A google search turns up the following hint:

• A suggestion that it is related to free space in the system reserved partition: http://answers.micro...d8c13376?auth=1

 

I discover there is an update log that might contain information: http://blogs.technet...acefmt-exe.aspx

 

Well, it turns out not to tell me much more:

2016/01/28 21:52:30.1367739 920   2792  Agent           Attempt 3 to obtain post-reboot results for event with cookie 30494152_2298305391.
2016/01/28 21:52:32.3446196 920   2792  Handler         Post-reboot status for session 30494152_2298305391: 0x800f0922.

However, that gives me a clue to go looking for logs, which leads to looking for setuperr.log, and then to looking in C:\$WINDOWS.~BT which leads to the file C:\$WINDOWS.~BT\Sources\Panther\setuperr.log:

2016-01-28 22:13:04, Error                        CDiagnosticsHelper::SetSQMDatapoint: Attempting to set a datapoint in an invalid SQM session
2016-01-28 22:13:07, Error                        CDiagnosticsHelper::SetSQMDatapoint: Attempting to set a datapoint in an invalid SQM session
2016-01-28 22:13:09, Error                 MOUPG  CDlpActionImpl<class CDlpErrorImpl<class CDlpObjectInternalImpl<class CUnknownImpl<class IMoSetupDlpAction> > > >::Suspend(1066): Result = 0xC1800104
2016-01-28 22:13:09, Error                 MOUPG  CSetupManager::ExecutePreDownloadMode(6829): Result = 0x800705BB
2016-01-28 22:13:09, Error                 MOUPG  CSetupManager::ExecuteDownlevelMode(381): Result = 0x800705BB
2016-01-28 22:13:09, Error                 MOUPG  CSetupManager::Execute(232): Result = 0x800705BB
2016-01-28 22:13:09, Error                 MOUPG  CSetupHost::Execute(371): Result = 0x800705BB
2016-01-28 22:13:15, Error                 CONX   ConX::Compatibility::CSystemAbstraction::GetSystemVolumeNtPath: Failed to retrieve system partition NT path.
2016-01-28 22:13:15, Error                 CONX   CFreeSystemPartitionDiskSpaceChecker failed. [Failed to retrieve system volume NT path.] HRESULT = 0x80070003
2016-01-28 22:13:15, Error                 CONX   ConX::Compatibility::CCompatibilityHost::SetScanResult: Compat scan from provider wsc:setup: failed. HRESULT = 0x80070003
2016-01-28 22:14:42, Error                 MOUPG  CDlpActionCompat::ExecuteSysReqScan(773): Result = 0x80070003
2016-01-28 22:14:42, Error                 MOUPG  CDlpActionCompat::ExecuteRoutine(620): Result = 0x80070003
2016-01-28 22:14:42, Error                 MOUPG  CDlpActionImpl<class CDlpErrorImpl<class CDlpObjectInternalImpl<class CUnknownImpl<class ICompatAction> > > >::Execute(441): Result = 0x80070003
2016-01-28 22:14:43, Error                 MOUPG  CDlpTask::ExecuteAction(3243): Result = 0x80070003
2016-01-28 22:14:43, Error                 MOUPG  CDlpTask::ExecuteActions(3397): Result = 0x80070003
2016-01-28 22:14:43, Error                 MOUPG  CDlpTask::Execute(1631): Result = 0x80070003
2016-01-28 22:14:43, Error                 MOUPG  CSetupManager::ExecuteTask(2024): Result = 0x80070003
2016-01-28 22:14:43, Error                 MOUPG  CSetupManager::ExecuteTask(1987): Result = 0x80070003
2016-01-28 22:14:43, Error                 MOUPG  CSetupManager::ExecutePreDownloadMode(6821): Result = 0x80070003
2016-01-28 22:14:43, Error                 MOUPG  CSetupManager::ExecuteDownlevelMode(381): Result = 0x80070003
2016-01-28 22:14:45, Error                 SP     CSetupPlatform::ResurrectNewSystem: Cannot resurrect new system.: Win32Exception: \\?\C:\$Windows.~BT\Sources\NewSystem.dat: The system cannot find the file specified. [0x00000002] __cdecl UnBCL::FileStream::FileStream(const class UnBCL::String *,enum UnBCL::FileMode,enum UnBCL::FileAccess,enum UnBCL::FileShare,unsigned long)[gle=0x00000002]
2016-01-28 22:15:09, Error                 MOUPG  CSetupManager::Execute(232): Result = 0x80070003
2016-01-28 22:15:09, Error                 MOUPG  CSetupHost::Execute(371): Result = 0x80070003

 Scanning though that list, the following stand out for me:

• ConX::Compatibility::CSystemAbstraction::GetSystemVolumeNtPath: Failed to retrieve system partition NT path.
• CFreeSystemPartitionDiskSpaceChecker failed
• CSetupPlatform::ResurrectNewSystem: Cannot resurrect new system.

Another google search turns up:

• A suggestion that the installer cannot find the System Reserve Partition: https://www.reddit.c...t_check_system/
• A very similar issue for someone upgrading to Win10: http://www.sevenforu...42b#post3143988
• A suggestion to that it is necessary to set both the device and osdevice entries in the BCD: http://www.sevenforu...tml#post3150003

 

Dumping the content of \Boot\BCD shows that device is set in many places, but osdevice only set in once place (Windows Boot Loader for "Windows 10"):

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=C:
description             Windows Boot Manager
locale                  en-us
inherit                 {globalsettings}
default                 {default}
resumeobject            {4cc765ac-6c1e-11e5-8997-00224d7a5e2f}
displayorder            {default}
toolsdisplayorder       {memdiag}
timeout                 30

Windows Boot Loader
-------------------
identifier              {default}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 10
locale                  en-us
inherit                 {bootloadersettings}
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {4cc765ac-6c1e-11e5-8997-00224d7a5e2f}
nx                      OptIn
bootmenupolicy          Standard

Resume from Hibernate
---------------------
identifier              {4cc765ac-6c1e-11e5-8997-00224d7a5e2f}
device                  partition=C:
path                    \Windows\system32\winresume.exe
description             Windows Resume Application
locale                  en-us
inherit                 {resumeloadersettings}
allowedinmemorysettings 0x15000075
filepath                \hiberfil.sys
bootmenupolicy          Standard

Windows Memory Tester
---------------------
identifier              {memdiag}
device                  partition=C:
path                    \boot\memtest.exe
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}

The other suspicious thing I noticed is that if I run bcdedit without explicitly specifying the location of the store, I get an error message:

C:\>bcdedit /enum all
The boot configuration data store could not be opened.
The requested system device cannot be found.

Edited by serpens, 31 January 2016 - 05:26 PM.

[serpens]

The other suspicious thing I noticed is that if I run bcdedit without explicitly specifying the location of the store, I get an error message:

C:\>bcdedit /enum all
The boot configuration data store could not be opened.
The requested system device cannot be found.

 

There are two things that potentially lead to this error message. The first is an attempt to read FirmwareBootDevice from the registry. This seems to be rewritten each boot. Copying SystemBootDevice over this key, then running bcdedit again leads to the following:

#	Time of Day	Thread	Module	API	Return Value	Error	Duration
185	11:42:31.534 AM	1	bcdedit.exe	NtQuerySystemInformation ( SystemSystemPartitionInformation, NULL, 0, 0x000000af5126f3b8 )	STATUS_SYSTEM_DEVICE_NOT_FOUND	0xc0000452 = The requested system device cannot be found. 	0.0006614
...
353    11:42:31.565 AM    1    bcdedit.exe    RtlNtStatusToDosError ( STATUS_SYSTEM_DEVICE_NOT_FOUND )    ERROR_SYSTEM_DEVICE_NOT_FOUND        0.0000014
...
356    11:42:31.565 AM    1    KERNELBASE.dll    RtlFormatMessageEx ( "The requested system device cannot be found.
", 0, TRUE, FALSE, FALSE, NULL, "籰兀¯", 94, 0x000000af5126f36c, 0x000000af5126f3a8 )    STATUS_SUCCESS        0.0000019

• Is there a way to have FirmwareBootDevice written correctly or re-written into the registry ?
• Is there a way to correct the way NtQuerySystemInformation works ?

[Wonko the Sane]

Is there a way to have FirmwareBootDevice written correctly or re-written into the registry ?

 

Maybe when offline?

Either using (from a PE) the Offline Registry editor:

http://reboot.pro/to...fline-registry/

 

Or using a Linux (or directly hex-editing the Registry)

See (seemingly unrelated):

http://reboot.pro/to...ch-using-linux/

 

Further question/doubt:

Maybe the issue you report is related to BCDboot not working properly?

 

Wonko

[cdob]

Which re-mapping you did in grub4dos before?

I used memdisk as described lately #243 http://reboot.pro/to...-10#entry197386

memdisk shift the reals disks and map the image to hd0, menu.lst translation:
map (hd0) (hd1)
map --mem /boot.vhd (hd0)
map --hook
 

Something *like*
map --mem /boot.vhd (hd0)
map --hook
right?

The original hd0 is overwritten, dosn't exist at BIOS level anymore:
bootmgr can't load winload.exe.

A good solution supports:
-bootmgr read \boot\bcd
-bootmgr read winload.exe
-the running windows can read and write to \boot\bcd. This resolves shutdown, reboot and sleep

The rule seems to be:
Bootmgr reads \boot\bcd from MBR disk using BIOS routines.
And bootmgr reads winload.exe from MBR or GPT disk using BIOS routines.
Both disks (the image file one and the real one) has to be available at BIOS routines.
And automatic load \boot\bcd: bcd has to be loaded from BIOS 0x80 disk. The disk id at running windows is not importand.

 
 

Maybe setting hard disk num at 1?
Or passing an edx= parameter

How to load \boot\bcd and winload.exe?
And the running windows should find boot\bcd.

Default boot, reference

map (hd0) (hd1)
map --mem (,2)/windows/boot.vhd (hd0)
map --hook
root (hd0,2)
chainloader /bootmgr
Will boot NTLDR from drive=0x80, partition=0x2(hidden sectors=0x1080)
boot

Windows doses boot. bcdedit does not list boot options.
"SystemBootDevice"="multi(0)disk(0)rdisk(0)partition(3)"
"FirmwareBootDevice"="multi(0)disk(0)rdisk(1)partition(3)"
Run mount_vhd.cmd and bcdedit list boot options: \boot\bcd is loaded automatically by unknown rules.

With a file %SystemDrive%\boot\bcd

map --mem (,2)/windows/boot.vhd (hd1)
map --hook
chainloader --edx=0x0281 (hd1,2)/bootmgr
Will boot NTLDR from drive=0x81, partition=0x2(hidden sectors=0x1080)
boot

Windows doses boot. bcdedit does not list boot options.
Run mount_vhd.cmd. bcdedit does not list boot options: \boot\bcd is not found.
Equal experience without a file %SystemDrive%\boot\bcd

With a file %SystemDrive%\boot\bcd

map --mem (,2)/windows/boot.vhd (hd1)
map --hook
root (hd0,2)
chainloader /bootmgr
Will boot NTLDR from drive=0x81, partition=0x2(hidden sectors=0x1080)
boot

Windows doses boot. bcdedit does not list boot options.
Run mount_vhd.cmd. bcdedit does not list boot options: \boot\bcd is not found.
Equal experience without a file %SystemDrive%\boot\bcd

Idea: Does bootmgr read \boot\bcd from GPT?
With a file %SystemDrive%\boot\bcd at (hd0,2), that's the GPT partition.

chainloader --edx=0x0280 (hd0,2)/bootmgr
Will boot NTLDR from drive=0x80, partition=0x2(hidden sectors=0x33000)
boot

\Boot\BCD not found.
Bootmgr searches \boot\bcd at BIOS device 0x80 and MBR partiton 0x2
 

map --in-situ (hd0,2)+1 (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr

\Boot\BCD is found, winload.exe is missing.


A tag file \windows\marker.7 added. And locate adjusted to (os)device in boot\bcd
http://reboot.pro/to...e-3#entry192417

map --in-situ (hd0,2)+1 (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr

\Boot\BCD is found, winload.exe is found. Drivers are loaded from the virtual MBR disk.
Next BSOD 0x7b Missing boot device: the switch to the GPT partition failed.

Idea: adjust MBR checksum after map in-situ
How to write to a MBR after map --in-situ; --hook?
This failed

map --in-situ (hd0,2)+1 (hd0)
map --hook
write --ofset=0x1A0 (hd0)+1 01A0
cat --hex (hd0)+1
dd if=()/mbr_patch of=(hd0)+1
cat --hex (hd0)+1

Is it possible to write to a in-situ MBR?

[Wonko the Sane]

At this point I guess that we need help from the good grub4dos Authors.

 

Maybe it is possible to modify the map --in-situ to allow "granular" mapping or directly edit it in memory.

I mean, AFAICU/CR the map --in-situ creates a temporary MBR (with a partition table containing a single partition entry corresponding to the partition supplied in its command line).

It should be possible (with some clever modification to the code) to have *something like*:

map --in-situ (hd0,1)+1 (hd0)

map --in-situ (hd0,2)+1 (hd0)

map --hook

OR something *like*

map --in-situ (hd0,1)+1 (hd0,1)

etc.

as you hinted earlier.

 

Very likely however - the "in situ" MBR is written *somewhere* in memory and could be hex-edited directly there (if we know the location).

In the case that what is created "in situ" is not a "whole MBR" but just a partition table (provided that it is not a single partition table entry ).

If it is a "whole partition table" (with 4 entries), but not a "whole" MBR sector, it should still be possible to insert a checksum correction, by (mis-) using the CHS values or the non used partition entries.

 

Wonko

[steve6375]

The --in-situ parameter is one I have not used (it is not mentioned in 'help map').

 

However, it seems to copy the existing partition table entry from the source device into memory and add a new partition table entry to the new partition table.

 

e.g.

 

hd0

30GB NTFS

Small type 21h hidden

 

hd1

Large NTFS ptn

map --in-situ (hd1,0)+1 (hd0)
map --hook

Now I get (cat --hex (hd0)+1)

 

hd0

Large NTFS ptn  << new entry

Large NTFS ptn

 

hd1

Large NTFS ptn

 

 

Presumably the new MBR can be accessed simply by using (hd0)0+1  ??

 

The diddy description/ ReadMe file says

It only virtualize the partition table and the number of hidden sectors in the BPB of the DOS Boot Record.

 

 

So I am guessing that any access to (hd0)0+1 and (hd0,1)+1  (the new partition) will access a copy of the MBR or PBR held in memory?  Any fiddling with the MBR and PBR after the map --hook will disappear as soon as an OS loads it's own drivers.

 

P.S. hd1 seems to be mapped to hd0 now. Any access to hd0 returns hd1's sectors (except for MBR and PBR).

P.P.S. If adding a partition image or existing partition from another hd, it gets added to the first partition table slot and the other partitions get shifted to the 2nd and 3rd slots. Grub4dos guesses at a suitable partition type number for the partition table entry if it does not recognise it (e.g. a type 21h partition is given a type 83h type number in the new partition table).

Edited by steve6375, 05 February 2016 - 09:52 AM.

[Wonko the Sane]

@Steve

Yes , this is the "normal" and "intended" use/operation of the --in-situ.

Can you find where in memory the "temporary" data is stored?

Can you verify whether it is possible to add more than one partitions to the "temporary" MBR/partition table?

 

cdob's idea is to edit *somehow* the temporary MBR to try and correct it's checksum, i.e. "loosely" porting the "XP Kansas City Shuffle" to this 7/8/10 .vhd booting, and see if this allows to have a "correct" ArcPath in FirmwareBootDevice (which should lead to a "mounted" \boot\BCD hive and in bcdedit finding it).

 

Wonko

[steve6375]

why do you need the memory address? You can use cat --locate --replace or dd with (hd0)0+1  to patch bytes.

 

assuming we have done --in-situ and map --hook, then...

echo -e -n \x33\xf0\x32 > (md)0x300+1
set START=0x1B0
dd if=(md)0x300+1 of=(hd0)0+1 bs=1 seek=%START% count=3

Edited by steve6375, 05 February 2016 - 11:16 AM.

[Wonko the Sane]

 

why do you need the memory address? You can use cat --locate --replace or dd with (hd0)0+1  to patch bytes.

 

Because seemingly that approach does not work (or I mis-read cdob's last post ), also maybe that will actually write to the "real" device (i.e. become something like "partnew"), I would like to understand the mechanism behind it, anyway.

 

If I got the last experiments reports correctly, what is missing is a "on-the-fly" creation of (at least two) partitions in a MBR partition table (on a GPT disk, i.e. exchanging the FAT32 "booting for EFI" real partition with the .vhd "booting for BIOS" image).

This works for one (through the mapping --in-situ) but it doesn't (or it doesn't properly) for two of them, and then there is the added (educated) guess about the need to change a few bytes to correct the checksum.

It would be good to know if (and how many) bytes are "virtualized" through the map --in-situ command (a whole sector, a whole partition table and its four slots only, one partition table slot only, etc.). 

 

 

 

Wonko

[steve6375]

yes, you are right, sorry!   Writes don't work to an in-situ disk if the sector is LBA0 or the PBR - dd or write do not report any error but the sector is not changed (not even the real sector). Writes do work on other sectors though (and permanently change the real disk/image file).

 

The bytes from 1b0 to 1bf are not changed by the map --in-situ command ,but map --in-situ will not work on disk in memory (only accepts a real disk), so the real MBR would need to be changed before doing the map --in-situ, but then it would be permanently changed!

[Wonko the Sane]

yes, you are right, sorry!   Writes don't work to an in-situ disk if the sector is LBA0 or the PBR - dd or write do not report any error but the sector is not changed (not even the real sector). Writes do work on other sectors though (and permanently change the real disk/image file).

 

The bytes from 1b0 to 1bf are not changed by the map --in-situ command ,but map --in-situ will not work on disk in memory (only accepts a real disk), so the real MBR would need to be changed before doing the map --in-situ, but then it would be permanently changed!

Yep.

What I am guessing is that *somewhere*  a "temporary" *something* is written and then "merged" on-the-fly when commands (like geometry or root, etc.) are issued.

I am just imaging that the *something* must reside *somewhere* in memory and can be modified by addressing it "directly in memory".

But I seem to find it not.

Another thing (but I made a few tests with a grub4dos floppy image I had handy, using a very old grub4dos, so this may not apply to later releases) I noticed that if you have a "normal" MBR disk with two partitions, let's say (hd0), if you map --in-situ (hd0,0) (hd2) (and then map --hook) the partition are shifted and "inverted".

I will try again with a specially crafted image and with a recent grub4dos, maybe it is just the one I have now in the floppy image that is "queer".

 

Wonko

 

P.S.: Just to keep everything as together as possible, some related discussion in the past:

http://reboot.pro/to...sb-stick-fails/

 

 

[cdob]

by (mis-) using the CHS values or the non used partition entries.

Searching grub4dos source code reveals:
in-situ supports partition numbers: --in-situ=N

map --in-situ=1 (hd0,2)+1 (hd0)
writes one partition table entry, and zero the other three entries.

given a hard disk image GPT.vhd:
0x1BE 00 00 01 00 EE FE FF FF 01 00 00 00 FF FF FF 01
0x1CE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

map --in-situ=1 (hd0,2)+1 (hd0)
writes partition table entry, and zero the other entries.
0x1BE B4 0E CD 10 AC 3C 00 75 F4 C3 41 42 43 44 00 00
0x1CE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The MBR saved as file mbr_in-situ.

Adjust checksum:
copysgcs.exe mbr_in-situ GPT.vhd 0x1D4

Adjusted hard disk image GPT.vhd:
0x1BE 00 00 01 00 EE FE FF FF 01 00 00 00 FF FF FF 01
0x1CE 00 00 00 00 00 00 33 0D 99 F7 00 00 00 00 00 00
(A running Window does mount this disk as GPT still.)
Boot this hard disk and apply: map --in-situ=1 (hd0,2)+1 (hd0)
There is the same checksum at real hard disk and mapped hard disk.

map --in-situ=1 (hd0,2)+1 (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr
boot

Reult to BSOD 0x7b

[tinybit]

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.

[Wonko the Sane]

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.

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 

[tinybit]

what does "map --in-situ" do?

it virtualize the partition table and BPB "hidden sectors" field.

when a real-mode software calls int13 to read the mbr sector to a buffer,
the int13 handler of grub4dos will take 2 steps:

(1). call ROM int13 to read data onto the buffer. note that for each call
to int13 to read data, you must specify a buffer to transfer data, or else
you could not call int13.

(2). modify the buffer data corresponding to the partition table.

similarly the int13 handler will correct the BPB hidden sectors field after it calls ROM BIOS.

the handler won't change any other area of the sector. it will not change the boot record code,
and it will not change the disk signature at offset 0x1B8 of the mbr sector.

if you want to change the disk signature(I mean, to virtualize it), you have to modify the handler,
and add a new option to the map command.

[serpens]

I stumbled across this https://technet.micr...s/dn858566.aspx which talks about installing Windows into a VHD, formatted using MBR, but stored on a GPT partition. I'm guessing that this gives the installed Windows system an MBR environment that it is happy with.