Jump to content
30960 posts in this topic

Recommended Posts

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

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

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

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

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

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.

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

@Jief_Machak

may I ask maybe a stupid thing?

It seems that debug log is written till boot loader bootmenu appears before choosing from which OS I want to boot
After choosing and booting it does not write any data anymore

 

If it is so, in the debug log I see always:

GetOSVersion: 10.13.6 (17G14033)

[OS: 10.13.6 | MatchOS: All | MatchBuild: no] ==> allowed by OS

 

also if I start Big Sur

 

Is there a your commit which solve this?

Or in your opinion is not related to the problem some people have to not be able to have a single config.plist to boot in high Sierra or Big Sur?

 

thank you

5 minutes ago, Jief_Machak said:

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.

without touching absolutely anything in the setup
using the default config.plist created from scratch yesterday starting from the sample, but only by changing version of Clover, in this case one that I compiled yesterday, mojave (but also catalina and BS) starts without problems

5125 (master, commit 18038055a)_MOJ_OK_debug.log

CLOVERX64_5125_18038055a.efi.zip

11 minutes ago, iCanaro said:

without touching absolutely anything in the setup
using the default config.plist created from scratch yesterday starting from the sample, but only by changing version of Clover, in this case one that I compiled yesterday, mojave (but also catalina and BS) starts without problems

5125 (master, commit 18038055a)_MOJ_OK_debug.log

CLOVERX64_5125_18038055a.efi.zip

I know, but that doesn't help. The clover that can boot mojave is a local compilation I've made. So I've made a modification, made it work, and maybe lost it in the next commits.

Because the logs are the same, whether it works or not, our only chance is to do as I proposed to understand what make it fail. So I can add logs, understand, and re-fix it.

Sorry about that. I was multitasking too much the other day...

22 minutes ago, iCanaro said:

in this case one that I compiled yesterday

Sorry, I saw build id : 20201021172059-1803805-dirty and I thought I compiled it, with a modification.

Ok, things are different now.

1) the build id is "dirty". That means a file was modified compare to github. Do you still have that dir where you compiled that version ? Can you do git status in it ?

Edited by Jief_Machak
6 minutes ago, Jief_Machak said:

Can you do git status in it ?

1457709628_Schermata2020-10-23alle13_17_07.thumb.png.398a0e5b26cc81613725340cd46fc5a5.png

 

12 minutes ago, Jief_Machak said:

I know, but that doesn't help. The clover that can boot mojave is a local compilation I've made. So I've made a modification, made it work, and maybe lost it in the next commits.

Because the logs are the same, whether it works or not, our only chance is to do as I proposed to understand what make it fail. So I can add logs, understand, and re-fix it.

Sorry about that. I was multitasking too much the other day...

 

if i got it right basically text i clover taken here

https://github.com/jief666/CloverCommits

until, if I can, find the point between the one he starts and the next one that doesn't start

there's no problem

no, no, wait, wait.

If you can compile a commit, make it work and the one I compile doesn't, it's a whole different story.

Forgot what I've said. Do not delete or change anything yet.

 

Buildme may have updated it, because now we are at the latest commit.

You should have done what I proposed "git status", and not buildme -> status.

I don't know if buildme was updated to handle the git submodule.

 

Still, it's strange you have new commits in OpenCorePkg. Could "cd" in OpenCore and do "git status" ?

 

10 minutes ago, Jief_Machak said:

no, no, wait, wait.

If you can compile a commit, make it work and the one I compile doesn't, it's a whole different story.

Forgot what I've said. Do not delete or change anything yet.

 

Buildme may have updated it, because now we are at the latest commit.

You should have done what I proposed "git status", and not buildme -> status.

I don't know if buildme was updated to handle the git submodule.

 

Still, it's strange you have new commits in OpenCorePkg. Could "cd" in OpenCore and do "git status" ?

 


Hi @Jief_Machak BuildMe don't have --recursive-submodules args for git clone. First I create the submodule in my currently existing repo. Finally, I recreate a clean src folder and git clone with --recursive-submodules args.

Spoiler

iMac-de-Mathieu:opencorepkg mathieu$ git status

HEAD detached at 39fb4341

nothing to commit, working tree clean

iMac-de-Mathieu:opencorepkg mathieu$ git log

commit 39fb43413e5d3377de65bd0355a11b790edada4f (HEAD, origin/master, origin/HEAD, master)

Author: jief666 <github.com@jfa.knudsen.ovh>

Date:   Wed Oct 21 17:26:33 2020 +0300

 

    Less log + global for InternalGetApfsSpecialFileInfo.

 

Edited by Matgen84

anyway, for information, I've been testing back the Clover here
https://github.com/jief666/CloverCommits
until C-20201016100620-aee426f-5125.efi
and no one starts mojaje me, indeed to be honest, I tested some of them also on BS and he does not start too.
only by selecting configs with the matchos fields empty starts BS but mojave even so it still doesn't start

  • Sad 1
×
×
  • Create New...