Jump to content
30960 posts in this topic

Recommended Posts

17 hours ago, mariosun said:

Clover 5149 works in Ventura from original release

https://www.macos86.it/topic/86-aggiornamento-clover/?do=findComment&comment=133394

 

image.thumb.png.173666ba8fb50e562bc0783507efde06.png

 

 

problem is this attached if you try to boot again with Opencore, It was solved previously but now it is back again! ;)

 image.thumb.jpeg.a773c93ab501381d66d28aa848f55065.jpeg

 

Clear Cmos or others methods you like help to boot again with Opencore safe if you haveNVRAM problems

https://github.com/acidanthera/bugtracker/issues/1868#issuecomment-970377807

 

i have same issue NVRam, and F11 at Clover GUI not reset NVRam

10 hours ago, oldman20 said:

i have same issue NVRam, and F11 at Clover GUI not reset NVRam

to reset successfully NVRAM if this problem happens, I use Clover R5149 release found on clover Hacky site

If it doesn't work for you you can try with some older release

I use also 084 Opencore release

Edited by mariosun
  • Like 2
2 hours ago, mariosun said:

to reset successfully NVRAM if this problem happens, I use Clover R5149 release found on clover Hacky site

If it doesn't work for you you can try with some older release

I use also 084 Opencore release

I already v5149, and current use opencore 084 too. 

4 hours ago, Slice said:

After testing Opencore I can't boot by Clover until make F11.

I need more observations related to switch between bootloaders.

Do you have UEFI Shell for Open Core and Clover? Maybe get a dmpstore in each case and compare.

  • Like 1
8 hours ago, joevt said:

Do you have UEFI Shell for Open Core and Clover? Maybe get a dmpstore in each case and compare.

Do you know why some variables in NVRAM should be Volatile or Non-volatile?

Volatile as said Acidanthera.

Non-volatile as said Clover developers 10 years ago.

  • Like 3
16 hours ago, joevt said:

Do you have UEFI Shell for Open Core and Clover? Maybe get a dmpstore in each case and compare.

No, variables will be set at system start not at Shell start.

We can get some list of variables by DarwinDumper but the list is restricted.

5 hours ago, Slice said:

No, variables will be set at system start not at Shell start.

 

I suppose the solution is to somehow put a dmpstore between when Clover and OpenCore is launching macOS and when macOS starts. Can they be fooled into thinking that a UEFI Shell renamed to boot.efi is macOS? Do this in the preboot partition.

  • Haha 1
  • 2 weeks later...
  • 2 weeks later...

@Slice

Forgot to tell you that gcc released version 12.0.2 last month.

a few thing to report :

building against binutils 2.38 (actual installed version)

tested on my environment produce a working build and clover boot fine

 

Actually there's also an update to binutils 2.39

 

This release (due to the implemetation of gprofng) need bison 3.14+ and java17 SDK installed
else build fails (at least that's my guess as i do not have java installed and build fails)
and have no intention to install java

 

However if we want to update to this release to have have a successful binutils build gprofng should be disabled
either adding

--disable-gprofng

or

--enable-gprofng=NO

 both are valid

This solve the build failure and produce a working clover boot

I don't know if its worth investigating further this issue, i'm actually not going to as i do not want any java installed on my machine

 

Obviously we can just choose to only update GCC using actual binutils.

its just a heads-up

  • Like 3

anyone has this issue: Clover cant show GUI to boot if ApfsDriverLoader.efi and/or HFSPlus.efi inside drivers/UEFI/ like me? I must put they in root of EFI partition and load manual with UEFI Shell: load ApfsDriverLoader.efi

or add manual driver with UEFI Shell: bcfg driver add 0 fs0:\ApfsDriverLoader.efi "Apfs"?

Everything i checked working normal, only just trouble with driver efi

  • Sad 1
2 hours ago, oldman20 said:

anyone has this issue: Clover cant show GUI to boot if ApfsDriverLoader.efi and/or HFSPlus.efi inside drivers/UEFI/ like me? I must put they in root of EFI partition and load manual with UEFI Shell: load ApfsDriverLoader.efi

or add manual driver with UEFI Shell: bcfg driver add 0 fs0:\ApfsDriverLoader.efi "Apfs"?

Everything i checked working normal, only just trouble with driver efi

Hi @oldman20, i I never have a issue with HfsPlus.efi driver (Clover/Drivers/UEFI). Instead of ApfsDriverLoader.efi, I use verbose patched apfs.efi corresponding to the macOS version

Edited by Matgen84
  • Confused 1
5 minutes ago, Matgen84 said:

Hi @oldman20 ApfsDriverLoader is a Lilu plugin kext not a driver. Using ApfsDriverLoader.kext into Clover/Kexts/Others, works fine. I never have a issue with HfsPlus.efi driver (Clover/Drivers/UEFI)

what? ApfsDriverLoader is kext? i dont imaging that, link please?

Just now, oldman20 said:

what? ApfsDriverLoader is kext? i dont imaging that, link please?

 

I apologize because I was confused with something else. I edit my previous post 😊

  • Sad 1

Report a new build earlier this month. Works fine from bootable hi siera till ventura but unfortunately Can't boot any lower than this siera all the way to Mountain ⌘ Powered by Clover revision: 5149 (master, commit dd0beb211)

Only the AFPS format can work well, but not the HFS format.

Edited by naiclub
17 minutes ago, naiclub said:

Report a new build earlier this month. Works fine from bootable hi siera till ventura but unfortunately Can't boot any lower than this siera all the way to Mountain ⌘ Powered by Clover revision: 5149 (master, commit dd0beb211)

Only the AFPS format can work well, but not the HFS format.

What driver did you use HfsPlus.efi or VboxHFS.efi?

  • Like 1

Removed a moment ago Boot to Siera The result is the same as the black screen. I think it's because we have to choose Smbios lower than imacpro or choose Clover. Lower version like 513x down 512x Do you think the same as me?
because I use the version from 5126-5138 never had a problem But when it comes to 5149 The config.plist must be modified to fit the newer version. So it doesn't work with older versions. Is this correct? waiting for your confirmation
P.S. This is a discussion.

Versions before 5123.1 were without OpenCore. May be this is the problem.

Other possible difference is OpenRuntime. We were using OsxAptioFix3Drv.efi before this.

I don't think config.plist does matter. Old Clover don't understand new keys as well as new Clover ignores obsolete keys. Default values will be set in both cases.

  • Like 3
10 minutes ago, Slice said:

Versions before 5123.1 were without OpenCore. May be this is the problem.

Other possible difference is OpenRuntime. We were using OsxAptioFix3Drv.efi before this.

I don't think config.plist does matter. Old Clover don't understand new keys as well as new Clover ignores obsolete keys. Default values will be set in both cases.

This is the most obvious answer.

thank you so

On 9/30/2022 at 4:17 PM, Slice said:

Versions before 5123.1 were without OpenCore. May be this is the problem.

Other possible difference is OpenRuntime. We were using OsxAptioFix3Drv.efi before this.

I don't think config.plist does matter. Old Clover don't understand new keys as well as new Clover ignores obsolete keys. Default values will be set in both cases.

Hello, I have tried modifying the behavior. with the latest clover 5149 Coincidentally, it worked better than expected. Bootable from the latest 10.8-13 By changing you version of FakeSMC.kext to the version of RehabMan. and also get a complete display of the sensor values But I've done this before, but it's been a long time. It's the previous clover version. but not as good as version 5149
I want to know why

×
×
  • Create New...