OSDev.org

Hi,

Just for the fun I was trying to make a "dual boot" with Windows and my UEFI OS Loaders (Which for now is more or less just an UEFI application).

However I was trying to just place my compiled .EFI file in the EFI partition on the preinstalled Windows system.
I assigned a drive letter to what I expect to be the EFI partition on the system. However no "EFI" directory was present there?

I created the folder and placed my binary file under a sub directory like the UEFI specification says.
(Of course) That didn't made any difference when I rebooted my file was not discovered by UEFI.

Then I found out that Windows has a "bcdedit" cmd tool which can edit these boot records. I tried to add a entry for my loader.
It succeeded to create the entry, and I can select it from the Windows bootmanager. However it fails to execute my file.
By googling a little a tool easyUEFI popped up. But is couldn't even figure out a EFI partition on my disk hence it could not find the records.
That lead me to the conclusion that was I strongly think is the EFI partition is formatted with NTFS?? and not FATx which the specification says?

I don't know if anyone find this interesting, but does anyone have some information about this? Does windows not follow the specification?

Just to set the frame I not particular fan of UEFI, but I have invested some time the last couple of weeks to get to know it better, such that I can have I valid opinion.
I'm special not fan of Windows and I use it only in rare situations,
like in this situation where I coincidentally had a test computer with Windows preinstalled and I thought to get a little fun before formatting it.

Edit:
A bonus question from me:
The directory structure that the UEFI specification says, I guess that this does not mean that it will auto detect the boot options?
I guess that this has to be configured in the UEFI NVRAM or?

Rhodez wrote:That lead me to the conclusion that was I strongly think is the EFI partition is formatted with NTFS?? and not FATx which the specification says?

Let's start at the beginning: Does your disk have a GPT or an MBR? Is an EFI system partition present in your partition table? (You should be able to tell using diskmgr.msc) And what file system does it have? Windows will tell you in the drive properties.

Once you have that, what is the structure of that file system? I mean, what directories and files are actually present? Maybe then you can find out how those files relate to what is in NVRAM, and then you can figure out why your loader doesn't run.

Rhodez wrote:The directory structure that the UEFI specification says, I guess that this does not mean that it will auto detect the boot options?

There is one name that UEFI must recognize, depending on architecture. And at least one buggy UEFI implementation in use on Acer laptops, that completely disregards NVRAM and only boots the Windows boot loader and the default boot loader for x86_64. I know, because I used to have one, and I had to install GRUB with the default name (was it BOOTX64.EFI?) before the laptop would recognize it. So that's an option, too. Like Brendan used to say: Working firmwares are like a unicorn: You can't prove they don't exist, but every time someone says they found one, it will turn out to just be a horse.

nullplan wrote:Let's start at the beginning: Does your disk have a GPT or an MBR? Is an EFI system partition present in your partition table? (You should be able to tell using diskmgr.msc) And what file system does it have? Windows will tell you in the drive properties.

The information I gave was from the diskmgr.msc, however i did assume that it was GPT but it seems to be MBR (It it what it says when a click at propeties). I didn't know that MBR would work with UEFI?
Since the disk is a NVMe it must mean that is boots with UEFI?

Maybe I should boot a live Linux USB and investigate with some tools that I know better. hehe.

But if I understand correct the MBR should then just contain a partition with an EFI system partition? right?
My disk has three partitions. The main C:, a recovery, and then partition 0 which very much fits in size to an EFI partition. However diskmgr.msc just says it is NTFS?

nullplan wrote:

Rhodez wrote:The directory structure that the UEFI specification says, I guess that this does not mean that it will auto detect the boot options?

There is one name that UEFI must recognize, depending on architecture. And at least one buggy UEFI implementation in use on Acer laptops, that completely disregards NVRAM and only boots the Windows boot loader and the default boot loader for x86_64. I know, because I used to have one, and I had to install GRUB with the default name (was it BOOTX64.EFI?) before the laptop would recognize it. So that's an option, too. Like Brendan used to say: Working firmwares are like a unicorn: You can't prove they don't exist, but every time someone says they found one, it will turn out to just be a horse.

I like the Brendan quote

I could try to just rename it to BOOTX64.EFI and see if that would have an effect.

The partition has a \boot directory where there is directories with a lots of languages - da-DK, en-GB ect. Inside the directory there is a bootmgr.exe.mui.

But if we assume a unicorn like firmware, it would be up to the NVRAM to hold the boot records for all other OS loaders than the default BOOTX64.EFI?

Rhodez wrote:Since the disk is a NVMe it must mean that is boots with UEFI?

What does one have to do with the other? NVMe is merely a storage technology. And all storage devices (with the possible exception of SD cards) don't care one jot or tittle about what is stored on them. No, MBR partition tables have the problem that they are limited to - I don't remember exactly, was it 2TB or 4TB? And in theory a legacy BIOS implementation of NVMe could exist. So no, NVMe does not automatically mean UEFI. Or at least I don't know that it would.

However, MBR can work with UEFI, of course. Needs a system partition, which is signalled with partition type 0xEF (or was it 0xEE? Have to look this up later).

Rhodez wrote:But if I understand correct the MBR should then just contain a partition with an EFI system partition? right?

Not really. If the disk is really using an MBR partition table, then it should contain all partitions that are defined. But the system partition should be one of them. Actually, it should be the first one, but I'd need to read the UEFI spec for details.

Rhodez wrote:My disk has three partitions. The main C:, a recovery, and then partition 0 which very much fits in size to an EFI partition. However diskmgr.msc just says it is NTFS?

Well, if it is NTFS then either you have a nonstandard UEFI implementation or that isn't the partition you are looking for. Considering the contents are also not what you expect, i suspect the latter. That is also supported by this:

Rhodez wrote:The partition has a \boot directory where there is directories with a lots of languages - da-DK, en-GB ect. Inside the directory there is a bootmgr.exe.mui.

This seems to be some Windows boot partition, not a UEFI system partiton. Maybe part of the recovery system.

Does the system have a BGRT? That is a specific ACPI table, that contains an image that operating systems can display while the system is loading. If it is present you get a logo of the mainboard manufacturer displayed on screen while Windows is loading. And to my knowledge that table is specific to UEFI systems. Well, I suggest you boot a Linux Live system on it and have a look with it.

nullplan wrote:

Rhodez wrote:Since the disk is a NVMe it must mean that is boots with UEFI?

What does one have to do with the other? NVMe is merely a storage technology. And all storage devices (with the possible exception of SD cards) don't care one jot or tittle about what is stored on them. No, MBR partition tables have the problem that they are limited to - I don't remember exactly, was it 2TB or 4TB? And in theory a legacy BIOS implementation of NVMe could exist. So no, NVMe does not automatically mean UEFI. Or at least I don't know that it would.

Of course it is possible that a BIOS could contain a NVMe driver, but I'm pretty much sure that isn't the case. By this Intel document about booting from a nvme disc https://www.intel.com/content/dam/suppo ... Rev1-1.pdf page 7 it is stated that
"In order to support the required UEFI NVMe driver, your system’s firmware must be based on UEFI 2.3.1 or later."

The only case I know about with nvme boot outside UEFI is purism with coreboot
(https://puri.sm/posts/adventures-with-c ... s-storage/)

nullplan wrote: However, MBR can work with UEFI, of course. Needs a system partition, which is signalled with partition type 0xEF (or was it 0xEE? Have to look this up later).

Rhodez wrote:But if I understand correct the MBR should then just contain a partition with an EFI system partition? right?

Not really. If the disk is really using an MBR partition table, then it should contain all partitions that are defined. But the system partition should be one of them. Actually, it should be the first one, but I'd need to read the UEFI spec for details.

It was what i meant, that a (probably the first) partition should be a EFI system partition, sorry for not be specific enough.

nullplan wrote:Does the system have a BGRT? That is a specific ACPI table, that contains an image that operating systems can display while the system is loading. If it is present you get a logo of the mainboard manufacturer displayed on screen while Windows is loading. And to my knowledge that table is specific to UEFI systems. Well, I suggest you boot a Linux Live system on it and have a look with it.

I think I will boot with a Linux system, just to get some non-Windowsified information. hehe.

The structure of the partition does neither say UEFI to me, why I'm also asking.
I'll see if I come up with something more interesting information when I have tried to investigate with Linux.

Oh well.... ....

So Linux told the same as I/we already knew.

Then I just got the idea to set the firmware to ONLY boot with UEFI, and Windows could not load.
Changed back to legacy boot first, and Windows booted again. I guess that this answers the question.

I just had the understanding that Windows on new systems always would install itself to use UEFI,
and also that legacy BIOS would not recognize nvme discs, but I get the feeling that I'm wrong about this.

Rhodez wrote:I just had the understanding that Windows on new systems always would install itself to use UEFI,

Only if you boot the installer with UEFI. If you boot the installer with the CSM, it will install itself to use the CSM.

Rhodez wrote:and also that legacy BIOS would not recognize nvme discs,

Legacy BIOS can recognize anything with the right option ROMs. It probably has one built in, although some NVMe disks include their own legacy option ROMs as well.

Octocontrabass wrote:

Rhodez wrote:and also that legacy BIOS would not recognize nvme discs,

Legacy BIOS can recognize anything with the right option ROMs. It probably has one built in, although some NVMe disks include their own legacy option ROMs as well.

Affirmative.

I have one question left though. When I bought my first computer with a nvme disk and I was installing Linux, i could not select a partition as bootable, formatted as MBR, with "cfdisk".
Back then I settled with the answer "it's a nvme you must use GPT and UEFI", so that's what I did.

So why would cfdisk not allow to let a partition be bootable? I do not expect someone to know.
Now I have a test computer with a nvme disk and I will definitely do some testing with legacy BIOS boot on the nvme.

Rhodez wrote:So why would cfdisk not allow to let a partition be bootable?

Only primary partitions may be marked bootable. Maybe you were using a logical partition?

I'm not aware of any such limitations in cfdisk, but some component of the installer should complain if you boot the installer in UEFI mode and try to install a legacy BIOS bootloader.

Octocontrabass wrote:

Rhodez wrote:So why would cfdisk not allow to let a partition be bootable?

Only primary partitions may be marked bootable. Maybe you were using a logical partition?

I'm not aware of any such limitations in cfdisk, but some component of the installer should complain if you boot the installer in UEFI mode and try to install a legacy BIOS bootloader.

That's maybe the case. It is a couple of years ago, so I don't know if the installer was booted in UEFI, but that could be true.