Clover General discussion

[tmbt]

1 hour ago, ellaosx said:

@tmbt

yes. it for all 3rd party kexts

Thanks!

[Slice]

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".

[arsradu]

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 February 11, 2019 by arsradu

[tmbt]

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

 

[arsradu]

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 February 12, 2019 by arsradu

[bidero]

Guys, I'm still having problems with boot chime   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. 

[lisai9093]

For boot chime, is it possible to add USB speaker support? My desktop use USB speaker as the only output

[Slice]

@arsradu

If you have FakeSMC and other critical kexts in SLE then you sure you can boot after OS update broking kext injection.

Anyway you need FakeSMC and LAN in Clover/kext folder to boot into Recovery.

So the logic is follow: let all kext to be in SLE and so in cache to speedup boot and for some troubles. But keep all kexts also in Other folder to boot into recovery or to OS Installer.

Then "Detect" has a sense to not inject kexts from "Other" if we have them in cache but do this in the case of clean cache (Recovery or Installer).

 

Anyway I see that double injection is not dangerous so we can always set Inject=YES.

10 hours ago, lisai9093 said:

For boot chime, is it possible to add USB speaker support? My desktop use USB speaker as the only output

I don't know how.

10 hours ago, bidero said:

Guys, I'm still having problems with boot chime   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. 

I have no such issue with my ALC1150.

[smolderas]

1 hour ago, Slice said:

@arsradu

If you have FakeSMC and other critical kexts in SLE then you sure you can boot after OS update broking kext injection.

Anyway you need FakeSMC and LAN in Clover/kext folder to boot into Recovery.

So the logic is follow: let all kext to be in SLE and so in cache to speedup boot and for some troubles. But keep all kexts also in Other folder to boot into recovery or to OS Installer.

Then "Detect" has a sense to not inject kexts from "Other" if we have them in cache but do this in the case of clean cache (Recovery or Installer).

 

Anyway I see that double injection is not dangerous so we can always set Inject=YES.

I don't know how.

I have no such issue with my ALC1150.

Hi Slice,

 

can you please separate the boot chime from theme loading, so we can use boot chime while GUI->Fast is set to "true"?

[tmbt]

On 2/11/2019 at 5:02 PM, arsradu said:

 

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

 

 

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.

 

 

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

 

 

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

 

 

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.  

 

 

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? :))

 

 

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.

 

I can agree on all your point. I'm using some of the kext that don't work in clover folder so i should kextcache my kernel anyway .

After a while you will be used to install kext in /L/E . I don't use any app to do that. Just the terminal and some command line . So i guess it's very subjective but thanks for the discussion

 

Mattia

[Andres ZeroCross]

Hi @Slice can you make AudioDXE.efi play sound without nvram set,, like bootchimedxe. So AudioDxe.efi will automatic select audio output and sound at high volume if no nvram set yet in "Startup Sound Output".

[Badruzeus]

Minor issue related to Clover GUI; having a weird "tool_shell.png" appearance with UEFI, no problem with Legacy (SS: bottom left). Shell is still functional. Strange, it appears normal if booting from USB (UEFI). I use Scan=true on config.plist - GUI #btw

[Slice]

2 hours ago, Badruzeus said:

Minor issue related to Clover GUI; having a weird "tool_shell.png" appearance with UEFI, no problem with Legacy (SS: bottom left). Shell is still functional. Strange, it appears normal if booting from USB (UEFI). I use Scan=true on config.plist - GUI #btw

 

It may be a problem of File System of your EFI partition.

UEFI BIOS has quirky FAT32 driver. For this purpose I have Fat-64.efi in the Clover distribution. It works better.

[pepitillo]

Hi there, 

I'm using the recently added Clover feature of playing sound on boot.

I was wondering if there is a problem with my config or I'm missing something, but when I boot with "Time-out=0" the boot Chime plays twice (the second is a little bit cut off).

Booting with "Time-out=1" plays the sound fine (but it's showing GUI).

I add the sound i'm using.

Thank you in advance.

sound.wav

Edited February 16, 2019 by pepitillo

[Slice]

1 hour ago, pepitillo said:

Hi there, 

I'm using the recently added Clover feature of playing sound on boot.

I was wondering if there is a problem with my config or I'm missing something, but when I boot with "Time-out=0" the boot Chime plays twice (the second is a little bit cut off).

Booting with "Time-out=1" plays the sound fine (but it's showing GUI).

I add the sound i'm using.

Thank you in advance.

sound.wav

I know this bug.

[Sherlocks]

r4877, report.

PlayAsync=TRUE, scan drive with play sound, then enter GUI. and i have a timeout 3, 3 -> 2 -> 1. automatically enter macos. there is no loop sound.

PlayAsync=TRUE, scan drive with play sound, then enter GUI. and i have a timeout 3, 3 -> 2 -> "enter key". enter macos. there is loop sound until boot macos.

 

thanks in advance

Edited February 16, 2019 by Sherlocks

[Bor]

On 2/13/2019 at 1:12 AM, bidero said:

Guys, I'm still having problems with boot chime   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. 

I have same problem on my rig. I got ALC1150 too.

[phi777]

Guys, i've stumbled upon a very interesting artikle about apple's T2 chip.https://duo.com/labs/research/apple-t2-xpc

 

[Teras]

Hello people.

 

During the last days, I experience a strange behavior with boot sequence, and I'd be grateful if you gurus can help me.

First of all, my system:

Gigabyte Z390 Aorus pro, i9 9900K, Samsung 970 Evo, AMD Vega 64

This system installed fine and worked as expected.

 

*But*, due to some issues with my Windows installation, I had to flash my BIOS to the latest version, and to fiddle around with the system. Then, at some time, when I tried to boot to OSX, although booting started and everything seemed to work fine, just after booting, instead of displaying the login screen, an inner square appears, just like the screenshot. (Actually this was taken when tried to boot in safe mode, when I try to boot regularly, there is either a dark square where this square is, or garbage, or green color). As you can see here, even the mouse pointer is visible (and movable).

 

The strange thing is, if I boot from my USB stick, using the EXACT files, as from my HD EFI partition, the system boots perfectly! So, if I use the stick to load Clover, it properly initializes visuals, if I use the disk to load Clover, it fails.

This drives me mad, and I can't find any logic in this, or how to debug it.

 

Please help!

 

(PS: I hope this is the correct thread!)

 

[Zenith432]

@Teras: Are you using UEFI boot from both the HDD and the USB stick?  If using legacy boot on one of them, you get a completely different UEFI bios, which could explain the difference.  Also, note that when booting legacy Clover, it sometimes picks up CloverX64.efi from a different disk (!) if multiple copies exist - because the search algorithm of boot6/boot7 does not know which disk it was loaded from.

[arsradu]

12 hours ago, Teras said:

Hello people.

 

During the last days, I experience a strange behavior with boot sequence, and I'd be grateful if you gurus can help me.

First of all, my system:

Gigabyte Z390 Aorus pro, i9 9900K, Samsung 970 Evo, AMD Vega 64

This system installed fine and worked as expected.

 

*But*, due to some issues with my Windows installation, I had to flash my BIOS to the latest version, and to fiddle around with the system. Then, at some time, when I tried to boot to OSX, although booting started and everything seemed to work fine, just after booting, instead of displaying the login screen, an inner square appears, just like the screenshot. (Actually this was taken when tried to boot in safe mode, when I try to boot regularly, there is either a dark square where this square is, or garbage, or green color). As you can see here, even the mouse pointer is visible (and movable).

 

The strange thing is, if I boot from my USB stick, using the EXACT files, as from my HD EFI partition, the system boots perfectly! So, if I use the stick to load Clover, it properly initializes visuals, if I use the disk to load Clover, it fails.

This drives me mad, and I can't find any logic in this, or how to debug it.

 

Please help!

 

(PS: I hope this is the correct thread!)

 

That looks like a piece of the default Mojave wallpaper. So that means you're probably reaching Desktop. Now, I've never seen this issue before. My guess is that something has to be different between your Clover USB drive and your HDD/SSD EFI. Something you might have missed. Either Clover is not the same version, not installed the same way (legacy vs UEFI mode), maybe kexts are not the same versions, drivers are not exactly the same... I don't know. But that would be my opinion on this issue so far.

 

If you want, you can remove sensitive serials from your SMBIOS and upload both the EFI folder on your USB and the one on your SSD/HDD. Also, although I think your BIOS might have already done that after flashing, you can try setting it to Optimised Defaults again and see if that helps. Also, just for testing, you can always put back the old BIOS and see if that changes anything. If not, then it's not the actual BIOS. It's gotta be something else. Personally I'm not sure it's Clover related. Probably not. But as I said, you can upload both so we can take a look.

 

Also, in case you haven't already done that, you can mount both your USB EFI partition and your HDD/SSD EFI partition and copy-paste everything (make sure you're not merging anything in the process) from one place to the other.

 

But before that, let's have a look at the current setup.  

Edited February 20, 2019 by arsradu

[Matgen84]

16 hours ago, Teras said:

Hello people.

 

During the last days, I experience a strange behavior with boot sequence, and I'd be grateful if you gurus can help me.

First of all, my system:

Gigabyte Z390 Aorus pro, i9 9900K, Samsung 970 Evo, AMD Vega 64

This system installed fine and worked as expected.

 

*But*, due to some issues with my Windows installation, I had to flash my BIOS to the latest version, and to fiddle around with the system. Then, at some time, when I tried to boot to OSX, although booting started and everything seemed to work fine, just after booting, instead of displaying the login screen, an inner square appears, just like the screenshot. (Actually this was taken when tried to boot in safe mode, when I try to boot regularly, there is either a dark square where this square is, or garbage, or green color). As you can see here, even the mouse pointer is visible (and movable).

 

The strange thing is, if I boot from my USB stick, using the EXACT files, as from my HD EFI partition, the system boots perfectly! So, if I use the stick to load Clover, it properly initializes visuals, if I use the disk to load Clover, it fails.

This drives me mad, and I can't find any logic in this, or how to debug it.

 

Please help!

 

(PS: I hope this is the correct thread!)

 

 

As @arsradu copy EFI folder from USB stick to EFI Folder on your HDD. Before that, you can recreate EFI partition on your hard disk, maybe corrupted

1. Boot on USB
2. go to Terminal
3. diskutil list

   newfs_msdos -v EFI -F 32 /dev/rdisk0s1 (for example)

More experienced users may have a better solution than me

 

[apianti]

You should provide a video of the verbose mode output, or just see if it is printing that output and then going to the desktop. Also I would actually recommend that you just run the clover installer again and then put you config, drivers, and kexts from your usb. You may not have been using UEFI mode to boot from the usb. It's hard to tell really you gave very limited information.

[Badruzeus]

@Slice sorry, I got building issue after r4886 commit. Thanks.

 

Edited February 26, 2019 by Badruzeus

[Zenith432]

@Badruzeus: I think it's a typo.  Remove the offending line

diff a/rEFIt_UEFI/Platform/HdaCodecDump.c b/rEFIt_UEFI/Platform/HdaCodecDump.c
--- a/rEFIt_UEFI/Platform/HdaCodecDump.c
+++ b/rEFIt_UEFI/Platform/HdaCodecDump.c
@@ -404,7 +404,6 @@ EFI_STATUS SaveHdaDumpBin() {
                        }
                }
                
-               CodecAddress;
                Status = HdaIo->GetAddress(HdaIo, &CodecAddress);
                
                CopyMem(HdaCodec.Header, hdcID, 4);