Contribute
Register

Opencore - Seeking advice

Status
Not open for further replies.
1) Not an upgrade just an update of a working Big Sur from OC 0.7.0 to 0.8.7 (to refresh dated skills set).
2) YES but USB kext was working on OC 0.7.0
3) YES and disabled iGpu to enable Big Sur to work with Imac SMBIOS.

I hope that helps in finding a solution.
 
Have gone back to manual ... I assume I remove:

Checking for values missing from working Sample:

Sample.plist -> Misc -> Debug - Missing Key: SerialInit
Sample.plist -> Misc -> Security - Missing Key: AllowToggleSip
Sample.plist -> Misc -> Security - Missing Key: AllowNvramReset
Sample.plist -> NVRAM - Missing Key: LegacyEnable
Sample.plist -> UEFI -> Audio - Missing Key: AudioOut
Sample.plist -> UEFI -> Audio - Missing Key: MinimumVolume
Sample.plist -> UEFI -> Audio - Missing Key: VolumeAmplifier
which is why I don't really recommend the configurators :)

I normally open up my config.plist and then the sample.plist using PlistEditPro and check the differences

you have the correct idea in using ocvalidate to check the config.plist first

then i would for example, look for SerialInit in the sample.plist to see where it goes and then add that to my config.plist

make all those changes and then re run ocvalidate to make sure I didn't break anything

regarding MinDate and MinVersion, that can be left at 0 for Big Sur
 
which is why I don't really recommend the configurators :)

I normally open up my config.plist and then the sample.plist using PlistEditPro and check the differences

you have the correct idea in using ocvalidate to check the config.plist first

then i would for example, look for SerialInit in the sample.plist to see where it goes and then add that to my config.plist

make all those changes and then re run ocvalidate to make sure I didn't break anything

regarding MinDate and MinVersion, that can be left at 0 for Big Sur

Just having dinner my end of the world (+8 GMT).

Will evaluate all the above. @UtterDisbelief I realise I haven't answered your queries accurately. Will make better analysis and edit the above.

@Feartech I was surprised you made the suggestion as I have, since using OC, tried to follow the best policy, rather than the easy methods.
 
Just having dinner my end of the world (+8 GMT).

Will evaluate all the above. @UtterDisbelief I realise I haven't answered your queries accurately. Will make better analysis and edit the above.

@Feartech I was surprised you made the suggestion as I have, since using OC, tried to follow the best policy, rather than the easy methods.
only because there has been many changes to the config.plist since your previous version :)
 
@Feartech / @UtterDisbelief so have finally got the system back to a working BigSur 11.4 on OC 0.7.0 via SSD EFI.

@UtterDisbelief tried all the USB2 slots and still got "prohibited" on all including USB3, albeit, only one of the USB2 slots (above Firewire) recognized the USB drive.

Boot off USB is obviously OC 0.8.7 as picker images are different.

USB kext attached.

Am at the end of my night as I have a 4:30AM start tomorrow. Am proceeding to make Carbon Copy clone drive and will attempt more at a later time.

EDIT - MEH **** I think I have worked it out. USB kext is from when using SMBIOS 14,2 ... rather than the spoofed 15,1 for Big Sur?

EDIT 2 - Maybe not depsite IOKitPersonalities being wrongly labelled in USB kext?
 

Attachments

  • Screen Shot 2022-12-11 at 7.56.22 pm.png
    Screen Shot 2022-12-11 at 7.56.22 pm.png
    24.5 KB · Views: 15
  • Screen Shot 2022-12-11 at 8.07.59 pm.png
    Screen Shot 2022-12-11 at 8.07.59 pm.png
    85.7 KB · Views: 22
  • Screen Shot 2022-12-11 at 8.09.31 pm.png
    Screen Shot 2022-12-11 at 8.09.31 pm.png
    34.8 KB · Views: 14
Last edited:
@Feartech / @UtterDisbelief so have finally got the system back to a working BigSur 11.4 on OC 0.7.0 via SSD EFI.

Per challenge of updating OC some tips:

• ocvalidate does-not and can-not ensure that a config.plist is correct/useful. It's a syntax checker that helps you eliminate grammatical errors.
• ocvalidare can tell you when config items are needed-but-missing, deprecated and mis-specified. It does sanity checking of value type/format per the spec, but can't know if config is correct for a use-case.
• Every OC release includes documentation (spec) Configuration.pdf which explains every config schema item, with the accompanying sample.plist to show examples of each.
• The most common errors are naturally old config.plist items which have been removed from spec (unknown config that's no longer a part of OC or user error) and new OC schema additions where your old config.plist needs addition of parameters or changes of param values to accommodate new/changed features. The bigger the version difference, the more parameter / schema changes you can expect.
• Schema means the format and range of acceptable config.plist entries. IOW ocvalidate compares every entry it finds with the schema for that OC version to determine if the entry fits in context. When ocvalidate reports "no schema" its saying it doesn't recognize the entry in context. Just because it doesn't recognize an entry doesn't make it wrong or bad. Ocvalidate doesn't know anything about appropriateness of config. It's just a warning to you to remind you to understand the entry and why it's there.
• When ocvalidate calls out key errors, you need to fix those because the given entry will not function as intended if it's parameters are incorrect. "failsafe" is the default value which OC adopts when it encounters parameters it doesn't recognize.
• The job of creating a correct / useful config.plist is far beyond the scope of ocvalidate. Configurators offer more per-build contextual assistance, with the caveat that they also add additional ways to be wrong, including that the configurator may produce config which is erroneous for a given version of OC, which ocvalidate may or may not detect.

In general, you should attend to all ocvalidate errors because they suggest likely configuration errors, ranging from an incomplete config to wrongly-specified config where at its worst, the config.plist is so defective that OC cannot completely interpret it. For this reason any error from ocvalidate should be considered unacceptable even though an erroneous config.plist could can be found to work.

Consult the Configuration.pdf that comes with the OC version to understand OC parameters and formats and gain insights into features.

In your case, avoid configurators
as they will lead you down a primrose path which might just as well introduce errors for your old build as help you avoid them. As you had a previously working config and as when OC advances it doesn't tend to invalidate previously working configs (notwithstanding that a config.plist could have errors and still work, and that OC progress could expose such an error in a build, but let's assume your config is basically OK) it's safest to do what you have been so far: just run ocvalidate and look up its errors in Configuration.pdf.

For example, per your post in the other thread on 0.8.7 diffs

NOTE: This version of ocvalidate is only compatible with OpenCore version 0.8.7!
OCS: No schema for HibernateSkipsPicker at 2 index, context <Boot>!
This says that ocvalidate doesn't recognize the parameter HibernateSkipsPicker. Is it in documentation Confguration.pdf?
OCS: Failed to calculate size of true field containing <empty> as type integer, context <ShowPicker>!
This says ShowPicker's value is the wrong type or is not appropriate. Again look in the documentation.
Serialisation returns 2 errors!
Completed validating /Volumes/Big Sur — Data/Users/Desktop/OC 0.8.7 Big Sur/plists/OC 0.8.7 Boot Fail.plist in 1 ms. Found 2 issues requiring attention.
I was not able to follow how your USB got impugned in all this re boot failure with prohibited sign—maybe I didn't read thread carefully enough— but if you have boot picker config errors it's not a surprise to see a system respond with a basic OS load fault.

Hth
 
@
Per challenge of updating OC some tips:

• ocvalidate does-not and can-not ensure that a config.plist is correct/useful. It's a syntax checker that helps you eliminate grammatical errors.
• ocvalidare can tell you when config items are needed-but-missing, deprecated and mis-specified. It does sanity checking of value type/format per the spec, but can't know if config is correct for a use-case.
• Every OC release includes documentation (spec) Configuration.pdf which explains every config schema item, with the accompanying sample.plist to show examples of each.
• The most common errors are naturally old config.plist items which have been removed from spec (unknown config that's no longer a part of OC or user error) and new OC schema additions where your old config.plist needs addition of parameters or changes of param values to accommodate new/changed features. The bigger the version difference, the more parameter / schema changes you can expect.
• Schema means the format and range of acceptable config.plist entries. IOW ocvalidate compares every entry it finds with the schema for that OC version to determine if the entry fits in context. When ocvalidate reports "no schema" its saying it doesn't recognize the entry in context. Just because it doesn't recognize an entry doesn't make it wrong or bad. Ocvalidate doesn't know anything about appropriateness of config. It's just a warning to you to remind you to understand the entry and why it's there.
• When ocvalidate calls out key errors, you need to fix those because the given entry will not function as intended if it's parameters are incorrect. "failsafe" is the default value which OC adopts when it encounters parameters it doesn't recognize.
• The job of creating a correct / useful config.plist is far beyond the scope of ocvalidate. Configurators offer more per-build contextual assistance, with the caveat that they also add additional ways to be wrong, including that the configurator may produce config which is erroneous for a given version of OC, which ocvalidate may or may not detect.

In general, you should attend to all ocvalidate errors because they suggest likely configuration errors, ranging from an incomplete config to wrongly-specified config where at its worst, the config.plist is so defective that OC cannot completely interpret it. For this reason any error from ocvalidate should be considered unacceptable even though an erroneous config.plist could can be found to work.

Consult the Configuration.pdf that comes with the OC version to understand OC parameters and formats and gain insights into features.

In your case, avoid configurators
as they will lead you down a primrose path which might just as well introduce errors for your old build as help you avoid them. As you had a previously working config and as when OC advances it doesn't tend to invalidate previously working configs (notwithstanding that a config.plist could have errors and still work, and that OC progress could expose such an error in a build, but let's assume your config is basically OK) it's safest to do what you have been so far: just run ocvalidate and look up its errors in Configuration.pdf.

For example, per your post in the other thread on 0.8.7 diffs


This says that ocvalidate doesn't recognize the parameter HibernateSkipsPicker. Is it in documentation Confguration.pdf?

This says ShowPicker's value is the wrong type or is not appropriate. Again look in the documentation.

I was not able to follow how your USB got impugned in all this re boot failure with prohibited sign—maybe I didn't read thread carefully enough— but if you have boot picker config errors it's not a surprise to see a system respond with a basic OS load fault.

Hth
@c-o-pr the ONLY reason I tried the configurator was due to previously given advice. Since starting with Opencore I have avoided auto configurators like the plague.

It’s been years since I have updated my Hack working on the premise “it’s not broke don’t fix it”. However, as I am now wanting a new Hack, in the hope I can achieve another decade odd with a single computer and be happy, I thought it best to start by updating Opencore to the latest version.

Silence is Golden is less than 50c a day cost and still performs excellently day by day with one AIO water cooling failure in its life. I like the AppLe environment but not the hardware cost (particularly in AUS).

Thank you for the very concise reply as I’ve learnt new terminology and methodology … and increased my knowledge.
 
@

@c-o-pr the ONLY reason I tried the configurator was due to previously given advice. Since starting with Opencore I have avoided auto configurators like the plague.

It’s been years since I have updated my Hack working on the premise “it’s not broke don’t fix it”. However, as I am now wanting a new Hack, in the hope I can achieve another decade odd with a single computer and be happy, I thought it best to start by updating Opencore to the latest version.

Silence is Golden is less than 50c a day cost and still performs excellently day by day with one AIO water cooling failure in its life. I like the AppLe environment but not the hardware cost (particularly in AUS).

Thank you for the very concise reply as I’ve learnt new terminology and methodology … and increased my knowledge.
FWIW, here's the procedure I follow for updating OC, never failed me. ;)
 
I'll park the Opencore update from 0.7.0 to 0.8.7 config.plist issues for the moment.

I don't know whats going on with USB kext ... USB kext was created when I first moved from Clover to Opencore in line with @Stork guide for our MB. It was working for the OSX update from Catalina to BigSur as I installed using the normal USB install method.

However (on OC 0.7.0), using latest Hackintool with same USB kext I get the 15 ports in Catalina (fully updated) using Imac 14,2:

Screen Shot 2022-12-12 at 4.36.32 pm.png


On Bigsur 11.4 using latest Hackintool with same USB kext I get the 12 ports in Catalina (fully updated) using Imac 15,1:

Screen Shot 2022-12-13 at 9.25.14 am.png


The images are taken one after the other and no changes bar boot drives.

I do remember that the GA-Z77X-UP5 TH has some strange USB setup that caused multiple issues trying to create the initial working USB kext. When you view the difference you'll notice that USB receiver is missing in Bigsur yet my mouse is working?
 
USBPorts.kext states the SMBIOS version of the system used when the kext was created. So in your case iMac14,2 is stated twice in the USBPorts.kext/Contents/info.plist.

If you have now changed the system SMBIOS to iMac15,1 so you can run Big Sur, you need to change the 2 x entries in the kext's info.plist to match the new SMBIOS.

As shown in the two screenshots below, showing the two entries in a similar info.plist, when viewed in ProperTree.

Screenshot 2022-12-13 at 21.16.10.png SMBIOS/XHC name highlighted

Screenshot 2022-12-13 at 21.16.22.png Model name highlighted

Both need to be changed for the kext to activate your USB ports.

To change these settings in the kext you need to do the following.
  1. Right-click on the kext and select 'Show Package Contents' from the sub-menu.
    • Screenshot 2022-12-13 at 21.25.41.png
  2. Double-click the Contents folder.
    • Screenshot 2022-12-13 at 21.25.50.png
  3. Double-click the info.plist and it should open with your default plist editor (ProperTree)
    • Screenshot 2022-12-13 at 21.25.59.png
  4. Make the 2 x edits and save the info.plist.
When you reboot as the SMBIOS will now match the model in the kext your USB ports will be working again.
 
Status
Not open for further replies.
Back
Top