374 replies to this topic

[devdevadev]

I think screenshots are conveying lots of meanings of whole tutorial. You can test it in your GPT disk. May be it also work for you.........

I think following is the main point which is the soul/secret of whole tutorial..........



Is it not ?

BTW.... Is convention @milindsmart wrong ?

Regards....

Attached Thumbnails

• 

[milindsmart]

Yeah, the more closely I read it, I can say with 90% certainty he's doing the exact same thing as us : use another MBR disk to hold bootmgr + files.

[milindsmart]

In the meantime, I have one update : Vista x86 rtm does not boot on GPT. I'll double check... but putting together info from
 

The following Windows editions include support for UEFI:

• [...]
• Windows® 7, Windows Vista® with Service Pack 1 (SP1), Windows Server® 2008 R2 and Windows Server® 2008
  • Support UEFI 2.0 or later on 64-bit systems. They also support BIOS-based PCs, and UEFI-based PCs running in legacy BIOS-compatibility mode.
  • [...]

and

Can Windows 7, Windows Vista, and Windows Server 2008 read, write, and boot from GPT disks?
Yes, all versions can use GPT partitioned disks for data. Booting is only supported for 64-bit editions on UEFI-based systems.

This is exactly as officially supported, SP1 adds GPT booting support to Vista. However, Vista RTM does support GPT Data disks...
 
From this we can conclude that if
 
A = set of all OSes that support data GPT disks
B = set of all OSes that support boot GPT disks (with the above tweaks)
 
then A =/= B,  which is surprising to me originally because Windows 7 32-bit worked just fine.

[milindsmart]

Another success, using MBR disks in GPT partitions!

 

See original at http://reboot.pro/to...on/#entry187140 .

 

The arrangement : 
GPT disk 13000MB, Grub2 MBR

• gpt1 : NTFS partition holding bootmgr and BCD
• gpt2 : BIOS boot partition for Grub2
• gpt3 : FAT partition holding Grub2, Grub4dos files.... no bootsector
• gpt4 : embedded MBR disk
• gpt5 : NTFS Windows partition

MBR disk 80MB : standard MS MBR, 1 partition, holding bootmgr+BCD

 

At Grub4Dos prompt :

 

map (hd0) (hd1)

map --hook

map (hd1,3)+1 (hd0)

map --hook

root (hd0,0)

chainloader /bootmgr

boot

 

Windows boots. Somewhat funny and curious, it recognizes gpt1 (see above) as the system partition, even though it had no role in this process. Changing it's partition type to a linux one, results in the expected situation, with no system partition found in disk management.

 

Notes : 

Does not work if the MBR disk image is not mapped to (hd0)

Does work if "+1" is substituted for "/bootmgr"

[chenall]

Does this help for it?

http://bbs.wuyou.com...read&tid=337283

Boot windows in BIOS from gpt partition..

use grub4dos + ntboot with only one command line.
ntboot nt6=(hdx,y)

Edited by chenall, 07 September 2014 - 06:55 AM.

[milindsmart]

Nice  Can you describe in short how you're doing it? Are you using a memdisk-type approach?

 

How similar is it to what we're doing here?

Important posts in this thread :

• http://reboot.pro/to...pt/#entry181883
• http://reboot.pro/to...pt/#entry181941
• http://reboot.pro/to...pt/#entry181960
• http://reboot.pro/to...e-3#entry186306
• http://reboot.pro/to...e-3#entry186400
• http://reboot.pro/to...e-2#entry184489

Also, is this also similar to your method? : http://windowsforum....ent_srl=5956541

[Wonko the Sane]

@chenall

Nice , though at first sight the thingy is a nice batch to automate the booting once grub4dos is loaded.

 

I am not sure to understand (actually I am sure I do not understand ) how grub4dos is installed/loaded.

 

Till now the issue has been to actually load grub4dos on a GPT disks from BIOS with two restrictions:

1. not change the GPT partition table in the protective MBR <- i.e. have Windows recognize the disk as GPT
2. have the thingy "transparent" to EFI firmware

 

Till now there are two solutions provided in this thread:

1. a (hidden or visible) small fat partition in the area that is never used + a modified MBR code
2. use of grub2 as "main" bootmanager to chainload grub.exe

Once the grub4dos is loaded, everything is fine and there are a few techniques available, though of course your fully automated method (once someone will be able to test it and make some comments/instructions in English) is very useful .

 

Is this the reference, right?

http://chenall.net/post/ntboot/

http://c-dl.qiniudn.com/dl/NTBOOT.rar

 

Wonko

[Tripredacus]

In the meantime, I have one update : Vista x86 rtm does not boot on GPT. I'll double check... but putting together info from
 

and

This is exactly as officially supported, SP1 adds GPT booting support to Vista. However, Vista RTM does support GPT Data disks...
 
From this we can conclude that if
 
A = set of all OSes that support data GPT disks
B = set of all OSes that support boot GPT disks (with the above tweaks)
 
then A =/= B,  which is surprising to me originally because Windows 7 32-bit worked just fine.

 

Windows 7 "kinda" works just fine, sometimes. OK so as for the Vista issue, the UEFI spec (aka the evil plot to eliminate x86) was finalized prior to the release of Vista SP1. As such, Microsoft announced that only Vista SP1 x64 would support booting from a GPT disk. NOTE: I am not saying in UEFI mode because at that time, EFI was only available on server boards and *maybe* some (Intel) workstation boards... I hadn't dealt with Intel Workstation boards, but if one were to have the entry level server chipset (or has an EFI shell) then it likely could.

 

Now Windows 7 was not planned to support GPT boot disks either, but it is a little better. There are even problems of booting Windows 7 from an MBR disk on a board with UEFI 2.3.1 firmware even in Legacy mode, but ONLY if the deployment uses the System Reserved partition. If you deploy Windows 7 32bit as a single, disk-spanning, partition (or the OS is in part 1) then the OS will boot every time. Either way, 32bit Win7 is not supported on UEFI HARDWARE, legacy boot or not. This is why you saw all OEMs selling PCs with 64bit Win7. The HPs and Dells of the world.

 

If you remember, original reports from MS was that WIndows 8 would only be released in 64bit and 128bit which follows along the UEFI spec. It obviously did not happen and the evil UEFI founders were defeated... and thus Microsoft fixed Windows 8 32bit's bootloader to work properly on UEFI hardware and GPT disk. Windows 7 tho, seems it can take a hike.

[milindsmart]

Very interesting indeed.. I was under the impression that because GPT was(is) part of the EFI spec, Microsoft decided to only support 2 of the 4 (firmware + disk partitioning) schemes. You're saying that they were planning to support GPT on BIOS itself..?

And I did not know at all about the incompatibility of Windows on UEFI 2.3.1 hardware.. Any forum reports, threads, news articles, mailing lists discussing this?

Tripredacus, on 08 Sept 2014 - 11:51 PM, said:
If you remember, original reports from MS was that WIndows 8 would only be released in 64bit and 128bit which follows along the UEFI spec. It obviously did not happen and the evil UEFI founders were defeated... and thus Microsoft fixed Windows 8 32bit's bootloader to work properly on UEFI hardware and GPT disk. Windows 7 tho, seems it can take a hike.

128 bit was a huge joke. UEFI had no requirement of bitness for firmware. And yeah, Windows 8 UEFI compatibility was surprising.

BTW I thought you were joking around about UEFI being evil, but maybe not. Care to share why you dislike it so much?

[Tripredacus]

You can do GPT on BIOS already, but you just can't boot on it. You can make GPT volume on Windows 2000 if you want.

 

The problem of Windows 7 32bit not working properly on UEFI was not discovered (by me) from threads or pages on websites. I found out when the new boards made it into production and the OS wasn't booting. The problem is not 100%, sometimes it would boot sometimes it wouldn't. 64bit Win7 did not show this problem. I ended up creating a support case with Microsoft. It came down to that 32bit Win7 didn't support the UEFI 2.3.1 firmware even if you weren't trying to do anything fancy. I found through testing that it would boot 100% of the time if the OS was in the first partition, and then boot randomly if the first was something else like System Reserved. When I say "not boot" what happens is the BCD was read but it couldn't find winload.exe or other critical boot files. There are also cases where you can't manually install Win7 32bit from DVD on this hardware (you get an error).

 

On a (likely) related note, I also found when testing UEFI PXE boot on Server 2012, that you couldn't deploy an OS in multi-partition on MBR disk! Well technically it would all work, but sometimes it couldn't create boot files or the it would boot with BCD error as found before with other methods. See here:

http://www.msfn.org/...vers/?p=1013748

 

I was kinda joking about UEFI being evil. Its more related to the requirements Microsoft implemented with Windows 8 and Server 2012. For one, when the UEFI 2.3.1 boards came out, obviously 32bit Win7 didn't work properly and yet MS hadn't made any mention that the OS wasn't supported. Had to find out the hard way. And to make matters worse, there were drivers available for 32bit OS on those boards. So you'd have support for 32bit from, say, Intel or Asus, but not from Microsoft!

 

So that's why almost every OEM system sold in the past few years had 64bit Win7 or 8. It wasn't because 64bit Win7 pretty much fixed the horrible wow64 support that XP64 did, it was because of the hardware. The biggest problem is that it was a forced change by the hardware manufacturers, brought on by those companies that worked on the UEFI spec. The user-base was still not fully onboard with getting rid of 32bit due to either bad past experiences (XP64) or needing to run 16bit software.

 

Here's an example, take a look at this list:

http://www.intel.com...b/CS-033076.htm

Intel had added UEFI 2.3.1 to boards during their 3rd gen CPU refresh. Take this board: DZ68DB. Win7 32bit supported by MS on this board on the original release. But AA# AAG27985-105 and later it has UEFI and OS not supported. To make matters worse, think about this repair scenario. You buy a PC with the DZ68DB when it came out with Windows 7 Pro SP1 32bit. Then the board fails or whatever but it is under warranty. You send the PC into repair but the only replacement boards are rev 105 and higher. Guess what, your HDD might not even boot now. Go find an older board? Where to find them? No one sells boards and say they are "these" or "this" AA number. How do you tell the customer that their OS might not boot reliably on a replacement board? How do you tell them you can install 64bit for them instead? I'd be pissed and you'd be pissed.

 

I don't dislike UEFI, actually find it interesting. I was disappoint when 128-bit wasn't going to be made. I was looking forward to having 2 exabytes of RAM!  

[milindsmart]

A significant step forward in the modification of bootmgr!
 
There are 2 addresses from which all the disk ID information is taken, so the approach I took is to modify them in memory in Bochs, catching the write by the write watchpoint.
 
0x25554 -> this contains the MBR disk signature, change it to the GPT disk signature[1] 0x25550 -> has 0x01, got to change it to 0x00
this will be used to match 0x1014c0 later, which contains the GPT disk signature. Making them identical allows the boot process to proceed to the next stage

The signature is written by instructions at 0x21bc(3-6) by the 16-bit stub, BEFORE bootmgr.exe loads. This same content is copied elsewhere AFTER it has loaded, by means of real-mode callbacks. The 0x01 is written at some other time, but you can modify that too along with the disk sig.
Where this is writing from, I cannot tell because the values of segment offset registers make no sense to me, with my limited understanding. ds and ss are 0x60, and bx is ~0x1764, but I don't know how word ptr ss:[bx+4] becomes 0x25554... (in fact looking at it, the brackets and everything don't even make any sense.   )

 
0x25582 -> this contains something like the MBR partition disk signature (value is 0x0010, no idea really). This should be changed to the gpt disk signature. I don't know when this is written to.
this will be compared to 0x101aa0 later. Making them identical allows the boot to continue.....

The first thing you'll notice after this is that the BCD is fully loaded, so the higher resolution screen, prettier fonts, and the boot menu are finally available. Also, memory test option works, which is an absolute delight to see after fiddling hex values... the sweet fruits of labour

And you'll get the "Starting Windows" winload.exe screen!!! It takes a few seconds (on a full emulator like Bochs which has to be very slow) and then returns to tell :
 

File: \Windows\System32\config\system
 
Status : 0xc0000017
 
Info : Windows failed to load because the system registry file is missing or corrupt

I suppose some other place has the MBR info... If anyone has about an hour, a working Bochs copy, and a GPT disk with Windows 7 on it, and is willing to help out from this stage, please tell me : I'll write out detailed instructions.

Meanwhile, the F8 menu works, and when seeing safe mode, I notice that the registry is the first file that it attempts to load, which immediately fails. So a strong indication of stale data.

Fee Fie Fo Fum, I smell the blood of a hackable bootmgr!

[1] Do remember to use the correct endianness of the GUID... The rules are honestly completely crazy, so I suggest copying the on-disk representation from a hex editor, rather than using gdisk or diskpart

[milindsmart]

Interesting and mind-boggling problem :

disk 1 (MBR) -> system partition + disk 2 (GPT) -> boot partition = Boots (one of the first accomplishments in the thread)

But

disk 1 (GPT) -> (system partition + boot partition) + memory fiddling described above = winload.exe cannot read the disk

AND

disk 1 (MBR) -> system partition + disk 2 (GPT) -> boot partition + memory fiddling described above = winload.exe cannot read the disk

It seems somehow weird that winload.exe is happy being on a GPT disk while it's loaded by bootmgr.exe from an MBR disk, but isn't happy when bootmgr.exe is from the same GPT disk, which is convinced that it's ok.

[Wonko the Sane]

It seems somehow weird that winload.exe is happy being on a GPT disk while it's loaded by bootmgr.exe from an MBR disk, but isn't happy when bootmgr.exe is from the same GPT disk, which is convinced that it's ok.

 

Or maybe the "memory fiddling" that you very vaguely mumbled about is simply "wrong" or "incomplete", or *something else* doesn't *like* the BOOTMGR.EXE (are you sure it is BOOTMGR;EXE and not BOOTMGR?) on GPT disk volume.

 

I fail however to see a good reason for trying an alternate (complex) solution to a problem that has been already solved in a simple manner through the grub4dos mapping of a new floppy or hard disk on the fly.

 

Wonko

[Tripredacus]

I saw this observation on Technet, which might be related:

http://social.techne...=w7itproinstall

[Wonko the Sane]

I saw this observation on Technet, which might be related:

http://social.techne...=w7itproinstall

Well, that one is seemingly related to another thing, it is about issues when booting in UEFI mode (and not in BIOS mode which this thread is about) and having issues IF a MBR disk with an extended partition is connected to the system (even an external USB disk drive, as long as it has an Extended partition).

 

Wonko

[milindsmart]

Or maybe the "memory fiddling" that you very vaguely mumbled about is simply "wrong" or "incomplete", or *something else* doesn't *like* the BOOTMGR.EXE (are you sure it is BOOTMGR;EXE and not BOOTMGR?) on GPT disk volume.

Well I figured this stuff out by tracking individual assembly instructions, possible only because of debug symbols being available and IDA being so awesome... Any clarity would be a bonus

And that bonus is precisely what Michael Brown of iPXE provided me on an IRC chat, which I will describe in the next post. It builds on http://ipxe.org/bootapp/spec , an extremely unique piece of info on how bootmgr.exe works. I was putting it off because it's a big enough bomb compared to the scant info we are currently working with...

I call it bootmgr.exe because although the file on disk I am using is bootmgr, all the hacking is happening at the PE execution stage.

I fail however to see a good reason for trying an alternate (complex) solution to a problem that has been already solved in a simple manner through the grub4dos mapping of a new floppy or hard disk on the fly.

If it was simply incapable of using GPT disks, then what you say makes sense... But because it is just soooo close to being capable of booting seamlessly all on its own, I just don't feel like being satisfied with wimboot. All the other solutions are even less elegant. And also, I'm a bit hooked to the reverse engineering

[milindsmart]

So take a look https://git.ipxe.org...:/src/bootapp.h and https://git.ipxe.org...fd1:/src/main.c , along with the iPXE page I linked to above....

Basically these memory addresses correspond to fields in a structure whose address is passed by the 16-bit stub to bootmgr.exe as its only parameter... He's done an amazing job of working out the details!

So that is how he emulates a disk in wimboot, and which is how I eventually plan to make a new 16-bit stub that works fine with GPT disks, which I can put together with bootmgr.exe with Joakim's Bootmgr recompiler. The beauty of this is that there is no INT table hooking : bootmgr.exe will willingly accept a bunch of parameters.

The even better part I found out just now is that bootmgr.exe passes a structure to winload.exe that is, AFAICT, exactly of the same type.

Another interesting tidbit is that the ntoskrnl.exe is apparently initialized in the same way as the XP kernel is : with a long list of familiar arguments and there is even something called the NT Kernel Command line, according to mcb30.

Far out, I expect that we'll be able to make the path to the BCD as a parameter

[Wonko the Sane]

If it was simply incapable of using GPT disks, then what you say makes sense... But because it is just soooo close to being capable of booting seamlessly all on its own, I just don't feel like being satisfied with wimboot. All the other solutions are even less elegant. And also, I'm a bit hooked to the reverse engineering

Well, then it is for the "sheer fun" of it, and it is more than justified .

 

Wonko

[milindsmart]

That sounds a lot like : "ah good luck, carry on then! We'll just watch, thank you".

[Wonko the Sane]

That sounds a lot like : "ah good luck, carry on then! We'll just watch, thank you".

 

As I see it, before this thread there were (say) 2,852 unresolved issues connected to Windows booting, now there are just 2,851 remaining as one has been solved, one way or the other.

 

Is the next step finding a more elegant solution (remembering that elegance, like beauty, is in the eye of the beholder) for the same, already solved, problem or tackle another new, strange problem?

 

Everyone is free to reply to this question the way he/she fits and act accordingly, the only main thing is having fun while doing this (or that, or something completely different).

 

Sometimes it is fun to get from A. to D., sometimes it is fun just the path you take from A. to D. (through B. and C. or through E., F. and G.) even if you never reach D., and sometime it is fun to enumerate all possible paths from A. that will get you to D., and everyone is free to find the fun in each of these, that is the good thing about freedom.

 

Maybe the quoted sentence sounds like "ah good luck, carry on then! We'll just watch, thank you" because it actually means "ah good luck, carry on then! We'll just watch, thank you", but I fail to see the issue should the way it sounds be its actual meaning.  

 

 

Wonko

[milindsmart]

Well let me explain...

 

The motivation to get this working is partly fun, as you said it. The whole concept of MBR sounds like an injustice, and anything that helps people stop using it, is worth it, in my view. Basically making the world slightly more "right"...

But ultimately I wish that it is useful to some people at least. I am somehow not of the type to do something "purely" for the fun : if ultimately that thing happens to be entirely useless, the fun aspect decays...

 

In this context, if you really think about it, there are very few forums where members do this level of hacking... Major open source contributors do much of their work alone. The rest of the "Tech" sites are just support forums : just ways for users to solve their problem to "get back to whatever else they like doing", as if OS tweaking is somehow inherently a "lower" activity that people do when forced, but avoid in favour of "higher tastes", like ugly modern paintings or playing political games.

 

In the english speaking world, there seems to be only MSFN, 911 CD and this forum, where interested folks hang out.. The only other sites that do a similar level of stuff is neowin.net and mydigitalllife.info , but there there is a greater prevalence of cracking than here (very interesting too). Also, the first three share a lot of the userbase... My point is, if people here don't think it's a worthwhile thing to do, then there are not going to be very many out there who do. For which I'm sure there's a very good reason... I just am not sure of what it is.

 

From what you indicated, this seems like a spending effort to solve an already solved problem.. Grub4dos embedded disk mapping is very unwieldy because as of now, there is no remotely sustainable way to put or remove files from inside unless using WinVBlock too. Memdisk is better but still will not let bcdedit or any other boot configuration tool to work. Wimboot is nearly ok, but it's a bit slow, since it needs a Grub or Grub4dos to run on, and itself does not execute instantaneously. You also have to remember that Windows cracks, bootsector viruses and everything in between appear very similar since such screens disappear quickly. Don't you think having this as a normal method of booting would make it hard to tell with a casual glance what else is influencing (and perhaps corrupting) the boot process?

 

Hope you can see now why it's not a solved problem...

[Wonko the Sane]

I still fail to see the actual problem you depict.

 

The problem (the one I can see) is (or was):

How to boot a Windows 7 from a GPT disks in BIOS mode?

 

And there are already several proposed solutions to this problem (which in itself is also a rarely found in the wild problem).

 

If you have BIOS you can use grub4dos, and use any of:

1. booting from *anything* else to grub4dos and then create a floppy on the fly
2. adding to the GPT disk a way to boot without modifying it's GPT status by means of a small volume "invisible" to BOTH MBR and GPT tools and then create a floppy on the fly or use another copy of BOOTMGR+ \boot\BCD
3. modifying the GPT disk adding a simple small partition (as above, but visible to GPT tools)
4. modifying the GPT disk adding an EF02 partition and using the Syslinux gptmbr+grub2 to load grub4dos and then do the same as above
5. modifying the GPT disk adding an EF02 partition and using the Syslinux gptmbr+grub2 to load grub4dos and adding an EF01 partition to be mapped as "whole disk"

any number of slight variations of the above.

 

Of course one might not *like* any of the above, but besides that, unless some serious "show stoppers" are found and explained, I will consider all of them valid solutions to the problem.

 

And we have to agree to disagree on the main philosophy.

 

MBR or GPT don't make that much of a difference (they are essentially the same thing, an addressing scheme), the GPT is simply a (badly implemented IMHO) evolution of the MBR scheme.

Mind you, set aside the fun about the "wasted" bytes in GPT, it is not "bad" in itself, it is bad because it creates - most probably by design - a number of incompatibilities with BIOS, in order to make UEFI a *need* or more generally to make obsolete existing computing equipment and OS's and software.

If you prefer, if when the good MS (or IBM) guys "invented" the MBR scheme, they had proposed the GPT one instead it would have been very smart, proposing it as an "evolution" of MBR is fundamentally "wrong", as they could have easily have made a "new" set of specifications keeping a large (even if not integral) compatibility with BIOS.

 

 

Wonko

[MsK`]

Hello,
 
I'm trying to replicate Sacha Weaver's / wzyboy's method of booting but boot is stuck at "Loading boot sector... booting..."
 
A bit of background first. One or two years ago, my hard drive was failing so I bought a new one which happened to be 3TB big. I didn't know at the time that it had to be GPT partitioned and that windows couldn't boot from it unless booting from UEFI. Well, officially of course. I found the tianocore/duet solution and managed to install it, all was fine. (except for those crazy long boot times ^^)
 
Yesterday, after a windows update, my duet installation got broken. I couldn't even get to the "boot maintenance something" menu. And unfortunately, the gitorious repo with the binaries and the documentation is dead now. So I searched for alternatives solutions.
 
I found the boot from USB stick method (http://www.sevenforu...-mbrs-duet.html). Works perfectly fine, but I'd like to get my USB stick back
 
As I couldn't manage to install grub or grub4dos with clear documentation about the GPT boot thing. (sorry, I've read so much stuff yesterday about all those boot strategies that by the end of the day I got very confused about everything !), I installed syslinux using this method : http://www.lightofda...cgi/BIOSBootGPT
 
I then followed wzyboy's instruction to build a hdd image and set up syslinux to start memdisk with this image.
 
This is as far as it gets me:

 
I mailed wzyboy and unfortunately, he doesn't have a windows machine anymore. He still gave me this answer:

The fact that your computer stuck at "Loading boot sector ...
booting..." indicates your bootmgr.vhd may lack a valid MBR boot
signature (a boot sector). I suggest dumping the first 446 bytes of
that image to verify whether it has the boot signature or not. Also,
the sole partition on the virtual disk should be marked as "active",
which can be verified by fdisk.

So I checked as good as I could and found this:

Looks like a valid MBR to me...


Looks legit to me...

Any thoughts ?

Edited by MsK`, 19 April 2015 - 08:09 AM.

[Wonko the Sane]

It is likely that the issue here is the actual hard disk image.

 

The CHS geometry memdisk reports 5/243/47 seems like the result of throwing dices!

 

How EXACTLY did you create it?

 

WHICH exact OS are you running? Windows 7?

 

From the screenshot of the MBR, the relevant partition data is:

80 20 21 00 07 F2 2F 03 00 08 00 00 00 F0 00 00

that equates to:

07 80 0/32/33 3/242/47 2048 61440

 

A good idea would be (just to exclude this possibility of strange issues with strange CHS) to use a more "normal" set of values.

I see you have the wxHexeditor, so you can change the values:

80 20 21 00 07 F2 2F 03 00 08 00 00 00 F0 00 00

to:

80 01 01 00 07 FE 3F 02 3F 00 00 00 04 BC 00 00

that equates to:

07 80 0/1/1 2/254/63 63 48132

 

After having made this change you will need to attach the vdisk and re-format it, then re-run the:

 

# Write boot sector and BCD
X:\> bootsect /nt60 b: /mbr
X:\> bcdboot c:\Windows /s b:

 

 

Or, maybe better, start from scratch, creating a new vhd image using a tool that gives you finer control to the size and geometry of a .vhd, such as the excellent clonedisk:

http://reboot.pro/fi...e/24-clonedisk/

http://reboot.pro/to...5244-clonedisk/

 

 

Wonko

 

P.S.:

In any case (as it costs nothing) do add inside the .vhd a simple BOOT.INI file like:

[boot loader]
Timeout=30
default=C:\grldr

[operating systems]
C:\grldr="grub4dos"

C:\whatever="Something else"

 

 

as this is the simplest way to see if the BOOTMGR loads and the issue is to be found in a later stage (like the \boot\BCD).

 

As a side note the link you provided:

http://www.lightofda...cgi/BIOSBootGPT

makes use of Syslinux 4.06, it is possible that you are using another version (and some of the newer ones had some issues, not necessarily connected to this kind of booting problem, but you never know).

[MsK`]

Thanks for the reply. I'm indeed running Windows 7, 64 bits if it matters. I followed the steps from wzyboy on page 2 (http://reboot.pro/to...o-gpt/?p=184489). I also tried adding the bcdedit from http://www.sevenforu...-mbrs-duet.html but that didn't change anything.

If I change the values you told me and then re-run bootsect, wouldn't bootsect overwrite those changes ?

I'm going to take a look at that clonedisk and add the boot.init you suggested, seems like a very good idea.

 

Edit: oh, and I installed the syslinux I could get from the latest ubuntu live which I guess is the same as the latest version in ubuntu.

 

Edit2: Ah, and I create the vhd from the command line you get in the windows 7 dvd installer when pressing shift+F10.

Edited by MsK`, 19 April 2015 - 01:22 PM.