MP 1,1-5,1 RefindPlus|OpenCore by MyBootMgr

[Dewdman42]

JedNZ, thanks for contributing useful information. So I guess one thing that stands out in my mind is that the kernel injection approach perhaps is easier because you don't have to actually configure a specific volume UUID into config.plist like you do with DeviceProperties. I don't think that UUID is likely to change for me, so its a bit moot point, but in terms of MyBootMgr, I can see how it would be much much simpler to just throw the kext injection in there and not worry about it.

I was just wondering why this was chosen, and any pros/cons. I will have to try to go read other forum threads elsewhere if I can find them to find out more about those kext injections since it bothers Dayo so much that I ask here. Sorry Dayo. I am not meaning to offend you. But maybe you can lay off me too eh? I'm just asking questions.

 

[Dewdman42]

Thanks. I need to chill out a bit myself but I must confess that I am a bit short of patience when after putting a lot of effort into writing up a guide, I get indications that it is not being read.

ps - I have read the guide in its entirety multiple times FWIW.

 

[Dayo]

I will have to try to go read other forum threads elsewhere if I can find them to find out more about those kext injections since it bothers Dayo so much that I ask here.

Not bothered as much as wanting to maintain focus. If you look through this thread, you will see this is a constant refrain. As before you know it, you have several pages of confusing contradicting posts.

I am not meaning to offend you. But maybe you can lay off me too eh? I'm just asking questions.

OK. Truce in place.

What I am struggling with is why/how you have formed an opinion that the guide exclusively says to use kexts when this is not the case.

BTW, the response by @JedNZ applies in general but does not in this case since the three methods in the guide, Innie.kext, 3rd_party_SATA.kext and setting the device properties, are all stuff to be done manually and not programmatically done.

Anyway, still a mystery as to why/how you feel the guide says to use kexts as opposed to device properties.

ps - I have read the guide in its entirety multiple times FWIW.

Fair enough. Just means you missed this Device Properties based option each time:

​

So, this guide is not kext exclusive which then makes your question not MyBootMgr specific but a general one of the pros/cons of kext v Device properties. Those sorts of questions are kindly requested to be directed to other points.

 

[Dewdman42]

alright...so the DeviceProperties...is perhaps even more reliable then the kext's...but just harder to setup? I'm not meaning to make any criticism about your guide Dayo...just seeking clarity to make sure I have chosen the right way to setup my machine...I chose option 3. And I do remember reading that. I was still left with the question in my mind why anyone would choose options 1 or 2... but I think you're saying..they are just easier to setup and most times should work...but if you really want to be sure...do option 3. yea?

 

[Dewdman42]

I guess I was making the assumption also that ConfigFactory might choose option 1 or 2 based on how I might have answered the questions..I don't remember now if there was a question about PCIe disks. Whereas this third option is not the default, so to speak..

 

[Dayo]

alright...so the DeviceProperties...is perhaps even more reliable then the kext's...but just harder to setup? I'm not meaning to make any criticism about your guide Dayo...just seeking clarity to make sure I have chosen the right way to setup my machine...I chose option 3. And I do remember reading that. I was still left with the question in my mind why anyone would choose options 1 or 2... but I think you're saying..they are just easier to setup and most times should work...but if you really want to be sure...do option 3. yea?

I think the answer to your question is self evident and outlined clearly enough in the guide without needing reaffirmation.

You are over analysing things in general. There are three options given. Settle on one that works for you and forget about the others. If there were issues associated with them, the guide would have spelt such out to guide your choice and in such cases throughout the guide, such are flagged as "recommended" or "not recommended" to help decision making.

Anyway, just settle on whichever works for you and close the chapter.

 

[joevt]

There are three options given.

There is another method which doesn't require a kext or boot loader. It uses gfxutil and the script at

macOS nvram boot variables, device properties, EFI device paths

macOS nvram boot variables, device properties, EFI device paths - gfxutil.sh

gist.github.com

to add the properties to NVRAM.

Example usage at:

Clover General discussion

www.insanelymac.com

 

[Dayo]

There is another method which doesn't require a kext or boot loader

No! Not another method!!

On a serious note, we are working with, and setting things up for, bootloaders here so the methods set out are related to such.

 

[Dewdman42]

I think the answer to your question is self evident and outlined clearly enough in the guide without needing reaffirmation.

I guess I'll take that as a yes. Thank you.

 

[Dayo]

It looks like it might be 1024x768 or 1280x1024 scaled to fit 16:9

My GPU is a Sapphire Pulse RX590 8GB. I connect to a Samsung U28E590 28" 4K display via DisplayPort cable with DisplayPort 1.2 setting and with Freesync on.

Took another look at this and couldn't find anything within RefindPlus that might be causing this. Doesn't mean there isn't, just that I couldn't pin anything down.

However, your log suggests it might be something to do with the GPU or with the monitor settings.

1. There are no GOP Modes with a 16:9 Ratio which you imply is the aspect ratio
2. You mention that the monitor is 4K but none of the resolutions are close to this

So for some reason, the monitor aspect ratio and resolution are not getting passed to the GPU or are not being picked up correctly by the GPU.

Have you tried another monitor or this one without FreeSync to see if there is a difference?

 

[JedNZ]

FIXED! I turned the FreeSync setting to off on my monitor and I now have beautiful RefindPlus GUI and OC Pick-list rendering at 3840x2160 (by the looks of it). When it switches from the Apple logo progress screen to the login screen, the resolution changes to 1920x1080 (or maybe 2560x1440 - but pretty sure it's the former). As soon as I'm logged into a User account if reverts back to 3840x2160.

Speaking of FreeSync, I can't find anything that says whether macOS supports this (even if the hardware does), other than this cursory mention:

Nothing special about the larger resolutions. The Mac Pros run 5k, there's a forum member with two connected to his.
https://forums.macrumors.com/threads/mac-pro-with-dual-dell-5k-works-flawlessly.2029119/

All 4k/5k displays are compatible with the Vega 56 seeing as it has a max resolution of 7680 x 4320. macOS just won't support any freesync technology, and if it is enabled on the display may result in a black screen, so if you're pick a freesync supported monitor, just be sure to disable it for macOS.

There's also USB3.1c to Displayport cabling but haven't used it but I assume works fine as USB3.1c is just delivering the bitstream to the display, except with a USB3.1 cable. I haven't googled the LG Ultrafine to see if it has displayport or not but I've connected several different 4k displays to my Vega 56, and all work as expected.

Thanks again @Dayo.

 

[Macschrauber]

Test this and tell us the result.
Put a RefindPlus in each EFI Partition, each with a refind.conf with a unique manual stanza that indicates which bay it is installed to.
Reboot the computer, zap the pram twice, then see what gets booted.

Got in the situation to test this again, this time an AHCI Blade was involved.

Emptied the nvram by triple bong
AHCI Blade with Mojave in Slot 3
Spinner with RefindPlus in EFI on Bay1

AHCI Blade was loaded, no EFI on this blade.



pulled the AHCI Blade,
RefindPlus was loaded situated in EFI Partition of the spinner in Bay 1


so at least with an AHCI Blade zapping nvram should not failback to bootx64.efi in /volumes/efi/efi/boot/ in one of the Sata Bays.

 

[Dayo]

with an AHCI Blade zapping nvram should not failback to bootx64.efi in /volumes/efi/efi/boot/ in one of the Sata Bays.

Evaluation order for the internal interfaces is: 4 x PCIe Slots -> 2 x PATA Ports -> 4 x SATA Ports.
External Interfaces, such as USB, fit in there somewhere (maybe at the end) but I haven't tested.

One of the PATA Ports is used by the SuperDrive which leaves one free to connect a disk (or two as I have).

 

[startergo]

One of the PATA Ports is used by the SuperDrive

On cMP5,1 it is SATA. Also it is first in the boot order after NVRAM reset.

 

[Dayo]

Updated to v064.
See "Preamble" -> "Important Notes" -> "Requirements" in Post 1 for changes to GPU compatibility requirements.

 

[freqrider]

Hi Dayo,

I have tried both your 0.6.3 an .4 packages on my 3,1 with Big Sur and the config would not boot into Big Sur, even when responding yes to question, ”are you booting into Big Sur on your mac 3,1?” A friend an I were able to modify config to wirk with Big Sur and 0.6.3 but the config that was created did not work. If you like, you can view my modified config to compare. Booting Big Sur on the 3,1 is def not SOP.

Dropbox - File Deleted - Simplify your life

www.dropbox.com

 

[Dayo]

Hi,

What item(s) exactly did you modify? Can you outline the BigSur specific changes you made?
That is, not the cosmetic OpenCanopy stuff as I am struggling to find them.

Only material change I can see is that you have:

1. "DisableLinkeditJettison" set to "false"
2. "SignalAppleOS" set to "true"
3. "LegacyCommpage" set to "true"

Didn't expect these to have the described impact and seem a bit odd choices.
Assume I must be missing something obvious.

 

[freqrider]

Hi,

What item(s) exactly did you modify? Can you outline the BigSur specific changes you made?
That is, not the cosmetic OpenCanopy stuff as I am struggling to find them.

Only material change I can see is that you have:

1. "DisableLinkeditJettison" set to "false"
2. "SignalAppleOS" set to "true"
3. "LegacyCommpage" set to "true"

Didn't expect these to have the described impact and seem a bit odd choices.
Assume I must be missing something obvious.

 

[freqrider]

Yes, this is my 0.6.3 Working config. I haven’t got 0.6.4 working yet. I didn’t modify the config myself entirely, all I know is mine boots big Sur and the one generated by your config package did not. Ones I know of are; AvoidRuntime defrag=true; SetupVirtualMap=true; AppleCPUPmCfgLock and AppleXcmpExtraMsrs=true. And custom bootargs necessary for BigSur, patched OS on 3,1. I tried changing these on a 0.6.4 created package config but it still wouldn’t boot Big Sur. Honestly, what changes are needed to boot BS on MY 3,1 are still a mystery to me. Machine spoofing is not required to boot patched BS on the 3,1 and has been disabled.

 

[freqrider]

Yes, this is my 0.6.3 Working config. I haven’t got 0.6.4 working yet. I didn’t modify the config myself entirely, all I know is mine boots big Sur and the one generated by your config package did not. Ones I know of are; AvoidRuntime defrag=true; SetupVirtualMap=true; AppleCPUPmCfgLock and AppleXcmpExtraMsrs=true. And custom bootargs necessary for BigSur, patched OS on 3,1. I tried changing these on a 0.6.4 created package config but it still wouldn’t boot Big Sur. Honestly, what changes are needed to boot BS on MY 3,1 are still a mystery to me. Machine spoofing is not required to boot patched BS on the 3,1 and has been disabled.

I guess my question to you is, what flags are ticked/modified in your config when you select ‘yes’ to ‘are you booting BS on your 2008 macPro’ question? I can run it by my friend who managed to get BS actually booting from within OC on my 3,1. Amazingly, he doesn’t own one and still got it working! Maybe he can offer some insight?

 

[Dayo]

Probably easier to just pass him the generated 0.6.4 file and let him do his magic.

One thing that might be useful for you to know is that the ConfigFactory tool only tries to actually activate BigSur when the computer has APFS support which a 3,1 will not have unless the firmware has been flashed for this. It still asks the BigSur question for other reasons I can't recollect right now.

Took a cautious approach to BigSur in general as there are still quite a few unknowns and things that are broken or will perhaps break on other Mac OS versions if enabled. The priority was to keep Catalina and earlier working and not implement anything that might break these for the sake of BigSur.

While I do expect that it works on 5,1 as it stands at least, I will move things further forward on the next release and assume that if needed, those that want to jump on BigSur now will be able to manually tweak things with the jump off point provided.

 

[freqrider]

Probably easier to just pass him the generated 0.6.4 file and let him do his magic.

One thing that might be useful for you to know is that the ConfigFactory tool only tries to actually activate BigSur when the computer has APFS support which a 3,1 will not have unless the firmware has been flashed for this. It still asks the BigSur question for other reasons I can't recollect right now.

Took a cautious approach to BigSur in general as there are still quite a few unknowns and things that are broken or will perhaps break on other Mac OS versions if enabled. The priority was to keep Catalina and earlier working and not implement anything that might break these for the sake of BigSur.

While I do expect that it works on 5,1 as it stands at least, I will move things further forward on the next release and assume that if needed, those that want to jump on BigSur now will be able to manually tweak things with the jump off point provided.

Good to know, thanks. Yes my bootrom is patched for apfs:nvme support. That config I sent actually works fine with Mojave/Cat and Big Sur, luckily. And that is precicely what I did, sent him the generated 0.6.3 config to modify

 

[H2SO4]

Hi all/Dayo. Have a question for you. Some background first;

I have a Mac Pro 5,1 with the latest BootRom.
It has 4 drives installed -
SATA1 High Sierra on APFS. (High Sierra).
SATA2 Windows 10 UEFI. (Untitled). BootRom has been dumped.
SATA3 a 3TB ExFAT data only drive. (GREEN).
SATA4 a 120GB Mac OS Extended Journaled drive. (BootLoader).
It was running Mojave with an RX470 installed but I wanted an Nvidia GTX1070FE card so I downgraded to High Sierra.
I installed Opencore and got both Windows and High Sierra with no encryption enabled running side by side. What I couldn't do was to get Windows to boot with the Nvidia card in.

I 'cleaned' the 120 in windows and reformatted.
The RefindPlus installation began with the RX470 in and the Windows drive removed, so the initial ConfigFactory reflected that.
Soft bless worked fine and I was cool.
A power down and the Nvidia and Windows drive were installed, and ConfigFactory re-run with a couple of pertinent changes. My problem is that the Windows drive does not show as an option in either of the boot environments.
Any ideas as to where things have gone wrong?

Thanks.

 

[Dayo]

Seems you may have dodged a bullet there as booting UEFI Windows from RefindPlus is a bad idea (I believe the guide says not to do this .... maybe warning needs to be made more dire)

The only way to use UEFI Windows safely with this setup would be essentially what you already had with OpenCore alone as you would have to always boot it through OpenCore to avoid risking damaging your cMP. (You should add it to the "dont scan volumes" list in the RefindPlus Config to prevent it from showing up in RefindPlus to avoid being able to click on it by mistake) RefindPlus can now protect Macs from NVRAM damage by UEFI Windows but Legacy Windows is still recommended

If by "the Windows drive does not show as an option in either of the boot environments" you mean RefindPlus and OpenCore, as said, lucky it doesn't in RefindPlus and no idea on OpenCore.

You can ask the question on the OpenCore thread (OpenCore setup through this process is just a normal setup)

 

[H2SO4]

Seems you may have dodged a bullet there as booting UEFI Windows from RefindPlus is a bad idea (I believe the guide says not to do this .... maybe warning needs to be made more dire)

The only way to use UEFI Windows safely with this setup would be essentially what you already had with OpenCore alone as you would have to always boot it through OpenCore to avoid risking damaging your cMP. (You should add it to the "dont scan volumes" list in the RefindPlus Config to prevent it from showing up in RefindPlus to avoid being able to click on it by mistake)

If by "the Windows drive does not show as an option in either of the boot environments" you mean RefindPlus and OpenCore, as said, lucky it doesn't in RefindPlus and no idea on OpenCore.

You can ask the question on the OpenCore thread (OpenCore setup through this process is just a normal setup)

Yep, no problem, I'll have a mooch around there. But yes, disappeared from both RF+ and OC.
I can't remember why I opted or UEFI now but I took the precautions as suggested in a few threads.