If you resort, you can go to the hybrid menu immediately after, without writing out the newly sorted GPT - gdisk will use the resorted table to create the hybrid MBR. Next step in creating the hybrid MBR, you'll be asked if the GPT should be stuffed in the MBR, say yes.
I thought I'd finally relegated Windows to life inside a virtual machine, but alas, I came across some games I'd like to play that just won't do in that setup. In the days since Windows last occupied its own specified chunk of my disk I've done a lot of flipping around with different OSes and Linux distributions, and it turned out that while I had free space, I was at the maximum number of partitions supported. So, believing that it should Just Work® here in the 21st century and having performed a cursory examination of Google that indicated it should work, I converted over to a and attempted to install Windows 7.
Lo and behold, Windows 7 only works with GPTs on EFI systems, and mine uses BIOS. I should have noticed this in my earlier research, but that would have just been too easy.So, I'm left with the choice of converting back to MBR and trying to jigger my partition layout around such that I can make one for Windows, or going with a. The latter sounds more appealing. Unfortunately, there are lots of scary warnings about hybrid MBRs on the Internet, so I have a few questions.Will Windows do something ugly to my bootloader since it's really on GPT but it will see MBR?
Will that require more repair than booting from a LiveCD and running grub-install? Is there anything I need to avoid other than making sure I never touch partitioning tools on Windows? Will my computer explode? Would lots of headaches be saved if I just switched back to MBR?
(I understand that Macs use hybrid MBRs with Boot Camp, so hopefully this won't be as difficult as I'm making it out to be.). There's no need to regress to the MBR partitioning scheme, nor even any need for a 'hybrid MBR' partitioning scheme. (I have such on one of my machines, and attest that they are not for the fainthearted.), and (to protect you from yourself, in Microsoft fashion) refuses to install on them in the first place. In your case, your problem is a fundamental deficiency of your firmware, and isn't really a Windows issue at all. Your firmware doesn't understand the EFI partition table.Such understanding is necessary if one wants to convert one's operating system bootstrap to be on EFI partitioned discs. One's firmware needs to know.
Your firmware isn't very smart, though, and doesn't know how to do much more than load the 'master boot record' and run its bootstrap code. On an EFI partitioned disc there's no code in the 'master boot record' to crank through the rest of the EFI boot process.At best, right now, you have MBR bootstrap code that is equally as ignorant of the EFI partition table scheme as your firmware, and that's expecting to find and process an MBR partition table.
What you need is two things:. to have MBR bootstrap code that knows how to read the EFI partition table, and find a second-stage bootstrap loader that is also EFI-partition-table-capable and which will enable you to in turn load and run operating system boot loaders. some way of persuading Windows 7 to install on an EFI partitioned discThe first is not impossible.
There are two sources of such EFI-partitioning-aware MBR bootstraps:. (after this answer was first written, in fact).
The so-called 'GPT' MBR boostrap in SYSLINUX, written by H. Peter Anvin, is another.Both will but with an EFI partition table. Failing those two, the best alternatives that you'll get right now are:. GRUB 2: Unfortunately this still relies upon poking hardwired numbers into its MBR bootstrap code to tell it where to find the next part of its loader.
But that second stage, once loaded and run, is fully capable of understanding the EFI partition table and bootstrapping operating system boot loaders from within partitions. It doesn't know how to run EFI operating system boot loaders, though, it only knowing how to cope with either VBRs or Linux and the BSDs. UEFI DUET: Again unfortunately, although this installs in a volume and brings up a fully capable EFI Boot Manager and EFI Shell, it still needs something else to load and run its VBR in the first place. And right now that something else has to be something like GRUB2, which itself rely upon hardwired sector numbers in the MBR code, or SYSLINUX, or indeed my EFI-partitioning-aware MBR bootstrap.
But you will be able to run proper EFI operating system bootstrap loaders.The second (persuading Windows 7 to install on an EFI partitioned disc) is achievable, with the x86-64 flavour of Windows 7 at least. It's complex, not officially supported by Microsoft, and requires making what is effectively your own Windows installation disc with the EFI version of Microsoft's Boot Manager on it, and running that from within an EFI boot environment somehow. (If you have UEFI DUET installed, this is fairly easy, of course.) But it convinces Windows 7 that it its installer was bootstrapped on an EFI system, which criterion the installer uses to determine whether it will allow Windows to be installed on an EFI partitioned hard disc.Of course, there's the additional, final, complexity of, once installed, bootstrapping Windows 7 from day to day; because the installer, knowing that you have EFI firmware, will have installed the EFI version of Microsoft's Boot Manager. There are several possible solutions to this problem. To summarize, in more-or-less my order of preference:.
Upgrade your motherboard - If you get a motherboard with UEFI boot features, you'll be set, since you can then install Windows in UEFI mode. Most (maybe all) boards based on Intel's Sandy Bridge are UEFI-capable, although some don't advertise this fact. Many new AMD boards are also UEFI-capable. In fact, there's a chance you've already got such a board. Many Intel-brand boards sold in the past few years have a UEFI boot option buried in their CMOS settings screens. You might try searching for such an option. You may need to use UEFI mode for all your OSes, though.
Fortunately, Linux converts over quite easily, and can switch back and forth with no reconfiguration once it's set up to boot either way. Note that you'll need a 64-bit version of Vista or 7 to install Windows in UEFI mode. Use a second hard disk - You can install Windows to an MBR disk and keep Linux on a GPT disk. You can even put Windows data partitions on the GPT disk if you like (provided you're using Vista or 7); only the Windows boot disk has to be on MBR. Even if you've got some old 20 GB drive, it's probably sufficient to hold the Windows C: partition, and you can then put your Windows program files on a GPT partition, provided you're using Vista or 7. Convert to MBR - You can do this with, but with certain caveats. Most notably, you'll have to have at least one free sector preceding each logical partition you want to create, and all the logical partitions must be contiguous.
If your current disk doesn't meet those specifications, you'll either lose partitions in the conversion or you'll need to resize some partitions to create the necessary gaps. There's also some risk of data loss, particularly if you have to resize partitions. Use UEFI DUET - As JdeBP suggested (and linked to ), UEFI DUET is a possibility.
IMHO, the drawbacks to this approach aren't as great as JdeBP suggests, IF UEFI DUET even boots on your system. (Odds are good if you've got a 64-bit Intel CPU, less good on 64-bit AMD CPUs, and it won't work at all on 32-bit CPUs.) You do have to be careful and have a good mind for technical troubleshooting to try this, though. You can do some preliminary explorations with a USB flash drive; install UEFI DUET to it and see if you can get it to boot. If it boots, you'll probably be able to get Windows to install and boot, even on a regular basis, although there are pitfalls, as noted on my page on the subject. Once set up, UEFI DUET becomes, essentially, a rather big GPT boot loader for Windows. Use virtualization - It's not quite what you're asking for, but it's conceivable Windows would work acceptably in a virtual machine.
![]()
For gaming, though, I'm a bit skeptical you'd get the performance you need, but it might be worth trying. Hybrid MBR - You can set this up and install Windows to a hybridized partition. Windows will wipe out your current MBR-resident boot loader, so be prepared to re-install it. Personally, I don't recommend this solution, since hybrid MBRs are dangerous.
If all of the other options fall through, though, it might be this is give up on Windows.I'd also like to clear up a couple of misconceptions:. Windows' inability to boot from GPT on a BIOS-based computer is definitely a Windows limitation, not a firmware (BIOS) limitation. Linux, FreeBSD, and some other OSes can boot fine from GPT disks on BIOS-based computers. I don't know why Microsoft doesn't want to support booting Windows from GPT on BIOS-based computers, but they could certainly do it if they wanted to.
If nothing else, they could take a UEFI implementation, strip it to its essentials, and use it as a boot loader. SYSLINUX's GPT loader doesn't use hard-coded sector values; it has enough smarts to read the GPT and jump to the partition with a Legacy BIOS Bootable flag set on it. Not that there's anything wrong with hard-coding sector values, the way GRUB 2 does; the two solutions just have different advantages and disadvantages.
On 01:39 PM, Kirill Elagin wrote: Imagine, that I want to hybridize two partitions and I don't want to put 0xEE partition first in the table (it's a flash drive to be used with Windows). In my particular case the layout is the following: Number Start (sector) End (sector) Size Code Name 1 20 3.5 GiB 8E00 Linux LVM 2 728079 2.0 GiB 8300 Linux filesystem 3 1143374 2.0 GiB 0700 Microsoft basic data Original code will make hybridized partitions #1 and #2 in the MBR partition table, then it will create an 0xEE partition #4, then it will ask me if I want to cover unused space (sure, I want to cover backup GPT at the end of the disk), and then it will make partition #4 cover the end of the disk.
So I end up with main GPT structures unprotected and one empty slot in MBR GPT like this: Number Boot Start Sector End Sector Status Code 1 1143374 primary 0x0C 2 728079 primary 0x83 4 1563407 primary 0xEE Modified code does this: Number Boot Start Sector End Sector Status Code 1 1143374 primary 0x0C 2 728079 primary 0x83 3 1 7243775 primary 0xEE 4 1563407 primary 0xEEOK, thanks for the clarification. I'm accepting this patch into the nextversion of the program.-Rod [email protected] view. On 01:39 PM, Kirill Elagin wrote: Imagine, that I want to hybridize two partitions and I don't want to put 0xEE partition first in the table (it's a flash drive to be used with Windows). In my particular case the layout is the following: Number Start (sector) End (sector) Size Code Name 1 20 3.5 GiB 8E00 Linux LVM 2 728079 2.0 GiB 8300 Linux filesystem 3 1143374 2.0 GiB 0700 Microsoft basic data Original code will make hybridized partitions #1 and #2 in the MBR partition table, then it will create an 0xEE partition #4, then it will ask me if I want to cover unused space (sure, I want to cover backup GPT at the end of the disk), and then it will make partition #4 cover the end of the disk. So I end up with main GPT structures unprotected and one empty slot in MBR GPT like this: Number Boot Start Sector End Sector Status Code 1 1143374 primary 0x0C 2 728079 primary 0x83 4 1563407 primary 0xEE Modified code does this: Number Boot Start Sector End Sector Status Code 1 1143374 primary 0x0C 2 728079 primary 0x83 3 1 7243775 primary 0xEE 4 1563407 primary 0xEEOK, thanks for the clarification.
I'm accepting this patch into the nextversion of the program.-Rod Smithrodsmith@.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |