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

[Dayo]

Interesting. Will look at the logs properly later and would probably need to see logs from 067 at some point.

For now, in terms of the NVRAM reset, make sure it is the so called "Deep Reset" where you hold the keys down until you hear the 4th chime in sucession as explained in Post 1.

Also, try again after disabling the "supply_nvme" token that you manually enabled and copy a standalone NvmExpressDxe driver into the "BOOT/drivers" folder. MyBootMgr does not enable this token as I have basically decided to remove it from RefindPlus in favour of using a standalone driver instead.

Actually, are you sure you even need NVME support to start with? I note that the bit you linked to originally may be about AHCI sticks which are not NVME. Which adaptor and drive type have you got in place?

Summary:

1. Make you you executed a "Deep" Reset (Up to four chimes ... see Post 1)
2. Disable "supply_nvme" token
3. Confirm whether actually using and needing NVME and not AHCI.
   1. If actually using NVME, use attached standalone driver
   2. Confirm pcie adaptor and stick details

 

[ahihi]

Interesting. Will look at the logs properly later and would probably need to see logs from 067 at some point.

For now, in terms of the NVRAM reset, make sure it is the so called "Deep Reset" where you hold the keys down until you hear the 4th chime in sucession as explained in Post 1.

Also, try again after disabling the "supply_nvme" token that you manually enabled and copy a standalone NvmExpressDxe driver into the "BOOT/drivers" folder. MyBootMgr does not enable this token as I have basically decided to remove it from RefindPlus in favour of using a standalone driver instead.

Actually, are you sure you even need NVME support to start with? I note that the bit you linked to originally may be about AHCI sticks which are not NVME. Which adaptor and drive type have you got in place?

Summary:

1. Make you you executed a "Deep" Reset (Up to four chimes ... see Post 1)
2. Disable "supply_nvme" token
3. Confirm whether actually using and needing NVME and not AHCI.
   1. If actually using NVME, use attached standalone driver
   2. Confirm pcie adaptor and stick details

i did the deep reset and set up v091 again, now without supply_nvme. the drive is indeed an NVMe drive (Samsung 970 EVO Plus 1TB) and the adapter is a Lycom DT-120. i also have a third party heatsink installed.

first i verified that the drive does not appear at all when neither supply_nvme nor NvmExpressDxe are in use:

TEST6: HD 2600 XT, drive B: RefindPlus shows no volumes, OC_LEG only shows System Restart, System Shutdown, and Reset NVRAM

TEST7: HD 2600 XT, drive A,B: RefindPlus and OC_LEG show only Polyrhythm

next i installed NvmExpressDxe from OpenCore 0.9.1-DEBUG:

TEST8: HD 2600 XT, NvmExpressDxe, drive A,B: RefindPlus and OpenCore shows Polyrhythm and Serenia

TEST9: HD 2600 XT, NvmExpressDxe, drive B: RefindPlus shows no volumes, OC_LEG only shows System Restart, System Shutdown, and Reset NVRAM

going back to the GTX760 (still no boot screens):

TEST10: GTX 760, NvmExpressDxe, drive A,B: return -> boots into Polyrhythm

TEST11: GTX 760, NvmExpressDxe, drive A,B: down;return -> boots into Serenia

TEST12: GTX 760, NvmExpressDxe, drive B: return -> system reboots

so it seems nothing has changed wrt bootability of drive B.

blind OpenCore navigation does seem more consistent now and i have not gotten a safe mode boot yet, but that might be a fluke.

attached are logs from these tests as well as a pair of v067a logs from last week.

edit: i just now noticed you attached an NvmExpressDxe in your post! 😅 where is this one from, should i try it instead?

 

[osxfr33k]

I just want to mention that from the prior poster that I observed similar things as they had, graphics cards would work on earlier versions, and some would not give you the boot screen on the later versions, so I just wanted to ask if you would know if the AMD RX460 supports the boot screen or not on the most current version. I know your going to ask me all of these cards had the original manufactures firmware on them.

 

[Dayo]

@osxfr33k ... RX 460, or any GPU that meets the criteria in Post 1, should display. Please raise an issue if you observe otherwise. Typically best on GitHub if it appears RefindPlus specific. This is more so if something was working before and stops doing so in a later release. That is, you observe an apparent regression.

@ahihi ... Thanks for the tests. There has been a regression in RefindPlus 0.13.3.AD, with respect to Nvidia GPUs, resulting from a change aimed at improving handling UGA-Only GPUs. Basically, things had focussed on GOP units like basic RX 580 (which I have) and basic Nvidia (which I don't) for a couple of years. I finally got round to looking at my HD 5770 again this year, UGA-Only like your HD 2600, and started fixing regressions that had crept in for such GPUs but managed to add new ones for Nvidia units in the process.

The apparent dependency is not yet 100% clear but one thing is that OpenCore is set up by default to, over time, invalidate and refuse to show older versions of Mac OS (that use APFS) based on the details of the embedded APFS driver. At least one APFS driver version in play on your unit does not meet the criteria in OpenCore 0.9.1 for APFS drivers to have been released after 31 Dec 2020 and to be a certain version type if released after that date.

Haven't yet fully gotten my head around it all but can think of scenarios where this could lead to a volume not showing up unless another volume with an acceptable APFS driver is present. What is not clear is that this should not affect RefindPlus as it appears to do (If the reason).

Can you kindly raise an issue on GitHub to take things further as this needs fiddling with RefindPlus? You can tie the issue to the apparent regression in the 0.13.3.AD release. A link to the GitHub repo is under "Support Options" in Post 1.

Thanks

 

[Dayo]

The apparent dependency is not yet 100% clear

Been wracking my brains and think I have a plausible hypothesis.

It seems like this might be an MP31 specific issue as it does not have NVME or APFS support. This means that when RefindPlus is loaded, "Drive B", which is an NVME drive would not have been initialised. RefindPlus then adds NVME support, either via a 'SupplyNVME' feature or a standalone driver. They happen at different points but this does not make a difference to this part of the issues as the drive is still not initialised afterwards.

As a result of the drive not being initialised, the RefindPlus 'SupplyAPFS' feature, which loads embedded APFS drivers in APFS volumes, will fail to load this for that NVME drive as it cannot read the drive (being not initialised).

Spoiler: SIDE NOTE

Unfortunately, RefindPlus logging is vague in such cases as I have been unable to find a way to fully separate between when the SupplyAPFS feature 'fails' because APFS is already active (from firmware such as on MP51) or because APFS could not be found. Therefore, whenever SupplyAPFS fails, and RefindPlus is running on a Mac, it logs 'Already Started' as the former condition is typically the case.

RefindPlus proceeds to initialise drives not previously done where possible and will initialise "Drive B" but this is too late here as the APFS provision phase would have ended without an APFS driver active and therefore, RefindPlus would not be able to show the contents on the APFS container. If you had HFS+ in that NVME drive instead, it would show up without needing Drive A to be present.

When Drive A is present on a SATA port, it would have been initialised by the time RefindPlus is loaded, SupplyAPFS would work and Drive B would be displayed using the APFS Driver from Drive A. However, this is contingent upon the APFS driver from Drive A being compatible with the APFS version in Drive B. If you have a newer version of Mac OS with incompatible APFS in Drive B, the drive would also not show up despite the presence of Drive A.

An obvious solution is to delay triggering the SupplyAPFS feature until after the volume reinit. You can check the chances of success by adding the attached Mojave vintage APFS driver to the RefindPlus drivers folder and testing the instance with Drive B alone. No need for the ones with Drive A and doesn't matter whether using the standalone NVME driver or not.

You can post the outcomes here and we pick up from there after you raise the GitHub issue.

Thanks

 

[ahihi]

thank you so much for your help so far! i finally have some time to fiddle with this again and can now confirm that with x64_apfs.efi installed, drive B indeed becomes bootable even with drive A removed.

this makes the system immediately more usable as i can now set a short OC timeout and easily boot Mojave even with the boot screens currently missing. booting via timeout also seems to circumvent the spurious safe boots i had... maybe thats something for OC devs to look at.

regarding the github issue, did you want me to file one about the boot screen regression, the NVMe/APFS problem, or both?

 

[Dayo]

Might as well raise two separate issues. Thanks.

 

[osxfr33k]

@Dayo Confirmed RX460 rEFIndplus gives boot screen still on v090 was thinking of trying v091 unless you have a new one around the corner? Thanks.

 

[Dayo]

Nothing imminent.

Bear in mind going forward, that as it barely takes 4 mins to run MyBootMgr and that getting back to a working configuration, if required, only adds another 1 or 2 mins, you should not have to check in for misc confirmation.

The idea is to run what you want and if you encounter any issues, report them for fixes. If they are things you cannot live with, roll back to whatever you had before.

That is, the time and effort to be invested in running MyBootMgr should be trivial and this particularly applies to rolling back if required.

Well, that is the design goal at least and if not met, then please report how things fail to meet this goal so they can be fixed if possible.

 

[Dayo]

Updated MyBootMgr to v092
See change log in Post 1 for details

 

[osxfr33k]

Updated MyBootMgr to v092
See change log in Post 1 for details

Sorry to bother and can you explain which folder is used for which MacOS?

OC_AAA
OC_EXT
OC_VMM

I will assume OC_EXT is for the Ventura Drive is OC_AAA for the Catalina drive?

Thanks

Edited:

Never-mind the Config file at the end describes what is what thanks.

 

[Dayo]

Can you explain which folder is used for which MacOS?

OC_XYZ on one persons's setup is likely different from another's depending on what they have installed and what they have selected in ConfigFactory.

What each instance is for is written in the ConfigFactory debug log file as well as on the RefindPlus main screen when you highlight that item.

Have you not previously noticed that each OpenCore instance in RefindPlus states exactly what it is for when highlighted?

 

[osxfr33k]

OC_XYZ on one persons's setup is likely different from another's depending on what they have installed and what they have selected in ConfigFactory.

What each instance is for is written in the ConfigFactory debug log file as well as on the RefindPlus main screen when you highlight that item.

Have you not previously noticed that each OpenCore instance in RefindPlus states exactly what it is for when highlighted?

Yes thanks

 

[Dayo]

What each instance is for is written in the ConfigFactory debug log file as well as on the RefindPlus main screen when you highlight that item.

Just struck me that this might not be quite exact when an Nvidia GPU is being used.
Need to check on this.

 

[riven2000]

Hi Dayo - from our last conversation:

"
".../Data//MyTools/..." looks like a malformed path from two joined variables.
Doesn't throw an error on my unit and I think most setups process such into one slash but I can imagine some might not.

Anyway, I have eliminated this and re-uploaded the package. You can delete your current and grab a new one."

I just downloaded it again from the same link (still v. 0.92) and it still gives me the same error.

 

[Dayo]

it still gives me the same error.

I'm afraid I have no idea why that is the case.
I have just downloaded and run it without issue.

Edit:
If you got the exact same error, then you must be running the exact same dmg as that path string does not exist in the updated file. Either you didn't delete and reran the original, or you got served a cached file. I cleared the server cache after uploading the replacement but your ISP (or router etc along the way) may be caching stuff. The alternative is to wait for the next version.

 

[riven2000]

Would it help to reinstall Mojave?

 

[Dayo]

Would it help to reinstall Mojave?

If you are still seeing a message saying you have an error related to ".../Data//MyTools/...", you are not running the updated file as the double slash was removed in that. This has nothing to do with your OS.

 

[riven2000]

Great, thanks. It sounds like I could maybe have success with the file if I downloaded it from another machine / location.

 

[riven2000]

Went down to the UPS Store and downloaded the file there - everything is up and running now. Thanks!! Any chance the whole "disable SIP and re-bless EFI after every NVRAM cleaning" could be automated?

 

[Macschrauber]

Went down to the UPS Store and downloaded the file there - everything is up and running now. Thanks!! Any chance the whole "disable SIP and re-bless EFI after every NVRAM cleaning" could be automated?

You can make a firmware dump right after resetting nvram, setup sip and blessing. When you need a cleaned nvram you can flash back the firmware dump.

I made a firmware analysis / dump / flash tool

Healthy NVRAM normal behaviour on 4,1->5,1 machines

Macschrauber's Rom Dump I needed to encrypt the disk image as DropBox has flagged it for containing Flashrom. The password is rom. What's new in the latest versions: Update from 20-2-2024 -> checking Fsys for missing items or wrong order sometimes they get into the wrong order or items...

forums.macrumors.com

 

[Dayo]

Automate the whole "disable SIP and re-bless EFI after every NVRAM cleaning"

This smells like an example of the XY Problem.

You only need to click an icon in RefindPlus to toggle SIP on/off and the "BootBlesser" app automates blessing stuff. I assume you are "cleaning" the NVRAM so much that this has been a burden. Why all the cleaning?

 

[riven2000]

Actually I was only doing it once, after I had set up RFP. Looks like it reenables SIP and disables RFP, so the EFI has to be re-blessed.

 

[Dayo]

Yes, when you clear the NVRAM, the SIP setting is cleared along with the other NVRAM items and when SIP is not explictly set, the default setting, active, is used by Mac OS.

If you were following the instructions in the guide, clearing the NVRAM is a step that comes BEFORE installing RefindPlus and involves ensuring you only have natively bootable Mac OS instances connected and not AFTER installing RefindPlus.

If you do it after, you will get booted into the first bootable item the firmware finds in an ESP. If you only have RefindPlus in all your ESPs, it will be booted and all will be well. If you also have something else, that may get booted instead.

Hopefully, you did not have UEFI Windows present and got booted into that!

 

[riven2000]

Nope, it's all legacy. Now to tweak my RFP screen.