374 replies to this topic

[Wonko the Sane]

I would imagine that when using DUET (which is a form of UEFI loadable from BIOS) what you are actually doing is EFI booting (and not BIOS booting, which is the topic of this thread).

 

Which boot files are actually  used with DUET?

1. \BOOTMGR + \boot\BCD
2. \bootmgr.efi, \EFI\microsoft\boot\BCD, \EFI\boot\bootx64.efi or \EFI\boot\bootx32.efi and/or \EFI\Microsoft\Boot\Bootmgfw.efi

As said earlier, nowadays Clover:

http://reboot.pro/to...e-6#entry192048

http://reboot.pro/to...r1/#entry191282

represents an updated version/fork of the Tianocore (please read as DUET) which is maintained.

 

Wonko

[vi-2010]

I would imagine that when using DUET (which is a form of UEFI loadable from BIOS) what you are actually doing is EFI booting (and not BIOS booting, which is the topic of this thread).

 

Which boot files are actually  used with DUET?

1. \BOOTMGR + \boot\BCD
2. \bootmgr.efi, \EFI\microsoft\boot\BCD, \EFI\boot\bootx64.efi or \EFI\boot\bootx32.efi and/or \EFI\Microsoft\Boot\Bootmgfw.efi

BIOS loads DUET executable code from the MBR (first) sector of a disk (which can be GPT- or MBR-based). Then the DUET MBR code loads the first sector of a FAT32 partition which contains DUET PBR. Then DUET PBR loads the Efildr20 file which is a part of DUET. Then Efildr20 loads <EFI system partition>:\EFI\Boot\bootx64.efi . Here a detailed description: https://github.com/migle/BootDuet .

[Wonko the Sane]

@AnonVendetta

Well, that is an easy test to do.
When someone has a DUET (or any other UEFI emulator) booting setup, files \BOOTMGR and \boot\BCD (if any) can be deleted and the system will continue booting as before since the UEFI emulation will use the UEFI bootfiles.
 
This thread is (or should have been) about "BIOS booting on GPT disks", and not about "UEFI booting through emulation on GPT disks" (which is a possible alternative but is IMNSHO a completely different topic).
 
As already said earlier, more than once, there is nothing inherently "Mac specific" in Clover, it is one of it's features, and I already gave a link: http://reboot.pro/to...r1/#entry191282
to Steve6375's nice tutorial:
http://www.rmprepusb.com/tutorials/122
http://rmprepusb.blo...os-to-uefi.html
where no MAC is used/involved/talked about.
 
If the original DUET works for you, then good , Clover is (or should be) more up to date and have solved a number of issues that DUET has been reported to have on this or that hardware.

 

@vi-2010

I know.

I was trying in an as kind as possible way to make you (and AnonVendetta) aware of the hijacking nature of the posts related to UEFI emulation.

 

Wonko

[Wonko the Sane]

Noone was trying to hijack the thread, we just got off into a DUET discussion. Perhaps interested individuals should move this line of conversation to the thread I started.
<insert here several lines detailing personal experience with DUET and other UEFI emulation, notwithstanding the declared intention to not wanting to hijack the thread>

Sure , let's call the end result (the effective hijacking of the thread) an unintentional  "side effect" or "collateral damage".
 
In a perfect world a Mod or Admin would split the off-topic posts to a separate thread, but heck, democracy has its costs.
 

Wonko

[cdob]

I was more dubious about the batch, particularly running it on a system with UAC etc, if there is any need to elevate or to lock the disk, etc.

Sorry, haven't tried this yet.
 

What do you think that is needed (besides adding a "more current" grldr (which one?) and a basic menu.lst)?
What do you mean with "add another floppy image"?

Idea was to add a 360kb floppy image, bootmgr and \boot\bcd. No, I don't know a practical reason so far, may be this can be nice in future.


A basic sectors 63-2047 example

Spoiler

http://reboot.pro/to...e-4#entry186656
Boot a Windows 8.1 DVD, press shift F10

DISKPART:
sel disk 0
clean
convert gpt
create par prim
format fs ntfs quick label=Win8
assign letter=C
exit

DISM.exe /Apply-Image /ImageFile:e:\sources\install.wim /Index:1 /ApplyDir:C:\

rem create boot VHD image
diskpart.exe < create_vhd.txt
bcdboot.exe C:\windows /s V: /f BIOS

fill a helper USB stick
bcdboot.exe C:\windows /s U: /f BIOS
boot from USB stick

Running at Windows 8.1 with elevated permissions:

SET tdisk=0

ECHO Copying LBA0 to LBA0Disk%tdisk%.ori ...
dsfo \\.\Physicaldrive%tdisk% 0 512 LBA0Disk%tdisk%.ori

::and apply the 63-2048 code
copy /b LBA0Disk%tdisk%.ori LBA0Disk%tdisk%.mod
dsfi LBA0Disk%tdisk%.mod 0 432 MkbootFatMOD2.mbr

ECHO Writing new MBR ...
dsfi \\.\PhysicalDrive%tdisk% 0 512 LBA0Disk%tdisk%.mod

::adjust embedded menu.lst inside <GPT_GRLDR.ima>\grldr
copy /b GPT_GRLDR.ima GPT_GRLDR.mod
dsfi GPT_GRLDR.mod 277596 315 embedd.lst

ECHO Writing new PBR ...
dsfi \\.\PhysicalDrive%tdisk% 32256 1016320 GPT_GRLDR.mod

No need to configure UAC or lock a partition.

Continue installation http://reboot.pro/to...e-8#entry193407, jump to "Mount boot.vhd at running windows:". That's the importand part.

Suggestion for a basic config:
offer a customer to include a own grub4do menu file to sectors 63-2047.
One example: the embedd.lst is integrated to grldr inside sectors 63-2047.


A more sophisticated approach, let's call a premium config: mount the fake partition.
At Win 8 default security settings rejects imdisk request. I've no simple solution from running Win 8

Spoiler

offset 63*512 = 32256
size 63 to 2048 > 1985*512 = F8200 1016320

read only works:
imdisk -a -f \\?\physicaldrive0 -b 32256 -s 1016320 -o ro -m Z:
Creating device...

nircmd.exe elevatecmd runassystem imdisk -a -f \\?\physicaldrive0 -b 32256 -s 1016320 -o ro -m Z:
Creating device...


writing fails:
nircmd.exe elevatecmd runassystem cmd.exe /k imdisk -a -f \\?\physicaldrive0 -b 32256 -s 1016320 -m Z:
Creating device...
Error creating virtual disk:
The process cannot access the file because it is being used by another process.


rem run as TrustedInstaller
rem joakim http://reboot.pro/fi...d-runfromtoken/
net.exe start trustedinstaller
bin\runassystem64.exe "bin\runfromtoken64.exe trustedinstaller.exe 1 cmd.exe"
C:\windows>imdisk -a -f \\?\physicaldrive0 -b 32256 -s 1016320 -m Z:
Creating device...
Error creating virtual disk:
The process cannot access the file because it is being used by another process.


Contrary from running Win 8 PE
x:\windows\system32>imdisk -a -f \\?\physicaldrive0 -b 32256 -s 1016320 -o rw -m Z:
Creating device...
Created device 0: Z: -> \\?\physicaldrive0
Notifying applications...
Done.

Possible work arround with gdisk

Spoiler

gdisk /dev/sda
Command (? for help): n
Partition number (4-128, default 4):
First sector (34-31457246, default = 31455232) or {+-}size{KMGTP}: 63
Last sector (63-2047, default = 2047) or {+-}size{KMGTP}:
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 2700
Changed type of partition to 'Windows RE'
Command (? for help): w

Diskpart lists a small partition, a letter can be assigned. Another grldr and menu.lst can be copied. Booting Win8 is possible still.

It would be nice if your batch supports the custom menu request
No need to support mounting sectors 63-2047 currently. A sophisticated end user can do this manually.

[cdob]

I did BCD  for VHD file. Put this file to the grub. and I can boot it well with

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

Not going to sleep the windows 8.1?

The running windows 8.1 misses the file \boot\bcd.
Solution: mount the vhd file at running winows 8.1. Windows will remember the boot hard disk automatically and finds \boot\bcd.

Which partitions do you use?
Does /boot/bootmgr.vhd exist at a ext, FAT or NTFS partiton?
Add a ext driver. Orr move bootmgr.vhd to a FAT or NTFS partiton: e.g. c:\windows\bootmgr.vhd

At runing windows 8.1 create a task:
Computer Management / Task Sheduler http://www.eightforu...indows-8-a.html
create a new task at System account with 'highest privileges' checked and 'run it on computer startup'.
Action: PowerShell.exe Mount-DiskImage -ImagePath c:\windows\bootmgr.vhd -NoDriveLetter

grub.cfg

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

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

Adjust (hd0,gpt3) to local partitons.

[Wonko the Sane]

OK, the attached mkhidGPT001.zip may work.

Needed files:
dsfi.exe and dsfo.exe from the DSFOK toolkit: http://members.ozema...eezip/freeware/
mformat.exe, mmd.exe,mdir.exe, mcopy.exe from the Mtools (for Windows): http://reboot.pro/fi...ile/267-mtools/


The idea is that you have a directory (no spaces or weird characters in the path, please), where you have files:
mkhidGPT.cmd
FAT12grldr.bss
HidGPT63.mbr
dsfi.exe
dsfo.exe
mformat.exe
mmd.exe
mdir.exe
mcopy.exe
and a sub-directory "\root"

The batch will (should):
1. create a FAT 12 formatted image
2. replicate the contents of the \root sub-directory inside the image
3. deploy (optionally) the image to a GPT disk in the (unused) area from LBA 63 to LBA 2047
4. write to the MBR some special code, capable of booting to the deployed image AND a correspondent BPB to have it mapped as super-floppy.


The image in itself uses a PBR code loading grub4dos' grldr, which is the minimum content of the \root sub-dir when creating the image, i.e.:

\root-
      |- grldr

The typical contents of \root would however be:

\root-
      |- grldr
      |- menu.lst
      |- BOOTMGR
      |- boot-
              |- BCD

Once booted to grub4dos the root will be established to (hd0), i.e. to the super-floppy, all the pre-existing GPT partitions should be listed by simply running the geometry command.
It is entirely the responsibility of the user to provide an adequate menu.lst (a good idea would be to map (hd0) to (fd0), hook the mapping and chainload the BOOTMGR on (fd0)) and \boot\BCD.

There are some options (by changing some values in the batch) to change the volume label and serial in the PBR of the image, while first part of HidGPT63.mbr (the BPB) is at the moment "fixed", an almost unneeded complication of reflecting the values produced by the batch may be added later.

There has been only VERY MINIMAL testing, so be careful, and ONLY attempt using the batch on devices for which you have a SURELY working backup of first 2048 sectors.
 
@cdob
All in all, instead of providing a pre-made image and adding files to it (through mounting with IMDISK or with other tools) dynamically creating one with Mtools seems to me preferrable, and - notwithstanding the somehow complex syntax of the mformat and mcopy tools - with some practice it may become a good replacement for bfi (than can create only some given fixed formats) and for extract (that does not deal with directories/subdirectories). 
 

Wonko

Attached Files

•  mkhidGPT001.zip   3.84KB   1266 downloads

[cdob]

OK, the attached mkhidGPT001.zip may work.

It does works well, good work.

Running at Windows 8.1 with elevated permissions at a one disk machine (and SET MinDisk=0):

mkhidGPT.cmd myimage.img 0

A proper MBR and sectors 63-2047 are written.
Windows booting from BIOS at GPT disk does work.
 

\root-
|- grldr

Yes, grub4dos-0.4.5c-2015-05-18 finds menu.lst at c:\windows (hd0,0)
 

\root-
|- grldr
|- menu.lst

Yes, MBR super-floppy does works too. Thanks for explaining this approach.grub4dos-0.4.5c-2015-05-18 finds menu.lst at (hd0).
We can test a c:\menu.lst: edit this file at windows.
Keep c:\menu.lst, hide the file.Or to move menu.lst at sectors 63-2047
We are free to choose a option.

I'm loading c:\windows\boot.vhd at menu.lst currently. http://reboot.pro/to...e-8#entry193407
That way windows has access to \boot\bcd.

The map (hd0) to (fd0) seems to be nicer, including bootmgr and \boot\bcd
Contrary windows can't write to \boot\bcd so far.
Testing:

map (hd0) (fd0)
map --hook
root (fd0)
chainloader /bootmgr
boot

bootmgr dosn't find \boot\bcd
Neither a "map (hd0)63+1985 (fd2)", \boot\bcd is missing.
Did I messed up boot\bcd ? Dosn't bootmgr likes this floppy?


All binaries are 32 bit and won't work at a default x64 DVD. That's fine, educate the end user.
Run this at a proper environment, a full installed windows. Or a x64 PE with wowsys64.
Or boot a x86 DVD, press shift F10, apply a x64 install.wim and run mkhidGPT.cmd.

[comcc]

I'm sorry to say that I haven't read all of this thread, but it might be worth mentioning that YEARS ago (2009), I was playing around with OS X 10.5, 10.6 and Windows 7 RC1 (beta) at around the same time. On an ASUS P5Q Deluxe WITHOUT the UEFI beta (I seem to recall it was a v2201? BIOS that had been modified with HPET fixes for OS X) I used OS X to create a GPT disk, and then installed Win7 RC1 X64 to a GPT partitioned drive without any issues.

 

Some points to note: Windows recognized and installed to the EXISTING partition on the hard drive, and booted fine, but was not able to modify partitions on the drive until it was cleaned using diskpart. It also refused to try to use the drive if I only used diskpart to create and partition a GPT disk, so something about the way OS X wrote the MBR wrapper on the GPT disk worked with Win7 RC1, and was different from what diskpart does.

 

I had cleaned the drive by the time Win7 RTM came along, and never tried to repeat that result, but it's always been in the back of my mind to go back and see if I can determine just how that happened.

 

Maybe I'll fire up a VM, and see if I can get that to work again...

[Wonko the Sane]

 

The map (hd0) to (fd0) seems to be nicer, including bootmgr and \boot\bcd
Contrary windows can't write to \boot\bcd so far.
Testing:

map (hd0) (fd0)
map --hook
root (fd0)
chainloader /bootmgr
boot

bootmgr dosn't find \boot\bcd
Neither a "map (hd0)63+1985 (fd2)", \boot\bcd is missing.
Did I messed up boot\bcd ? Dosn't bootmgr likes this floppy?

 

Queer

It did work (when mapped to (fd0) only, not (fd1) or (fd2):

http://reboot.pro/to...e-4#entry186656

http://reboot.pro/to...e-4#entry186471

 

Please try again with 

map (hd0)63+1985 (fd0)

 

Remember this:

http://reboot.pro/to...9mgr-wim/page-2

http://reboot.pro/to...r-wim/?p=186266

 

Maybe it's time we have found an actual use for the OFS? 

Making inside the 1985 sectors a floppy image containing the BOOTMGR and the \boot\BCD while keeping it accessible from the "outer filesystem"?

 

Wonko

[cdob]

I used OS X to create a GPT disk, and then installed Win7 RC1 X64 to a GPT partitioned drive without any issues. 
...
so something about the way OS X wrote the MBR wrapper on the GPT disk worked with Win7 RC1, and was different from what diskpart does.
...
Maybe I'll fire up a VM, and see if I can get that to work again...

Thanks for the information, that's awesome. Do you rememver more details? Did you used one hard disk or two hard disks?
Win 7 x64 SP1 gui setup refuses a GPT disk here (GPT layout created with diskpart).
 
 

Queer
It did work (when mapped to (fd0) only, not (fd1) or (fd2):

Please try again with
map (hd0)63+1985 (fd0)

I'm ashamed, yes it works with "map (hd0)63+1985 (fd0)".
Too much testing, dedicated testing hardware (X200s with MVA LED pannel http://forum.thinkpa...c.php?t=92693).without backups.
Bootmgr finds (fd0)\boot\bcd.

 

Maybe it's time we have found an actual use for the OFS? 
Making inside the 1985 sectors a floppy image containing the BOOTMGR and the \boot\BCD while keeping it accessible from the "outer filesystem"?

Well, I'm getting greedy: what about a hard disk image?
One step back: a booted windows should use a writeable \boot\bcd. To configure next boot.
How to accomplish that given the 1985 sectors image?

[Wonko the Sane]

Well, I'm getting greedy: what about a hard disk image?

I wonder if possible in the sense that booting from it may be a challenge.

 

One step back: a booted windows should use a writeable \boot\bcd. To configure next boot.
How to accomplish that given the 1985 sectors image?

No ideas, short of loading a driver (let's say Firadisk or Winvblock) but then there will be issues with signed drivers, etc.

Maybe a .vhd?
I'll think a bit about it.

I don't think there will be issues in using the available 1985 sectors as two parts:
first part a superfloppy or an underfloppy (or whatever) containing just the needed grub4dos and the rest for a .vhd mapped by it, provided that the native .vhd mechanism may be able to "hook it".
One could even do a further step back and go for the 63 or 128 sectors WEE, and have the grldr together with the BOOTMGR and \boot\BCD in the second (vhd) chunk.

I'll think a bit about it and do a couple experiment (up to the point the grldr can map anything).

Another idea (maybe) could be to *somehow* create a modified grldr.mbr with the "hole" increased from 1 to 62 sectors. but cannot say if possible. (and this would only simplify the loading of grldr removing the need for the bootsector in the FAT12 volume, please read as "allowing to use a hard disk image directly).


Wonko

[Wonko the Sane]

@cdob

I did some experiments with a OFS setup, but I am having an issue related to the use of subdirectories.

 

Right now the mkhidGPT.cmd is made so that (in theory) you can add more subdirectories to "root" and sub-subdirectories, this makes complex to put together an OFS.

 

Would it be acceptable to have this "fixed" structure with only one "boot" subdir?

\root-
      |- grldr
      |- menu.lst
      |- BOOTMGR
      |- boot-
              |- BCD

It will be possible to add files to "root" and to the "root\boot" subdir, but not having another subdir under "root" nor any subdir under "root\boot".

 

I don't see (given the limited scope of this particular 1985 sectors extent) any particular problem with this, but maybe *something* is needed that I am missing.

 

Wonko

[cdob]

Would it be acceptable to have this "fixed" structure with only one "boot" subdir?

Yes, only one "boot" subdir is a good limitation. I don't expect another one.

Clarify previous experience:
Windos 8 remembers grub4dos boot.vhd using native drivers. The vhd mounted late at boot using PowerShell.
http://reboot.pro/to...e-8#entry193407

Windos 7 dosn't remembers the grub4dos boot.vhd.
A manually reg.exe load boot\bcd does work. bcdedit works next.
http://reboot.pro/to...e-7#entry192902

I expect different Windows behaviour at a OFS setup solution too.
May be different Windows 7 and up solutions are appropiate.

[Wonko the Sane]

Yes, only one "boot" subdir is a good limitation. I don't expect another one.

Good though after having reviewed the procedure, it is not "impossible" to have a "free style" set of dirs/subdirs, there is only some complications (that I would gladly avoid) a "penalty" of one added used sector for each (which becomes unavailable as disk space).
 
Now, we must get to more details.
Right now in the OFS the contents of the inner .img (temporarily called _fake.vhd) are made accessible from the outer image, as an example here is the output of the outer .img:
 
 

L:\>dir /s
Il volume nell'unità L è G4D_BIOSGPT
Numero di serie del volume: 6653-7457

Directory di L:\

24/07/2015 20.07 <DIR> boot
24/07/2015 20.07 977.408 _fake.vhd
24/07/2015 20.07 398.356 bootmgr
24/07/2015 20.07 274.191 grldr
24/07/2015 20.07 4.474 menu.lst
4 File 1.654.429 byte

Directory di L:\boot

24/07/2015 20.07 <DIR> .
24/07/2015 20.07 <DIR> ..
24/07/2015 20.07 262.144 bcd
1 File 262.144 byte

Totale file elencati:
5 File 1.916.573 byte
3 Directory 34.304 byte disponibili

And these are the actual contents of the inner .img (_fake.vhd):
 
 

M:\>dir /s
Il volume nell'unità M è GPTINNER
Numero di serie del volume: 6653-7457

Directory di M:\

24/07/2015 20.06 <DIR> boot
24/07/2015 20.06 398.356 bootmgr
24/07/2015 20.06 274.191 grldr
24/07/2015 20.06 4.474 menu.lst
3 File 677.021 byte

Directory di M:\boot

24/07/2015 20.06 <DIR> .
24/07/2015 20.06 <DIR> ..
24/07/2015 20.06 262.144 bcd
1 File 262.144 byte

Totale file elencati:
4 File 939.165 byte
3 Directory 0 byte disponibili

Now, since the actual same extents are mapped, the contents of each file are the same, which implies that - say - the menu.lst inside the inner .img cannot be different from the menu.lst accessible from the outer .img (which may be not a real problem, as the menu.lst may well contain a "default" entry automatically loading (say) a mynu.lst, only if some conditions are met (let's say the UUID of the volume) or this switch coupld be implemented in the embedded menu.lst of grldr, but it creates an issue with the \boot\BCD.
 
Since space is tight, there is no doubt that grldr and BOOTMGR need to be OFSed, (which allows to save roughly 398356+274191-36864 bytes in the example, actually 779+536-72=1243 sectors) but the space used by the inner image remains the same no matter if the files in it are re-indexed in the outer image or not, so there is not enough space for a different \boot\BCD in the outer .img, unless the sizes of these \boot\BCD's are dramatically reduced, if I recall correctly by compacting the hive/recreating it with BCDEDIT form scratch or using a third party tool, much smaller \boot\BCD's can be created, which might allow us enough space for this.
We can further save some sectors by:

• "anticipating" the fake partition to sector 34 instead of sector 63
• using a non-standard (1) sector before instead of 63 in the .vhd
• reducing FAT table sizes (both in the inner and outrer images) increasing the cluster size (which now is at 512 bytes, but due to the non-even size of most files possibly this won't be an advantage)

Anyway, try the attached, it still needs a lot of refining and reordering (please read as "currently it is a mess and leaves behind any number of temporary files"), but seemingly it is working.
As a bonus a couple half-@§§ed batches to calculate the checksum of a VHD footer and to actually create the footer are included.
And this opens another question :
Will the .vhd mounting mechanism accept a .vhd with a geometry of 0/255/63 i.e. smaller than 8.225.280 bytes? (or will another CHS geometry be needed, let's say a 16/63 one? )
 
@All, please if you are NOT cdob DO NOT attempt using the attached batch, it still lacks a number of checks/safety measures.


Wonko

Attached Files

•  OFSGPT001.zip   7.08KB   742 downloads

[comcc]

Thanks for the information, that's awesome. Do you rememver more details? Did you used one hard disk or two hard disks?
Win 7 x64 SP1 gui setup refuses a GPT disk here (GPT layout created with diskpart).
 

I spent some time this weekend with Virtualbox, and was not able to duplicate the behavior I was describing. I will need to try it with actual hardware, but it is possible that what I experienced was due to the particular hardware / BIOS setup I was using at the time.

 

I had used partimage (Linux) to restore mbr Windows partitions to what was technically a GPT configured hard drive. It ended up something of a hybrid from my trying to build a dual-boot Hackintosh / Windows machine.

 

If I have any luck, I'll let you know what happens.

[milindsmart]

Well, you will never know if something works until you try it.

Isn't it funny that I have been accused of attempting to prevent you from discovering new ways?

The issue Sha0 was referring to was about the possibility that due to a non-standard BIOS a perfectly compliant GPT disk may not boot on a given machine and that if made bootable on that particular BIOS (with some hybridizing or other trick) that same disk unmodified might not boot on another given machine with a particularly "strict" (or "wrong") EFI implementation.

But this is not your case, you only have to make a "good enough" GPT disk for Windows that is also "good enough" for the stupid BIOS you have, there is no real need that the disk is integrally compliant with *any* EFI firmware.

So you can well use a hybridized MBR and each and every trick (+ 1) fair and unfair as long as you obtain the expected result.

Which checks does the BIOS make?
Like:

1. that at least one entry in partition table starts with 0x80
2. that the partition table entry that starts with 0x80 has a "known" partition ID
3. that the partition table entry has valid CHS addresses
4. that the partition table entry has valid LBA data
5. that there are no overlaps in the 4 partition entries
6. etc.

What checks does the Windows loader make?
Like:

1. that only one 0xEE partition exists
2. that that partition entry does not have the 0x80 flag
3. that no partition entries have the 0x80 flag
4. that no other partition with "known" partition ID exist
5. that no other partition with a "known" partition ID has the 0x80 active flag
6. etc.

Once you will have (through experimenting) a more clear idea of the behaviour of both the BIOS and of the Windows loader, then likely one or more valid solutions to your specific issue can be found (and VERY likely they will be a hack of some kind).



Wonko

 

So I'm back, with pretty good news.

 

Wonko, you are right that for this one system, the issue of a "friendly BIOS" does not arise, since I just have to fiddle and make it work here, spec be damned. The important thing to note here is that bootmgr imposes yet another constraint (of 0xEE not being marked active), which in my case seemed impossible to solve at first glance.

 

To recap, with the 0xEE marked active, grub and linux run, but bootmgr refused. I actually started today with the intention of following the above advice, and got around to installing grub4dos in preparation. But then I realized that this HDD had data, and I had no free HDDs to play with as of now. And even shrinking the protective partition is a major, potentially manually executed task, because of the need for GPT-unaware tools. So anyway, I developed cold feet, and started to investigate how to solve the problem head on.

 

The solution as I saw it, was to mark the partition active to start with, and use grub4dos to mark it inactive before passing on control to bootmgr. Which means that each time windows is started up (or shutdown), the 0xEE has to be marked active. If power went off abruptly, then preparing this at shutdown leaves the system vulnerable to non-bootability. And windows might not even accept a GPT disk with an 0xEE marked active (as anything, data or boot disk). Any info on this?

 

Anyway, so the solution that I wanted was to spoof the MBR with just one change - the 0xEE marked inactive - before passing on control to bootmgr. I searched and searched, but I still don't know how to do it in Grub4Dos.

 

What did happen, was that I searched online with the right keywords, having seen a UEFI option in the BIOS. Lo and behold, I found :

 

(together, they give detailed info on UEFI support on 2008-era motherboards. I'm surprised)

http://techreport.co...hp?f=36&t=64546

http://arstechnica.c...hp?f=8&t=100695

http://arstechnica.c...558110#p3558110

 

Basically, by giving up AHCI (being so late, the latest BIOS released in or after 2010 had fixed Native IDE, rather than confine UEFI to Legacy), and with the knowledge that there was, in fact, a one-time boot menu by pressing F10, I started up the board on UEFI for the first time, 7 years after it was bought.

 

Long story short, with the exception of some startup animation bug, Windows 7 boots in UEFI on GPT. Next step is to get Fedora also to use UEFI.

 

I still will get around to exploring the limitations of bootmgr w.r.t the 0xEE partition, but this was a nice touch

[Wonko the Sane]

The solution as I saw it, was to mark the partition active to start with, and use grub4dos to mark it inactive before passing on control to bootmgr. Which means that each time windows is started up (or shutdown), the 0xEE has to be marked active. If power went off abruptly, then preparing this at shutdown leaves the system vulnerable to non-bootability. And windows might not even accept a GPT disk with an 0xEE marked active (as anything, data or boot disk). Any info on this?

 

Well, you can mark it inactive in grub4dos pre-BOOTMGR and make it active again as "first thing" when the Windows boots (this way you greatly limit the "power shortage" issue as you limit to the bare minimum the time when it would make damages), coincidentally a loosely similarly scoped approach was just discussed:

http://reboot.pro/to...g-boot-loaders/

 

Still it is far from being "elegant" and there is no real reason to use this workaround when much better solutions exist.

At least I find the solutions provided in this thread by cdob and myself to be highly preferable, though most probably we will never know if any of them work on your machine.

 

If I get it right you are using a SATA/AHCI disk in "IDE compatible mode", now on early disks/devices (and SATA implementations) this made in practice no difference, but if your motherboard and disks support NCQ (Native Command Queuing) it more or less equates to preparing for racing on foot by securing to your ankles some legcuffs:

https://en.wikipedia.org/wiki/Legcuffs

 

Wonko

[serpens]

This thread has been very useful to help me configure my dualboot box to support Win10. As thanks, here's a record of what I discovered along the way.
 
For now my systems still use legacy BIOS since it allows me to boot old (ancient) configurations, but I use GPT because of the additional flexibility and support for large disks. Previously I had Linux and WinXP installed using a hybrid MBR that allowed WinXP to see an MBR partitioned disk, and Linux to see the actual GPT partitioned disk.
 
As I upgraded to Win10, I realised I was going to have a problem and was glad to discover this thread, in particular Sascha Weaver's post in this thread, and also in the superuser.com forum. Some of the following will be old news to those already familiar with this forum, but I note these things here for completeness.
 
Installation

• When booted from legacy BIOS, Win10 installation will only create and target MBR partitions.
• Once installed, Win10 will treat hybrid MBRs as MBR partitioned disks and not GPT.
• 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".
• I was only successful installing Win10 by installing it on an MBR partition.
• I chose to copy Win10 from the installation partition to a GPT partition, but converting MBR to GPT would also work.

Cloning
 
Because I had an existing multiboot GPT configuration, I came across some interesting issues when cloning my installed Win10 MBR partition.

• NTFS file systems have a serial number which does not seem to have any bearing on the way partitions are known to Win10. Grub uses the NTFS serial number to find file systems and I find it useful to make sure that each file system has a different serial number. I use ntfslabel --new-half-serial to ensure that cloned partitions have unique serial numbers.
• Win10 records mounted drives and their letter assignments in the registry. I spent quite a few hours with a very confused Win10 system which thought C: drive was the WinXP partition. The symptom here was a very busy disk drive and a completely black screen with a working mouse cursor! The key lesson here: erase HKLM/System/MountedDevices on the target after cloning.
• I didn't get to the bottom of BCD Mechanics, and in the end resorted to deleting /Boot, and issuing bcdboot c:\Windows /s c: as a simple means to get a clean BCD.

Booting

• I had the most consistent and easy to reproduce results with Sascha Weaver's bootmgr.vhd technique. It's possible to use this with GRUB and SYSLINUX memdisk.
• I had to use the most recent version of GRUB to have it interwork correctly with wimboot after having no luck earlier versions.
• The compressed Win10 bootmgr has a slightly different layout and wimboot is unable to extract the uncompressed bootmgr.exe from it.
• I made some changes to bmzip to use it from Linux, and you can find those changes on github. Using this it is possible to extract bootmgr.exe and feed it directly to wimboot, although it would be great to get the right changes into wimboot have it understand the Win10 bootmgr layout.
• With these changes, I also did have success having GRUB use wimboot to start Win10.

[Wonko the Sane]

Good.

 

Just for the record/JFYI, some of what you describe is the same since at least NT 4.0 (and most probably going back all the way up to NT 3.1) (i.e. nothing particularly new in Windows 10 about these)

 

A NTFS volume (as well as a FAT volume, actually any file system with some exceptions) does have a "serial number" field, see:

http://reboot.pro/to...ed-drive-image/

(only seemingly unrelated)

The GRUB/grub4dos way to identify partitions or volumes is the UUID command.

 

Letter assignment in Windows NT is given initially along a set of "priority" or "order" rules and recorded in a set of registry keys under HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices\ , the data used to identify a partition/volume is the disk signature and the offset at which the partition/volume starts, see:

http://www.911cd.net...showtopic=19663

(the volume serial has nothing to do with this, if you think about it a drive letter is assigned the moment you create a partition or volume in diskpart or disk manager, before actually formatting it with a filesystem, whilst the volume serial is a field created by the format command and belonging to the filesystem)

In older NT systems (if I recall correctly up to 2K) deleting the HKLM/System/MountedDevices made the system unbootable while starting from XP (I believe) if the key is missing it is recreated with the same rules:

http://www.msfn.org/...-drive-letters/

 

Wonko

[cdob]

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"

I wonder: did you tried booting a helper USB stick too?
Yes, Windows 7, 8 and 10 shows different results.
 

I had to use the most recent version of GRUB to have it interwork correctly with wimboot after having no luck earlier versions.
...
With these changes, I also did have success having GRUB use wimboot to start Win10.

That's good news. Can you post the grub.cfg entry?

[serpens]

I wonder: did you tried booting a helper USB stick too?
 
That's good news. Can you post the grub.cfg entry?

 
No, I didn't boot a helper USB stick.
 
I recompiled wimboot and made some modifications to allow it to find bootmgr.exe in the compressed win10 bootmgr image.
 
With that the GRUB configuration can be set up very nicely:
 

menuentry "Windows 10" {
  linux16 ${prefix}/wimboot
  search --no-floppy --fs-uuid --set=root 6b6c8c965277f54f
  initrd16 \
    newc:bootmgr:(${root})/bootmgr \
    newc:bcd:(${root})/Boot/BCD
}

I leave wimboot installed alongside grub.cfg, and have GRUB search for the Win10 partition.

[thomnet]

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

 

I have been trying to figure this out for several days now, but after much reading here and over at sevenforums the exact process eludes me. What you wrote above makes total sense to me, 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, and perhaps my failure is due to a wrong version of one of the required elements.

 

I bow down to your extreme wisdom sir and respectfully ask for your guidance to accomplish my goal for a mixed OS BIOS multiboot system using only GPT drives and no USB boot required (virtual MBR is ok, and as I understand it an absolute necessity for BIOS booting)

 

Serpens also seems to have accomplished this but his most recent post is a bit short on the details, at least for me. I'm an old school guy who can't live in the abbreviated twitter world; I need to have things spelled out.

 

Relevant posts I've made:

 

System components (never mind the rest of my trials and tribulations; Seagate and Vertex drive failures)

 

General background and latest attempt with memdisk

 

Any further experiments and attempts to get the BIOS - GPT booting process working will be done on my MacBook Pro (quad core, 8GB RAM) in a Parallels VM environment, which will be much faster to iterate thru various scenarios. Once I get it perfected I'll migrate onto the target platform with a new SSD and 3 HDDs.

 

Thx in advance. I'll continue reading up here. BTW, I grabbed the memdisk binary from Steve's easy2boot files I installed in December on my 160GB USB drive. I used the grub2 from Linux Mint 17.2.