Jump to content
8755 posts in this topic

Recommended Posts

Yea I have come across this glitch before in Catalina and as I described before, that was the only remedy I found to empty the Bin of the pesky files, hope you find a solution without balking your install or maybe someone will come up with another viable idea. Good luck.

Apologies for late reply but I just trashed my install (both Big Sur and Catalina) so now the trash is cleared. I never keep important files on my laptop so it’s no biggie, just annoying.
Also putting Big Sur possibly on hold until I find out if the BCM94352Z is compatible with Big Sur and below and get it. Currently have the DW1820A and it’s not supported and I cannot get the workarounds to.....work. Sorry for o/t again. I’ll make proper thread if needed.


Sent from my iPhone using Tapatalk
9 hours ago, Sherlocks said:

@Andrey1970

hi some model firmware was update with smc version from 10.15.6 beta FirmwareUpdate.pkg

EFIPayloads:

 - IM131.88Z.F000.B00.2006101655
 - IM141.88Z.F000.B00.2006101806
 - IM142.88Z.F000.B00.2006101806
 - IM143.88Z.F000.B00.2006101806
 - IM144.88Z.F000.B00.2006101937
 - IM151.88Z.F000.B00.2006101815
 - IM161.88Z.F000.B00.2006111040
 - IM162.88Z.F000.B00.2006111037
 - IM171.88Z.F000.B00.2006161817
 - IM181.88Z.F000.B00.2006161750
 - IM183.88Z.F000.B00.2006161818
 - MB101.88Z.F000.B00.2006161757
 - MB81.88Z.F000.B00.2006111041
 - MB91.88Z.F000.B00.2006161751
 - MBA51.88Z.F000.B00.2006101654
 - MBA61.88Z.F000.B00.2006101810
 - MBA71.88Z.F000.B00.2006111040
 - MBP101.88Z.F000.B00.2006101655
 - MBP102.88Z.F000.B00.2006101655
 - MBP111.88Z.F000.B00.2006101815
 - MBP112.88Z.F000.B00.2006101814
 - MBP114.88Z.F000.B00.2006111040
 - MBP121.88Z.F000.B00.2006111041
 - MBP131.88Z.F000.B00.2006161748
 - MBP132.88Z.F000.B00.2006161749
 - MBP133.88Z.F000.B00.2006161756
 - MBP141.88Z.F000.B00.2006161817
 - MBP142.88Z.F000.B00.2006161750
 - MBP143.88Z.F000.B00.2006161755
 - MBP91.88Z.F000.B00.2006101934
 - MM61.88Z.F000.B00.2006101936
 - MM71.88Z.F000.B00.2006111040
 - MP61.88Z.F000.B00.2006101810


SMCJSONs:

 - Mac-031B6874CF7F642A: 2.14f24
 - Mac-189A3D4F975D5FFC: 2.16f68
 - Mac-27ADBB7B4CEE8E61: 2.15f7
 - Mac-2BD1B31983FE1663: 2.19f12
 - Mac-35C1E88140C3E6CF: 2.12f143
 - Mac-35C5E08120C7EEAF: 2.24f32
 - Mac-3CBD00234E554E41: 2.18f15
 - Mac-42FD25EABCABB274: 2.22f16
 - Mac-473D31EABEB93F9B: 2.36f101   <-for example, old version 2.36.f98
 - Mac-4B682C642B45593E: 2.39f40
 - Mac-551B86E5744E2388: 2.45f4
 - Mac-63001698E7A34814: 2.47f3
 - Mac-65CE76090165799A: 2.33f12
 - Mac-66E35819EE2D0D05: 2.37f24
 - Mac-77EB7D7DAF985301: 2.17f7
 - Mac-77F17D7DA9285301: 2.40f1
 - Mac-7DF21CB3ED6977E5: 2.13f15
 - Mac-81E3E92DD6088272: 2.21f92
 - Mac-937CB26E2E02BB01: 2.27f2
 - Mac-9AE82516C7C6B903: 2.35f108
 - Mac-9F18E312C5C2BF0B: 2.26f2
 - Mac-A369DDC4E67F1C45: 2.31f37
 - Mac-A5C67F76ED83108C: 2.38f11
 - Mac-B4831CEBD52A0C4C: 2.43f10
 - Mac-B809C3757DA9BB8D: 2.34f3
 - Mac-BE088AF8C5EB4FA2: 2.41f2
 - Mac-BE0E8AC46FE800CC: 2.25f87
 - Mac-CAD6701F7CEA0921: 2.44f5
 - Mac-DB15BD556843C820: 2.33f12
 - Mac-E43C1C25D4880AD6: 2.28f7
 - Mac-EE2EBD4B90B839A8: 2.42f13
 - Mac-F60DEB81FF30ACF6: 2.20f18
 - Mac-FA842E06C61E91C5: 2.23f11
 - Mac-FFE5EF870D7BA81A: 2.32f21
 

thanks in advance

 

Pull-request welcome.

On 6/30/2020 at 11:01 AM, Download-Fritz said:

Cannot you all read even the Errata doc when tinkering with obviously experimental Betas? You use KC, it is not supported, a workaround is literally spilled out for you in the PDF.

Hi, you are one of OC's developers right?

Thank you man. I wouldn't be running the newest macOS if it wasn't for your work.

 

 

  • Like 1

I've got Big Sur running under a VM on the 3970X in my signature. It's working rather well. I'm booting with v060 from 5 July and also with 11 July v060.

 

But with either commit, I'm not seeing all kexts being loaded. The only kexts loaded are those with a contents of MacOS (and using an ExecutablePath). In other words, if the kext file only contains Info.plist, it is not loaded.

 

Loaded kexts are shown with "kextstat | grep -v com.apple":

Spoiler

kextstat.thumb.png.a8d1199aa6411529d12ffdd31224597a.png

 

In example below, AGPMInjector.kext is not loaded, but AppleALC.kext is loaded (I was also trying to load BrcmBluetoothInjector, MCEReportDisabler and RadeonBooster; but none of these would load):

Spoiler

265364811_OCKernelAdd.thumb.png.c51477d786c1eba3706774f37dc4afda.png

 

Or, are these latter ones not listed with "kextstat | grep -v com.apple" because they're not actively injecting anything? If so, then how to verify that they're working?

Edited by iGPU
clarification
On 7/12/2020 at 11:28 AM, iGPU said:

I've got Big Sur running under a VM on the 3970X in my signature. It's working rather well. I'm booting with v060 from 5 July and also with 11 July v060.

 

But with either commit, I'm not seeing all kexts being loaded. The only kexts loaded are those with a contents of MacOS (and using an ExecutablePath). In other words, if the kext file only contains Info.plist, it is not loaded.

 

Loaded kexts are shown with "kextstat | grep -v com.apple":

  Reveal hidden contents

kextstat.thumb.png.a8d1199aa6411529d12ffdd31224597a.png

 

In example below, AGPMInjector.kext is not loaded, but AppleALC.kext is loaded (I was also trying to load BrcmBluetoothInjector, MCEReportDisabler and RadeonBooster; but none of these would load):

  Reveal hidden contents

265364811_OCKernelAdd.thumb.png.c51477d786c1eba3706774f37dc4afda.png

 

Hello, i am facing a problem when i try to update from catalina to BigSur (RYZEN BUILD) I USE an efi of a youtuber that managed to update to BigSur,thé installation process os working fine until the second restant here is what i've got:

the efi https://mega.nz/folder/wpI1TIKC#Pt_sDhb0M4d57Xx4FUehEg

m'y config RYZEN 2600

GT 710 ,MSI a320m bazooka ,SSD 860 Evo ,8gb ram

 

Spoiler

Screenshot_20200712_134432.jpg

 

Hello, i am facing a problem when i try to update from catalina to BigSur (RYZEN BUILD) I USE an efi of a youtuber that managed to update to BigSur,the installation process is working fine until the second restant here is what i've got:

the efi https://mega.nz/folder/wpI1TIKC#Pt_sDhb0M4d57Xx4FUehEg

m'y config RYZEN 2600

GT 710 ,MSI a320m bazooka ,SSD 860 Evo ,8gb ram

 

Spoiler

Screenshot_20200712_134432.jpg

 

1 hour ago, Malikeryy said:

Hello, i am facing a problem when i try to update from catalina to BigSur (RYZEN BUILD) I USE an efi of a youtuber that managed to update to BigSur,thé installation process os working fine until the second restant here is what i've got:

 

m'y config RYZEN 2600

GT 710 ,MSI a320m bazooka ,SSD 860 Evo ,8gb ram

 

Updating with this beta is not a good idea. Do a fresh install either of existing NVMe/SSD or USB drive.

 

(I actually did succeed in an update with ß1, initially, but then had a boot-loop during login. Apparently there is/was a problem with credentials. I gave up after this happened twice and did a fresh install; only this was successful.)

Edited by iGPU
8 hours ago, iGPU said:

 

Updating with this beta is not a good idea. Do a fresh install either of existing NVMe/SSD or USB drive.

 

(I actually did succeed in an update with ß1, initially, but then had a boot-loop during login. Apparently there is/was a problem with credentials. I gave up after this happened twice and did a fresh install; only this was successful.)

I just did a fresh install of Beta1 using the above link EFI (added correct serials etc). Credentials?   
I downloaded the Beta2 update and ran it on the install.   I used a HDD so it took about 2 1/2 hours total but all is good.   

  • Like 4

Rather than opening a thread for it, I'll just ask here. Is it possible to specify a Hardware UUID in OpenCore? In Clover setting CustomUUID achieves this.

 

I've migrated two of my hacks to OC now and in both cases I ended up with new hardware UUIDs. My remaining Clover hack is my main work machine and I'm worried that changing the UUID could affect software activations on it. So I'm a little hesitant to try just now.

 

To be clear, the UUID you set in the PlatformInfo isn't the one you will see in System Profiler.

12 minutes ago, Riley Freeman said:

Rather than opening a thread for it, I'll just ask here. Is it possible to specify a Hardware UUID in OpenCore? In Clover setting CustomUUID achieves this.

 

I've migrated two of my hacks to OC now and in both cases I ended up with new hardware UUIDs. My remaining Clover hack is my main work machine and I'm worried that changing the UUID could affect software activations on it. So I'm a little hesitant to try just now.

 

To be clear, the UUID you set in the PlatformInfo isn't the one you will see in System Profiler.

Run macserial with Clover, copy System ID, insert in SystemUUID OpenCore.

  • Like 3
32 minutes ago, Andrey1970 said:

Run macserial with Clover, copy System ID, insert in SystemUUID OpenCore.

 

Thanks! I'll try this later.

 

Tried this with my laptop and it worked perfect. I have the old UUID back. So it should be safe to work on migrating my X79 over to OpenCore now.

Edited by Riley Freeman
2 hours ago, Riley Freeman said:

So it should be safe to work on migrating my X79 over to OpenCore now. 

Check also all the other platform info and insert them in opencore config.plist.

Maybe you will need to insert them manually.

For imessage/facetime these should be needed.

I've managed to get mostly there but have got a couple of stumbling blocks. Firstly I can't figure out how to fake my CPU type (3930k to 6-Core Intel Xeon). In Clover I set it to 0x501 in the CPU section. According to the Clover conversion guide I should set this as PlatformInfo->SMBIOS->ProcessorType->1281 but it's not injecting so I still see "3.2Ghz Unknown". I didn't have a SMBIOS section until this as I've been using Generic.

 

Also when I left OpenCore to inject my GeForce 210 everything seemed to be going fine until it switched to the final boot stage (out of verbose) when it would kernel panic. The panic referred to the nvidia drivers. I grabbed an old ssdt I had for nvidia injection and this fixed the crash but I now have a @2min hang on boot while a couple of IOHDA calls time out. This may be related to HDMI but I'm not completely sure. My original SSDT didn't have a HDMI section as I've never bothered to enable this on my 210. I added one but it hasn't fixed the hang.

 

Any idea why the nvidia drivers would crash like that? I'd be happy to use OpenCore's nvidia injection over injecting another SSDT.

 

 

Edited by Riley Freeman

Hi guys,

 

Apologies if this has been discussed before. I've been away for a while. And as you probably know, the search feature of the forum hasn't been working for a while now, so... for those of you who tried Big Sur (beta 2), have you guys tried booting into the 10.16 Recovery partition? Does it work for you? Cause I'm getting this error:

OCB: LoadImage failed - unsupported

For as far as I could google, this seems to be (or at least was) pretty common for AMD builds. It's not the case for me since I'm an Intel user, so I was wondering if anyone else got the same error. I'm on OC 0.6.0.

 

Also, in case you're thinking about it, from my tests so far, it's probably a pretty bad idea to start the installation from an already booted Big Sur partition onto a Catalina partition (attempting to follow with an update on that one). I don't know what it does but it ends up throwing this error at some point during the process ("Current device configuration and target is invalid for install in the current state. Please try again.") and making that partition unbootable. Seems to have something to do with startup security, which you're supposed to set to High, from Recovery. Could also be something else entirely. That's just where I managed to find a mention of it. The problem is obviously that, since you can't boot into Recovery, you also can't change that (assuming it can be changed in the first place). Soo...backup, backup, backup.

 

Also, just in case this is in any way off-topic, I would like to kindly ask a moderator to either edit or move my post to wherever they consider a more appropriate place for it. Also, sorry for spamming.

Thank you.

Edited by arsradu

Yeah, initially I tried without it, and it didn't work for me. Could be that I missed something... After that, I added apfs.efi to Drivers to see if it makes any difference and that finally allowed me to boot into BS Recovery.

 

I'll try to look more into it (I most likely missed something) and see if I can get it to boot without the actual apfs.efi driver.

 

Thank you very much for the feedback!

8 hours ago, ghost8282 said:

Check that PlatformInfo --> Automatic is not set to true.

Note that you need to add manually all the keys when it is set to false.

 

I managed to find the values I needed to add here. I now have the CPU showing as a Xeon.

 

I also fixed my hanging IOHDA issue by rolling back to an older AppleALC version and injecting no-hda-gfx to disable HDMI. Still don't know why OpenCore's nvidia injection was crashing but my SSDT works fine.

 

Thanks for the help!

Edited by Riley Freeman
8 hours ago, Pavo said:

apfs.efi is not needed with the latest OpenCore to boot into BS Recovery, only need to set JumpstartHotPlug to true/yes.

 

Pavo,

 

I tried booting into BS Recovery with JumpstartHotPlug enabled, but see error: "OCB: LoadImage failed - Unsupported" and OC won't boot into Recovery. Instead, selecting the "Recovery 10.16" disk repeatedly loops back to menu (but from there, I can successfully boot into BS). I'm using OCBuilder compiled v060 (14 July).

 

Also, do you have any comments about my earlier post here?

 

Thanks.

Edited by iGPU
3 hours ago, iGPU said:

Instead, selecting the "Recovery 10.16" disk repeatedly loops back to menu (but from there, I can successfully boot into BS)

Did your installation complete successfully, without any forced shutdown?

I noticed the same behaviour (loop when trying to access recovery) when I forced a shutdown at Forcing CS_RUNTIME for entitlement : com.apple.rootless.restricted-block-devices

On 7/15/2020 at 7:18 AM, iGPU said:

 

Pavo,

 

I tried booting into BS Recovery with JumpstartHotPlug enabled, but see error: "OCB: LoadImage failed - Unsupported" and OC won't boot into Recovery. Instead, selecting the "Recovery 10.16" disk repeatedly loops back to menu (but from there, I can successfully boot into BS). I'm using OCBuilder compiled v060 (14 July).

 

Also, do you have any comments about my earlier post here?

 

Thanks.

Injector kext (ones without a ExecutablePath) do not show up in kextstat, you need to check IORegistryViewer to see if it loaded, For example AGPMInjector below:

 

 

Spoiler

Screenshot 2020-07-15 08.52.08.png

 

 

Spoiler

Screenshot 2020-07-15 08.52.40.png

 

  • Like 2
14 hours ago, ghost8282 said:

Did your installation complete successfully, without any forced shutdown?

I noticed the same behaviour (loop when trying to access recovery) when I forced a shutdown at Forcing CS_RUNTIME for entitlement : com.apple.rootless.restricted-block-devices

 

I've already installed BS. I now simply want to boot into Recovery rather than directly into BS.

3 hours ago, Sbrillo said:

how to add GUI on OpenCore 6.0 and boot chime?

 

it's OpenCore 0.6.0 -- not yet reached 6.0 :)

 

Read the manual (Configuration.pdf -- hint look for OpenCanopy & AudioSupport).

Then download the Resources folder from https://github.com/acidanthera/OcBinaryData (also mentioned in the manual)

You do not need all the Audio files in the Resources folder if you only want the chime.

 

×
×
  • Create New...