Jump to content

Clover General discussion


ErmaC
30,171 posts in this topic

Recommended Posts

ok then is my hack, but is not all bad, at last I managed to repair the random reboots, when I wasn't at the hack...

I already checked and as you can see in the picture I have OsxAptioFix2Drv-64, OsxAptioFix3Drv-64, and I think it is the culprit...

IMG_0088.jpeg

Edited by MorenoAv
Link to comment
Share on other sites

39 minutes ago, MorenoAv said:

ok then is my hack, but is not all bad, at last I managed to repair the random reboots, when I wasn't at the hack...

I already checked and as you can see in the picture I have OsxAptioFix2Drv-64, OsxAptioFix3Drv-64, and I think it is the culprit...

IMG_0088.jpeg

Since you have AptioMemoryFix, you do not need EmuVariableUefi, OsxAptioFix2Drv or OsxAptioFix3Drv. Not sure what AsAmiShim is for. Upload your entire EFI folder because I assume you have other things wrong also.

Edited by Pavo
  • Like 1
Link to comment
Share on other sites

Thanks @Pavo,

I have no ideia what is AsAmiShim, too, but the others I have deleted them, and rebooted but the result is the same, a painfull slow boot, and at this moment I was looking for ways to locate and uninstall the drivers from L/E or S/L/E to see if it resolves the slowww boot... I only kept OxsAptioFix3Drv-64 and EmuVariable-64.efi.

Link to comment
Share on other sites

Just now, MorenoAv said:

Thanks @Pavo,

I have no ideia what is AsAmiShim, too, but the others I have deleted them, and rebooted but the result is the same, a painfull slow boot, and at this moment I was looking for ways to locate and uninstall the drivers from L/E or S/L/E to see if it resolves the slowww boot... I only kept OxsAptioFix3Drv-64 and EmuVariable-64.efi.

Try to reset your Nvram first, press F11 at GUI CLOVER

Link to comment
Share on other sites

2 hours ago, MorenoAv said:

@Andres ZeroCross, thanks but didn't result, rebooted instead... and the pita slow boot continues... Installed clover r4874, and cleaned the drivers-64 fold and nothing results...

IMG_0089.jpeg

 

As @Pavo says install AptiomemoryFix.efi, delete EmuvariableUEFI and OsxAptioFix3drv :) You folder don't have FSInject-64.efi (Clover files mandatory). This driver is installed with Clover automatically. You can keep HFSPlus.efi.

 

If you use FakeSMC.kext, install SMCHelper.efi  too.

Edited by Matgen84
Link to comment
Share on other sites

4 hours ago, MorenoAv said:

hi all,

Today I noticed that clover 4862, took much more time to boot, than usual, this is the new boot of clover or is only my hack?

 

 

Could you try to check the option to PlayAsync in Clover Config -> GUI? See if there's any improvement?

 

1496295032_Screenshot2019-02-09at20_16_48.thumb.png.92989bd2d65258947c458026a8f4ed92.png

 

You will need Clover 4871 or newer. You can find 4871 on Clover's official download page.

 

Edited by arsradu
Link to comment
Share on other sites

Thank you all for the help,

I made the changes suggested by @arsradu and @Matgen84, and almost nothing changed, the only change is that the boot was a second or two faster... I'll send my clover for your review, if you have time... 

CLOVER.zip

Edited by MorenoAv
Link to comment
Share on other sites

18 minutes ago, MorenoAv said:

Thank you all for the help,

I made the changes suggested by @arsradu and @Matgen84, and almost nothing changed, the only change is that the boot was a second or two faster... I'll send my clover for your review, if you have time... 

CLOVER.zip

 

Uncheck Debug option in Clover Boot. :)

 

896769935_Screenshot2019-02-09at21_08_34.png.257d605aa62aa0767b3eaa867a44caa3.png

Edited by arsradu
  • Like 1
Link to comment
Share on other sites

Thanks man... I'll try it right away... :)

 

Solved, it was the debug ... 

Thanks again...

 

PS: And now that the debug is solved, the random reboots began again, but the strange thing is the reboots occur when I'm not at hack, when I'm here all is well... can someone help me with this?

Thanks one more time and this time I'll send my EFI...

EFI.zip

Edited by MorenoAv
  • Like 2
Link to comment
Share on other sites

 

@MorenoAv I think your hack likes to play a little hide and seek with you there. :) Also, I think the reboots are not random.

 

And if you say they're happening when you're not using the machine, my first instinct would be to check whether or not your computer sleeps well. And also, if it wakes up from sleep well. In other words, power management options. Both for CPU and GPU.

 

Cause, sometimes, on some GPUs (in my experience, the iGPUs tend to do that), the system goes into a reboot when waking up from sleep. Now, you can of course, test this theory by setting your computer to never go to sleep by itself, from System Preferences -> Energy Saver -> Prevent computer from sleeping automatically when the display is off.

 

If you still have that issue after that, then the issue might be caused by something else. But my guess is that it's GPU PM. So, although this is not a fix, it's a valid workaround, in case the attached config doesn't help you.

 

Now, I took a look at your config, and it looks like you forgot to add ig-platform-id along with your Inject Intel. Also, not sure they're important for this case, but I also adjusted a few things in ACPI.

 

Also, I don't know how you zip your files, but it doesn't seem to be using the built-in archiver. And I don't know why. Cause if you try to double click one of your archives to extract it, you will get this.

 

1428097727_Screenshot2019-02-10at20_34_35.png.71a0c5a3d5a7daef3e27b0213f4a7e88.png

It still works with third party softwares like iZip Unarchiver, or Extractor or similar ones. But not with the default one. And, for some reason, it seems to only occur with your files. :) So, while I can still see your files, I just thought you should know about it.

 

Anyway, could you please, try the attached config and see if it works any better? The issue is most likely not Clover related.

 

config.plist.zip

Edited by arsradu
Link to comment
Share on other sites

Hi @arsradu

Thanks for your time and willingness to help me, and you are right my machine likes to play hide and seek with me, and still can but not for much long... the replacement is almost here. But meanwhile I tried you config.plist and adjusted System Preferences -> Energy Saver -> Prevent computer from sleeping automatically when the display is off, and tried to put the machine to sleep and it immediately wakes again...

It's a surprise for me because I can open my zip files, and they are created by Mojave with compress file only. For unzip I normally use not the default unzip but the unarchiver.

The culprit must be GPU PM.

Edited by MorenoAv
Link to comment
Share on other sites

11 minutes ago, MorenoAv said:

Hi @arsradu

Thanks for your time and willingness to help me, and you are right my machine likes to play hide and seek with me, and still can but not for much long... the replacement is almost here. But meanwhile I tried you config.plist and adjusted System Preferences -> Energy Saver -> Prevent computer from sleeping automatically when the display is off, and tried to put the machine to sleep and it immediately wakes again...

It's a surprise for me because I can open my zip files, and they are created by Mojave with compress file only. For unzip I normally use not the default unzip but the unarchiver.

The culprit must be GPU PM.

 

So, with System Preferences -> Energy Saver -> "Prevent [...]" DISABLED, you cannot put the machine to sleep?

 

The point of that feature is to keep the computer on. To not allow it to enter sleep mode by itself. However, putting it to sleep from the Apple menu -> Sleep should override that and force it to go into sleep. If it tries to go to sleep, then automatically wakes up, then yes, that's a matter of GPU PM and it's not related to Clover.

 

I was only curious if your restarts happen when the "Prevent [...]" option is Enabled. Meaning if you leave your computer idle for 15 minutes for example, or however it takes it to automatically go to sleep, it won't go to sleep of course, since the Prevent option is ON, but will it reboot after 15 minutes? That's what I wanted to know.

 

Cause I think it won't restart by itself. And I think the problem is on Wake from sleep. Basically, instead of waking up normally, it goes into reboot instead. But I could be wrong.

Edited by arsradu
  • Like 1
Link to comment
Share on other sites

In the end I don't know how much time it takes to reboot, and I say this, because if for example I am at the machine and go eat dinner when I go back to the machine it has rebooted and is in initial screen, ready to put the password to enter maOS. It happens the two ways, with or without ''Prevent'' and it didn't sleep, instead reboots immediately...

 

Link to comment
Share on other sites

7 hours ago, tmbt said:

Hi guys,

the injectKexts=Detect works also with VirtualSMC ? Because in the Clover wiki it refers only about FakeSMC.kext

 

Thnaks

 

No, "detect" means "detect FakeSMC in SLE". If detected then don't inject kexts from /EFI/CLOVER/kexts/other/

For my mind it is better to set injectKexts=YES, and forget about "Detect".

  • Like 4
Link to comment
Share on other sites

42 minutes ago, Slice said:

No, "detect" means "detect FakeSMC in SLE". If detected then don't inject kexts from /EFI/CLOVER/kexts/other/

For my mind it is better to set injectKexts=YES, and forget about "Detect".

 

Exactly. By the way, Slice. I'm not sure what's the default value here. But...wouldn't it be better to set YES by default? I think it's set to Detect by default. But...if we can inject kexts from Clover, why would we even bother with S/L/E in the first place?

Also, if we can build Clover with external drivers...can we also build it with external kexts...? Especially FakeSMC. Or VirtualSMC. And add one of them by default in Clover/kexts/Other? I think that's probably one of the most overlooked kexts. One that a lot of new users forget about. And also, one of the most important ones. :)) So...I don't know.

 

My opinion is that this should be set to YES by default. If people still like to have FakeSMC in S/L/E, sure, they can set it to Detect. But...then, you'll have only FakeSMC in S/L/E...and the rest of your kexts in Clover/kexts/Other...? It sounds not intuitive to me. If you can keep them all in one place, then maybe keep them all in one place, for easier management, in my opinion.

 

Now, there are indeed some kexts, such as CodecCommander, which, for as far as I know, only work from S/L/E. But...Detect only refers to FakeSMC. So...that's not gonna make any difference anyway.

 

Just my 2 cents.

Edited by arsradu
  • Like 2
Link to comment
Share on other sites

4 hours ago, Slice said:

No, "detect" means "detect FakeSMC in SLE". If detected then don't inject kexts from /EFI/CLOVER/kexts/other/

For my mind it is better to set injectKexts=YES, and forget about "Detect".

 

I think it's a way of thinking. All my kexts are in /L/E (including VirtualSMC and Lilu) and i've only VirtualSMC , lilu and WhateverGreen in /Other so that these kext are inject when /L/E is not available (i.e. during Apple update or Recovery).

I'm doing this because according to Rehabman :

- placing them in /S/L/E (or /L/E on 10.11+) and including in kernel cache, makes kextcache do a lot of error checking.
- if you develop kexts, error checking is very important!
- some kexts don't work from Clover/kexts (AppleHDA injector, CodecCommander, BrcmFirmware*)
- the idea behind Clover/kexts is to have a set of *stable* and *minimalistic* kexts that will allow booting of the installer/recovery, not full functionality
- so...the kexts there I tend to not update as often and the full set is not there (less unneeded kexts, less problems)
- placing kexts into kernel cache for day-to-day use is "more native" (as it would be on a real Mac) vs. injection (which is very non-Mac)

 

These seem to me all good reasons to do as he says so i'm following his example. I'm not sure if he is correct and i don't want to start a war .. I'm just following his advices

 

Mattia

 

Link to comment
Share on other sites

Quote

I think it's a way of thinking. All my kexts are in /L/E (including VirtualSMC and Lilu) and i've only VirtualSMC , lilu and WhateverGreen in /Other so that these kext are inject when /L/E is not available (i.e. during Apple update or Recovery).

 

To me, this is not efficient. One reason being that you're basically doubling your kexts. :))

 

Quote

- placing them in /S/L/E (or /L/E on 10.11+) and including in kernel cache, makes kextcache do a lot of error checking.

 

Not sure what kind of error checking is kextcache doing in this case. So I'm not gonna say anything on that. Maybe people with more experience and knowledge can comment on that.

 

Quote

- if you develop kexts, error checking is very important!

 

Are you a kext developer? If not...I don't see the benefit from your point of view.

 

Quote

- some kexts don't work from Clover/kexts (AppleHDA injector, CodecCommander, BrcmFirmware*)

 

True that. But...once again, are you using any of those kexts? Cause...I don't. At least not anymore.

 

Quote

- the idea behind Clover/kexts is to have a set of *stable* and *minimalistic* kexts that will allow booting of the installer/recovery, not full functionality

 

I'm not sure what was the idea behind this implementation, but I can tell you it served me very well over the years, and not just for installer/recovery. Actually, I've had more issues placing kexts in S/L/E than having them in Clover/kexts/Other. It might be (probably is) a very subjective point of view, but...I don't know. To me, it's a lot easier to drag and drop my kexts into Clover/kext/Other than fiddling with S/L/E's permissions and all that. Call me lazy, but I prefer spending my time actually using my computer, than trying to get it to work. So...I do appreciate the simplicity and the convenience that Clover's implementation brings to this. :) 

 

Quote

- so...the kexts there I tend to not update as often and the full set is not there (less unneeded kexts, less problems)

 

And still, you seem to prefer having two sets of kexts, one updated, one not, instead of having them all in one place, and up to date. How is that gonna bring you less problems? :))

 

Quote

- placing kexts into kernel cache for day-to-day use is "more native" (as it would be on a real Mac) vs. injection (which is very non-Mac)

 

It might be less native, and "non-Mac", but then again, a lot of the hackintoshing is. And, I personally haven't noticed any difference in day-to-day use between having those kexts in S/L/E rather than having them in Clover/kexts. And I think the benefits of this implementation overweigh the lack of realism.

 

Again, just my opinion. And also, not trying to cause any discussions or so. :)) Just...sharing my opinion on the points you laid out. Simply because I think difference of opinion (done right) can start a very nice and fruitful conversation. And it can lead to progress, on both sides.

Edited by arsradu
  • Like 6
Link to comment
Share on other sites

Guys, I'm still having problems with boot chime :cry:  I can only select AMD HDMI and Intel HDMI without freeze. Whenever I want to change my audio output to ALC1150 (any output), whole GUI freezes and no value is written to NVRAM. Since newer Clover revisions use different way of saving NVRAM value, BootChimeCfg is no longer working also. Tested on 4870, 4871 and 4876. 

Link to comment
Share on other sites

×
×
  • Create New...