Perhaps create a thread and ask there?
There is a bug indeed. The values are generated correctly but then overwritten by a setting added in v063. That is, it worked up to v062. A fix will be in the next release.
Last edited:
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 RefindPlus|OpenCore by MyBootMgr
- Thread starter Dayo
- Start date
-
- Tags
- multi boot opencore refindplus
- Sort by reaction score
cMP5,1 and Apple BOOTCAMP assistant for creating Windows 10 partition
Here is a little study on the official BOOTCAMP for the cMP5,1. It may be valid for other Macs, but it is not guaranteed. As you may know BOOTCAMP assistant throws this message, when you try to open it in an APFS formatted drive (Mojave and Catalina): I modified the BOOTCAMP Info.plist from a...
forums.macrumors.com
but it's fun. If you have RefindPlus, might as well look at the EFI Shell.
First thing you do is type
mode to get a list of text modes.Then type
mode x y to change the mode to the one with the most vertical lines.Then type
help for a list of commands.Then type
map for a list of file systems and block devices.Then type
fs0: to chose the first file system (like C drive of Windows)Then type
ls to get a list of files on that file system.If it has an EFI folder, then it's probably an EFI partition and you can use mkdir to make a directory and cd to change directory, and you can do commands and pipe their output to a file
dmpstore > dmpstore.txtThen you can boot into macOS, mount the EFI partition, and view the file you created.
The point is to gather info about your system so you can tell if Windows changes anything important afterward. You can discover what nvram variables it changes, or what boot code it adds to the MBR or PBR.
A VM is one way to do it. You still want to gather the info about your system before doing the install. So you have something to compare when it's done.
You don't need to change to MBR. You keep GPT and make hybrid MBR/GPT which is the same as GPT except the first block contains boot code to do BIOS boot of Windows, and the first block has a MBR partition table with up to 3 partitions specified (first partition should still by type EE - for EFI but is changed to extend only to the start of the first partition). iPartition.app does this with a couple clicks. Use the dumpvols.sh script before and after you do iPartition, to learn what iPartition does to your disk. iPartion.app cannot resize APFS partition so leave them alone. If you need to resize an APFS partition to create the FAT partition, then use Disk Utility.app to create the new partition. Then use iPartition.app to make the new partition Active and Visible in Windows.
It's a FAT partition on a hybrid GPT/MBR disk. macOS treats it as GPT. Windows will treat it as MBR. Don't do partitioning in Windows. Only use Windows to erase the partition as NTFS (you can tell what partition is the correct one by looking at the size and name).
Strange that you're not getting any 16:9 modes. Maybe the Radeon EFI driver sucks. But at least you're getting an image. Unless it's using the wrong GOP or UGA on GOP or something weird. In EFI Shell (access from RefindPlus), you can do this command (after setting the current directory to a writable directory as explained above.
dh > dh.txtdh -d -v > dh_d_v.txtEdit: script moved to https://gist.github.com/joevt/a99e3af71343d8242e0078ab4af39b6c
Last edited:
Correct. I just did a research on the Bootcamp operation from BigSur in cMP:
forums.macrumors.com
cMP5,1 and Apple BOOTCAMP assistant for creating Windows 10 partition
I have just played with the BOOTCAMP assistant in BigSur. It works for the cMP for creation of Windows 10 partition in MBR (hybrid) mode. First I created a BigSur on an external hard drive (NVME) on MBP15,1: Secure Boot- No security, External Boot- Allow booting from external media. I have an...
forums.macrumors.com
Somehow the latest Mojave security update facked up my BootMgr.. so it is not working anymore.
I have delete it with the uninstall tool. But now everytime when I want to try to start the 'configFactory' it says: Please uninstall Lilu to proceed. I totally not know what to do..
Who can help me?
Kind regards,
Mark
I have delete it with the uninstall tool. But now everytime when I want to try to start the 'configFactory' it says: Please uninstall Lilu to proceed. I totally not know what to do..
Who can help me? Kind regards,
Mark
Thanks for that info. its a lot to digest, but I will. One quick question...
cMP5,1 and Apple BOOTCAMP assistant for creating Windows 10 partition
Here is a little study on the official BOOTCAMP for the cMP5,1. It may be valid for other Macs, but it is not guaranteed. As you may know BOOTCAMP assistant throws this message, when you try to open it in an APFS formatted drive (Mojave and Catalina): I modified the BOOTCAMP Info.plist from a...
Once I setup a legacy Windows install on a hybrid MBR drive, presuming I decide to do it that way...do you then boot into windows WITHOUT OpenCore? Just use rEFInd's direct boot to the volume without OC in that case?
One more thing I want to ask before I forget. As I setup this rEFInd/OpenCore Mac...It is finally occurring to me a couple things:
So the above leads me to believe that I cannot do what I had hoped to do. I had hoped to setup a rEFInd setup that would have two OC icons for Catalina (with and without VMM), two icons for BigSur (with and without VMM) and then a direct Volume icon that would boot up Mojave (without OC) and a direct Volume icon to boot up Windows (without OC)
that's a nice idea, but as far as I can tell, I'm not sure I can do that because I haven't been able to figure out a way to configure in the OC
Right?
So the boot up procedure I guess would always be...select the OC instance I want...and then then also make sure to select the desired OSX volume in the OC Boot Picker menu as a second step... Two boot selections, one after the other, whenever booting to either Catalina or BigSur.
Am I Understanding this correctly or is there another variation on configuration I can look into to try to make this a little more automatic so that if I select a particular OC instance, it will then directly boot the particularly version of OSX that it is setup for?
- rEFInd can launch instances of OC or it can directly launch volumes without OC. (check)
- When using OpenCore, it does not appear to be straightforward to specify which precise volume I want that one particular OC instance to boot into. It appears that an OC instance will have the possibility to use a different
config.plistwith potentially different kext injection, etc..but...the "normal" way to use OpenCore is to let it scan all volumes and thne either select the specific volume in OC BootPicker...or depend on the "default"
- But the "default" is not something I can configure in rEFInd or OpenCore (right?)..its a global NVRAM parameter that gets specified by using System Preferences to select the startup disk.
So the above leads me to believe that I cannot do what I had hoped to do. I had hoped to setup a rEFInd setup that would have two OC icons for Catalina (with and without VMM), two icons for BigSur (with and without VMM) and then a direct Volume icon that would boot up Mojave (without OC) and a direct Volume icon to boot up Windows (without OC)
that's a nice idea, but as far as I can tell, I'm not sure I can do that because I haven't been able to figure out a way to configure in the OC
config.plist, which actual volume to boot to...it is always dependent on the global NVRAM setting.Right?
So the boot up procedure I guess would always be...select the OC instance I want...and then then also make sure to select the desired OSX volume in the OC Boot Picker menu as a second step... Two boot selections, one after the other, whenever booting to either Catalina or BigSur.
Am I Understanding this correctly or is there another variation on configuration I can look into to try to make this a little more automatic so that if I select a particular OC instance, it will then directly boot the particularly version of OSX that it is setup for?
ConfigFactory has detected that you have Lilu, and perhaps others such as Whatevergreen, installed outside OpenCore. As OpenCore would also inject these, having them in place would lead to a conflict and thus, it does not proceed.
You need to uninstall any such potentially conflicting Kext that is flagged by ConfigFactory first: https://www.maketecheasier.com/add-remove-kexts-from-macos
question about the RefindPlus configuration being used in MyBootMgr: I notice that there is an overrides dir with override.conf. I can't find any mention about this capability of using a separate override.conf file...anywhere in the docs of rEFInd. Is this an extension built into RedindPlus to use an overrides dir?
Default is "noscale", but made that setting and no change. Likewise, tried "fillscreen" and no change either.
The banner imagedoesn;t look bad anyway, it's the icons that are skewed.
Attachments
It uses the include feature from rEFInd. Take a look at the refind.conf file to see how it is brought in.
There is a page in the rEFInd docs that explains this.
question about Innie.kext and AHCI_3rdParty_SATA.kext. Are these needed when using OpenCore `DeviceProperties`?
I am using a Sonnet Tempo SATA SSD card (not NVMie). It has two SSD drives on it.
It has been working with with this setup, until last night one of the drives suddenly disappeared completely from the desktop and from disk utility too. At first I am very worried, oh no..the drive must be bad or something, but now I'm wondering if this is related to OSX thinking its an external drive and somehow getting confused about its connection as an external drive.
Wondering if I should use DeviceProperites configuration in OC (as described by CDF on the OpenCore thread), or this approach as handled by MyBootMgr, with Innie.kext and possibly the 3rdParty kext (I'm not sure exactly).
Any info from anyone that has followed the progression of that situation and knows the current best thing to do is?
I don't understand what is so confusing about the instructions in the guide.
It says there are two quick and easy options ... Innie or the 3rd party SATA Kext. It says try Innie first and then the latter if Innie does not work and reminds to disable Innie first before.
Alternatively it says, there is a more involved method that is guaranteed to work and explains how to do it including a reminder to make sure the other two are disabled if using this.
The purpose of the guide is to present the best thing to do.
While not recommended and not supported, you are free as a user to mix and match with stuff from elsewhere although the guide works on its own if followed literally.
However, some will always want to beat their own paths and you just need to know what you are doing if mixing and matching. Suggest referring queries to the sources of those items in such instances.
Last edited:
I wasn't asking for instructions how to do it, I was asking for an explanation of the difference between using Innie.kext or using OpenCore's DeviceProperties, as described in CDF's guide. I went with the latter and it seems to be working fine, but I would like to understand the pros and cons of this approach vs Innie.kext, for example. My understanding as of now is that Innie.kext is an older approach that perhaps was more useful without OpenCore. But I do not really know how to decide which way is the preferred way to do it..other then presuming for now that CDF's post on the other thread is more current with regards to the best way to set it up.
I am curious also why you chose to handle it that way in MyBootMgr instead of the way that CDF has arrived to on the OpenCore thread? If you know some particular reason why that approach is preferable, then I would still consider it, but I would like to know why.
I think the best approach is the "built-in" device property. Unfortunately it did not work on the MBP15,1. None of the kexts work there either (BigSur). Next good approach (which worked in BigSur on the MBP15,1) is to go to the bundle identifier and make the device appear internal from external like this:
OpenCore on the Mac Pro
Here is how I did it: Patch Arch x86_64 Base Comment IONVMeFamily Patch#External Count 0 Enabled...
forums.macrumors.com
With the above patch in the Kernel all NVME devices will appear internal. For AHCI devices find:
Code:
<key>Patch</key>
<array>
<dict>
<key>Arch</key>
<key>x86_64</key>
<key>Base</key>
<string></string>
<key>Comment</key>
<string>IOAHCIBlockStorage Patch#External</string>
<key>Count</key>
<integer>0</integer>
<key>Enabled</key>
<true/>
<key>Find</key>
<data>
RXh0ZXJuYWw=
</data>
<key>Identifier</key>
<string>com.apple.iokit.IOAHCIBlockStorage</string>
<key>Limit</key>
<integer>0</integer>
<key>Mask</key>
<data>
</data>
<key>MaxKernel</key>
<string></string>
<key>MinKernel</key>
<string></string>
<key>Replace</key>
<data>
SW50ZXJuYWw=
</data>
<key>ReplaceMask</key>
<data>
</data>
<key>Skip</key>
<integer>0</integer>
</dict>
</array>
Last edited:
This is a question about the intricacies of the workings of OpenCore and is the type of question users have been kindly requested in the guide in Post 1, as well as directly to you on a few previous examples, to direct to the OpenCore thread in order to keep the noise level here to a minimum and to maintain a focus on the mechanics of implementation in this thread as much as possible.
Use whatever works for you and to dig into details or for an exposition on such matters, please post to the OpenCore thread or create one:
Post 1 lays out three ways to achieve this purpose with one of them flagged as being guaranteed to work (Implying the other two may not work). Are you saying you have tried all three and none of them are working? That would be a good example of a relevant post here.
Last edited:
I am asking you a specific question about MyBootMgr, it doesn’t make any sense whatsoever to ask that question on the other forum thread. The question is: why did you choose to use the kext injection instead of device properties?
If you don’t know the answer just say so.
On the other thread you lectured me about asking the wrong questions there. In this thread you lecture me about asking the wrong questions here. Meanwhile you choose not to ever answer the question.
If you don’t know the answer just say so.
On the other thread you lectured me about asking the wrong questions there. In this thread you lecture me about asking the wrong questions here. Meanwhile you choose not to ever answer the question.
@startergo thanks for the insight about deviceproperties. Seems to be working so far for me on 5,1 catalina so I’ll stick with that for now unless dayo or anyone can give me specific reason why I would want to do the kext approach. Seems like this probably depends on the hardware you’re using. I don’t know what will happen when I go to Big Sur eventually. Might requiere kext for that, is that why?
I am also asking you a specific question which you don't seem to understand.
I repeat it ... There are three methods in the guide. Have you tried the three? Have you even taken the time to consider them? If you did, you would notice that two involve kexts and the third, which involves device properties and is stated as a guaranteed to work method, is basically the same thing as your "cdf" method.
So again ... have you tried all three methods set out in the guide?
I chose not to answer the question because the question implies you have not read the guide and the question would not come up if you had since the guide does not simply offer kext based methods to the exclusion of device properties as the question suggests.
That is a mis-characterisation of what happened.
You had asked a question there to which I had responded and explained to you that your issue was not related to what you thought it was caused by. I suggested that you do a search for a certain item to give you further insight.
You came back insisting it was but as you had indicated you could not find anything after a search, I took the time to do the search, explained the matter once again and provided you with the search links.
Your response to that was still insistent on your initial assumptions and you had not considered anything that had been explained or even bothered to follow the links provided and it was only then that you got a more forthright response.
Last edited:
My understanding is that Innie is a ubiquitous standards approach (kext injection is a “catchall” that will serve most setups without bespoke settings specific to particular hardware setups) while the device properties approach is specifically curated for the particular hardware setup and a moving target and subject to change between reboots if hardware is changed (adding/removing/moving components in PCIe slots or SATA bays). I wouldn’t even know how you could programme the latter into MyBootMgr, so maybe it’s too complex.
I can sense your frustration, however maybe ease off a little. Dayo is working tirelessly with this, and I certainly don’t want him demotivated or distracted, so maybe patience is a virtue. Your question is posed (in more than one place) and someone in the community will answer it if it can be.
I can sense your frustration, however maybe ease off a little. Dayo is working tirelessly with this, and I certainly don’t want him demotivated or distracted, so maybe patience is a virtue. Your question is posed (in more than one place) and someone in the community will answer it if it can be.
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.
In this particular instance, the question is framed as if the guide only provides a way to do this using kexts but a cursory glance at it would show that this is not the case. Which leaves me lost as to how the question came to be in the first place.
However, if notwithstanding the guide, the user still wants to understand the differences between using a kext or device properties, this I can understand but would prefer them to point this to the OpenCore thread instead. Others are however welcome to pitch in of course.
BTW, you touch on one important item here which I need to think of how to add to the guide.
If I get run over by a bus tomorrow or stop making updates for whatever reason, the codebase for RefindPlus is on GitHub and the current version as it stands can be built by anyone (instructions are there on GitHub and are quite simple).
You can also easily swap in a new release of OpenCore into your current setup directly or for a new starter, run MyBootMgr and then swap in the then current OpenCore.
An important development is that the patch that was needed to create OC_ALT will not be required as from OpenCore v0.6.4. This means that you can copy an "OC" folder and rename as "OC_ALT" and edit the config file as needed.
Does not have to be called "OC_ALT" but the code in the Helper Tools expect that name so using this name will keep everything working as before.