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

#176 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 12 June 2015 - 11:52 AM

Yeah I would have tried your technique myself except that my MBR-fiddling skills are a bit rusty, so its easier to screw up.

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? :unsure:

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).


:duff:
Wonko



#177 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 12 June 2015 - 07:08 PM

As I see it the "target" should be:

  • First partition (aka GPT (hd0,0))
  • 100 mb in size (or whatever is the default size for GPT install of the given Windows OS, I believe it is 300 Mb now for 8/8.1, but  I can most probably get it "on-the-fly" - as long as it is first partition - from the actual GPT partition table or from the FAT32 BPB, since it's position is "fixed" on LBA 2048)
  • FAT32 formatted as in the UEFI requirements EFIsys or "EF00" or "C12A7328-F81F-11D2-BA4B-00A0C93EC93B" or "ESP"
Yes, the batch #172 mkgrldrGPT_01.zip works. It's a good idea fake PartitionEntry 414. Generic approach not fixed to LBA 2048.
Spoiler

]I edited PBR bootmgr to grldr too.


In other words, let's take for the moment a "normal" install of Windows 8/8.1 on a GPT disk with UEFI.

My fault, a "normal" install of Windows 8/8.1 on a GPT disk with UEFI creates a 300 mb recovery partition and a 100 mb EFI partition.


Another idea:
conditions:
-XP supports a floppy like 3 TB USB HDD (no MBR, PBR only)
-some BIOS boot from a floppy like HDD (no MBR, PBR only)
-MBR code is 440 bytes https://en.wikipedia...ter_boot_record
-FAT32 and NTFS main code is less 440 bytes http://thestarman.pc...dex.html#ntfsbr

dd 440 bytes from FAT or NTFS PBR to MBR.

Given a GPT disk with a NTFS bootmgr partition C:
grldr and menu.lst copied to C:
dd first 440 bytes from the PBR C: to the MBR.
C: Bootstrap Code 'bootmgr' changed to 'buutmgr' http://thestarman.pc...m/mbr/NTLDR.htm
c:\grldr copied to c:\buutmgr

Windows 8.1 does boot from a BIOT GPT disk.

#178 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 13 June 2015 - 10:13 AM

Yes, the batch #172 mkgrldrGPT_01.zip works. It's a good idea fake PartitionEntry 414. Generic approach not fixed to LBA 2048.

Good. :)

I edited PBR bootmgr to grldr too.

Good, but all in all if you provide a different PBR "template" the batch will copy *any* PBR code.
 

My fault, a "normal" install of Windows 8/8.1 on a GPT disk with UEFI creates a 300 mb recovery partition and a 100 mb EFI partition.

But the EFIsys is still first partition in the GPT partition table?
If not, can you post first three sectors of such a disk (LBA 0,1,2)?
I don't think it would be difficult to parse the first 4 partition entries in the GPT partition table instead of just the first one.
 

Another idea:


But isn't this (more or less) what the original makebootfat attempts to do? :unsure:
I guess we can continue to predate from that project.

You cannot really-really just dd first 440 bytes from PBR to MBR (you will have to correct "Sectors Before" and "Reserved sectors" just like the batch currently does).

Maybe this new approach could be a "last option", limited to the (I believe few) people that for any reason have a BIOS that at the same time won't like the added partition table entry setup AND which BIOS support the (huge) superfloppy, casually Milindsmart could be a good tester (if he wishes to test such an approach).

I am not convinced (but will have to test) that this approach can work with MS FAT32 PBR code (and making the "additional" non-standard small NTFS partition is IMHO a bit like cheating, of course OK, but ...) because of the code on sector 13 of the volume, but surely we can find (or hack together) some booting code for FAT32 that can fit in that space.

Wouldn't a "normal" EFI accept besides FAT32 also FAT16 for EFIsys? :dubbio:

:duff:
Wonko

#179 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 13 June 2015 - 12:04 PM

The attached may do. :unsure:

I prefer mkgrldrGPT:

Following this MBR approach, given a second partition:
Partition Type: 07 NTFS
Start LBA: 0x00032800 206848
Num LBA: 0x0EE49800 249862144

MBR:
mbrfatmod32.mbr, 3-89 not changed, zeros still
414-429: 80 00 00 00 07 00 00 00 00 28 03 00 00 98 E4 0E

bootsect.exe /nt60 c:

LBA 206849: change BOOTMGR to GRLDR:
BOOTMGR: 07 00 42 00 4F 00 4F 00 54 00 4D 00 47 00 52 00
GRLDR: 05 00 47 00 52 00 4C 00 44 00 52 00 00 00 00 00

The machine does boot
mbr loads grldr
grldr maps (hd0,1) to (fd0) and chainloads (fd0)/bootmgr
windows 8.1 does boot

The big question now:
How to hack bootmgr to read MBR 414-429 partition entry?
bootmgr may read \boot\bcd that way. grub4dos may get obsolete.

#180 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 13 June 2015 - 02:04 PM

I am lost.
The referenced attached is "mkgrldrGPT" ? :unsure:
The MBR boot code simply chainloads the PBR of the partition in 414-429.
As seen in the batch copying the BPB to the MBR is optional and only useful to be able to map the thingy as (hd0) in grub4dos.
I wonder if there can be some trick (manipulating some piece of booting code) to trick BOOTMGR into believing that the disk is a superfloppy.

I don't think that hacking BOOTMGR is a good idea, and the additional (NTFS) partition is IMHO an unneeded complication, we are back to the previous attempt (apart the offset of the "custom" partition table entry) the difference is only with the size and filesystem of the added partition.

If there are no issue in using the EFIsys partition doubling it as BIOS boot partition hosting BOOTMGR and \boot\BCD why creating another partition? (if not for tests) :dubbio:

As a side-side note, there is another way to modify the NTFS bootsector to load NTLDR (instead of BOOTMGR) and then changing the NTLDR string to GRLDR needs not the "length correction", I once had a look at it but for all I can do I cannot find the notes I took at the time, I'll try again or re-check, just to add this - if needed - to the "bag o' tricks".

:duff:
Wonko



#181 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 13 June 2015 - 03:09 PM

The referenced attached is "mkgrldrGPT" ? :unsure:

Yes, your version from post #172.
 

The MBR boot code simply chainloads the PBR of the partition in 414-429.
As seen in the batch copying the BPB to the MBR is optional and only useful to be able to map the thingy as (hd0) in grub4dos.
I wonder if there can be some trick (manipulating some piece of booting code) to trick BOOTMGR into believing that the disk is a superfloppy.

Thanks for clarification.
No, I don't know a trick bootmgr to detect a superfloppy.
Bootmgr dosn't find \boot\bcd at (hd0) protective MBR so far.
No idea, how bootmgr works internally. Can anybody expain this?
 

I don't think that hacking BOOTMGR is a good idea

I'm thinking about "SystemBootDevice" and "FirmwareBootDevice" are correct after boot. No fix required at running windows.
http://reboot.pro/to...e-7#entry192902
A final solution should load \boot\bcd to registry by default boot too.
A hacked bootmgr may help to solve this.
 

the additional (NTFS) partition is IMHO an unneeded complication

This example refers to one windows partition only. All windows data are stored at this partition.
Some user may like this approach.
 

If there are no issue in using the EFIsys partition doubling it as BIOS boot partition hosting BOOTMGR and \boot\BCD

I go one step back and asks myself now:
is it appropiate to expect a EFIsys partition at a BIOS GPT disk?
Yes, we can use a EFIsys partition, if there is one. But do we have to force one? Should the user have a choice?

#182 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 13 June 2015 - 03:19 PM

is it appropiate to expect a EFIsys partition at a BIOS GPT disk?
Yes, we can use a EFIsys partition, if there is one. But do we have to force one? Should the user have a choice?

Now I see what you mean. :)

But I was still in my (self imposed) limitation of making a disk that could boot indifferently (i.e. physically moved) without modification from one BIOS system to an EFI system or boot on the same system as either CSM or "pure" EFI.

Or, to take a "normal" GPT disk from a EFI and have it additionally boot as BIOS.

 

 

On a BIOS GPT disk (used only on the same BIOS machine) the Syslinux approach should work fine (or doesn't it?):

http://reboot.pro/to...pt/#entry181908

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

 

:duff:

Wonko



#183 nightrain

nightrain
  • Members
  • 4 posts
  •  
    China

Posted 14 June 2015 - 07:06 AM

Here is my idea.

I tried to use firadisk+grub4dos to set up Windows 7 and above in legacy BIOS + GPT disk system correctly.

I use firadisk to load a vhd image read+write,which contains a MBR disk with a active partition.

Then I use Syslinux's gptmbr.bin MBR,GRUB4DOS's PBR,and gpt flag "Legacy BIOS Bootable" to make system boot into grub4dos.

 

Here's my menu.lst:
default 0
timeout 0

title Find /bootmgr.vhd and load directly [FIRADISK MODE]
find --set-root /bootmgr.vhd
map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)
map /bootmgr.vhd (hd0)
map (hd0) (hd1)
map --hook
write (99) [FiraDisk]\nStartOptions=disk,vmem=find:/bootmgr.vhd;\n\0
root (hd0,0)
chainloader /bootmgr

Then I modify windows's system hive \windows\system32\config\system:setup\cmdline to make cmd boot first in windows deploy.

I boot windows in disable driver signature enforcement mode to make firadisk driver installed correctly.(In windows 7 I use F8,but in windows 8 i use bootice to add a BCD OS load parameter:AdvancedOptionsOneTime=True to make F8 menu available the next boot)

In the CMD menu I use bcdedit to make TestSigning on.

 

When the firadisk virtual disk recognized correctly I run %windir%\system32\oobe\windeploy.exe to start the windows deploy process(Windows 8),or use shutdown -r -t 0 to restart PC to recognize VHD correectly(Windows 7).

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

 

BUT MY SOLUTION IS VERY INCONVENIENT!!

I hope someone can do this:

1st way:Hack bootmgr entirely to make bootmgr load BCD in GPT disk.

2nd way:Make a windows driver to modfy FirmwareBootDevice and load BCD hive during boot time.(Because load BCD hive during boot time is necessary to windows 8's metro OS selection screen and windows update)

But windows driver signing enforcement is very !@#$%^%$#@ and I don't know how to write a driver......



#184 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 June 2015 - 08:06 AM

Here is my idea.

 

Nice, but seemingly overcomplicated, why don't  you try any of the proposed solutions, now that cdob has confirmed that the mkgrldrGPT.cmd works fine:

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

you can try it, read starting from here:

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

 

 the result, in the worse case would be that nothing has changed, but if your BIOS needs not any bootable partition in the real disk MBR you will land to grub4dos with the "real" GPT partitions accessible maped as MBR ones.

 

:duff:

Wonko 



#185 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 15 June 2015 - 10:15 PM

I tried to use firadisk+grub4dos to set up Windows 7 and above in legacy BIOS + GPT disk system correctly.

This combination has been suggested, not reported so far. Thanks for sharing exprience.
 

Then I use Syslinux's gptmbr.bin MBR,GRUB4DOS's PBR,and gpt flag "Legacy BIOS Bootable" to make system boot into grub4dos.

MBR to grb4dos is possible, no need for syslinux and a special gpt patiton "Legacy BIOS Bootable".
 

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

Congratulations. I understand: a booted windows loads bcd to registry: bcdedit.exe list settings.
 

BUT MY SOLUTION IS VERY INCONVENIENT!!

Yes, Windows 8 causes inconvients using a unsigned driver.
Windows 7/8 boots from a VHD file. VHD drivers are integrated by default.
Do you have any idea/solution to use native VHD drivers instead of firadisk?

#186 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 24 June 2015 - 09:34 PM

Another observation at Windows 7 or Windows 8:
regedit.exe: unload HKLM\BCD00000000
bcdedit.exe lists a output.
There is HKLM\BCD00000000 at registry. 

Conclusion:
Windows remembers \boot\bcd device. And reloads the file automatically!

Windows store boot disk configuration somehow.
I suspect MBR signature and checksum still http://www.911cd.net...showtopic=21242

Theory: As for BIOS GPT boot from boot.vhd:
it's not time critical to mount boot.vhd early
boot.vhd can be mounted late
windows native drivers (obviously properly signed drivers) are sufficient:
create a start up script to mount boot.vhd


Given a 24 mb \Windows\Boot.vhd, one activce partiton, filled with bcdboot.exe
menu.lst


title /Windows/Boot.vhd
map () (hd1)
cat --length=0 /Windows/Boot.vhd || find --set-root /Windows/Boot.vhd
map /Windows/Boot.vhd (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr
.
Assign Computer Startup Scripts https://technet.micr...y/cc770556.aspx
Windows 8.1 Logon Script Delay Group Policy Setting http://blogs.technet...cy-setting.aspx


powershell.exe Mount-DiskImage -ImagePath c:\windows\boot.vhd -NoDriveLetter
.
Windows does boot.
bcdedit.exe, msconfig, power saving and windows update works.

#187 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 29 June 2015 - 07:50 PM

Windows 8.1 at GPT BIOS disk
Approach: boot Boot.vhd and mount boot.vhd at running windows using native drivers.
Benefit: bcdedit, msconfig, sleep and recocery boot works.

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

Boot a Win 8.1 PE
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
.

Grldr can be at windows partition or at another (fake) partition.
If grldr is located at c: then adjust c: boot code : change bootmgr to grldr
BOOTMGR: 07 00 42 00 4F 00 4F 00 54 00 4D 00 47 00 52 00
GRLDR: 05 00 47 00 52 00 4C 00 44 00 52 00 00 00 00 00
copy grldr c:\
copy menu.lst c:\

Boot helper USB stick twice.
Boot from internal hard disk next.

Mount boot.vhd at running windows:
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\boot.vhd -NoDriveLetter
.

Recovery Environment:

ReAgentc.exe /setreimage /enable /path C:\Recovery\WindowsRE
adjust winload.efi - winload.exe
bcdedit.exe /enum all
bcdedit.exe /set {guid} path \windows\system32\winload.exe
.

create_vhd.txt
create vdisk file=c:\Windows\Boot.vhd maximum=24
attach vdisk
create par prim
format fs=FAT quick
active
assign letter=V
.

menu.lst
title /Windows/Boot.vhd (hd)
cat --length=0 /Windows/Boot.vhd || find --set-root /Windows/Boot.vhd
#map append hard disk number
map /Windows/Boot.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr
.

Boot variations should work too:
GPT with grub2: chainload grub.exe or memdisk raw boot.vhd
GPT with syslinux: memdisk raw boot.vhd


I'm using GPT disk now
#96 http://reboot.pro/to...e-4#entry186656
And a embedded menu.lst
default 0
timeout 1

title /Windows/Boot.vhd (hd)
	errorcheck off
	find --set-root /Windows/Boot.vhd
	#map append hard disk number
	map /Windows/Boot.vhd (hd)
	map --hook
	root (hd-1,0)
	chainloader /bootmgr	
	boot
	errorcheck on
	commandline

title commandline
	commandline

title reboot
	reboot

title halt
	halt


#188 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 30 June 2015 - 10:48 AM

Good. :thumbsup:

 

I guess I can remove the "highly experimental" tag from the mkgrldrGPT batch on post http://reboot.pro/to...e-7#entry192974and call it "final"? :unsure:

 

Does it make sense to re-check the early attempts listed in 

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

and make a single package turned into something more "user friendly"?

 

:duff:

Wonko



#189 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 30 June 2015 - 03:32 PM

I guess I can remove the "highly experimental" tag from the mkgrldrGPT batch on post http://reboot.pro/to...e-7#entry192974and call it "final"? :unsure:

Yes, the fake partition entry works. This includes other offsets.
I haven't tested the batch thoroughly, mostly hexediting the MBR itself.
 

Does it make sense to re-check the early attempts listed in 
http://reboot.pro/to...e-4#entry186656
and make a single package turned into something more "user friendly"?

Yes, it's a good idea to make this more user friendly.
And it would be nice to adjust GPT_GRLDR.ima as a end user: another grldr, menu.lst. Even add a another floppy image. I think a end user accepts imdisk for this task.

Overall both approaches works, have benefit and drawbacks.
The end user has to decide which one he likes.

#190 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 30 June 2015 - 05:22 PM

Yes, the fake partition entry works. This includes other offsets.
I haven't tested the batch thoroughly, mostly hexediting the MBR itself.


Well, the MBR code is of course OK, 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.
Also, the check for having the EFYsys partition starting on LBA 2048 can be removed from the batch, I added it only as a primitive form of "safety" in case of a mis-selection of the physicaldrive.
 
 
 

Yes, it's a good idea to make this more user friendly.
And it would be nice to adjust GPT_GRLDR.ima as a end user: another grldr, menu.lst. Even add a another floppy image. I think a end user accepts imdisk for this task.

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"?
The GPT_GRLDR.ima needs to be that particular size to fit in the 63-2047 LBA area, 1016320 bytes in size or 1985 sectors, and has - besides the GRLDR loading bootsector code - some few tweaks/edits in the BPB mainly in order to maximize the available area for files, I could easily provide an empty (but still with the bootsector code loading GRLDR) is this what you mean?
Here also we could use extract.exe instead of IMDISK, in order to automate the populating of the image "offline", I don't think there is any need for folders, GRLDR and a menu.lst and *whatever* else, let's say a few grub4dos batches since there is not that much space remaining in 1985 sectors....

Overall both approaches works, have benefit and drawbacks.
The end user has to decide which one he likes.

Yep. :)

:duff:
Wonko

#191 gyurman

gyurman
  • Members
  • 9 posts
  •  
    Hungary

Posted 01 July 2015 - 08:17 PM

Hello Wonko the Sane and cdob

I read the solutions to start from GPT. I appreciate that your much of work is paid for it.

I really like the cdob solution. Where can I found Win 8.1 PE? How can I do without helper usb?

I do not understand another also, how and what it does bother me assembly code.

I have to would like, which can be detailed as Arch Linux Wiki and used Linux or Windows commands. I prefer syslinux, and vhd. Can you do? Unfortunately, have not much time to deal with this, but I will try at least under VirtualBox.

 

Thanks

 

#192 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 735 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 02 July 2015 - 05:35 AM

It looks like unforeseen circumstances may (or may not, I'm not sure yet) force me to make a foray into the very area which I initially found appealing, but later wanted to avoid. But above all else system stability is key for me, abd I'll go along with whatever method (native UEFI, DUET, BIOS/MBR, or BIOS/GPT) is most stable long-term.

 

I think I've discovered an issue with my system, which is that the 7 boot logo hangs randomly when booting in native UEFI, but never in BIOS/MBR. This never happens with 8/8.1, so it's an issue specific to 7 so far as I can tell.

 

Getting along with it, I'll run my BIOS/GPT tests in a VM for awhile. Are there any downsides to using the approaches in this thread?

 

Ine of my conditions is that Windows must always be aware of where its' boot files live, and I wont go along with anything that violates this principle. Said approach must also not make use of an unsigned driver, which would require Test Signing mode to be turned on.

 

There is too much info in this thread to digest, so I'm not even sure where to start. I'm mainly interested in GPT because of MBR's strict limit on primary partitions, none of my boot OS didks are big eniugh to need GPT.


Edited by AnonVendetta, 02 July 2015 - 06:08 AM.


#193 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 02 July 2015 - 08:55 AM

Are there any downsides to using the approaches in this thread?

Yes, unfortunately there a few (unconfirmed) reports about laptops catching fire. :(
The reports seem to imply that only some specific DELL and Alienware laptops are affected :whistling:.
 

Ine of my conditions is that Windows must always be aware of where its' boot files live, and I wont go along with anything that violates this principle. Said approach must also not make use of an unsigned driver, which would require Test Signing mode to be turned on.

Well, you cannot really dictate your conditions, you see what is available, you try it and if it doesn't suit you you simply don't use it.
 

There is too much info in this thread to digest, so I'm not even sure where to start.

Usually the beginning is a good start place. :unsure:
 

I'm mainly interested in GPT because of MBR's strict limit on primary partitions, none of my boot OS didks are big eniugh to need GPT.

Well, then you are going into this for futile motives :w00t:, which are fine :thumbup: as long as you know they are futile.
Just for the record the use of logical volumes inside extended partition is something that has worked (and worked reliably) in the last 25 years or more.

:duff:
Wonko



#194 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 735 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 02 July 2015 - 09:43 AM

Several of my apps require Test Signing Mode to be off. I'm not so much against unsigned drivers, but Microshaft has more and more increased the restrictions and security on every new version of Windows. No longer is an admin truly an admin, way back when admins could do alot more within the powers of their user accounts. It's their ballgame for the most part so the best we can do is work within the restrictions or find ways to circumvent them. Anyway, I just believe Windows needs to know where its' boit files live. For such a critical part of the system to seemingly disappear up in smoke just isnt kosher with me. Surely their must be a way other than Firadisk and WinVBlock. Ideas?

 

I've never really cared for logical volumes. Totally illogical to me. But they still serve their intended purpose of circumventing MBR's primary partitions limit. To me all partitions should just be primary, which is something GPT does right. Along with hash checks of data for redundancy and as a general safeguard against corruption. And with UEFI, no longer can one bootloader dominate the MBR. Instead all loaders get installed to the EFI partition, where no one loader dominates, and the only limitation is available space. The EFI also serves to keep critical boot files out of the OS partitions. But the one thing that *can* be controlled here is the fallback bootx64.efi loader.

 

@ Wonko: Futile motives? Why does everything have to be futile to you if it doesnt involve a logical reason for doing so? That's the way it seems to me. Consider instead that I'm considering this partly out of personal interest, partly necessity (maybe), and finally (and most important to me, I dont give a damn what you think about my reasons) simply because I can. Oh, and for a learning experience, perhaps. I find those to be perfectly valid reasons, and perfectly logical. I could swear I made comments along these lines earlier un the thread. Take this as a personal attack, take it as criticism, I dont care.I refuse to discuss/argue my motives with you further. Not that any of them were really your business to begin with.


Edited by AnonVendetta, 02 July 2015 - 09:58 AM.


#195 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 02 July 2015 - 10:30 AM

I refuse to discuss/argue my motives with you further. Not that any of them were really your business to begin with.


Sure :), they are your own business.

But since they are your own business, you don't really need to come here whining about being forced into something you wanted to avoid:

It looks like unforeseen circumstances may (or may not, I'm not sure yet) force me to make a foray into the very area which I initially found appealing, but later wanted to avoid.

noone is pointing a gun at you, forcing you to use any of the methods discussed here, they are publicly available, you can play freely with them (or decide to not play with them at all).

And then you cannot feel offended or surprised because after you stated:

But above all else system stability is key for me, abd I'll go along with whatever method (native UEFI, DUET, BIOS/MBR, or BIOS/GPT) is most stable long-term.

someone tells you how the most stable long-term method is to not use experimental/unsupported setups but rather use the supported and tested BIOS/MBR (since you don't have bigger than 2 Tb hard disks only with the very minor nuisance of needing to use logical volumes inside extended and that only if you really *need* more than 4 partitions).

The generic idea about these experiments is to have fun in developing and testing them, if you feel forced to use them and require stability long-term (besides imposing any condition), very likely these tests are not (hopefully not yet) suited for you.

:duff:
Wonko



#196 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 735 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 02 July 2015 - 10:53 AM

I just didnt like your "futile" wording, it just doesnt jive with me when someone claims my efforts are futile. You look it as futile, I see it as an opportunity to learn. Whining? That's just your interpretation. I simply dropped into the thread to note my situation and get a little advice on where to begin. As for being forced, that would be by my circumstances. Certainly BIOS/MBR is the most established. But it's old. I see UEFI as being established enough to be usuable. But I also dont mind experimental methods if they turn out to be stable. The only way to know is to test. The methods discussed are nontraditional and not established, regardless whether they work or not. I'm in no way surprised or offended by your implied advice to just use BIOS/MBR, I already suspected that would be your position. Life requires a certain amount of risk, just be crossing the street you could be hit by a car, but you probably do it everyday. Merely existing is a risk in itself. I'm willing to take a certain amount of risk while trying to maintain/establish stability.



#197 vi-2010

vi-2010
  • Members
  • 3 posts
  •  
    Belarus

Posted 04 July 2015 - 04:28 PM

I managed to install the UEFI DUET emulator to a GPT disk and then boot from this disk via BIOS. I used the UEFI DUET GPT boot sector from here: https://github.com/t...tSector/Gpt.asmand UEFI DUET precompiled binaries which I downloaded somewhere. The procedure is the following:

1. Copy gpt.com (compile gpt.asm using MASM 6.15) to the MBR of the GPT disk. Do not overwrite the partition table - overwrite just the executable code of the MBR. It can be done using BootIce (or something else). I actually fixed a bug in gpt.asm which prevented it from loading partitions other than the partition number 0 and disabled the check for the UEFI system partition GUID. But that's probably unnecessary.

You will probably have to set the number of your physical drive in gpt.asm. It's hardcoded to 80h which is wrong because BIOS sends the drive number in the DL register.

You will probably have to set the number of your GPT partition in gpt.asm. It's hardcoded to 0 as GptPartitionIndicator.

2. Copy bd32hd.bin from the DUET binaries to the first sector of the UEFI system partition. Overwrite just the executable code - do not overwrite everything else. The executable code goes from the offset 5Ah till the end of the first sector. The partition must be FAT32 and inside the first 1024 cylinders of the disk (it is probably 8.5 Gbytes).

3. Assign a letter to the UEFI system partition using MiniTool Partition Wizard (or something else).

4. Copy UEFI DUET files to the UEFI system partition from your UEFI DUET flash drive using a file manager.

Now you should be able to boot from your GPT hard drive via BIOS.



#198 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 735 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 05 July 2015 - 03:50 AM

@ vi-2010: Your approach to installing DUET seems like way too much hassle. I'd recommend just using Rod Smith's instructions @ http://www.rodsbooks.com/bios2uefi/. The DUET package wasn't available for download anymore, but I have cached copies in my Dropbox which I posted earlier in the thread. Syslinux is also needed, it's linked in my other post too. You'll also need a Linux distro live CD, I'd recommend Parted Magic. Theoretically the DUET install script should run and install correctly from any Linux, but failed for me when using Linux Mint. I suppose your approach would work if you want to install DUET from Windows, but I didn't try it. It took me less than 10 mins to create my partitions, install DUET, and boot into a Windows install CD, when using Mr. Smith's instructions. DUET has proven to be the only approach I've tried which has been 100% stable for me, it has never failed to boot (itself) or boot Windows or any other UEFI OS, not even once. I hear it doesn't work so well with some AMD chipsets, you'll have better luck with Intel.

Edited by AnonVendetta, 05 July 2015 - 03:54 AM.


#199 vi-2010

vi-2010
  • Members
  • 3 posts
  •  
    Belarus

Posted 05 July 2015 - 07:54 AM

I installed DUET to a GPT partition which already has Windows 7 64 bit installed on it. I did it without touching the Windows instance. I used to load Windows 7 by starting DUET from a USB flash, then DUET loaded Windows from the GPT disk. But then it occurred to me that it's inconvenient and unreliable to keep a USB stick always plugged in, so I devised a method to boot Windows 7 from the GPT disk itself.



#200 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 735 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 05 July 2015 - 08:21 AM

I installed DUET directly into the EFI partition, no USB required.







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

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users