12

We have UEFI servers and have come across a situation where we need to force Windows Server 2008 to boot via the legacy BIOS method instead of through UEFI.

Is there a way to tell Windows Server 2008 (either during install or post-install) to ignore the fact that it's installing onto an EFI machine and instead install and use the legacy BIOS bootloader?

I've tried a few suggestions which didn't help:

  • Format disks as MBR partitions before installing Windows

    Nope, Windows refuses to install:On EFI systems, Windows can only be installed to GPT disks

  • Install Windows, migrate the partition to an MBR disk, repair system

    Nope, the system repair console refuses to load. It complains that it doesn't recognize the version of Windows I'm attempting to repair.

  • Disable UEFI

    If I could disable UEFI and make the system legacy-only, I would have. However, the particular systems I'm using (IBM HS22, x3690X5) are UEFI-only with legacy support. You can't just disable UEFI on them. That would require a complete BIOS implementation.

The Solution!

As JdeBP points out, the sole method Windows uses to determine whether to use the EFI/GPT or BIOS/MBR bootloader is the method which was used to boot the install CD.

Combining this with Weaver's suggestion to craft a .iso image without the 0xEF boot catalog entry (far easier to do by hex-editing rather than remastering the image, by the way) leads us to a nice, concise answer:

Force the install media to boot via BIOS, not via UEFI as this is the only differentiator Windows Installer uses to determine which boot scheme to use.

MikeyB
  • 38,725
  • 10
  • 102
  • 186
  • This is going to be hardware specific. It may help if you mention the equipment and model. Some vendors provide an option for BIOS-compatability mode in the setup screen or as a boot option. – Tom Willwerth Sep 06 '11 at 19:28
  • The reason I didn't mention hardware in the question was a deliberate choice. I want to make this change on the Windows side by telling it to use a different bootloader. My IBM x3690X5 already has BIOS compatibility turned on, so any BIOS loaders will work. The problem is telling W2K8 to *not* use its UEFI bootloader. – MikeyB Sep 06 '11 at 19:32
  • 2
    @MikeyB: Why not just use GPT? – tegbains Sep 13 '11 at 18:49
  • @tegbains: $BIGCUSTOMER has an imaging environment which uses a product that does not properly support GPT. – MikeyB Sep 13 '11 at 18:58
  • 1
    If it hadn't taken a fortnight to wring this very important piece of information out of you, we could have saved Weaver a lot of grief. I suggest that you edit your question to reflect the actual goal, because what is in the title is [the step X that you cannot get to work](http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/put-down-the-chocolate-covered-banana.html) and your question is highly misleading. – JdeBP Sep 15 '11 at 15:08

3 Answers3

7

In short, yes and no for a few different reasons. If Windows is booting from a GPT disk, it must be from UEFI. Windows boot manager and loader cannot boot to MBR disk from native UEFI. However, if the UEFI is configured for legacy BIOS boot mode then an MBR disk can be used for booting. This stems from the Windows boot mode (BIOS with MBR or UEFI with GPT) being contingent on the environment in which it is envoked.

Read on for a little tech --

The physical hardware (or virtual hardware, but hardware nonetheless) firmware (BIOS/UEFI) provides the initial operating environment (boot related data structures and conventions) and firmware services available to subsequent stages of the operating system boot process.

BIOS/MBR

In the case of BIOS/MBR boot the first sector of the first bootable disk -- the master boot record (LBA 0) contains a handful of x86 (16 bit 8088) assembly, then the partition table, then a signature). The BIOS loads this sector into memory and begins executing -- the BIOS relinquishes its own program code control as soon as the MBR gets involved.

http://mbr.adamsatoms.com/

http://www.ata-atapi.com/hiwmbr.html

x86 assembly (Intel 8088 in most MBR's) in the MBR parses the partition table, searches for an active partition, and jumps to the first sector in that partition -- called the volume boot record. The volume boot record contains an x86 assembly jmp, a BIOS parameter block (not used by the system BIOS at all, so confusing name), and a bunch more x86 assembly that ultimately loads the operating system's boot loader (NTLDR or BOOTMGR in Windows environments) from the boot volume/partition itself.

NTLDR or BOOTMGR flip the CPU to protected mode, consult their boot-time configuration (boot.ini or the BCD respectively, both on the boot volume/partition), and load NTOSKRNL where the rest is history.

http://technet.microsoft.com/en-us/library/cc781134%28WS.10%29.aspx

http://en.wikipedia.org/wiki/Windows_NT_startup_process

http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/bios-parameter-block.html

UEFI/GPT

First let me state that I do not have much active experience with UEFI/GPT. However, as I have used it and understand it to operate -- the big difference (as it relates to our conversation) is that executable control is not transferred to the MBR.

Instead the UEFI firmware contains its own boot manager. This boot manager scans disks and media, -- glosses over the protective MBR of GPT formatted disks, arrives at the GPT header, and then dives into the EFI System Partition (ESP) where it looks for EFI executable programs -- which are supposed to be operating system boot loaders booting the OS directly, however as we have seen with the latest MS and Apple EFI executables, they are in fact boot managers adding another layer to th process and complexity.

http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html

http://msdn.microsoft.com/en-us/windows/hardware/gg463525#X-201104111922443

Conclusion/TL;DR

The point to take away from this is that there is an expected environment in which the operating system's boot manager and boot loader expect to run. From firmware level services available (BIOS/UEFI interrupts), data structures (variables, stack conventions, etc), and even disk formatting conventions. Cannot be changed at runtime -- at least not the way I understand it.

Your options?

Pre-install you can control the install by using BIOS/MBR or UEFI in legacy BIOS boot with MBR or UEFI with GPT.

Post-install -- there may be some interesting possibilities with changing the disk format (MBR to GPT and GPT to MBR) offline, then booting to a recovery console (in appropriate UEFI or BIOS mode) and working with bcdboot and bcdedit to get Windows boot manager set straight.

Update 2011.09.09

@MikeyB

Listing options as I understand them to be, not actually making any formal suggestions.

Nevertheless, after doing a little more research on UEFI (recall that I don't have much active experience with it) I have discovered a few interesting tidbits about the UEFI boot manager and support for CD/DVD booting.

The El Torito Boot Specification, from '95 is still around today and is used with bootable CD/DVD's. A single CD/DVD may have to boot on several architectures -- and while ISO 9660 is rather platform independent, executable code is not. As such, the El Torito Boot Specification allows for multiple boot entries/images.

These entries/images contain a Platform ID, intended to indicate whether an entry is for PC, PowerPC, and other architectures so that architecture's BIOS (or firmware) can choose the right boot entry.

Standard x86 PC's with a BIOS has an El Torito Platform ID of 0x00. UEFI capable Platform ID is 0xEF -- rather creative.

Standard x86 PC BIOS's ignore all other entries except 0x00. UEFI firmware's that have legacy BIOS support (known as Compatibility Support Module (CSM)) -- while able to boot 0x00, will prefer a 0xEF native boot entry from the catalog.

The Windows 2008, 2008 R2, and 7 DVD media contain a multiple image El Torito catalog with both 0x00 and 0xEF. The 0x00 is the default, but a UEFI will gloss over it if a 0xEF exists and choose the 0xEF entry -- as it is native.

What is possible -- is to craft media that only contains the preferred Platform ID in the El Torito boot catalog. Instead of a multi-entry catalog, create a single entry catalog with a 0x00 Platform ID. This should force the UEFI firmware, if in fact it supports legacy BIOS boot, to choose the 0x00 Platform ID and boot the legacy BIOS boot entry on the Windows media.

How to do it?

Using Oscdimg it is possible. Below are several examples of people creating UEFI only media to get around the limitations in Apple's UEFI implementation. Note that this is the opposite of what we are trying to do -- we want to create a BIOS only, leaving out the UEFI boot entry from the catalog.

UEFI Only (Opposite) 1

UEFI Only (Opposite) 2

The process to create BIOS only media is similar with changes to the -b and -p arguments to the following

-bC:\path\to\Etfsboot.com -p0x00

A great resource that shed some excellent light on Microsoft's chosen madness on the Windows install media is the UEFI Support and Requirements for Windows Operating Systems document.

Weaver
  • 1,932
  • 11
  • 12
  • 1
    "Pre-install you can control the install by using BIOS/MBR or UEFI in legacy BIOS boot with MBR or UEFI with GPT." OK, so *how* do you tell Windows: "Install to a MSDOS-style partition table."? – MikeyB Sep 09 '11 at 16:38
  • @MikeyB Boot the Windows installation media in a computer system with a traditional BIOS. Or -- boot the Windows installation media in a computer system with UEFI set in legacy BIOS boot mode. Note that your UEFI must support a legacy BIOS boot mode. – Weaver Sep 09 '11 at 19:58
  • You're suggesting I install Windows onto a completely different computer then move the disks over? Not a good idea at all. Also, when you set a UEFI computer to 'legacy BIOS mode', it just enables the legacy BIOS hooks for booting legacy MBR disks. It *doesn't turn off UEFI*, so Windows still says "Is this a UEFI system? Yup." – MikeyB Sep 09 '11 at 21:00
  • @MikeyB Added updates to the original answer. – Weaver Sep 10 '11 at 01:27
  • @mikeyB- I think you are confused about the legacy BIOS modes of MOST (not all sadly) UEFI machines, you are always booting into UEFI regardless of whether you set legacy mode so asking windows to "ignore" the UEFI mode doesn't seem to make sense (even if it were possible). You should be able to get 2k8 to use the bios calls if you format the disk as MBR rather than GPT. – Jim B Sep 12 '11 at 19:17
  • 1
    I've seen something similar with server 2008, in the process of learning about BIOS and MBR disk size limits. I built a server with 2008 R2 and enabled legacy BIOS mode due to the fact it wouldn't install with USB media (an MS bug) however I found it then used MBR rather than GPT because BIOS isn't capable of loading GPT (unless you have a boot loader of some sort). In short, switching to legacy mode definitely installs in legacy mode, the proof will be in disk manager where you'll see MBR not GPT disks. – Alex Berry Sep 13 '11 at 08:30
  • @Jim_B: Nope, not at all confused. And nope, Windows 2008 refuses to install if the're pre-existing partitions on an MBR disk. – MikeyB Sep 13 '11 at 16:19
  • @MikeyB I have heard of similar behavior with UEFI boot and attempting install to MBR partitions. Per my answer, using an El Torito boot catalog with only a BIOS boot entry will force the UEFI firmware to boot the BIOS boot entry in the El Torito catalog -- if CSM is enabled and supported in the UEFI. You will need to make the CD/DVD as described. – Weaver Sep 13 '11 at 19:03
  • @Weaver: THAT IS NOT THE PROBLEM! – MikeyB Sep 13 '11 at 19:33
  • @MikeyB It is fairly obvious from your last several responses that a rather large misunderstanding is present between the question being asked and the answers and comments being presented. I have answered what I believe to be your question. If there is something I am missing please do your best to refocus the question. – Weaver Sep 13 '11 at 21:19
  • @Weaver: I'm not trying to boot from a CD. What's important is convincing Windows to use the MBR partition layout and BIOS bootloader rather than the GPT/UEFI bootloader. – MikeyB Sep 13 '11 at 23:03
  • @MikeyB 'It doesn't turn off UEFI, so Windows still says "Is this a UEFI system? Yup." ' ---> That depends on your firmware options. I have seen many boards with the ability to disable UEFI. – Milind R Jan 18 '14 at 18:07
  • @JimB 'you are always booting into UEFI regardless of whether you set legacy mode' ---> Why? The UEFI is an _interface_, and so it can definitely be turned off, and providing an option for it in the firmware setup screen is not hard, I have seen it. What you might have meant is 'you are always booting into firmware regardless of whether you set legacy mode', which of course it true. – Milind R Jan 18 '14 at 18:10
  • @milind, you'll have to tell the engineers at HP that they've simply gotten it all wrong in those early UEFI firmware systems that allowed you to choose. – Jim B Jan 18 '14 at 22:38
  • @MilindR Yes, the *computer* is always booting into UEFI. The distinction is whether UEFI boots Windows or UEFI boots the BIOS shims which then boot Windows. – MikeyB Jan 20 '14 at 03:08
  • @MikeyB The UEFI is just an interface. Whether it uses a BIOS shim or whether the UEFI itself was a shim on top of legacy BIOS is irrelevant. So the computer boots with the firmware either presenting the UEFI, or presenting the legacy BIOS interface. The detail of what is built on what comes under the UEFI Platform Initialisation spec, which is a distinct thing from UEFI itself. The OS and the rest of the system needn't care. – Milind R Jan 20 '14 at 05:31
  • @JimB what's wrong with being allowed to choose? Perhaps I didn't understand your comment correctly. – Milind R Jan 20 '14 at 05:34
6

Microsoft won't let you achieve your step; so address your goal instead.

Microsoft erroneously conflates has an EFI partitioned hard disc with has EFI firmware. This is, of course, clearly wrong. It's quite possible — and indeed is becoming ever more desirable these days — to have an EFI partitioned disc on a machine that has old non-EFI firmware. You actually — although it took over a fortnight for people here to wring the goal out of you rather than the step — want the converse. You want to have an old PC/AT-style MBR partitioned disc on a machine that has EFI firmware. (EFI firmware itself has no problem with either partition table format, and is indeed required by the EFI specification to understand both. It's Microsoft that makes this error.) And you want this because someone else's software cannot understand the EFI partition table.

One of the several consequences of Microsoft's error is that the Windows NT 6.1 installer has to be invoked from an install medium that has in turn been bootstrapped from old PC98 firmware, in order for it to accept the idea of installing Windows NT 6.1 to a disc partitioned with the old PC/AT MBR partitioning scheme. Unfortunately, if the Windows NT install disc is bootstrapped in the new EFI way the installer will think that there's EFI firmware, and so declare that it cannot be installed to non-EFI partitioned hard discs.

As Weaver has pointed out, and as the Microsoft documentation explains, the installation CD-ROM is in fact dual-boot. As Rod Smith further explains, one therefore can manually construct a Windows NT 6.1 install disc that bootstraps in the old PC98 way. The Windows NT 6.1 installer will then allow installation to an old PC/AT MBR partitioned hard disc.

However, on systems lacking a compatibility support module, as you say your system does, this will not help one whit. Your system will require the EFI version of Microsoft's Boot Manager, installed on the EFI System Partition, because that's how your firmware will try to bootstrap the operating system. But when the Windows NT 6.1 installer is started on non-EFI firmware, it installs the non-EFI version of Microsoft's Boot Manager and won't create an EFI System Partition. Such an installation will not actually bootstrap on your machine, and you won't even be able to complete the installation procedure. Indeed, because you lack a CSM you won't even be able to begin the installation procedure, because you won't even be able to bootstrap the installation disc in the old PC98 way. Microsoft won't let you achieve your step, two times over.

So focus on your goal, instead. Your goal is to enable your customer to deploy Windows Server 2008 onto machines that have EFI firmware from a system image. Therefore the correct question that you should be asking — of the software vendor — is how to get that old/broken disc imaging software fixed so that it has no trouble with the EFI partition table.

JdeBP
  • 3,970
  • 17
  • 17
  • Oh my system doesn't lack a compatibility mode, that's not a problem. So you're saying that the only way the Windows installer detects whether the system is EFI is via the method which was used to bootstrap? That's new and critical information - I'll try that out. – MikeyB Sep 15 '11 at 15:53
  • Ahah! It works! That's the critical piece of information that I needed: **"Force the install media to boot via BIOS, not via UEFI as this is the method Windows Installer uses to determine which boot scheme to use."** – MikeyB Sep 20 '11 at 20:04
  • @JdeBP +1 to you for a wonderful answer. – Weaver Sep 21 '11 at 22:58
3

One simple method would be to simply perform a base install of Windows on a machine that doesn't support EFI, capture it with your image software and restore it to the real hardware.

A good choice might be to build your base install in a VM. In earlier versions (ver < 6) of Windows didn't adapt well to be moved from one type of hardware to another. With recent versions Windows as long as the storage controller is supported on the image Windows will do a pretty good job at adapting to the new hardware.

The Windows install (ver >=6) disk basically usually include a wim file which is basically just an image of the operating system.

Zoredache
  • 128,755
  • 40
  • 271
  • 413
  • That's exactly what I was going to suggest. Run the Windows setup on another (BIOS/MBR) system, then move the disk or its image to the destination server. *If* it boots, then PnP will ensue and it will happily run on the different hardware. – Massimo Sep 15 '11 at 05:48