Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30,171 posts in this topic

Recommended Posts

Andres ZeroCross
Andres ZeroCross
Posted
Posted
Stupid question about Clover. If there is a option set as 'NO' in default Clover Config.plist, can it be deleted? Or could Clover assume that something is 'YES' if it is missing on Config.plist? I would like to delete all options in plist that I've set as 'NO' for simplicity.

Not for all option, at GUI -> Scan, if you set Legacy = No, then there is no Legacy entry boot (if you boot with legacy). But if you delete this line, then legacy entry will shown. It's just for sample,

 

Sent from my Mi Note 2 using Tapatalk

 

 

 

  • Like 1
Link to comment
Share on other sites
Joni_78
Joni_78
Posted
Posted
10 hours ago, Andres ZeroCross said:

Not for all option, at GUI -> Scan, if you set Legacy = No, then there is no Legacy entry boot (if you boot with legacy). But if you delete this line, then legacy entry will shown. It's just for sample,

 

Sent from my Mi Note 2 using Tapatalk

 

 

 

 

Thank you. I guess it's better to leave 'No' entries in the plist.

Link to comment
Share on other sites
mrjayviper
mrjayviper
Posted
Posted (edited)

I got a board without built-in NVMe port in the motherboard.

 

Has anyone been able to use a PCIe-based NVMe and uses a USB drive/frontend with clover so the NVMe can be use as an OS drive? So the motherboard is booting off the USB stick and then clover will then be booting off the NVMe drive.

 

seems like it's going to work but wanting to know if anyone has used/tested such a setup.

 

Thanks a lot! :)

Edited by mrjayviper
Link to comment
Share on other sites
Badruzeus
Badruzeus
Posted
Posted
12 hours ago, pkdesign said:

Latest Clover 4769 breaks legacy BIOS boot. Had to revert back to 4741 in order to boot my system.

Working fine here either, I've 3 ancient machines using Legacy.

 

7 hours ago, ellaosx said:

latest has verbose before GUI. can we clean that?

On my case is not Clover, but recent "ApfsDriverLoader*.efi".

  • Like 3
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
5 hours ago, Badruzeus said:

Working fine here either, I've 3 ancient machines using Legacy.

 

On my case is not Clover, but recent "ApfsDriverLoader*.efi".

Is it a version from github where there is debug or from clover package where release version?

  • Like 2
Link to comment
Share on other sites
Badruzeus
Badruzeus
Posted
Posted
52 minutes ago, Slice said:

Is it a version from github where there is debug or from clover package where release version?

I did test again using ApfsDriverLoader-64.efi from r4769 (SourceForge release), and it gives no Apfs related debug logs. A same result with ApfsDriverLoader-64.efi v2.0.5 (github release). I was referring to this commit, but I could be wrong if this is the cause. I've reported this here on November 7th with r4741.

 

 

@ellaosx Is this debug logs you meant? I guess, it is from ApfsDriverLoader built with ebuild.sh --ext-co (or buildclover script) contains latest change from AppleSupportPackage (since, the build script will pull it).

VirtualBox_Clover Bootloader_22_11_2018_20_17_18.png

  • Like 2
Link to comment
Share on other sites
Badruzeus
Badruzeus
Posted
Posted
2 minutes ago, Matgen84 said:

@Badruzeus @ellaosx

 

There is no issue with ApfsDriverloader.efi using Clover r4771 :)

 

If In understand well, ebuild.sh file: "--ext-co" "checkout & build external drivers at ..src/EXT_PACKAGES". It means download and compile from source this driver. Right? 

 

It should be: Yes (compiled from source using latest commit).

 

I just rebuilt r4771 using UDK, and weird is.. still ApfsDriverLoader gives debug logs (files attached).

@ellaosx is your 10.13 (or 10.14) using HFS+ or APFS? On my case is: HFS+, though I saw no diff with APFS previously. 

r4771-UDK-Apfs.zip

  • Thanks 1
Link to comment
Share on other sites
LAbyOne
LAbyOne
Posted
Posted
2 minutes ago, Badruzeus said:

It should be: Yes (compiled from source using latest commit).

 

I just rebuilt r4771 using UDK, and weird is.. still ApfsDriverLoader gives debug logs (files attached).

@ellaosx is your 10.13 (or 10.14) using HFS+ or APFS? On my case is: HFS+, though I saw no diff with APFS previously. 

r4771-UDK-Apfs.zip

Same here HFS+ 10.13  latest 3 releases have this behaviour previous versions don't

  • Like 1
Link to comment
Share on other sites
Matgen84
Matgen84
Posted
Posted
1 hour ago, Badruzeus said:

It should be: Yes (compiled from source using latest commit).

 

I just rebuilt r4771 using UDK, and weird is.. still ApfsDriverLoader gives debug logs (files attached).

@ellaosx is your 10.13 (or 10.14) using HFS+ or APFS? On my case is: HFS+, though I saw no diff with APFS previously. 

r4771-UDK-Apfs.zip

 

If you want, you can test my apfsdriverloader: it works well on Mojave

ApfsDriverLoader-64.efi.zip

  • Like 1
Link to comment
Share on other sites
fusion71au
fusion71au
Posted
Posted (edited)
On 11/22/2018 at 5:31 AM, pkdesign said:

Latest Clover 4769 breaks legacy BIOS boot. Had to revert back to 4741 in order to boot my system.

 

Try replacing just the "boot" file with the one attached, compiled with GCC53.  I have also attached Clover_v2.4k_r4772 package installer compiled with GCC53...

 

1603819292_bootfile.png.2ad1145c5c4ef0610c131ba081ad6168.png

 

I noticed that for the latest officially released Clover r4769 from Sourceforge, the boot process would hang on my legacy desktop after seeing "6" on the screen.  It seems that CloverEFI (the boot6/boot7 "boot" file) compiled with XCODE 10.1 fails to chainload CLOVERX64.efi but CloverEFI compiled with GCC53 works OK.

 

Bug possibly due to latest edk2 28338 sync with commit r4761?

 

Clover_v2.4k_r4772.pkg.zip

boot.zip

Edited by fusion71au
XCODE 10.1 problem but XCODE 8, 9 and GCC OK
  • Like 2
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
6 hours ago, fusion71au said:

 

Try replacing just the "boot" file with the one attached, compiled with GCC53.  I have also attached Clover_v2.4k_r4772 package installer compiled with GCC53...

 

1603819292_bootfile.png.2ad1145c5c4ef0610c131ba081ad6168.png

 

I noticed that for the latest officially released Clover r4769 from Sourceforge, the boot process would hang on my legacy desktop after seeing "6" on the screen.  It seems that CloverEFI (the boot6/boot7 "boot" file) compiled with XCODE fails to chainload CLOVERX64.efi but CloverEFI compiled with GCC53 works OK.

 

Bug possibly due to latest edk2 28338 sync with commit r4761?

 

Clover_v2.4k_r4772.pkg.zip

boot.zip

officially released Clover 4769 compiled with UDK2018 without any changes for a long period.

  • Like 3
Link to comment
Share on other sites
fusion71au
fusion71au
Posted
Posted (edited)
On 11/23/2018 at 9:27 PM, Slice said:

officially released Clover 4769 compiled with UDK2018 without any changes for a long period.

 

@Slice,

 

Notice that commit r4761 includes a change to Variable.c in /Patches_for_UDK2018/MdeModulePkg/Universal/Variable/RuntimeDxe/ ...

 

Spoiler 

--- a/Patches_for_UDK2018/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
+++ b/Patches_for_UDK2018/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
@@ -2459,6 +2459,8 @@
         if (Variable->CurrPtr != NULL) {
           if (VariableCompareTimeStampInternal (&(((AUTHENTICATED_VARIABLE_HEADER *) CacheVariable->CurrPtr)->TimeStamp), TimeStamp)) {
             CopyMem (&AuthVariable->TimeStamp, TimeStamp, sizeof (EFI_TIME));
+          } else {
+            CopyMem (&AuthVariable->TimeStamp, &(((AUTHENTICATED_VARIABLE_HEADER *) CacheVariable->CurrPtr)->TimeStamp), sizeof (EFI_TIME));
           }
         }
       }

 

 

Also noticed that official Clover r4769 was compiled with XCODE 10.1 (with tool chain set to XCODE8) but r4741 was compiled with XCODE 8.3.3 ---> successful boot...

  

6:891  0:000  Starting Clover revision: 4741 on CLOVER EFI
6:891  0:000  Build with: [Args: -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE8 | -D NO_GRUB_DRIVERS_EMBEDDED -D USE_LOW_EBDA -a X64 -b RELEASE -t XCODE8 -n 5 | OS: 10.12.6 | XCODE: 8.3.3]

Edit

Further to XCODE 10.1 being the problem, my legacy desktop boots fine with Clover r4772 compiled with XCODE 8.2.1 or XCODE 9.2 (both with tool chain set to XCODE8)....

  

6:897  0:000  Starting Clover revision: 4772 on CLOVER EFI
6:897  0:000  Build with: [Args: -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE8 | -D DISABLE_USB_SUPPORT -D NO_GRUB_DRIVERS_EMBEDDED --conf=/Users/fusion71au/src/edk2/Conf -D USE_BIOS_BLOCKIO -D USE_LOW_EBDA -a X64 -b RELEASE -t XCODE8 -n 3 | OS: 10.11.6 | XCODE: 8.2.1]

  

6:911  0:000  Starting Clover revision: 4772 on CLOVER EFI
6:911  0:000  Build with: [Args: -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -D USE_APPLE_HFSPLUS_DRIVER -t XCODE8 | -D DISABLE_USB_SUPPORT -D NO_GRUB_DRIVERS_EMBEDDED --conf=/Users/fusion71au/src/edk2/Conf -D USE_BIOS_BLOCKIO -D USE_LOW_EBDA -a X64 -b RELEASE -t XCODE8 -n 5 | OS: 10.13.6 | XCODE: 9.2]

 

If I swap out the boot6 "boot" file with one compiled with XCODE 10.1, the boot hangs ---> after seeing "6" on the screen, it stops at an underscore symbol "_" and no GUI appears.

Edited by fusion71au
r4772 tested OK compiled with XCODE 8.2.1, 8.3.3 or 9.2 but not 10.1
  • Like 2
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
18 hours ago, fusion71au said:

 

@Slice,

 

Notice that commit r4761 includes a change to Variable.c in /Patches_for_UDK2018/MdeModulePkg/Universal/Variable/RuntimeDxe/ ...

 

 

 

This is never used.

For legacy Clover boot6 and boot7 there is

MdeModulePkg/Universal/Variable/EmuRuntimeDxe/

And for EmuVariableDxe.efi there is separate sources

Clover/Protocols/EmuVariableUefi/EmuVariableRuntimeDxe.inf

Otherwise we have hardware NVRAM and use Variable functions from UEFI BIOS.

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