Contribute
Register

[HOW TO] OpenCore 0.8.1 > 0.8.2 differences

Status
Not open for further replies.
I must say that since OC 0.8.1, it occasionally "seems" to boot but gives a 10s black screen instead and comes back to the picker (without rebooting!) then I press Return and it boots normally... I've cleared NVRAM to no avail.
I have had kinda similar problems in the past, when trying to cut corners by dragging stuff from a previous-version config.plist to the new sample.plist. It seems that there is much more "underhood" in the plist than is apparent, and that it's better to start fresh with the new plist. YMMV.
 
I have had kinda similar problems in the past, when trying to cut corners by dragging stuff from a previous-version config.plist to the new sample.plist. It seems that there is much more "underhood" in the plist than is apparent, and that it's better to start fresh with the new plist. YMMV.
And ocvalidate didn't spot any difference? :eek:
I'm doing the other way around: ProperTree's OC Clean Snapshot of Sample.plist and moving any difference from Sample.plist to config.plist in PlistEdit, but who knows... That's something to check, then.
 
And ocvalidate didn't spot any difference? :eek:
I'm doing the other way around: ProperTree's OC Clean Snapshot of Sample.plist and moving any difference from Sample.plist to config.plist in PlistEdit, but who knows... That's something to check, then.
Didn't ever use OCValidate, or ProperTree either. Have stuck exclusively with PlistEditPro (forever).
 
Didn't ever use OCValidate, or ProperTree either. Have stuck exclusively with PlistEditPro (forever).
always worth checking your edited config.plist with ocvalidate before booting from it
 
always worth checking your edited config.plist with ocvalidate before booting from it
True that, but as I wrote, I no longer edit my previous config.plist. I now always start with the new sample.plist and only use the previous version for comparison.
 
Strange: I updated OC to 0-8-2 but on my boot screen it still indicates 0-8-1

I did several time the update it doesn't change anything. Before I could reset the NVRAM in order to change this.
 
Strange: I updated OC to 0-8-2 but on my boot screen it still indicates 0-8-1

I did several time the update it doesn't change anything. Before I could reset the NVRAM in order to change this.
add in ResetNvramEntry.efi and reset nvram
 
I must say that since OC 0.8.1, it occasionally "seems" to boot but gives a 10s black screen instead and comes back to the picker (without rebooting!) then I press Return and it boots normally... I've cleared NVRAM to no avail.
Not a big deal, though, so I'm waiting to see if it gets fixed in future versions or if I'd better stick to 0.7.9 or 0.8.0 (it can also be a kext issue...)
A little update about that mini-bootloop: I put back in OC 0.8.2's EFI all the kexts contemporaneous with OC 0.7.9 and after a few days it came back, so it's peculiar to 0.8.1+ and not the kexts.
I'm reverting now to OC 0.8.0 with current kexts, I'll let you know.

EDIT 0.8.2: after various trials, it's been 3 days now, without the mini-bootloop so it's very likely that the issue was due to my changing EnableSafeModeSlide and ProvideCustomSlide to NO, in order to try and boot in Safe Mode (which was not very successful anyway...)
It was hard to identify as most of the times it was booting normally. :rolleyes:
On the other hand, the KP with AppleALC-1.7.3 happens as well with my Z68 (Ivy) and my DELL Optiplex 3020 (Haswell), so it's clearly a bug in that kext version.
 
Last edited:
The OpenCore team has been working on different parts.
Adaptation to macOS 13 Ventura developer beta has been the one that has received the most contributions. In addition, new layouts have been added on AppleALC.
OpenCore 0.8.2

Main changes
  • Updated builtin firmware versions for SMBIOS
  • Updated --restore-nosnoop info to avoid breaking sound in Windows or Linux at boot
  • Added injected kext bundle version printing in DEBUG builds
  • Added Linux compatibility for CreateVault scripts
  • Fixes for macOS 13.
config.plist

Nothing to do.

Kexts

All kexts have received support for macOS13.
  • AirportBcrmFixup 2.1.6
  • AppleALC 1.7.3: layouts added, sleep fixes for certain layouts
  • BrcmPatchRAM 2.6.3: improved macOS 12 support
  • CPUFriend 1.2.6
  • CpuTscSync 1.0.9:
  • DebugEnhancer 1.0.7
  • FeatureUnlock 1.0.9
  • HibernationFixup 1.4.6
  • Lilu 1.6.1
  • MacHyperVSupport 0.9: fixes and improvements
  • NVMeFix 1.1.0: improved macOS 12 support
  • RestrictEvents 1.8.0: fixes for real Macs, MacPro7,1 patch for Ventura
  • VirtualSMC 1.3.0
  • VoodooRMI 1.3.5: device updated
  • WhateverGreen 1.6.0: fixes, Intel FAQ updated.
Hi @miliuco! I've got a question about ForceDisplayRotationInEFI: I can't find many explanations about it, I thought it was meant to rotate the picker but it doesn't change neither the picker nor MacOS's display.
This is for a DELL Optiplex 3020 SFF with video output through a Display Port>VGA adapter. Presently, it boots with the original 0° rotation until half the white apple then applies the 90° rotation (which is currently set in Monitor prefs).
 
I assume this question refers to a Hack and not a real Mac system.

That being the case this is what the Configuration manual says regarding the ForceDisplayRotation entry.

Screenshot 2022-07-23 at 18.22.03.png

Assuming your system doesn't natively support Display rotation from boot:
  1. You might want to try enabling the DirectGopRendering entry in the UEFI > Output section.
  2. As well as the AppleEg2Info entry in the UEFI > ProtocolOverrides section.
Both are set as False/Disabled by default, as shown in the extract from the Sample.plist from OC 0.8.2.

Screenshot 2022-07-23 at 18.26.01.png
 
Status
Not open for further replies.
Back
Top