Need lesson understanding UEFI & legacy BIOS modes

Topic

New Reply

I could use some help with how different Mother Board settings effect Windows 10 Refresh, Re-Installs, and Feature updates.

My ASUS ROG Z370-E Mother Board is UEFI with CSM (compatibility mode enabled).  Windows is installed in UEFI mode and the 2 hard drives (not SSD’s) are GPT (vs MBR) with NTFS.

>How is Windows 10 installed in UEFI mode vs legacy BIOS mode to begin with (eg: what settings tell the Windows installer which to install?)

>Once Windows 10 is installed in UEFI mode, will all future Refresh, Re-Installs, etc be UEFI automatically?

>Will Feature Updates installed via Windows 10 Updater be UEFI automatically?

>If a Feature Update is created via Windows 10 Media Creation Tool (MCT), will it install as UEFI automatically via USB?  via a CD created from a MCT .iso?  via a USB created by Rufus from a MCT .iso? – what Rufus settings are used?

>For informational purposes, how would I create a legacy BIOS Windows 10 installation if I ever needed or wanted to?  Would disks have to also be MBR?

Thanks to all who respond.

Windows 10 Pro x64 v22H2 and Windows 7 Pro SP1 x64 (RIP)

Reply | Quote

Replies

Boot to UEFI Mode or legacy BIOS Mode

Windows and GPT FAQ

Boot and UEFI

How to Check if Windows 10 is using UEFI or Legacy BIOS

 

Windows 10 Pro 22H2

1 user thanked author for this post.

Tex265

Reply | Quote

(Note: FWIW, Legacy and MBR have morphed into somewhat murky definitions, so being literally accurate is an exercise in futility. Back when there was only one way of doing things it didn’t need a formal name, but nowadays the terms have been used back and forth to mean boot methods and/or partition table schemes. Since what you want to know is how things work, I’ll use the terms loosely so take that into account.)

GPT vs. Legacy/MBR are two differing styles of indexing the partitions on a disk. UEFI vs. BIOS (sometimes also referred to as Legacy/MBR) are differing methodologies of booting the OS, whatever OS that may be.

When booting a Legacy/MBR disk, the BIOS begins the boot process by loading and executing code in the first sector (the “Master Boot Record”) of the hard disk. The MBR determines which partition to boot, and passes boot control to that partition. From there, the BCD/boot code takes over and boots the OS (which may be on the same or a different partition).

When booting a GPT disk, the UEFI BIOS begins the boot process by passing control to a special EFI partition on the GPT disk, and the EFI partition determines which partition to boot. No MBR code is involved.

Note that once Windows is installed, however, it doesn’t actually care where it is and how you got there, and for its own internal operations it merely uses the disk identifier (Disk ID or GUID) and the starting sector location of the OS partition, regardless of whether that be GPT, MBR Primary, or MBR Extended. (You’ll find that recorded in the [HKLM/System/MountedDevices] registry key.)

A couple points to note:

GPT and Legacy/MBR are differing styles of partition tables, not differing styles of partitions. Many people seem to assume the partitions are also different, but they are not. Partitions created under either are of the same, identical structure.

Booting an OS from a Legacy/MBR disk requires BIOS/CSM/Legacy/MBR firmware on the motherboard. Booting from a GPT disk requires UEFI firmware.

Okay, you probably already knew that much, but I’ve reiterated it to summarize the relevant points as a backdrop to the following.

Windows 10 can be installed in either UEFI or MBR mode. If you start with a blank, unpartitioned disk and UEFI installation media, the Windows installer will automatically initialize the disk as GPT and continue installing in UEFI mode. In contrast, you can initialize the disk yourself as Legacy/MBR, pre-create your partitions, boot the installation media in BIOS mode, and the Win10 installer will install the OS in MBR mode. In short, if you give it an existing framework, it will use what you give it.

(Aside: you can even clone or image/restore the Win10 OS partition from GPT to MBR or vice-versa, because remember, the partitions are identical either way. But because the boot methodology to get to the OS via GPT vs. MBR are different, the cloned/restored partition may need to have its boot files “repaired” to be compatible with the target disk’s partitioning scheme.)

As for Rufus, it can create media that can boot in either BIOS or UEFI mode, depending on how you have your BIOS configured.

As for any future updates, including feature updates, they replace the OS itself, not the boot method. The UEFI/GPT vs. BIOS/MBR stays the same. It isn’t even material to Win10 (because remember, Windows only references the disk identifier and starting sector location), so the updater isn’t going to trash your partitions.

Besides, it would be foolish for the installer to try, because it would be difficult or impossible for it to know whether the computer’s BIOS supports one, the other, or both modes. Imagine the havoc if it were to trash the partitions on a working MBR system in an effort to reinstall as UEFI, only to find it’s an older non-UEFI compliant computer.

And finally, converting a disk between MBR and UEFI is no trivial task. Do it wrong and you can lose everything. Some of the better cloning/imaging utilities can do it, but I don’t think that’s within Microsoft’s repertoire. Heck, after more than a decade they still can’t even fix diskpart/Disk Management to achieve the same functionality as most third-party partition management tools–that you can get for free these days.

 

3 users thanked author for this post.

Tex265, doriel, JohnW

Reply | Quote

dg1261 wrote:

Booting an OS from a Legacy/MBR disk requires BIOS/CSM/Legacy/MBR firmware on the motherboard. Booting from a GPT disk requires UEFI firmware.

Well… actually, no. That only holds for Windows.

It is possible to load *an* OS from a MBR disk using UEFI, and similarly *an* OS from a GPT disk using BIOS… as long as you aren’t committed to a specific OS beforehand.

Linux and for example FreeBSD are somewhat more flexible than Windows in this regard, and differently from each other too. (The BSDs have traditionally had a somewhat different approach to partitioning…)

And other operating systems might have other requirements still.

dg1261 wrote:

As for any future updates, including feature updates, they replace the OS itself, not the boot method. The UEFI/GPT vs. BIOS/MBR stays the same. It isn’t even material to Win10 (because remember, Windows only references the disk identifier and starting sector location), so the updater isn’t going to trash your partitions.

Besides, it would be foolish for the installer to try, because it would be difficult or impossible for it to know whether the computer’s BIOS supports one, the other, or both modes. Imagine the havoc if it were to trash the partitions on a working MBR system in an effort to reinstall as UEFI, only to find it’s an older non-UEFI compliant computer.

Well a FreeBSD update once changed on-disk state from UEFI (if you were using that) to BIOS, and to be able to boot you just had to flip the firmware to BIOS mode too. If you had one of those UEFI-only systems it was more complicated to recover, yes…

dg1261 wrote:

And finally, converting a disk between MBR and UEFI is no trivial task. Do it wrong and you can lose everything. Some of the better cloning/imaging utilities can do it, but I don’t think that’s within Microsoft’s repertoire. Heck, after more than a decade they still can’t even fix diskpart/Disk Management to achieve the same functionality as most third-party partition management tools–that you can get for free these days.

There is actually even a way to produce a hybrid disk that is both, within some constraints. These are often seen with Linux, especially the distro installers …

It’s just, this is far from trivial to make for a general purpose system.

1 user thanked author for this post.

Ascaris

Reply | Quote

mn– wrote:

There is actually even a way to produce a hybrid disk that is both, within some constraints. These are often seen with Linux, especially the distro installers …

This is the typical mode for bootable USB drives for maximum flexibility on various systems.  One notable exception is the Ultimate Boot CD .iso, which makes it unusable on my Acer Swift laptop, as it is not possible to enable legacy BIOS mode.  All of the others, like Linux installers, Windows installers, and rescue drives for backup programs, have worked with both types of boot when created with either the Linux Mint bootable USB utility or the GNOME disks utility, both of which are simple tools that only two options: Which .iso, and which USB drive.

By default, the popular Rufus program, my standard go-to in Windows and a great tool despite this one misgiving I’m about to describe, won’t create the “boots on anything” USB drive.  This was an intentional choice by the Rufus dev.  He posits that if you create the USB drive specifically for the computer you’re intending it to be booted on, with the boot type you wish to use on that PC, you won’t accidentally boot it in the wrong mode and end up with a Windows or Linux installation that isn’t the way you wanted.  I think that’s kind of silly– if you understand the difference between the boot modes at the time you’re making the USB drive, you obviously understand the difference at the time the PC boots too.

Most PCs can be in one mode or another, legacy or UEFI, and if you want the Windows or Linux installation to use UEFI, you’re probably already configured to boot UEFI, so that’s the only thing you could boot without changing settings anyway.  The same applies to a BIOS system or one in legacy mode– if that’s the only kind of boot your PC can do, then you won’t be able to accidentally boot in the wrong mode.

Then there’s the odd one like my Asus P8P67 Deluxe motherboard, which allows a UEFI or BIOS boot to be selected from the boot override screen.  On dual-mode USB drives, there are two options for the drive… one that says UEFI and one that has no designation, which is the legacy option.  It can perform a UEFI or legacy boot from that menu without having to have an option for legacy or UEFI mode.  It doesn’t pick a boot mode until it knows which boot option you want to use.

Even on this type of system, you can get messed up with the default options in Rufus, even though this is the exact thing the inflexible default options are supposed to prevent.  If you wrote the bootable USB drive in the wrong mode, perhaps because you didn’t understand that it doesn’t write “boots on everything” images as you might expect, the user may not immediately notice that there is no UEFI: NAME-OF-DRIVE option and select the only option that’s there, thus performing a legacy boot, which is just the nature of how humans work.  (Ask me how I found out about this possible chain of events!)

IMO, there is no reasonable reason not to provide “boots on everything” mode by default, which is why this is the norm for just about everything USB if installed with default options.  The very same Windows .iso that creates a “boots on everything” USB drive when written from a simple Linux USB writer will not when written with Rufus… unless you select the secret option, which requires the user to enable it with ALT-E.  A graphical program that has no hint that such an option exists, nor a way to enable it in the options (you have to read the FAQ to learn about it), is just weird and feels almost vindictive to me.

I don’t know about anyone else, but when I am writing an .iso image to a drive, I’m not creating it specifically for the task at hand.  I’m creating a drive that I will continue to use, perhaps on other devices, as long as it is useful.  I’d want it to work on my BIOS laptop as much as on my UEFI PCs!

That quirk aside, Rufus is still a great tool.

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

2 users thanked author for this post.

Elly, doriel

Reply | Quote

Thank you very much, this was exactly that resume, that I needed. Now I feel like I know what am I doing again

Dont get me wrong, every computer I installed in our company works, but my experience was just empirical = I created Rufus bootable devices many, many, many times, until I realized that there must be equality in BIOS/UEFI settings and Rufus settings. Few dreamless nights happenned. Now you tell me there is an ALT-E shortcut? good lord, this is hidden gem. Why is the best function hidden?

I use Acronis true Image for deploying Windows including SW, but M$ is doing enverything they can to make it harder. Every half year I need to create new image for upcomming computers.

Maybe if you can tell us, whis is better/faster? MBR or GPT? Does it somehow affect speed of booting for example? I read somewhere, that GPT can significantly improve PC performance. Hoax or truth?

Dell Latitude 3420, Intel Core i7 @ 2.8 GHz, 16GB RAM, W10 22H2 Enterprise

HAL3000, AMD Athlon 200GE @ 3,4 GHz, 8GB RAM, Fedora 29

PRUSA i3 MK3S+

Reply | Quote

doriel wrote:

Maybe if you can tell us, whis is better/faster? MBR or GPT? Does it somehow affect speed of booting for example? I read somewhere, that GPT can significantly improve PC performance. Hoax or truth?

Hm, better… Detached from any context… MBR is probably better under the old 504 MByte limit, GPT just uses too much space there. Conversely MBR is noticeably quite bad at 2 TBytes to 16 TBytes, and worse from then on.

Then again in a context where the operating system may be relevant, MBR is a lot worse past 2 TBytes already. As in, common cases of “won’t run at all”.

I suppose there’s a theoretical advantage for MBR during boot. GPT needs to read a couple of blocks more from the disk … comes down to minimal fractions of a second with modern hardware, once per bootup (and disk rescan if hotplugging).

During normal runtime there should not be any performance difference at all.

During maintenance operations… well, that’s a workflow question. Depends on specifics.

Most of the actual differences come from software/firmware-connected dependencies of the yes/no kind rather than quantitative differences. Like how you can’t do Thunderbolt interface security without UEFI-mode firmware, which requires GPT… assuming the usual Thunderbolt-equipped hardware and MS Windows.

1 user thanked author for this post.

doriel

Reply | Quote

Yes, datached from any context, sory for that. It was too general question I suppose.

But I do not know much about it. I just wanted to know “the right way” to install the OS. Maybe it depends on system we chose. I thought you will write something like:

“Do not use MBR with BIOS, it is 25 years old and it lacks performance. Please use GPT on UEFI – this setup can get optimum throughput of your data, if you are using PCIe SSD from Samsung.”

Sorry for my amateurish approach

Dell Latitude 3420, Intel Core i7 @ 2.8 GHz, 16GB RAM, W10 22H2 Enterprise

HAL3000, AMD Athlon 200GE @ 3,4 GHz, 8GB RAM, Fedora 29

PRUSA i3 MK3S+

Reply | Quote

Thanks to all who have responded. In reading the responses I learned quite a bit, but unfortunately a lot of this discussion is way above my pay grade!

Could I impose again to perhaps answer my specific questions in more simple terms?  And thanks to reading these responses – several more questions?

Much appreciated to all!

>How is Windows 10 installed in UEFI mode vs legacy BIOS mode to begin with (eg: what settings tell the Windows installer which to install?)

>Once Windows 10 is installed in UEFI mode, will all future Refresh, Re-Installs, etc be UEFI automatically?

>Will Feature Updates installed via Windows 10 Updater be UEFI automatically?

>If a Feature Update is created via Windows 10 Media Creation Tool (MCT), will it install as UEFI automatically via the USB stick?  via a CD created from a MCT .iso?  via a USB stick created by Rufus from a MCT .iso? – what Rufus settings are used?

>For informational purposes, how would I create a legacy BIOS Windows 10 installation if I ever needed or wanted to?  Would disks have to also be MBR?

>>I utilize the built in Windows Backup program to make image backups.  Are they automatically in UEFI/GPT form for recovery?

>>What effect does setting the UEFI to allow CMS have on Windows installs, updates, backups, etc?  If CMS is not allowed, I can’t access my USB devices (thumb drive, portable hard drive, or CD) as alternate boot drives at startup.  Does this risk unintentionally performing a legacy Bios install of an update or Feature update?

>>What about UEFI using GPT and different USB drive disk formats?  I read somewhere that USB drives are MBR and Fat32? USB thumb drives are used with the Windows Media Creation tool to restore of Feature upgrade – why does this mis-match work?

Windows 10 Pro x64 v22H2 and Windows 7 Pro SP1 x64 (RIP)

Reply | Quote

Tex265 wrote:

>How is Windows 10 installed in UEFI mode vs legacy BIOS mode to begin with (eg: what settings tell the Windows installer which to install?)

The installer checks what mode the system is running in, and install to that.

Tex265 wrote:

>Once Windows 10 is installed in UEFI mode, will all future Refresh, Re-Installs, etc be UEFI automatically?

Tex265 wrote:

>Will Feature Updates installed via Windows 10 Updater be UEFI automatically?

Well yes, unless Microsoft botches things as badly as a competitor did once.

As in the open-source FreeBSD project (you know, the actually older free-and-open-source operating system that just happened to be in legal trouble and not distributable at a time when Linus Torvalds decided he wanted one too) once issued an update that converted the on-disk install from UEFI to BIOS mode, causing systems to become unbootable until that setting got flipped to match in the system boot settings, or installation was repaired back to UEFI via external boot method.

Tex265 wrote:

>For informational purposes, how would I create a legacy BIOS Windows 10 installation if I ever needed or wanted to? Would disks have to also be MBR?

Yes, Windows requires at least the boot disk to be MBR for booting in legacy BIOS mode. As in, set the system to legacy-only mode and install Windows, it’ll install to MBR disks and be legacy mode.

Tex265 wrote:

>>What effect does setting the UEFI to allow CMS have on Windows installs, updates, backups, etc? If CMS is not allowed, I can’t access my USB devices (thumb drive, portable hard drive, or CD) as alternate boot drives at startup. Does this risk unintentionally performing a legacy Bios install of an update or Feature update?

Do you mean CSM? CSM is the thing that allows legacy-mode access to devices that don’t have UEFI support… so yeah, you definitely need that if your USB and whatever controllers don’t support UEFI directly.

And yes, it does come with all kinds of risks depending on what hardware and firmware you’re running. This is the hard part

With CSM, you’ll potentially be giving “legacy” devices direct access to system memory in many cases. There have been proof-of-concept attacks using the USB PS/2 compatibility feature for example… and direct memory bus internal access from an external connector in case of Thunderbolt, worst case full takeover. Theoretically assuming attacker has infinite resources and assuming you’re on standard PC hardware without extra firmware hardening.

Tex265 wrote:

>>What about UEFI using GPT and different USB drive disk formats? I read somewhere that USB drives are MBR and Fat32? USB thumb drives are used with the Windows Media Creation tool to restore of Feature upgrade – why does this mis-match work?

USB drives can be anything just as well as any other disk. And hybrid devices are technically possible, just having been decided to not be worth the trouble and complexity for general use.

1 user thanked author for this post.

Tex265

Reply | Quote

mn- thanks very much!
If I may impose on you to answer the several remaining questions?

>If a Feature Update is created via the Windows 10 Media Creation Tool (MCT), will it install as UEFI automatically via the USB stick? via a CD created from a MCT .iso? via a USB stick created by Rufus from a MCT .iso? – what Rufus settings are used?

>>I utilize the built in Windows Backup program to make image backups. Are they automatically in UEFI/GPT form for recovery?

>How is Windows 10 installed in UEFI mode vs legacy BIOS mode to begin with (eg: what settings tell the Windows installer which to install?)

mn- answered
The installer checks what mode the system is running in, and install to that.

The “mode” is set from within the Motherboard – correct? And selecting EUFI with CSM is still EUFI – correct? Or does CSM need to be turned off for Windows installation purposes?

Windows 10 Pro x64 v22H2 and Windows 7 Pro SP1 x64 (RIP)

Reply | Quote

Tex265 wrote:

mn- thanks very much!
If I may impose on you to answer the several remaining questions?

Well I was hoping someone with more experience with the specific products would’ve helped…

Tex265 wrote:

>If a Feature Update is created via the Windows 10 Media Creation Tool (MCT), will it install as UEFI automatically via the USB stick? via a CD created from a MCT .iso? via a USB stick created by Rufus from a MCT .iso? – what Rufus settings are used?
>>I utilize the built in Windows Backup program to make image backups. Are they automatically in UEFI/GPT form for recovery?

The MCT .iso should by default be a hybrid and works as a normal installer even when written to disk.

Making USB from that… well depends on how you do that part.

Haven’t used Rufus or the Windows image backups myself. I’d expect the Windows image backups to use the Windows installer boot system.

Tex265 wrote:

The “mode” is set from within the Motherboard – correct? And selecting EUFI with CSM is still EUFI – correct? Or does CSM need to be turned off for Windows installation purposes?

Yes, motherboard, or firmware interface wherever you have it.

Well you might need CSM to have a keyboard and mouse… or a display adapter… or any number of other things, if you happen to be on oldish hardware.

It’s still supposed to be UEFI but you may have problems if your disks are accessed through something that doesn’t know about UEFI. For old hardware on the boot path, it’s more straightforward to use legacy mode…

(Haven’t had much time to play around and experiment with my old parallel-SCSI parts… I have a bunch of those, should probably find a newer optical disk torture test again to see if something less ancient is better at reading badly scratched disks than the old SCSI Plextor…)

Reply | Quote