Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30,171 posts in this topic

Recommended Posts

Matgen84
Matgen84
Posted
Posted (edited)
33 minutes ago, Jief_Machak said:

My second entry is Options and 3rd is about Clover with Clover sign.

 

 

Send me your debug.log. It doesn't do that here, so I can't tell.

 

 

@Jief_Machak In my theme, Options is also the second entry

 

When I rename, @Jief_Machak CLOVERX64.efi to BOOTX64.efi. When I pass spacebar  on Boot macOS from BigSur - Data via Prebbot. Clover GUI hangs on Options for Boot macOS from BigSur - Data via Prebbot on Preboot. No mouse, no keyboard.

 

EDIT: After reboot, I clean NVRAM (F11). So I can get out of Options sections. But I can't boot at all when I click on OS icons (no keyboard no mouse).

EDIT 2: In fact, I can't boot at all after select Os Icon (no pointer, no keyboard) :cry:

debug.log

Edited by Matgen84
Link to comment
Share on other sites
iCanaro
iCanaro
Posted
Posted (edited)
1 hour ago, Slice said:

I see there are many people not understanding what is what. Let me clarify.

UEFI BIOS usually boot to /EFI/BOOT/BOOTX64.EFI but this file can be replaced by Windows installation or by Linux installation so why we decided to keep Clover as separate file /EFI/CLOVER/CLOVERX64.EFI which will be untouchable by other systems. But UEFI BIOS doesn't know Clover! How to learn it to boot to Clover? We developed a way to do this, regards to Dmazar. 

In the Clover GUI you may see second line of entries like tools entries. First one is to call Shell.efi and the second one with a Clover sign is for writing the boot entry /EFI/CLOVER/CLOVERX64.EFI into nvram to use as default boot entry.

So now on my computer #1 I have two boot entries which I can choose by pressing F12:

"UEFI Boot from HDD" which linked to /EFI/BOOT/BOOTX64.EFI which is older good working Clover 5122.

"Clover boot from HDD" which linked to /EFI/CLOVER/CLOVERX64.EFI which is current test version.

The file BOOTX64.EFI is just the file CLOVERX64.EFI of other revision being renamed.

 

 

Thank you! you were enlightening... I always discover new things about Clover that I wasn't fully aware of

 

PS: what happened to Clover's PDF guide, even if in Russian, maybe you find someone who translates it

Edited by iCanaro
  • Like 1
Link to comment
Share on other sites
Matgen84
Matgen84
Posted
Posted (edited)
8 minutes ago, mifjpn said:

Thank you for Jief's efforts.
Apparently, WhatEverGreen.kext from Big Sur hasn't been injected. The result was the same without putting it.
I think Jief already knows, but OpenCore does not consider the order of injection of Kexts of OpenCore.
When creating a config.plist, the order is consciously decided and included.
Looking at the log, it seems that they are arranged in the order in which they were read, but I was a little worried, so I reported.

 

Just my opinion: Opencore load Lilu first.

 

From Dortania guide: About Kernel/Add section, "Here's where you specify which kexts to load, order matters here so make sure Lilu.kext is always first! Other higher priority kexts come after Lilu such as VirtualSMC, AppleALC, WhateverGreen, etc."

Edited by Matgen84
  • Like 1
Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted
18 minutes ago, Matgen84 said:

 

Just my opinion: Opencore load Lilu first.

 

From Dortania guide: About Kernel/Add section, "Here's where you specify which kexts to load, order matters here so make sure Lilu.kext is always first! Other higher priority kexts come after Lilu such as VirtualSMC, AppleALC, WhateverGreen, etc."

 

If unspecified, a "default" kext load order seems like a good idea, as long as there is an easy way customize the kext order (override the default).

Link to comment
Share on other sites
iCanaro
iCanaro
Posted
Posted
1 minute ago, tonyx86 said:

 

Se non specificato, un ordine di caricamento di kext "predefinito" sembra una buona idea, a patto che esista un modo semplice per personalizzare l'ordine di kext (sovrascrivere il predefinito).

In a way, it already exists
in other kexts are prioritized over 10.xx or 11

  • Like 1
  • Thanks 1
Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted
5 minutes ago, Slice said:

Lilu is just wrong designed. It should not be first loaded, it should be first started.

 

I think Lilu kext start must be working correctly, because I don't observe any problems when I install my 3rd-party kexts in /L/E (not injected by CLOVER).  No?

Link to comment
Share on other sites
usr-sse2
usr-sse2
Posted
Posted
22 minutes ago, Slice said:

Lilu is just wrong designed. It should not be first loaded, it should be first started.

It's related to OpenCore, not Lilu. OpenCore requires that the dependencies should be placed before dependent kexts, or else it would drop them because it can't find the symbols. The same applies to e. g. VoodooPS2Controller which should be placed before VoodooPS2Trackpad.

  • Like 1
Link to comment
Share on other sites
Jief_Machak
Jief_Machak
Posted
Posted

Ok, I'm back.

In this experimental version, I made sure lilu is loaded first. To test, this EFI will make sure that the first kext to be injected are :

  Lilu.kext
  VirtualSMC.kext
  WhateverGreen.kext
  AppleALC.kext
  IntelMausi.kext
  SMCProcessor.kext
  SMCSuperIO.kext
  USBPorts.kext
No problem if don't have all that, of course. I got this order looking at the working config,plist of MatGen84.

 

I don't really get this UI freeze. I don't have them in Qemu or VMWare. Everyone, could you try this efi (not committed, so you really have to get this file). And send me the debug.log ?

CloverX64.efi.zip

  • Like 1
Link to comment
Share on other sites
Matgen84
Matgen84
Posted
Posted (edited)
11 minutes ago, Jief_Machak said:

I forgot to say something : my first goal with this experiment, is to boot Big Sur INSTALLER.

Are you all trying to boot an installer, or an installed macOs ?

 

All my tests are from USB Installer. sixth tests in progress.
 

Always busy time out 'ACPICPU' 'ARTC'. Prebbot.log in few minutes

Hi @Jief_Machak

Preboot.log attached

 

Always busy time out 'ACPICPU' 'ARTC' and black screen. Big Sur seems to be loaded (sounds effect when I press spacebar)

 

EDIT: Rename CLOVERX64.efi to BOOTX.64 still don't work. Hangs Clover, can't boot :bye: I've to use official 5122 BOOTX64.efi instead of it, to test

 

 

debug.log

Edited by Matgen84
an
  • Like 1
Link to comment
Share on other sites
lclerte
lclerte
Posted
Posted
4 hours ago, LIMITANT said:

 

 

This this the point ... how can we mix that !!!

Only if @Slice and @vit9696 are agreed to work together as one team ..

I think Apple Big Sur beta is the beginning of difficulties , future releases will need more hard work what can be resolved by working as one team

 

Dear friends, I am, here, very happy to see that many of you share my certainty, which I have expressed on other forums (and which has earned me many insults!): That the years will be difficult, the new versions of Mac OS more and more difficult to boot and that the only solution is to bring together all the old and new devs on Clover and Opencore on a single and unique bootloader project,"CloveOpen" ,  which would combine the ease of Clover and the precision of Opencore..Otherwise, both will disappear and we will find ourselves condemned to no longer be able to use that Big Sur !! Thanks for reading

  • Like 1
Link to comment
Share on other sites
Jief_Machak
Jief_Machak
Posted
Posted
7 minutes ago, Matgen84 said:

Preboot.log attached

Before sending preboot, search for this line  

=== [ StartLoader ] =============================

or this line 

=== [ StartLoader11 ] ===========================

If you have the first... it's the wrong efi.

 

To avoid mistakes, you take the habit to copy the file in EFI/CLOVER and use my little script to copy it on EFI/BOOT/BOOX64.efi

 

 

 

copy cloverX64 to efi_boot

  • Thanks 1
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

GCC compilation strange error 

[CC] AutoGen
during IPA pass: cp
lto1: internal compiler error: Segmentation fault: 11
[CC] driver
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

May be I have to update gcc-10.1 -> 10.2

  • Thanks 1
Link to comment
Share on other sites
Matgen84
Matgen84
Posted
Posted
1 minute ago, Jief_Machak said:

Before sending preboot, search for this line  


=== [ StartLoader ] =============================

or this line 


=== [ StartLoader11 ] ===========================

If you have the first... it's the wrong efi.

 

To avoid mistakes, you take the habit to copy the file in EFI/CLOVER and use my little script to copy it on EFI/BOOT/BOOX64.efi

 

 

 

copy cloverX64 to efi_boot

 

 

@Jief_Machak Thanks for the script. But I've got a problem with your Cloverx64: when I rename to Boot/Bootx64.efi: I can't boot at all, hangs on Clover GUI.

I try your script, now

Link to comment
Share on other sites
Jief_Machak
Jief_Machak
Posted
Posted
Just now, Slice said:

GCC compilation strange error 


[CC] AutoGen
during IPA pass: cp
lto1: internal compiler error: Segmentation fault: 11
[CC] driver
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

May be I have to update gcc-10.1 -> 10.2

I know version Gcc 9.2.0 is working. I can send you the zip version of the folder containing that gcc, if you'd like

2 minutes ago, Matgen84 said:

I can't boot at all, hangs on Clover GUI.

Still send me the debug.log after you rebooted. I'd like to see where it stops. I didn't touch the UI in that experimental version. So it might be a bug that exists in the master branch. We should definitely catch that.

Link to comment
Share on other sites
Matgen84
Matgen84
Posted
Posted
3 minutes ago, Jief_Machak said:

I know version Gcc 9.2.0 is working. I can send you the zip version of the folder containing that gcc, if you'd like

Still send me the debug.log after you rebooted. I'd like to see where it stops. I didn't touch the UI in that experimental version. So it might be a bug that exists in the master branch. We should definitely catch that.

 

Sorry How to use you little script ! Please

Link to comment
Share on other sites
Jief_Machak
Jief_Machak
Posted
Posted
1 minute ago, Matgen84 said:

 

Sorry How to use you little script ! Please

Just put it in EFI/CLOVER(so next to CloverX64.efi) and double click on it in Finder. It is just a one line cp command in it.

Quicker than duplicate CloverX64.efi in Finder, then rename it, then move it. But there is no magic... ^_^

  • Thanks 1
  • Haha 1
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Master branch compiled by gcc-10.1 fine. The possible reason is OC tuned for XCODE5 and uses own version of EDK2.

I think it will be better not to copy the whole OC but get all needed libraries and modules from them and use our compilation system with our EDK2 modules.

I have to remind that I previously did this including OpenRuntime and OcQuirks.

  • Like 2
Link to comment
Share on other sites
Matgen84
Matgen84
Posted
Posted (edited)
15 minutes ago, Jief_Machak said:

Just put it in EFI/CLOVER(so next to CloverX64.efi) and double click on it in Finder. It is just a one line cp command in it.

Quicker than duplicate CloverX64.efi in Finder, then rename it, then move it. But there is no magic... ^_^

 

CLOVERX64 renane BOOTX64 ---> OK

But  I can't boot at all: very strange error message on the monitor (see pictures) 

 

Debug.log attached

debug.log

 

 

1.jpg

Edited by Matgen84
  • Like 1
Link to comment
Share on other sites
Jief_Machak
Jief_Machak
Posted
Posted
1 minute ago, Slice said:

I have to remind that I previously did this including OpenRuntime and OcQuirks.

I didn't realise. I didn't really see it before I started this. If you had integrated OcStartImage, ok, no problem to jump back to master.

I was wondering if it was possible to get the all OC folder and then point to the part we want to use. The main reason for that is that keeping in sync with the main OC repo is ultra simple ! One git command to merge from upstream and all my little modifications (mainly removing some STATIC) and the file I added are still there while OC is updated. I am really against duplication when possible.

And because it's a submodule, it doesn't even take space in the Clover repo !

That's also why I used a branch. I leave you the final word. If you prefer that we get and copy what we need from Clover, that's OK. In that case, I still think we should make a folder where we put everything that come from OC. But if you think about that, it's basically what it is now.

 

Link to comment
Share on other sites
Slice
Slice
Posted
Posted
6 minutes ago, Jief_Machak said:

I didn't realise. I didn't really see it before I started this. If you had integrated OcStartImage, ok, no problem to jump back to master.

I was wondering if it was possible to get the all OC folder and then point to the part we want to use. The main reason for that is that keeping in sync with the main OC repo is ultra simple ! One git command to merge from upstream and all my little modifications (mainly removing some STATIC) and the file I added are still there while OC is updated. I am really against duplication when possible.

And because it's a submodule, it doesn't even take space in the Clover repo !

That's also why I used a branch. I leave you the final word. If you prefer that we get and copy what we need from Clover, that's OK. In that case, I still think we should make a folder where we put everything that come from OC. But if you think about that, it's basically what it is now.

 

I propose currently don't mix these branches until new one will be more or less working. Currently no.

I updated gcc-10 and successfully compiled the master-branch but not new one. 

[SLINK] UsbKbDxe
during IPA pass: cp
lto1: internal compiler error: Segmentation fault: 11
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper: fatal error: /Users/sergey/src/opt/local/cross/bin/x86_64-clover-linux-gnu-gcc returned 1 exit status
compilation terminated.
/Users/sergey/src/opt/local/cross/lib/gcc/x86_64-clover-linux-gnu/10.2.0/../../../../x86_64-clover-linux-gnu/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [/Users/sergey/src/CloverBootloader/Build/Clover/RELEASE_GCC53/X64/FileSystems/VBoxFsDxe/VBoxIso9660/DEBUG/VBoxIso9600.dll] Error 1

It looks like some script error mixing DEBUG and RELEASE folders.

  • Like 1
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...