Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
You first need to install rEFind "Installing rEFInd Manually Using MacOS" and then replace the refind_x64.efi and/or boot.efi (depending on your method of installation) with the provided one here. There is no refind.app.
No! No! No!
The whole thing is self contained. It is literally plug and play.
Screen Shot 2020-08-31 at 4.02.45 PM.jpg



Do not implement anything that is not explicitly written.
If it's not written, it is not an oversight!

Screen Shot 2020-08-31 at 3.59.17 PM.jpg


Issues as I have seen so far, invariably arise from second guessing the guide and jumping to assumptions.
The pledge made about following literally (word for word) is for real.
 
Last edited:
I strictly followed your guide step by step without adding anything.

I got the following structure for my REFIND_OC USB volume :​

Mac-Pro-de-Patrick:~ pat$ tree -L 2 /volumes/REFIND_OC
/volumes/REFIND_OC
└── EFI
├── BOOT​
├── OC​
├── OC_ALT​

And every folders contain all files from myBootMgr.

If I asked wether it’s necessary to install REFIND, it’s because I don’t understand what is wrong in the way I followed your guide.

I tried to format my USB stick with GUID partition table or with Apple partition table, using MAC OS extended format in both case, it changes nothing.

Why Bootblesser is looking for Refind in EFI, if it doesn’t exist? The only file named refind is refind.conf but within BOOT folders not at EFI level.

What could I look for to understand what is wrong ?
 
Last edited:
OK. I will review the app to see if it has an issue.
The USB Volume disk should be HFS+
Use Terminal for now.

To SoftBless:
Code:
sudo bless --folder '/Volumes/REFIND_OC/BOOT' --file '/Volumes/REFIND_OC/BOOT/BOOTx64.efi' --setBoot --nextonly

To FirmBless:
Code:
sudo bless --folder '/Volumes/REFIND_OC/BOOT' --file '/Volumes/REFIND_OC/BOOT/BOOTx64.efi' --setBoot


Alternatively, you can still get the safety you want by using the EFI Partition on the USB and following the EFI Mode instructions.

Might have had some gaps in the testing of the USB Mode. I know the Blesser works for EFI mode and this can be the EFI Partition on a USB Stick. Will fix the blesser app as required but will only update in about a week. So follow one of the two options outlined.

EDIT:
There is a issue with the app for USB Mode.
Will be fixed in the next update.
 
Last edited:
When I use Terminal, I get this:
Mac-Pro-de-Patrick:~ pat$ sudo bless --folder '/Volumes/REFIND_OC/EFI/BOOT' --file '/volumes/REFIND_OC/EFI/BOOT/BOOTx64.efi' --setBoot --nextonly
Could not set boot device property: 0xe00002e2

I didn’t find the meaning of this error code 0xe00002e2.
I shall try later the alternate solution by using the EFI partition on the USB. I shall write the results

Thanks for your help
 
When I use Terminal, I get this:
Mac-Pro-de-Patrick:~ pat$ sudo bless --folder '/Volumes/REFIND_OC/EFI/BOOT' --file '/volumes/REFIND_OC/EFI/BOOT/BOOTx64.efi' --setBoot --nextonly
Could not set boot device property: 0xe00002e2

I didn’t find the meaning of this error code 0xe00002e2.
I shall try later the alternate solution by using the EFI partition on the USB. I shall write the results

Thanks for your help
First SIP needs to be disabled. Second blessing does not work when booted from OC.
 
  • Like
Reactions: Dayo
First SIP needs to be disabled. Second blessing does not work when booted from OC.
How does OC stop blessing? Does it override an EFI runtime service responsible for setting NVRAM variables? The override only affects certain EFI variables?
 
How does OC stop blessing?
It is not a broad brush item that you cannot bless with OpenCore but when the RequestBootVarRouting Config setting is enabled as it is in the distributed OpenCore configs here.

When this setting is enabled, OpenCore creates a separate GUID namespace, that is not accessed by the System Firmware, before loading the OS.

With this is place, anything blessed when booted from OpenCore will not be detected by the System Firmware and will only be visible to OpenCore. As it is not visible to the firmware, when you startup your computer, it will not load such "blessed" items.

RequestBootVarRouting, as you may recollect, is what OpenCore uses to determine the default boot drive for instance when you select this from System Preferences.

Illustration assuming you are purely using OpenCore:
  • You had previously blessed OpenCore, the System Firmware is aware of this and you are booted into Mac OS via OpenCore with RequestBootVarRouting active.
  • You select a start disk in System Preferences and the OS basically "blesses" that disk but this info goes to OpenCore and is recorded by OpenCore. System Firmware does not see this information and OpenCore remains the blessed item there.
  • You reboot, System Firmware boots OpenCore, since that is what it has, and when OpenCore is loaded, your indicated Start Disk is highlighted.
  • If what you blessed is not a proper start disk, for instance, a Refind efi file, it is simply ignored/prevented by OpenCore AFAICS.
Same applies here with myBootMgr just that the Refind instance is what would be in the System Firmware and the startup disk thing would only come in if/when OpenCore is launched.

Since this distributes a config with RequestBootVarRouting, this restriction applies but is now covered in the guide without going into the nuts and bolts as the preference is to leave such to the main OpenCore thread so as to keep focus. Would appreciate if follow up stuff goes there.
 
Last edited:
  • Like
Reactions: startergo
Do you have Windows? What is the result of:
Code:
nvflash --version

Code:
EEPROM ID (EF,6013) : WBond W25Q40EW 1.65-1.95V 4096Kx1S, page

Sign-On Message       : GP107 PG210 SKU 0 VGA BIOS
Build GUID            : B73978D4D1844651B3B3D66DDE2C6BCE
IFR Subsystem ID      : 3842-6258
Subsystem Vendor ID   : 0x3842
Subsystem ID          : 0x6258
Version               : 86.07.42.00.50
Image Hash            : 33B32C993A0630EFFDC0FD054506C191
Product Name          : GP107 Board
Device Name(s)        : GeForce GTX 1050 Ti
Board ID              : 0xF001
Vendor ID             : 0x10DE
Device ID             : 0x1C82
Hierarchy ID          : Normal Board
Chip SKU              : 400-0
Project               : G210-0000
Build Date            : 03/21/17
Modification Date     : 07/11/17
UEFI Version          : 0x30008
UEFI Variant ID       : 0x0000000000000007 ( GP1xx )
UEFI Signer(s)        : Microsoft Corporation UEFI CA 2011
XUSB-FW Version ID    : N/A
XUSB-FW Build Time    : N/A
InfoROM Version       : G001.0000.01.04
InfoROM Backup        : Not Present
License Placeholder   : Not Present
GPU Mode              : N/A

Here's what I see:

What does this tell us?

Code:
PS C:\Users\Dude\Desktop> .\nvflash64 --version
NVIDIA Firmware Update Utility (Version 5.620.0)
Copyright (C) 1993-2019, NVIDIA Corporation. All rights reserved.


Adapter: GeForce GTX 1080     (10DE,1B80,1462,3362) H:--:NRM  S:00,B:06,D:00,F:00


EEPROM ID (EF,6013) : WBond W25Q40EW 1.65-1.95V 4096Kx1S, page

Sign-On Message       : GP104 PG413 SKU 0 VGA BIOS
MSINV336MH.180
Build GUID            : 00000000000000000000000000000000
IFR Subsystem ID      : 1462-3362
Subsystem Vendor ID   : 0x1462
Subsystem ID          : 0x3362
Version               : 86.04.17.00.50
Image Hash            : 0B453B9343FC3F5CD51539459D8BB851
Product Name          : GP104 Board
Device Name(s)        : GeForce GTX 1080
Board ID              : 0xED06
Vendor ID             : 0x10DE
Device ID             : 0x1B80
Hierarchy ID          : Normal Board
Chip SKU              : 400-0
Project               : G413-0000
Build Date            : 05/09/16
Modification Date     : 05/27/16
UEFI Version          : 0x30007
UEFI Variant ID       : 0x0000000000000007 ( GP1xx )
UEFI Signer(s)        : Microsoft Corporation UEFI CA 2011
XUSB-FW Version ID    : N/A
XUSB-FW Build Time    : N/A
InfoROM Version       : G001.0000.01.03
InfoROM Backup        : Present
License Placeholder   : Present
GPU Mode              : N/A[\CODE]
 
Since I primarily use the Mac Pro for gaming and need the GTX 1080, it seems using the red hot HD 2600 and a small monitor is the only feasible solution. As I plan to use the Mac Pro also with different versions of Mac OS, and not all support the necessary NVIDIA video driver. I hoped that rEFInd or OpenCore with GOP support would finally allow me to get rid of the Apple GPU, but...
 
Btw, I installed 10.13 and 10.14 with a flashed GTX 680 for Mac and updated the firmware to 144.0.0.0 in the hope it would make any difference. Unfortuantly it does not. Still the same problem. I still get no pre-boot screen using either the GTX 1080 or GTX 760. I must have swapped GPU adapters in and out 5000 times, and I just had enough for now.

When working with and without a grey preboot screen, I suggest to time the startup. It can be very misleading what is happening, when it's simply a matter of waiting long enough for the system to get ready. Using the debug versions of the bootloaders, I noticed the following:

Cold startup: rEFInd menu takes 20 - 30 seconds to appear. OpenCore adds another 60 - 80 seconds before you can make a selection.
 
It is not a broad brush item that you cannot bless with OpenCore but when the RequestBootVarRouting Config setting is enabled as it is in the distributed OpenCore configs here.

When this setting is enabled, OpenCore creates a separate GUID namespace, that is not accessed by the System Firmware, before loading the OS.

With this is place, anything blessed when booted from OpenCore will not be detected by the System Firmware and will only be visible to OpenCore. As it is not visible to the firmware, when you startup your computer, it will not load such "blessed" items.

RequestBootVarRouting, as you may recollect, is what OpenCore uses to determine the default boot drive for instance when you select this from System Preferences.

Illustration assuming you are purely using OpenCore:
  • You had previously blessed OpenCore, the System Firmware is aware of this and you are booted into Mac OS via OpenCore with RequestBootVarRouting active.
  • You select a start disk in System Preferences and the OS basically "blesses" that disk but this info goes to OpenCore and is recorded by OpenCore. System Firmware does not see this information and OpenCore remains the blessed item there.
  • You reboot, System Firmware boots OpenCore, since that is what it has, and when OpenCore is loaded, your indicated Start Disk is highlighted.
  • If what you blessed is not a proper start disk, for instance, a Refind efi file, it is simply ignored/prevented by OpenCore AFAICS.
Same applies here with myBootMgr just that the Refind instance is what would be in the System Firmware and the startup disk thing would only come in if/when OpenCore is launched.

Since this distributes a config with RequestBootVarRouting, this restriction applies but is now covered in the guide without going into the nuts and bolts as the preference is to leave such to the main OpenCore thread so as to keep focus. Would appreciate if follow up stuff goes there.
Correct. To avoid this hiccup I normally bless my rEFInd with a EFI vbios card directly from the Apple bootpicker using CNTRL+ENTER and then from the OC menu the default boot partition again with CNTRL+ENTER. This works fine until NVRAM reset is issued. Of course one can always disable RequestBootVarRouting, reboot, bless rEFInd from within the OSX (with SIP disabled) (which in this case should work) and use CNTRL+ENTER as described without efi vbios video card. Once blessed the RequestBootVarRouting can be reset again to TRUE.
There is another way of skinning the cat:
1. Turn on your Mac and immediately press and hold these two keys: Command (⌘) and R
2. Release the keys when you see an Apple logo, spinning globe, or other startup screen
3. Bless rEFInd from terminal and reboot, or simply select rEFInd as a startup disk (if rEFInd appears as a startup disk). This will only be available if rEFInd is installed in HFS+ and is relabeled as boot.efi. By default, the refind-install script installs rEFInd to your disk's ESP. Under macOS, you can instead install rEFInd to your current macOS boot partition by passing the script the --notesp option, or to a non-boot HFS+ partition by using the --ownhfs devicefile option. Under either OS, you can install to something other than the currently-running OS by using the --root /mountpoint option.

rEFIt comes with a program rEFIt blesser. This program attempts to keep rEFIt set as the default boot loader, but it also has the purpose of protecting the computer from launching the wrong OS after waking from sleep. If you want that protection, one can install rEFIt and rEFItBlesser and then replace the refit.efi file with refind_x64.efi (renaming it to refit.efi). Used in this way, rEFInd will still look for its own configuration file, refind.conf, so you'll need to move it but not rename it. If you don't move the icons from the rEFInd package, your icons will continue to look like rEFIt icons.

@Dayo rEFIt blesser can be modified directly to bless rEFInd and use the rEFInd sctructure.
 
There is another way of skinning the cat
...
rEFIt blesser can be modified directly to bless rEFInd and use the rEFInd structure.
Recommendation remains that users should follow the guide, maintain the distributed structure and not introduce additional elements.
 
I updated the GPU firmware from 86.04.17... to 86.04.60.... Doesn't make any different. Same problem.

One thing I noticed, however: You need to remove the Apple GPU even when there is no screen attached. Otherwise, refind and opencore find 2 handles and sets the resolution to 1024x768 successfully, using the Apple GPU. But with no screen attached you won't see a thing. Well if there isn't a screen attached, it probably shouldn't use it.
 
I updated the GPU firmware from 86.04.17... to 86.04.60.... Doesn't make any different. Same problem.

One thing I noticed, however: You need to remove the Apple GPU even when there is no screen attached. Otherwise, refind and opencore find 2 handles and sets the resolution to 1024x768 successfully, using the Apple GPU. But with no screen attached you won't see a thing. Well if there isn't a screen attached, it probably shouldn't use it.
If you have 2 GPU's installed one of the screens has to be connected to the EFI GPU otherwise you will not see the boot screen. To see the boot screen on a valid GOP GPU there should not be any EFI GPU's installed. Also you need to check all outputs some of them might not work. Also use agdpmod=pikera as a boot argument in the OC config file.
 
Dayo
Can I use Your Guide Steps OCw/refind with my GTX 680?? {Doesn’t have UEFI GOP??}
I need refind and OC!
Really need your reply!! THANKS!
Sincerely,
papadj3
 
I just remembered that I also have a GT 730 lying around and thought I would give it a try. And guess what, it works in Sierra and also Mojave with Metal support right out of the box. Not a bad card considering it was cheap too. Of course it doesn't have a boot screen, so I thought I would give it a try with GOP. But shows exactly the same issue as with the GTX 1080. The GT 730 is relatively new with 2 GB GDDR5. Which makes me wonder if the GOP part is working at all. Have you seen it working?
 
I just remembered that I also have a GT 730 lying around and thought I would give it a try. And guess what, it works in Sierra and also Mojave with Metal support right out of the box. Not a bad card considering it was cheap too. Of course it doesn't have a boot screen, so I thought I would give it a try with GOP. But shows exactly the same issue as with the GTX 1080. The GT 730 is relatively new with 2 GB GDDR5. Which makes me wonder if the GOP part is working at all. Have you seen it working?
I just tested one GT-710. No boot screen either. I know it has good GOP, because I can see the Windows boot screen. Apparently NVIDIA boot screen is not well supported unless someone can chime in with a success story.

Code:
Adapter: GeForce GT 710       (10DE,128B,1462,8C93) H:--:NRM  S:00,B:0C,D:00,F:00


EEPROM ID (A1,3112) : FM FM25F02 2.7-3.6V 2048Kx1S, page

Sign-On Message       : GK208 P2132 SKU 14 VGA BIOS
MSINV809MH0.420
Build GUID            : Blank
IFR Subsystem ID      : 1462-8C93
Subsystem Vendor ID   : 0x1462
Subsystem ID          : 0x8C93
Version               : 80.28.A6.00.22
Image Hash            : 1F61E3FE61EA28B5EA39FC9EE4493BA9
Product Name          : GK208 Board - 21320014
Device Name(s)        : GeForce GT 710
Board ID              : 0xE430
Vendor ID             : 0x10DE
Device ID             : 0x128B
Hierarchy ID          : Normal Board
Chip SKU              : 203-0
Project               : 2132-0014
Build Date            : 10/09/15
Modification Date     : 12/28/15
UEFI Version          : 0x10033
UEFI Variant ID       : 0x0000000000000004 ( GK1xx )
UEFI Signer(s)        : Microsoft Corporation UEFI CA 2011
XUSB-FW Version ID    : N/A
XUSB-FW Build Time    : N/A
InfoROM Version       : N/A
InfoROM Backup        : Not Present
License Placeholder   : Not Present
GPU Mode              : N/A
 

Attachments

  • refind.txt
    44 KB · Views: 149
Last edited:
I also have a GT 730 lying around and thought I would give it a try.
I just tested one GT-710. No boot screen either. I know it has good GOP, because I can see the Windows boot screen.
Graphics Output Protocol AKA GOP is a specific protocol that was introduced around 2015. It is not the same thing as "bootscreen" which existed before GOP was introduced. So, that you can see Windows Bootscreen is not GOP related. There was obviously also bootscreen on Macs with supported legacy GPUs.

Both mentioned units are legacy, I.E., Pre-GOP, units that run on the older UGA/VGA method.

The pertinent information is spelt out in Startergo's posted log where there is an attempt to use UGA:
15:716 0:013 INFO: Could not Find Valid Replacement GOP
...
15:815 0:012 INFO: GraphicsOutputProtocol Not Available
15:827 0:012 Using UGADraw for Graphics
Your legacy GPUs do not have valid GOP and more importantly, are simply not Mac bootscreen compatible.
For those using even older legacy units but which have the required capability, it works perfectly OK.

Note that the poster linked is also confused about GOP means and thinks GOP means bootscreen. Which it does not. His GPU does not have GOP as it was released about a decade before GOP was introduced. It does have UGA Based Mac Bootscreen Support which is leveraged.

Anyway, RefindPlus as bundled with MyBootMgr requires Fully Compatible GPUs (GOP or UGA Based Mac Bootscreen Support) or Semi Compatible GPUs with Valid Usable or Fixable GOP. It doesn't matter whether Legacy or Current as long as it is one of the two types.

If your GPU does not fall into either category, you will not get the Graphical Preboot Screen. Trying to see whether a Text Preboot Screen can be provided for others.

In the absence of Mac Bootscreen support on your Legacy Units, you have to find a way to add Valid GOP to them or use other GPUs. This is a requirement and best to move further discussion on whether the mentioned units have the required Mac Bootscreen Support or how to add Valid GOP to them to the relevant thread.
 
Last edited:
Your legacy GPUs do not have valid GOP and more importantly, are simply not Mac bootscreen compatible.
For those using even older legacy units but which have the required capability, it works perfectly OK.

What do you consider a legacy card? Isn't it rather that the legacy Mac Pro does not support UEFI GOP?

How is it possible that refind or opencore can use GOP if the computer firmware is unable to initialize the GPU? Isn't this what flashing does accomplish, to install a GPU firmware that consists both, UEFI firmware for PC, and EFI firmware for the Mac, so both platforms can initialize the GPU and use GOP? This was as I remember also one of the design concepts when PCI-E was introduces long time ago - to have platform independent cards.

If you want a boot screen on a PC/Hackintosh similar to holding down the Option key on a Mac, you will obviously need an appropriate boot loader, and I'm sure this is what rEFInd and OpenCore with OpenCanopy can accomplish.

Right or wrong, I think none of these boot loaders contain hardware specific graphics drivers to initialize a GPU, which otherwise needs to be done in firmware or OS kernel when the system starts. However, there are many posts that claim to do this. I would like to try it, but following your instructions so far has not given me a preboot screen with any of the non Apple or non-flashed PC cards I've tried.

There is another post, which I thought was an interesting reading:
I find it very well written. It explicitly mentions the following:

• OpenCore gives Mac Pro users (4,1 and 5,1) that use an unflashed graphics card, a boot screen again!
System Requirements:
– 2009, 2010 or 2012 Mac Pro (2009 4,1 must be flashed to 5,1)
– Westmere or newer CPU architecture
– 144.0.0.0.0 Boot ROM

I have all that. Does anyone know where to find "OpenCore 0.5.8 NdkBootPicker.zip"?
 
I am not inclined to get into a discussion of GPU or other side issues in this thread as I am conscious that these can clutter the thread and confuse readers down the line.

Please post on this in a relevant thread to get wider input. You can tag me if you want.
 
Last edited:
I just tested one GT-710. No boot screen either. I know it has good GOP, because I can see the Windows boot screen. Apparently NVIDIA boot screen is not well supported unless someone can chime in with a success story.

Are you sure? I can see part of the Windows startup screen and part of the mac OS startup loading, aka boot screen, but only after the appropriate system kernel has already started. But this doesn't help to pick the boot device in the first place. I'm happy to try and learn something new and some of the reports look very promising. but I can't see how any boot loader can work-around the issue that the Mac firmware isn't UEFI compatible. I know from several past Hackintosh projects, that Clover, for example, can emulate UEFI, but this does not initialize adapter cards at the firmware/hardware level.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.