Contribute
Register

Resetting the NVRAM changes Boot Order in BIOS

Status
Not open for further replies.
Joined
Aug 17, 2010
Messages
175
Motherboard
Z390 Aorus Elite-CF
CPU
i7-8700K
Graphics
RX 580
Mac
  1. iMac
Mobile Phone
  1. Android
So, I am running the latest Monterey public beta (21A5304g). Everything's fine, except that every time I do a NVRAM reset, my boot order changes in BIOS.

I have 3 separate SSDs running Mac, Ubuntu and Windows. When I reset NVRAM, the boot order changes and the system starts booting directly from the Windows bootloader. So, everytime I do a NVRAM reset and the system restarts, I have to enter BIOS and make the Mac EFI Partition (containing Opencore 0.7.2) as my primary boot disk.

Has anyone experienced this? Any fixes for this?
 
So, I am running the latest Monterey public beta (21A5304g). Everything's fine, except that every time I do a NVRAM reset, my boot order changes in BIOS.

I have 3 separate SSDs running Mac, Ubuntu and Windows. When I reset NVRAM, the boot order changes and the system starts booting directly from the Windows bootloader. So, everytime I do a NVRAM reset and the system restarts, I have to enter BIOS and make the Mac EFI Partition (containing Opencore 0.7.2) as my primary boot disk.

Has anyone experienced this? Any fixes for this?

Maybe try with OpenCore LauncherOption and run OpenCore directly from firmware.

This is an excerpt from the OpenCore Dortania guide.

With OpenCore 0.6.6 and newer, we are now able to launch OpenCore directly from our firmware without needing a launcher (Bootstrap.efi or BOOTx64.efi) as an intermediary. This allows us to add OpenCore to our motherboard's boot menu and prevent issues where either Windows or Linux try to overwrite the EFI/BOOT/BOOTx64.efi path, which can happen when installing or updating Windows and therefore breaking OpenCore's ability to boot.

Then you end up with something like this in your BIOS.

111656480-f0f5d980-87e0-11eb-8229-43c4277a67ca.png
 
As far as I know, in a multi booting system with Windows included Windows will always place itself as the first boot volume whenever the NVRAM is cleaned or reset whether the OS X disk is named OpenCore or the generic disk name. That is the bullish nature of Windows, there is a tweak in OC to override this, to enter Windows as a special entry in the config.plist. You'll nee to read up on the guide how to do this.
 
As far as I know, in a multi booting system with Windows included Windows will always place itself as the first boot volume whenever the NVRAM is cleaned or reset whether the OS X disk is named OpenCore or the generic disk name. That is the bullish nature of Windows, there is a tweak in OC to override this, to enter Windows as a special entry in the config.plist. You'll nee to read up on the guide how to do this.
I think you have misunderstood the idea. This is not a disk name.

 
I think you have misunderstood the idea. This is not a disk name.


Your reference to "installing" OpenCore as a UEFI boot option is very useful.:thumbup:

However, as I understand it, @esafeddie was referring to the Windows Boot Manager entry in BIOS, not merely the name of the disk. It does indeed "bully" other OSs and take over unless controlled in some way. There is also the difference between installing both OSs on the same drive or on separate drives. In your screengrab there's only one physical drive for example.

NVRAM is either native or emulated. If emulated we can have direct control over it, but if native then that is down to the motherboard being used. With her way if NVRAM is reset then that can affect boot order as it appears in the BIOS boot menu.
 
Your reference to "installing" OpenCore as a UEFI boot option is very useful.:thumbup:

However, as I understand it, @esafeddie was referring to the Windows Boot Manager entry in BIOS, not merely the name of the disk. It does indeed "bully" other OSs and take over unless controlled in some way. There is also the difference between installing both OSs on the same drive or on separate drives. In your screengrab there's only one physical drive for example.

NVRAM is either native or emulated. If emulated we can have direct control over it, but if native then that is down to the motherboard being used. With her way if NVRAM is reset then that can affect boot order as it appears in the BIOS boot menu.
If you use LauncherOption you can disable all other boot options and boot order does not matter because you do everything through OpenCore. There is a copy of Win10 installed on that system on a separate disk.
 
If you use LauncherOption you can disable all other boot options and boot order does not matter because you do everything through OpenCore. There is a copy of Win10 installed on that system on a separate disk.

Yes, I understand, but does that help the OP with their NVRAM problem?

If they would like to boot Ubuntu and Windows via OpenCore then your suggestion is certainly an option, but any native NVRAM might still be affected and thus cause other issues with other OSs that, potentially, we wouldn't immediately see.
 
My system is exactly the same whenever I clean or reset the NvRAM then I have to go into the BIOS and reset the desired Boot order as Windows will place it self as first boot device. At the Boot Menu, you will see the Windows Disk as the first volume no matter the arranged boot order.

There is a tutorial on the other side to combat this by making Windows a special entry in the config.plist by finding the exact path of the Windows volume and enter the data in the config.plist. This will force OC to see OS X as the first disk and Windows the second, this will also reflect the positions at the Boot Menu.

This behaviour is not present in Clover as far as I know. I have attached a few pics to show my system, this is constant until I clean/reset the NvRAM then I have to change the boot order. I also do not use the Named Disk as Opencore but use the Generic name of the Disk, this way eliminates ghost entries in the BIOS.
Hope my post is not too convoluted and clears up the query for the OP.
 

Attachments

  • 26171601.png
    26171601.png
    1.5 MB · Views: 265
  • Screenshot 2021-08-26 at 18.17.13.png
    Screenshot 2021-08-26 at 18.17.13.png
    2.8 MB · Views: 309
  • Screenshot 2021-08-26 at 18.18.17.png
    Screenshot 2021-08-26 at 18.18.17.png
    155 KB · Views: 315
  • Screenshot 2021-08-26 at 18.41.47.png
    Screenshot 2021-08-26 at 18.41.47.png
    96.5 KB · Views: 261
Status
Not open for further replies.
Back
Top