Uefi Mode

0 views

Skip to first unread message

Adrienne Borgman

unread,

Aug 3, 2024, 1:51:32 PM8/3/24

to nyafearopna

In general, install Windows using the newer UEFI mode, as it includes more security features than the legacy BIOS mode. If you're booting from a network that only supports BIOS, you'll need to boot to legacy BIOS mode.

You might see separate commands for the same device. For example, you might see UEFI USB Drive and BIOS USB Drive. Each command uses the same device and media, but boots the PC in a different firmware mode.

Some devices only support one mode (either UEFI or BIOS). Other devices will only allow you to boot to BIOS mode by manually disabling the UEFI security features. To disable the security features, go to Security > Secure Boot and disable the feature.

Some older PCs (Windows 7-era or earlier) support UEFI, but require you to browse to the boot file. From the firmware menus, look for the option: "Boot from file", then browse to \EFI\BOOT\BOOTX64.EFI on Windows PE or Windows Setup media.

If you want to ensure that your drive boots into a certain mode, use drives that you've preformatted with the GPT file format for UEFI mode, or the MBR file format for BIOS mode. When the installation starts, if the PC is booted to the wrong mode, Windows installation will fail. To fix this, restart the PC in the correct firmware mode.

If you want a PC to only boot into a certain mode, you can remove the files that Windows PE or Windows Setup use to boot in UEFI or BIOS mode. Remove the following files, depending on the mode you want to boot to.

1. The server, even when set into UEFI in the BIOS, just doesn't want to UEFI boot from the Server Install DVD. I'm using a standard dvd-rom connected via SATA to the motherboard set to AHCI. I've tried RAID mode as well with similar results. Even what I manually select the boot device from the boot menu, UEFI isn't an option. I'm probably missing some step, configuration, or some nerd knob somewhere that needs turning. I'm sure someone has made this work at some point, can y'all clue me in on what configuration I need to be looking at? Or at least point me in the right direction please.

2. Backup & Restore - This is more a Windows question but it falls in line with the first one. In Windows Server 2016, does the backup and restore support UEFI, GPT, and large 4TB - 36TB RAID arrays? I've faced issues with 2008 & 2012 with disk/volume size limitations but haven't been working with 2016 enough to know what limitations are still in place. I've seen issues with Windows 10, UEFI, GPT, and Image Restorations failing. I'm curious with Server 2016 is plagued with the same problems and how y'all are dealing with them.

Thank you for your time and help. I'm reviewing these documents to work through them here shortly. I have previously updated both the bios and firmware but the GPT guide seems to have the missing steps that I wasn't getting. I'm going to work with it some more and try again.

I have worked through this process and have successfully UEFI booted and install Server 2016. I knew I was missing a step somewhere and that turned out to be having to go back into the BIOS and working through the Mass Storage Controller Config

Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

I currently have Windows 10 installed in UEFI mode and am trying to do a dual boot with Arch. I have created an installation media using Rufus. When I go to my BIOS to select the which drive to boot from, my installation media is listed twice, once with UEFI in front and one without. When I select the one with UEFI, Windows 10 is loaded instead. When I select the one without UEFI, I am able to boot into the live environment but it is not in UEFI mode. To dual boot, Windows 10 and Arch, do they need to use the same boot mode? After reading the wiki it seems that that is the case. If so, why am I unable to load Arch in UEFI mode?

I have three partitions on the primary drive in my computer. The drive is formatted to GPT and the three partitions are one ESP (EFI System Partition) and two Primary (Windows 10/Windows 7 each one). There are three options for "Boot Mode" in the motherboard settings, "Legacy", "UEFI" and "UEFI with CSM".

If it's set to "Legacy", the computer tells me "No operating system found". That's correct. If it's set to "UEFI with CSM", both Windows boots normally. If it's set to "UEFI", then only Windows 10 can boot. From the safe boot log I can see Windows 7 gets stuck at classpnp.sys.

I plugged in another drive in MBR, containint two partitions. One primary active with FAT32 and another primary with NTFS, with another Windows 7 installed. It seems I however just can't make it boot if the MB settings is set to either "UEFI" or "UEFI with CSM", but it boots perfectly when set to "Legacy". If I edit the BCD in the EFI partition on the primary disk to add an entry for this experimental Windows 7 installation, it boots under "UEFI with CSM", but still gets stuck at classpnp.sys in "UEFI".

I have another computer with a MSI B85 motherboard that has a switch named "CSM". If it's enabled then there are two options available in "Boot Mode", "UEFI" and "Legacy". If it's disabled then Boot Mode is locked to UEFI. In that case "UEFI" mode with CSM enabled allows Windows 7 to boot, but it won't boot with CSM disabled.

"UEFI with CSM" usually means mixed mode in which both native (UEFI) and CSM-based (BIOS) boot is available. The boot menu will show a mix of native UEFI boot entries and CSM "bootable disk" entries in this case.

However, one important side effect of disabling CSM is that it'll allow certain UEFI-only features to be activated (such as "fast boot"), at the same time preventing some BIOS-only features (such as PCI option ROM support).

As you've noticed, the Compatibility Support Module can be required by the operating system for UEFI boot, not just legacy boot. This is the case for Windows 7. There are in fact name-brand computers that even lack a CSM and cannot boot Windows 7 at all.

I've also noticed having it enabled/disabled can have other effects, like changing which monitor (in a multi-monitor system) or screen resolution is used during boot. It is also, in my experience, required to turn it off to do UEFI network boot. Otherwise, only the legacy network boot firmware is accessible, which cannot boot an operating system in UEFI mode.

People really make a mess out of what is still always just a UEFI protocol/driver (the word "BIOS" being used simultaneously as a shorthand for "firmware type", "OpROM technology" and "MBR boot" doesn't help though).

With this said, I wouldn't know about your laptop but if it's aged similarly to your 2013 LGA 1150 motherboard, then it might have been carrying an equally as old firmware like Aptio 4 (which was itself coming from an era of transition). In turn that could contain some leftover from the time when UEFI firmware was forced to boot BIOS-like-only.

Hence the tri-state toggle (each setting very broadly corresponding to an UEFI class) despite the fact that it doesn't really make sense to add a choice that is a strict subset of the capabilities of CSM proper. I.e. again, the thing cannot exist without or outside of UEFI (check the whitepaper I mention in the first link for more details).

But for some reason your OEM decided to re-frame its logic to have cut and dried "separate" boot tracks, even though the thing is not technically "exclusive" to any (well, on linux that is at least.. Windows is a little can of worms). Maybe they wanted to avoid as much as possible users unwittingly booting the old fashioned way? Or perhaps they wrote the setup menu code with the bare minimum of extra services to support W7 in mind, for those systems sold close to the W8 release date and dreaming of an expedite upgrade path?

Because that's the other factor that you are missing out: W7 isn't going to boot (out of the box at least) in a pure UEFI environment. It's either a full legacy installation, or an UEFI one tied to CSM (mostly for video output purposes, it's funny that your third point was already pretty close to the hacks to mix up partition schemes). Oh, and alas classpnp.sys usually means next to nothing.

So.. long story short, from what you are telling here, "UEFI with CSM" is therefore simply CSM except it has been made just an aid for native UEFI-aware OSs rather than the normal "full suite" of BIOS emulation (unclear if just out of dropping the MBR parsing, because of only accepting UEFI executables, or due to gutting all the extra code after "setting up BIOS interrupt calls and the legacy VBIOS").

In a sense it does exactly what it's written on the tin, but in another it's a pretty specious moniker too (also, please, your desktop has the option named LEGACY+UEFI which would have spelt it already clear).

BIOS boots by reading the first sector on a hard disk and executing it; this boot sector in turn locates and runs additional code. The BIOS system is very limiting because of space constraints and because BIOS runs 16-bit code, whereas modern computers use 32-bit or 64-bit CPUs. By contrast, EFI (or UEFI, which is just EFI 2.x) boots by loading EFI program files (with .efi filename extensions) from a partition on the hard disk, known as the EFI System Partition (ESP). These EFI boot loader programs can take advantage of EFI boot services for things like reading files from the hard disk.

As a practical matter, if you're using an OS like Linux that has complex BIOS-mode boot loaders, EFI-mode booting is likely to be similar to BIOS-mode booting, since GRUB 2 (the most popular BIOS-mode boot loader for Linux) has been ported to work under EFI, and many Linux distributions install GRUB 2 by default on EFI systems. OTOH, you can replace or supplement GRUB 2 with other EFI boot loaders. Indeed, the Linux kernel itself can be an EFI boot loader; code was added to do this with the 3.3.0 kernel. Used in this way, the EFI itself loads and runs the Linux kernel, or you can use a third-party boot manager like rEFInd or gummiboot to let you select which OS or kernel to boot.