Jump to content
3338 posts in this topic

Recommended Posts

Hi guys, 

Sorry to bother you with a very noob question, but I can't create an usb installer for macOS Ventura above is the result of one of many failed tries.

What I'm doing wrong? 

Captura de ecrã 2022-07-09, às 22.20.45.png

Captura de ecrã 2022-07-09, às 22.21.23.png

I don't normally install a beta version of macOS, but the FOMO was killing me, so I applied the Ventura Beta update to my Monterey 12.4 test rig.  With the release build of OC 0.8.2 (EFI here), the upgrade applied without issues.  I'm disappointed, because I was really looking forward to the boot loop :)

 

My system specs are below.  Thanks to everyone for paving the way and to the OC developers for your outstanding work!  Hopefully I didn't just jinx it.  My OC 0.8.2 config.plist is attached.

 

Ventura Beta on HackMini8,1

Spoiler

220438012_Screenshot2022-07-09at5_26_24PM.thumb.png.706d9f5ff5c143f84c8e3b8b0064f552.png

 

System Specs

  • HP EliteDesk 800 G4 Mini 65W (i5-8600, UHD630, Q370 Chipset, 32GB DDR4, SATA SSD)
  • Open Core 0.8.2 (Release build); Lilu 1.6.1 (Release build), WEG 1.6.0 (Release build)
  • OC 0.8.2 config.plist is attached

 

EDIT: Sleep/Wake works perfectly, video (non-DRM) streams perfectly, XCode Beta installed without issues.  If the Ventura updates are already this good, this new macOS is going to be a painless upgrade!

config-shared.plist.zip

Edited by deeveedee
Removed comments about SIP and lilubeta
  • Like 4
22 minutes ago, MorenoAv said:

Hi guys, 

Sorry to bother you with a very noob question, but I can't create an usb installer for macOS Ventura above is the result of one of many failed tries.

What I'm doing wrong? 

Captura de ecrã 2022-07-09, às 22.20.45.png

Captura de ecrã 2022-07-09, às 22.21.23.png

https://drive.google.com/file/d/1XSNzMpDQX0pZ6swCphvTeHglg5O10dlW/view?usp=sharing  ( the same goes for Ventura )

Edited by antuneddu
  • Like 1
  • Thanks 1
2 hours ago, PMheart said:

No worries! And thanks for testing it as well.

 

Could you please try my new testing material at https://github.com/acidanthera/WhateverGreen/actions/runs/2640401875 and follow https://www.insanelymac.com/forum/topic/351969-pre-release-macos-ventura/?do=findComment&comment=2788532, and then show me the results?

 

If it does work, could you please then try https://github.com/acidanthera/WhateverGreen/actions/runs/2642013384, and see if everything is the same?

 

Thanks!

 

Captura de pantalla 2022-07-09 a la(s) 4.47.09 p.m..png

  • Like 2
15 hours ago, PMheart said:

Could you please try playing HEVC encoded videos? You can try https://filesamples.com/formats/hevc.

 

Also, if possible, please compare my version against the official release 1.6.0. The anticipated result is that you will have green screen with 1.6.0, while it’s fixed with mine.

(1)as.vit9696.WhateverGreen (1.6.1) F469F034-B4B3-3E1E-8092-90C2153AF21B <54 17 9 7 6 3 2 1>

(2)as.vit9696.WhateverGreen (1.6.1) 67D042B4-6BFF-3D3C-B6DB-C1DCA62182D8 <55 17 9 7 6 3 2 1>

(3)as.vit9696.WhateverGreen (1.6.0) 629378EE-E10D-38A9-92E9-9D543A40F496 <55 17 9 7 6 3 2 1>

(4)as.vit9696.WhateverGreen (1.6.0) ADFB0FDB-2FD3-3BD9-95D0-36E4DE40791A <55 17 9 7 6 3 2 1>

All play VideoProc successfully and its output MP4 play video very good without audio output.

e.g. sample_1280x720_surfing_with_audio.hevc & sample_1280x720_surfing_with_audio.mp4

I can not find any difference among these four versions of WEG.

Edited by jsl2000
  • Like 1
2 hours ago, jsl2000 said:

(1)as.vit9696.WhateverGreen (1.6.1) F469F034-B4B3-3E1E-8092-90C2153AF21B <54 17 9 7 6 3 2 1>

(2)as.vit9696.WhateverGreen (1.6.1) 67D042B4-6BFF-3D3C-B6DB-C1DCA62182D8 <55 17 9 7 6 3 2 1>

(3)as.vit9696.WhateverGreen (1.6.0) 629378EE-E10D-38A9-92E9-9D543A40F496 <55 17 9 7 6 3 2 1>

All play VideoProc successfully and its output MP4 play video very good without audio output.

e.g. sample_1280x720_surfing_with_audio.hevc & sample_1280x720_surfing_with_audio.mp4

I can not find any difference among these three versions of WEG.

That is expected. I have seen some users who have no problem with HEVC decoding without removing profile 2. Glad to hear that all work!

 

If you would like to help me with another test: https://github.com/acidanthera/WhateverGreen/actions/runs/2643206397

 

Please attach your ioreg with this one. You can send me in private message as it may contain sensitive info (SN, etc.); afterwards I will just remove it.

Edited by PMheart
  • Like 3
1 hour ago, PMheart said:

That is expected. I have seen some users who have no problem with HEVC decoding without removing profile 2. Glad to hear that all work!

 

If you would like to help me with another test: https://github.com/acidanthera/WhateverGreen/actions/runs/2643206397

 

Please attach your ioreg with this one. You can send me in private message as it may contain sensitive info (SN, etc.); afterwards I will just remove it.

as.vit9696.WhateverGreen (1.6.1) 015105D0-272A-318B-A45F-1952D2388387 <55 17 9 7 6 3 2 1> working too !

 

 

Edited by jsl2000

@PMheart My apologies for any confusion caused but I now understand what exactly this dropping of Profile 2 helps to patch on SKL: playback of HEVC encoded in 10-bit format :) Since SKL does not have hw-decode for 10-bit as well, I believe this profile needs to be dropped to match SKL kexts, to allow proper sw-decode of 10-bit HEVC when using KBL kexts. This patch also automatically fixes video playback on Apple Arcade as well. You'll probably want to include this info on the release changelog/code comments for better clarity. You're welcome, by the way.


Also, fyi, this commit was actually causing a KP followed by reboot but the following one you pushed sometime back loads ok. Thank you! 🙏

 

UPDATE: To further confirm the relation of Profile 2 to HEVC 10-bit support, I attempted to encode a video to H.265 10-bit format using an open-source video transcoder HandBrake; as expected, the system indeed freezes up due to the presence of Profile 2 under 'IOGVAHEVCEncodeCapabilities'. Once again, removing this Profile allows for proper sw-encode of 10-bit without causing system to freeze up. At this point, I believe it would only be practical to have Profile 2 removed from EncodeCapabilities as well, should a user attempt to encode 10-bit when using KBL kexts on SKL.

Edited by aben
Added info about 10-bit encode
  • Like 6

after some test on encoding/decoding etc, i switch back to iMac19,1 with ace ventura...... Maybe in the future i will fight 'n kill for a working drm (fairp 4x) on this smbios but, for now, i need only one MP2019 on my desk ahahah (my real) xD ...for hack, slow down to coffee lake smbios sigh sob sub sab seb sib uhm think i use all voc letter...

 

 

Edited by D3v1L
  • Like 1
5 hours ago, D3v1L said:

after some test on encoding/decoding etc, i switch back to iMac19,1 with ace ventura...... Maybe in the future i will fight 'n kill for a working drm (fairp 4x) on this smbios but, for now, i need only one MP2019 on my desk ahahah (my real) xD ...for hack, slow down to coffee lake smbios sigh sob sub sab seb sib uhm think i use all voc letter...

 

 

 

no ok sorry sorry, is a joke... i'll return to MP7,1

700% faster on HEVC encoding... woah... geekbench, your downscore s*ck xD xD ahah 

 

image.thumb.png.261e59d57db732c3a7cac07ec4cdb9d7.png

Estimated 7mins for encoding with iMac19,1 smbios with Quick Sync uhd630 headless

 

 

image.thumb.png.1351a5b899f8f6b256b1f4a342a1e5b0.png

Estimated 1mins for encoding with MacPro7,1 smbios......

 

Edited by D3v1L
  • Like 2
2 hours ago, aben said:

@PMheart My apologies for any confusion caused but I now understand what exactly this dropping of Profile 2 helps to patch on SKL: playback of HEVC encoded in 10-bit format :) Since SKL does not have hw-decode for 10-bit as well, I believe this profile needs to be dropped to match SKL kexts, to allow proper sw-decode of 10-bit HEVC when using KBL kexts. This patch also automatically fixes video playback on Apple Arcade as well. You'll probably want to include this info on the release changelog/code comments for better clarity. You're welcome, by the way.


Also, fyi, this commit was actually causing a KP followed by reboot but the following one you pushed sometime back loads ok. Thank you! 🙏

Thanks for the explanation! Actually @dhinakg told me the same thing regarding 10-bit format, but we were unsure how to patch it back then. I will add some notes in the comment. Thanks for the idea again!

 

By the way, the fix is merged into master branch now, with some rush. Could you please try it? You can actually confirm whether profile 2 is indeed removed in ioreg.

 

One more thing: Now that we removed profile 2 for decoding, shall we do the same thing for encoding?

 

Ref: https://github.com/acidanthera/WhateverGreen/pull/101#discussion_r894774920

  • Like 5
36 minutes ago, PMheart said:

One more thing: Now that we removed profile 2 for decoding, shall we do the same thing for encoding?


I was just editing my earlier post to include this info and saw your reply, I've quoted it below :) 

And yes, I've tested the new commit, Profile 2 successfully drops. Thank you once again! 


UPDATE: To further confirm the relation of Profile 2 to HEVC 10-bit support, I attempted to encode a video to H.265 10-bit format using an open-source video transcoder HandBrake; as expected, the system indeed freezes up due to the presence of Profile 2 under 'IOGVAHEVCEncodeCapabilities'. Once again, removing this Profile allows for proper sw-encode of 10-bit without causing system to freeze up. At this point, I believe it would only be practical to have Profile 2 removed from EncodeCapabilities as well, should a user attempt to encode 10-bit when using KBL kexts on SKL.

Edited by aben
Typo
  • Like 3
16 minutes ago, aben said:


I just edited my earlier post to include this info :) 

And yes, I've tested the new commit, Profile 2 successfully drops. Thank you once again! 


UPDATE: To further confirm the relation of Profile 2 to HEVC 10-bit support, I attempted to encode a video to H.265 10-bit format using an open-source video transcoder HandBrake; as expected, the system indeed freezes up due to the presence of Profile 2 under 'IOGVAHEVCEncodeCapabilities'. Once again, removing this Profile allows for proper sw-encode of 10-bit without causing system to freeze up. At this point, I believe it would only be practical to have Profile 2 removed from EncodeCapabilities as well, should a user attempt to encode 10-bit when using KBL kexts on SKL.

Nice! And sure, I will handle it.

 

Meanwhile, if you want to help me test another one:  https://github.com/acidanthera/WhateverGreen/actions/runs/2643413607

 

This one has nothing to do with SKL/KBL patches, but is some code cleanup with the fw disabling etc. As long as you don’t get KP from it, it is then fine.

Edited by PMheart
  • Like 5
5 minutes ago, PMheart said:

Meanwhile, if you want to help me test another one:  https://github.com/acidanthera/WhateverGreen/actions/runs/2643413607

 

This one has nothing to do with SKL/KBL patches, but is some code cleanup with the fw disabling etc. As long as you don’t get KP from it, it is then fine.


Done! No KP with this one 👍

  • Like 2
On 7/9/2022 at 9:27 PM, D3v1L said:

I think he use MacPro7,1 smbios with AMD rig...so, WEG is not needed at all. Maybe sometimes system is more powerful w/o this kext...... Black screen issues in multi screen is only on iMac and iMacPro with some old dgpu... with WEG you NEED to use agdpmod pikera and you multimonitor work... without weg and MP7,1 (Ryzen etc, need to use this smbios to work correctly...) ALL port are recognized and work like expected with Navi dgpu (drm and fairplay 3.x too)...

 

weg is good but definitely not  "must needed"... 

I am testing a fresh install now with some config changes and kext updates. Will update thread how it goes. If this one fails then I’ll switch to using WEG and the boot-arg suggested above.

Still no luck. Tried all boot args, tried beta 2, latest dev kexts, still end up with black screen / no signal instead of initial setup screen. The whole install can be seen until that point. And Monterey still works with no issues. Maybe Monterey will be the last macOS on my AMD system. 

Edited by SavageAUS
  • Like 1

Upgrade of my HackMini8,1 to Ventura Beta 3 proceeded without issues using OC 0.8.3_30acb571 and Lilu-1.6.2_2ff83c6.  Well done, developers!

 

HackMini8,1: Ventura Beta 3

Spoiler

1736009511_Screenshot2022-07-10at8_56_46AM.thumb.png.229deaa12b7f5de66a96b841c8f89479.png

 

EDIT: For the Ventura Beta 3 upgrade, my EFI is as follows:

  • Start with my OC 0.8.2 EFI posted here
  • Update to OC 0.8.3 Beta
    • EFI/BOOT: Update BOOTx64.efi
    • EFI/OC: Update OpenCore.efi
    • EFI/OC/Drivers: Update OpenRuntime.efi, AudioDxe.efi, ResetNvramEntry.efi
  • EFI/OC/Kexts: Replace Lilu.kext 1.6.1 (Release) with Lilu.kext 1.6.2 Beta
Edited by deeveedee
  • Like 6

And that's it... finally updated to macOS Ventura beta 3, but had to resort to a hybrid method.

Initiate the update with my current EFI, but at the first reboot had to continue with the USB installer, until the last reboot continued with my current EFI.

Now what I want to know is why mi current EFI, boots fine, but did't work at install... 

Updated clover 0.8.3, updated kexts and drivers.

Anyone could help?

Thank you

Captura de ecrã 2022-07-10, às 14.11.33.png

config.plist.zip

Edited by MorenoAv
  • Sad 1

@MorenoAv I'm not sure if this helps you, but I was able to upgrade from Ventura Beta 2 to Ventura Beta 3 after upgrading my OC 0.8.2 EFI (attached here) to OC 0.8.3 Beta and Lilu 1.6.2 Beta (provided by fusion71au here).  I didn't make any other changes to my EFI / config.plist.  I noticed that your config.plist includes boot-arg -no_cpmact_check.  This is a new boot-arg for me - what is this?  Is that supposed to be -no_compat_check?  With SMBIOS iMac20,2 you don't need -no_compat_check (but you already know that), so I'm curious to know about this new boot-arg -no_cpmact_check.

Edited by deeveedee
  • Like 2

It's a typo, but I'm correcting it right away, good eye...

Thanks

It's the only error in my config.plist?

That don't explain why I can't install with this EFI but can boot after install...  

  • Sad 1

@MorenoAv I'm not familiar with your hardware, but I didn't see any glaring issues with your config.plist and I don't have your entire EFI to review.  If you had a typo in your config.plist, is it also possible that you didn't update all OC files when you upgraded to OC 0.8.3 Beta?  You might want to confirm in your EFI (file date July 8, 2022):

  • EFI/BOOT: Update BOOTx64.efi
  • EFI/OC: Update OpenCore.efi
  • EFI/OC/Drivers: Update OpenRuntime.efi

For Ventura Beta 3, in addition to making sure you have completely updated your OC 0.8.3 Beta, also make sure your have Lilu 1.6.2 Beta.

Edited by deeveedee
  • Like 3
Guest
This topic is now closed to further replies.
×
×
  • Create New...