SavageAUS Posted October 23, 2020 Share Posted October 23, 2020 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 More sharing options...
Guest Posted October 23, 2020 Share Posted October 23, 2020 (edited) @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 Edited October 23, 2020 by Guest config--->debug.log Link to comment Share on other sites More sharing options...
Jief_Machak Posted October 23, 2020 Share Posted October 23, 2020 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 More sharing options...
Jief_Machak Posted October 23, 2020 Share Posted October 23, 2020 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 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 More sharing options...
Jief_Machak Posted October 23, 2020 Share Posted October 23, 2020 @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. 2 Link to comment Share on other sites More sharing options...
Guest Posted October 23, 2020 Share Posted October 23, 2020 (edited) @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 October 23, 2020 by Guest typo Link to comment Share on other sites More sharing options...
Jief_Machak Posted October 23, 2020 Share Posted October 23, 2020 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/ 2 Link to comment Share on other sites More sharing options...
Guest Posted October 23, 2020 Share Posted October 23, 2020 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 More sharing options...
MacKonsti Posted October 23, 2020 Share Posted October 23, 2020 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 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. 1 Link to comment Share on other sites More sharing options...
corint1 Posted October 23, 2020 Share Posted October 23, 2020 (edited) 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 October 23, 2020 by corint1 Link to comment Share on other sites More sharing options...
Jief_Machak Posted October 23, 2020 Share Posted October 23, 2020 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 More sharing options...
Jief_Machak Posted October 23, 2020 Share Posted October 23, 2020 1 hour ago, MacKonsti said: recompiled final version of Clover pre-OpenCore I think that's 5123. https://github.com/CloverHackyColor/CloverBootloader/releases/tag/5123 Link to comment Share on other sites More sharing options...
iCanaro Posted October 23, 2020 Share Posted October 23, 2020 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 1 Link to comment Share on other sites More sharing options...
MacKonsti Posted October 23, 2020 Share Posted October 23, 2020 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 Thank you Link to comment Share on other sites More sharing options...
Jief_Machak Posted October 23, 2020 Share Posted October 23, 2020 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 . 1 Link to comment Share on other sites More sharing options...
Jief_Machak Posted October 23, 2020 Share Posted October 23, 2020 (edited) 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 Thank you That's exactly what @Slice did with 5123. This 5123 is just before the merge to bring OC in master branch. Edited October 23, 2020 by Jief_Machak Link to comment Share on other sites More sharing options...
MacKonsti Posted October 23, 2020 Share Posted October 23, 2020 (edited) 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 October 23, 2020 by MacKonsti Link to comment Share on other sites More sharing options...
Jief_Machak Posted October 23, 2020 Share Posted October 23, 2020 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. 1 Link to comment Share on other sites More sharing options...
Jief_Machak Posted October 23, 2020 Share Posted October 23, 2020 (edited) 48 minutes ago, iCanaro said: 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 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 October 23, 2020 by Jief_Machak 1 Link to comment Share on other sites More sharing options...
corint1 Posted October 23, 2020 Share Posted October 23, 2020 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 More sharing options...
iCanaro Posted October 23, 2020 Share Posted October 23, 2020 17 minutes ago, Jief_Machak said: Could you try commit 6a96d483304ac98bfcea5cba3d0d6c5e3ba2c1a4 and 109746ca8251ae953a4142db0dd46bbfc969d141 ? EDIT : you just need to try Mojave. done and here's the logsC-20201023090401-109746c.efi_MOJ_NOK_debug.log C-20201022165530-6a96d48.efi_MOJ_NOK_debug.log Link to comment Share on other sites More sharing options...
Jief_Machak Posted October 23, 2020 Share Posted October 23, 2020 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 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 More sharing options...
iCanaro Posted October 23, 2020 Share Posted October 23, 2020 @Jief_Machak To understand, when MatchOS finds blank field or All, kerneltopatch is applied for all macOS Correct?! Link to comment Share on other sites More sharing options...
corint1 Posted October 23, 2020 Share Posted October 23, 2020 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 ... 1 Link to comment Share on other sites More sharing options...
Jief_Machak Posted October 23, 2020 Share Posted October 23, 2020 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 More sharing options...
Recommended Posts