Jump to content

Clover General discussion


ErmaC
30,167 posts in this topic

Recommended Posts

I haven’t tried using any of the updated Clovers on my AMD rig yet so my config has no matchos in it and it works fine <- I’ll get around to updating soon but in the meantime I wanted to ask if I need to do anything with mmiowhitelist? If everything is working (except sleep - yes I’ve mapped USB ports, no I have not checked wake reason yet)

Link to comment
Share on other sites

@SavageAUS

to say it works fine does not help developer because it is working fine in some situations (single system) and some parameters seem not to work in a multi OSX configuration as ie opencore does
 

Also Kext to patch needs some adjustment because it applies some patching also when you do not need of it (see aquantia kext to patch if you use)


@Jief_Machak

 

if could be useful this is a part of a working opencore debug.log one booting with BigSur the other with HighSierraSame config, same disks configuration.
Disk configuration is also the same I use in clover testing, the only difference is I am booting from an USB pen when I use Clover

Schermata 2020-10-23 alle 8.09.51 AM.png

Edited by Guest
config--->debug.log
Link to comment
Share on other sites

7 hours ago, iCanaro said:

this build on the X570 AMD starts catalina and BS, but does not start mojave

mojave_NOK_debug.log

 

 

this clover commit starts mojave catalina and bs

mojave_5125 (master, commit 18038055a)OK_debug.log

 

used the same configuration, changed only Clover build

The logs are the same ! Few messages more here and then but same.

Are you sure you don't have random non-start ?

Link to comment
Share on other sites

5 minutes ago, fabiosun said:

it works fine does not help developer

That's ok. It's sometimes encouraging to know that it's working for someone ! In that sense, it helps.

 

6 minutes ago, fabiosun said:

if could be useful this is a part of a working opencore config one booting with BigSur the other with HighSierraSame config, same disks configuration.
Disk configuration is also the same I use in clover testing, the only difference is I am booting from an USB pen when I use Clover

Schermata 2020-10-23 alle 8.09.51 AM.png

I'm really not sure what you are showing here.

I don't know what your are calling "Disk configuration". Do you mean the same Clover folder ?

I'm not sure either it's OC log or Clover log.

8 minutes ago, fabiosun said:

seem not to work in a multi OSX configuration

If something is not working, we'll fix it. But you have to say what.

 

9 minutes ago, fabiosun said:

Kext to patch needs some adjustment

Hum, yes, ok. Which one ?

 

Your tests and reports are welcomed. But you have to be way more precise...

Link to comment
Share on other sites

@Jief_Machak

as I wrote it is a debug log of opencore

one booting in high sierra OSX, the other one booting in Big Sur

In one of this you see an ifgetOS..but I do not why and if it is useful to address then the use or not of the proper kernel patches AMD users need to boot properly

These patches are different from each OSX version

 

about Disks configuration

disk A is dedicated to big Sur

Disk B is dedicated to High Sierra

Disk B contain an EFI with Opencore boot loader (used to boot both systems)

I can say that with the same config I can boot all system available from high Sierra to latest Big Sur beta

 

I use an USB pen with Clover to boot the same disk configurations above

 

About Kext to patch

I, and other AMD users have to use a patch for aquantia 10G ethernet card to have it working on OSX greater than HighSierra

Clover seems to patch always..also High Sierra kext

Opencore instead skips correctly if patching is not needed.

 

I hope is more clear, and to be clear I appreciate your great efforts you are doing as a single devs..but I can't say also if always I read it works it is no good for me..but eiii it is an only an educated opinion..or not?

 

and..for me your Clover 5124 works well in all OSX I have tested using different way to do matchos configuration stuff (and using multiple config.plist file, which is to say it all one of the reason I am following your interesting and great job ;)

 

 

Edited by Guest
typo
Link to comment
Share on other sites

2 minutes ago, fabiosun said:

fgetOS

I don't know where that come from and what that mean. OC stuff, I guess.

 

2 minutes ago, fabiosun said:

Clover seems to patch always..also High Sierra kext

Did you configure correctly MatchOS in your config.plist ?

 

4 minutes ago, fabiosun said:

Clover 5124 works well in all OSX

If so, follow this https://jief-machak.gitbook.io/cloverhelp/ and I will make it work with the latest Clover.

I'll also find why "Clover seems to patch always..also High Sierra kext".

 

7 minutes ago, fabiosun said:

but I can't say also if always I read it works it is no good for me..but eiii it is an only an educated opinion..or not?

I'm not totally sure of what that means. What is no good for you ?

Again, if it was working before, and not anymore , follow this https://jief-machak.gitbook.io/cloverhelp/ 

  • Like 2
Link to comment
Share on other sites

2 minutes ago, Jief_Machak said:

I'm not totally sure of what that means. What is no good for you ?

Again, if it was working before, and not anymore , follow this https://jief-machak.gitbook.io/cloverhelp/ 

it is not good to say it works without adding in which situation (OSX used and Clover Commit used) but it is a my personal opinion

 

I can say in my case from 5124 it works well always if I use two different config.plist file without mixing KernelPatches stuff from one os to others

 

It never works with an only one config because every commit I have tested seems to overlap patches which are not useful ie in Big sur

As also a betatester here as said to you (I think SavageAUS but maybe also @Icanaro )

To be more clear (I hope) problem (not for all) but only for AMD cpu users are in kernelPatches detection and utilisation in clover! :)

I will try to understand better how to debug as you requested ;)

 

 

Link to comment
Share on other sites

Good day everyone, can I kindly ask a capable developer (or you @Jief_Machak) for a recompiled final version of Clover pre-OpenCore such as r5122 (release version, official etc.) including the bug fix (reported after r5122 in https://github.com/CloverHackyColor/CloverBootloader/issues/252 ) that fixes the broken patching with target bridge data? @Slice can you help getting a final pre-OC release build for anybody that wants to keep this as a reference version pre-OC please?

 

Just for machines that never intend to get Big Sur and to be able to benefit from the last ever per-OC Clover... I assume the compiled drivers in that r5122 release are not having issues, yes? Just the main EFI

 

I would hope that even the official release would reflect this but a compiled ZIP of the main boot-loader here would suffice :D I wish to update a couple of older hacks that are 6+ years old and that I won't bother even try Big Sur on them...

 

Thank you in advance.

  • Like 1
Link to comment
Share on other sites

it's getting worse ... the latest version doesn't boot ... the icons are a disaster ... when they appear, when they disappear ... you can only boot from a single partition ... I don't understand what's going on but it's getting worse ... everything is random ... the errors are different every time ... I was glad that voodooI2C was successfully implemented, but I think I'm giving up ... it's just wasted time on tests and tests ... and no satisfaction ... everything is random and random ... nothing is reproducible ..I'm sorry
 

edit:

when I have sound, when I don't ... the EFI partition can't mount in any way ... when it's not video ... I'm just talking about not having nerves to test other functionalities as long as it doesn't boot twice the same
 

Edited by corint1
Link to comment
Share on other sites

31 minutes ago, corint1 said:

it's getting worse ... the latest version doesn't boot ... the icons are a disaster ... when they appear, when they disappear ... you can only boot from a single partition ... I don't understand what's going on but it's getting worse ... everything is random ... the errors are different every time ... I was glad that voodooI2C was successfully implemented, but I think I'm giving up ... it's just wasted time on tests and tests ... and no satisfaction ... everything is random and random ... nothing is reproducible ..I'm sorry
 

edit:

when I have sound, when I don't ... the EFI partition can't mount in any way ... when it's not video ... I'm just talking about not having nerves to test other functionalities as long as it doesn't boot twice the same

What kind of answer do you expect from that post ?

With not even a debug.log, no info on what do you try to boot, with which version, etc. the only think I can say is "Poor you, sorry".

Link to comment
Share on other sites

2 hours ago, Jief_Machak said:

@iCanaro If you think you don't have random non-start, could try commits taken from here : https://github.com/jief666/CloverCommits

Start with "C-20201021172059-1803805.efi", just to make sure that the problem doesn't come from my own compilation.

If this one works, try the more recent ones.

preboot.log

with catalina and bigsur this Clover starts

C-20201021172059-1803805.efi_Catalina_OK_debug.log

C-20201021172059-1803805.efi_BS_OK_debug.log

 

with mojave does not start, also performed NVRAM reset

C-20201021172059-1803805.efi_Reset_NVRAM_MOJ_NOK_debug.log

C-20201021172059-1803805.efi_MOJ_NOK_debug.log

 

 

  • Like 1
Link to comment
Share on other sites

Hi @Jief_Machak the release mentions 5123 as the start of the OpenCore joint code/project. Hence my request for a 5122 compiled from sources including the patch-target-device fix (https://github.com/CloverHackyColor/CloverBootloader/issues/252)


If you can spare the time and do a release compilation, it would be great. Not sure if keeping the efi drivers or not would be simpler for you, I can get them from the ZIP release from Git.

 

I wish @Slice or any other dev accessing the releases in Git would make a nice, final pre-OC build for us non-Big-Sur-adventurers-yet :D:D

Thank you

Link to comment
Share on other sites

1 hour ago, fabiosun said:

I will try to understand better how to debug as you requested ;)

That's not hard, and it'll make our tests so much easier. Basically, once set up, the only thing you'll have to do is "git fetch" and "git pull", boot, commit and push.

The goal is to totally suppress risks linked to file copy and manipulation.

1 minute ago, MacKonsti said:

5123 as the start of the OpenCore joint code/project

No it's not, if I'm not mistaken. As far as I see in github branches history.

The 1st OC commit is 8ccee7054f974bd5c5f8cc3a85b32339d706ec8c, and it's not in the history of 5123.

Try it. If you see OC in debug.log, I'm wrong :w00t:

  • Like 1
Link to comment
Share on other sites

9 minutes ago, MacKonsti said:

I wish @Slice or any other dev accessing the releases in Git would make a nice, final pre-OC build for us non-Big-Sur-adventurers-yet :D:D

Thank you

That's exactly what @Slice did with 5123. This 5123 is just before the merge to bring OC in master branch.

Edited by Jief_Machak
Link to comment
Share on other sites

I do not doubt you @Jief_Machak but the text in the r5123 release indicates OC support as "it can successfully boot Big Sur" and "Check new config-sample.plist" so it could be misleading for people getting the pre-compiled stuff from Git :)

 

Nevertheless, r5123 has the target device patch broken as I reported it after r5123 and cannot patch H_EC device :( Can you kindly point to the commit that fixes this?

 

But I don't know my way around Git or branches or how to merge, nor can I compile, unfortunately. Not sure why I ask for the commit number :/

Edited by MacKonsti
Link to comment
Share on other sites

3 minutes ago, MacKonsti said:

Nevertheless, r5123 has the target device patch broken as I reported it after r5123 and cannot patch H_EC device

I can fix that and do a 5123.1!

What about 5122 ? Does it work for you ?

4 minutes ago, MacKonsti said:

OC support as "it can successfully boot Big Sur" and "Check new config-sample.plist"

I'm afraid that's a mistake... The tag was put on master branch, when the OC integration was still in another branch. But the mistake come from that.

  • Like 1
Link to comment
Share on other sites

48 minutes ago, iCanaro said:

in "mojave_5125 (master, commit 18038055a)OK_debug.log", it was a modified 18038055a and it boots. A non modified 18038055a seems not to boot it.

But all logs are the same.

Could you try commit 6a96d483304ac98bfcea5cba3d0d6c5e3ba2c1a4 and 109746ca8251ae953a4142db0dd46bbfc969d141 ?

EDIT : you just need to try Mojave.

Edited by Jief_Machak
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, Jief_Machak said:

What kind of answer do you expect from that post ?

With not even a debug.log, no info on what do you try to boot, with which version, etc. the only think I can say is "Poor you, sorry".

 

I'm not waiting for an answer, it was just an opinion or finding .... the clover is outdated ... I repeat everything that happens randomly ... I can't repeat two boot states ... so I have no logs to I'll show you ... it's not repetitive ... usb installer media is not displayed at boot ... for that you don't need any log ... I don't think I'm the only one in this situation ... if before the last version, I saw two  partitions (preboot and data ), now I see only one partition and I don't know which one it is ... most of the time it doesn't even boot from that partition ... in my opinion the kexts loading order still remains valid .... that's the problem ... and their patches ...it was just an opinion

Link to comment
Share on other sites

1 minute ago, corint1 said:

I'm not waiting for an answer, it was just an opinion or finding .... the clover is outdated ... I repeat everything that happens randomly ... I can't repeat two boot states ... so I have no logs to I'll show you ... it's not repetitive ... usb installer media is not displayed at boot ... for that you don't need any log ... I don't think I'm the only one in this situation ... if before the last version, I saw two  partitions (preboot and data ), now I see only one partition and I don't know which one it is ... most of the time it doesn't even boot from that partition ... in my opinion the kexts loading order still remains valid .... that's the problem ... and their patches ...it was just an opinion

Start by using less the 3 dots. Maybe it'll be less random :hysterical:

2 minutes ago, corint1 said:

usb installer media is not displayed at boot ... for that you don't need any log

Yes I do.

2 minutes ago, corint1 said:

I saw two  partitions (preboot and data ), now I see only one partition

Yep, redundant partition are now automatically hidden. And not randomly. You can still see them by pressing F3.

 

Listen, take your issues one by one. They can all be fixed. But you need to send something. Video of the random problem you are talking, debug.log, whatever. Something.

Link to comment
Share on other sites

7 minutes ago, Jief_Machak said:

Yep, redundant partition are now automatically hidden. And not randomly. You can still see them by pressing F3.

with F3 it doesn't show me anything more ... than the EFI partition ... I don't have time to take pictures or movies with what's happening ... I waste a lot of time with the compilation and then with the tests ... remember I'm clover and I'm positive ... if you noticed I gave directions ... and I still remain optimistic, if if I say something I say it because it happens, not because it seems to me ...
 

  • Sad 1
Link to comment
Share on other sites

4 minutes ago, iCanaro said:

@Jief_Machak 

To understand, when MatchOS finds blank field or All, kerneltopatch is applied for all macOS 
Correct?!

Yes.

 

Could you find a Clover folder that works for Mojave ? Because here I can't see anything wrong with Clover (maybe there is, but can't see it !).

Like a backup folder or whatever. Even if it works only for Mojave. Because it looks like a config.plist problem. Maybe a patch must NOT be applied ?

 

As usual, I call that differential debugging. I propose to restart from a working Mojave config. Then, we'll update Clover, knowing that the config.plist works and MUST NOT be touched. Then, we'll improve the working config.plist by importing changes from the non-working config.plist. Few at a times. And we'll know when it'll break.

Link to comment
Share on other sites

×
×
  • Create New...