Bootloader Clover problems report & features request

[Badruzeus]

Sorry guys, anyway.. I just finished migrating from OS X 10.11.6 + Xcode 8.2.1 to macOS 10.13.6 + Xcode 10.1.

Now, I'm having this issue when building Clover using: ./ebuild.sh -fr then on ./makepkg:

 

Building CloverUpdater application...
2019-03-25 05:19:22.199 xcodebuild[58708:503021] [MT] DVTSDK: Skipped SDK /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk; its version (10.6) is below required minimum (10.11) for the macosx platform.
2019-03-25 05:19:22.199 xcodebuild[58708:503021] [MT] DVTSDK: Skipped SDK /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk; its version (10.7) is below required minimum (10.11) for the macosx platform.
2019-03-25 05:19:22.200 xcodebuild[58708:503021] [MT] DVTSDK: Skipped SDK /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk; its version (10.8) is below required minimum (10.11) for the macosx platform.
2019-03-25 05:19:22.200 xcodebuild[58708:503021] [MT] DVTSDK: Skipped SDK /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk; its version (10.9) is below required minimum (10.11) for the macosx platform.
2019-03-25 05:19:22.201 xcodebuild[58708:503021] [MT] DVTSDK: Skipped SDK /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk; its version (10.10) is below required minimum (10.11) for the macosx platform.
** BUILD FAILED **


The following build commands failed:
	Ld /Users/badruzeus/src/UDK2018/Clover/CloverPackage/CloverUpdater/build/CloverUpdater.app/Contents/MacOS/CloverUpdater normal x86_64
(1 failure)
make: *** [CloverUpdater] Error 65
MacBook-Pro:CloverPackage badruzeus$ 

..and yes, I use multiple SDK's on /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/

(10.6 upto 10.14), MinimumSDKVersion on '../MacOSX.platform/Info.plist' is 10.11.

Any missing step with Xcode 10? Thanks.

Edited March 24, 2019 by Badruzeus

[Matgen84]

8 hours ago, Badruzeus said:

Sorry guys, anyway.. I just finished migrating from OS X 10.11.6 + Xcode 8.2.1 to macOS 10.13.6 + Xcode 10.1.

Now, I'm having this issue when building Clover using: ./ebuild.sh -fr then on ./makepkg:

 

Building CloverUpdater application...
2019-03-25 05:19:22.199 xcodebuild[58708:503021] [MT] DVTSDK: Skipped SDK /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk; its version (10.6) is below required minimum (10.11) for the macosx platform.
2019-03-25 05:19:22.199 xcodebuild[58708:503021] [MT] DVTSDK: Skipped SDK /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk; its version (10.7) is below required minimum (10.11) for the macosx platform.
2019-03-25 05:19:22.200 xcodebuild[58708:503021] [MT] DVTSDK: Skipped SDK /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk; its version (10.8) is below required minimum (10.11) for the macosx platform.
2019-03-25 05:19:22.200 xcodebuild[58708:503021] [MT] DVTSDK: Skipped SDK /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk; its version (10.9) is below required minimum (10.11) for the macosx platform.
2019-03-25 05:19:22.201 xcodebuild[58708:503021] [MT] DVTSDK: Skipped SDK /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk; its version (10.10) is below required minimum (10.11) for the macosx platform.
** BUILD FAILED **


The following build commands failed:
	Ld /Users/badruzeus/src/UDK2018/Clover/CloverPackage/CloverUpdater/build/CloverUpdater.app/Contents/MacOS/CloverUpdater normal x86_64
(1 failure)
make: *** [CloverUpdater] Error 65
MacBook-Pro:CloverPackage badruzeus$ 

..and yes, I use multiple SDK's on /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/

(10.6 upto 10.14), MinimumSDKVersion on '../MacOSX.platform/Info.plist' is 10.11.

Any missing step with Xcode 10? Thanks.

 

Hi

 

Sometimes ago, I've the same problem after migrate to Mojave + Xcode 10.1

 

I've forgotten to remove previous Xcode command tools and install tools for Xcode 10.1

Edited March 25, 2019 by Matgen84

[Badruzeus]

53 minutes ago, Matgen84 said:

 

Hi

 

Sometimes ago, I've the same problem after migrate to Mojave + Xcode 10.1

 

I've forgotten to remove previous Xcode command tools and install tools for Xcode 10.1

Ok, no worry.. my bad; I had issue with /Applications dir permissions before installing XCode. No problem after repair. Thanks.

[Matgen84]

Hi

 

Don't try with Xcode 10.1. After installing Xcode 10.2 and command lines tools 10.2 under Mojave 10.14.4: I've this issue to build Clover r4906

[CC] b64cdecode
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:60:9: error: redefinition of 'Netmodel' with a different type: 'CHAR8 *[4]' vs 'CHAR8 *' (aka 'char *')
CHAR8*  Netmodel[4];
        ^
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:33:9: note: previous definition is here
CHAR8*  Netmodel;
        ^
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:693:35: error: incompatible pointer types passing 'UINT32 (*)[4]' to parameter of type 'UINT32 *' (aka 'unsigned int *') [-Werror,-Wincompatible-pointer-types]
            GetPciADR(DevicePath, &NetworkADR1, &NetworkADR2, NULL);
                                  ^~~~~~~~~~~~
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:536:69: note: passing argument to parameter 'Addr1' here
VOID GetPciADR(IN EFI_DEVICE_PATH_PROTOCOL *DevicePath, OUT UINT32 *Addr1, OUT UINT32 *Addr2, OUT UINT32 *Addr3)
                                                                    ^
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:693:49: error: incompatible pointer types passing 'UINT32 (*)[4]' to parameter of type 'UINT32 *' (aka 'unsigned int *') [-Werror,-Wincompatible-pointer-types]
            GetPciADR(DevicePath, &NetworkADR1, &NetworkADR2, NULL);
                                                ^~~~~~~~~~~~
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:536:88: note: passing argument to parameter 'Addr2' here
VOID GetPciADR(IN EFI_DEVICE_PATH_PROTOCOL *DevicePath, OUT UINT32 *Addr1, OUT UINT32 *Addr2, OUT UINT32 *Addr3)
                                                                                       ^
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:696:33: error: incompatible pointer to integer conversion assigning to 'CHAR8' (aka 'char') from 'CHAR8 *' (aka 'char *'); dereference with * [-Werror,-Wint-conversion]
            Netmodel[net_count] = get_net_model(deviceid);
                                ^ ~~~~~~~~~~~~~~~~~~~~~~~
                                  *
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:2914:20: error: incompatible pointer to integer conversion assigning to 'CHAR8' (aka 'char') from 'CHAR8 *' (aka 'char *'); dereference with * [-Werror,-Wint-conversion]
    Netmodel[card] = get_net_model((FakeVen << 16) + FakeID);
                   ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                     *
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:2988:25: error: incompatible pointer to integer conversion passing 'UINT32 [4]' to parameter of type 'UINT32' (aka 'unsigned int') [-Werror,-Wint-conversion]
    aml_add_dword(root, NetworkADR1);
                        ^~~~~~~~~~~
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/AmlGenerator.h:27:52: note: passing argument to parameter 'value' here
AML_CHUNK* aml_add_dword(AML_CHUNK* parent, UINT32 value);
                                                   ^
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:2998:9: error: address of array 'NetworkADR2' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion]
    if (NetworkADR2) {
    ~~  ^~~~~~~~~~~
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:2999:22: error: ordered comparison between pointer and integer ('UINT32 *' (aka 'unsigned int *') and 'int') [-Werror]
      if (NetworkADR2> 0x3F)
          ~~~~~~~~~~~^ ~~~~
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:3031:33: error: incompatible integer to pointer conversion passing 'CHAR8' (aka 'char') to parameter of type 'CHAR8 *' (aka 'char *'); take the address with & [-Werror,-Wint-conversion]
    aml_add_string_buffer(pack, Netmodel[card]);
                                ^~~~~~~~~~~~~~
                                &
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/AmlGenerator.h:43:71: note: passing argument to parameter 'string' here
AML_CHUNK* aml_add_string_buffer(AML_CHUNK* parent, /* CONST*/ CHAR8* string);
                                                                      ^
9 errors generated.
make: *** [/Users/mathieu/src/UDK2018/Build/Clover/RELEASE_XCODE8/X64/Clover/rEFIt_UEFI/refit/OUTPUT/Platform/FixBiosDsdt.obj] Error 1


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/mathieu/src/UDK2018/Build/Clover/RELEASE_XCODE8/X64/Clover/rEFIt_UEFI/refit]


build.py...
 : error F002: Failed to build module
	/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/refit.inf [X64, XCODE8, RELEASE]

- Failed -

 

Edited March 26, 2019 by Matgen84

[Slice]

46 minutes ago, Matgen84 said:

Hi

 

Don't try with Xcode 10.1. After installing Xcode 10.2 and command lines tools 10.2 under Mojave 10.14.4: I've this issue to build Clover r4906

[CC] b64cdecode
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:60:9: error: redefinition of 'Netmodel' with a different type: 'CHAR8 *[4]' vs 'CHAR8 *' (aka 'char *')
CHAR8*  Netmodel[4];
        ^
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:33:9: note: previous definition is here
CHAR8*  Netmodel;
        ^
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:693:35: error: incompatible pointer types passing 'UINT32 (*)[4]' to parameter of type 'UINT32 *' (aka 'unsigned int *') [-Werror,-Wincompatible-pointer-types]
            GetPciADR(DevicePath, &NetworkADR1, &NetworkADR2, NULL);
                                  ^~~~~~~~~~~~
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:536:69: note: passing argument to parameter 'Addr1' here
VOID GetPciADR(IN EFI_DEVICE_PATH_PROTOCOL *DevicePath, OUT UINT32 *Addr1, OUT UINT32 *Addr2, OUT UINT32 *Addr3)
                                                                    ^
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:693:49: error: incompatible pointer types passing 'UINT32 (*)[4]' to parameter of type 'UINT32 *' (aka 'unsigned int *') [-Werror,-Wincompatible-pointer-types]
            GetPciADR(DevicePath, &NetworkADR1, &NetworkADR2, NULL);
                                                ^~~~~~~~~~~~
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:536:88: note: passing argument to parameter 'Addr2' here
VOID GetPciADR(IN EFI_DEVICE_PATH_PROTOCOL *DevicePath, OUT UINT32 *Addr1, OUT UINT32 *Addr2, OUT UINT32 *Addr3)
                                                                                       ^
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:696:33: error: incompatible pointer to integer conversion assigning to 'CHAR8' (aka 'char') from 'CHAR8 *' (aka 'char *'); dereference with * [-Werror,-Wint-conversion]
            Netmodel[net_count] = get_net_model(deviceid);
                                ^ ~~~~~~~~~~~~~~~~~~~~~~~
                                  *
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:2914:20: error: incompatible pointer to integer conversion assigning to 'CHAR8' (aka 'char') from 'CHAR8 *' (aka 'char *'); dereference with * [-Werror,-Wint-conversion]
    Netmodel[card] = get_net_model((FakeVen << 16) + FakeID);
                   ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                     *
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:2988:25: error: incompatible pointer to integer conversion passing 'UINT32 [4]' to parameter of type 'UINT32' (aka 'unsigned int') [-Werror,-Wint-conversion]
    aml_add_dword(root, NetworkADR1);
                        ^~~~~~~~~~~
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/AmlGenerator.h:27:52: note: passing argument to parameter 'value' here
AML_CHUNK* aml_add_dword(AML_CHUNK* parent, UINT32 value);
                                                   ^
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:2998:9: error: address of array 'NetworkADR2' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion]
    if (NetworkADR2) {
    ~~  ^~~~~~~~~~~
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:2999:22: error: ordered comparison between pointer and integer ('UINT32 *' (aka 'unsigned int *') and 'int') [-Werror]
      if (NetworkADR2> 0x3F)
          ~~~~~~~~~~~^ ~~~~
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/FixBiosDsdt.c:3031:33: error: incompatible integer to pointer conversion passing 'CHAR8' (aka 'char') to parameter of type 'CHAR8 *' (aka 'char *'); take the address with & [-Werror,-Wint-conversion]
    aml_add_string_buffer(pack, Netmodel[card]);
                                ^~~~~~~~~~~~~~
                                &
/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/Platform/AmlGenerator.h:43:71: note: passing argument to parameter 'string' here
AML_CHUNK* aml_add_string_buffer(AML_CHUNK* parent, /* CONST*/ CHAR8* string);
                                                                      ^
9 errors generated.
make: *** [/Users/mathieu/src/UDK2018/Build/Clover/RELEASE_XCODE8/X64/Clover/rEFIt_UEFI/refit/OUTPUT/Platform/FixBiosDsdt.obj] Error 1


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/mathieu/src/UDK2018/Build/Clover/RELEASE_XCODE8/X64/Clover/rEFIt_UEFI/refit]


build.py...
 : error F002: Failed to build module
	/Users/mathieu/src/UDK2018/Clover/rEFIt_UEFI/refit.inf [X64, XCODE8, RELEASE]

- Failed -

 

I C

[Badruzeus]

Thanks @Slice build succeeded after r4907, booting fine as usual, GFX model detection is also working (I think).

I just don't get what does r4904 commit mean related to HDEF, what's changed?

[apianti]

@Slice,

 

From that code, NetName is not referenced anywhere else in code, why does it exist?

 

@Badruzeus,

 

The difference is that it changed from fixing the device name and injecting properties to merely just fixing the device. The properties are added with hda injection enabled instead.

[Slice]

8 hours ago, apianti said:

@Slice,

 

From that code, NetName is not referenced anywhere else in code, why does it exist?

 

Because of 4908 

[apianti]

9 hours ago, Slice said:

Because of 4908 

 

You should use only one string instead then and when you make the device in aml, set the fourth character to the card number like

STATIC CHAR8 NetName[5] = "ETH0";
...
NetName[3] = '0' + (CHAR8)card;
dev = aml_add_device(root, NetName);

That changes the amount of binary memory space used from more than twenty bytes including instructions to like ten bytes including instructions. Any list of strings that behaves like this should be changed as it will reduce the binary size and performs appropriately the same.

 

EDIT: Typo.

Edited March 27, 2019 by apianti

[fusion71au]

Hi guys,

 

I noticed that I started getting CMOS resets on my legacy Ga-P55aUD3 desktop (system 2 in my sig) after updating to 10.14.4.  This was fixed by replacing the AppleRTC.kext in 10.14.4 with the vanilla kext from 10.14.3 (and rebuilding kextcache/pre-linked kernel).

 

Maybe one of the Clover developers can update Clover's automatic AppleRTC.kext patching to handle the newer version - attached are the vanilla kexts from 10.14.3 and 10.14.4 ...

 

AppleRTC_10.14.3.kext.zip

AppleRTC_10.14.4.kext.zip

 

Edit1

On 3/29/2019 at 8:04 AM, ctich said:

@fusion71au - https://www.applelife.ru/threads/clover.42089/page-957#post-797312

 

Thanks very much @ctich . 

 

Adding the following code from @RodionS in Clover's config.plist/KernelAndKextPatches/KextsToPatch prevents my BIOS/CMOS from resetting when booting into 10.14.4...

 

<key>KextsToPatch</key>
		<array>
			<dict>
				<key>Comment</key>
				<string>AppleRTC for 10.14.4</string>
				<key>MatchOS</key>
				<string>10.14.x</string>
				<key>Find</key>
				<data>dTMPtw==</data>
				<key>Name</key>
				<string>com.apple.driver.AppleRTC</string>
				<key>Replace</key>
				<data>6zMPtw==</data>
			</dict>

 

Edit2

Issue fixed in Clover r4911+, thanks to @Sherlocks .

Edited March 31, 2019 by fusion71au
Issue fixed in Clover r4911+

[ctich]

@fusion71au - https://www.applelife.ru/threads/clover.42089/page-957#post-797312

[chris1111]

@apianti commit 4912 EdkCompatibilityPkg  is present in UDK2018

[apianti]

Yes, but it is not even used by anything, so it is not required to checkout.

[chris1111]

12 minutes ago, apianti said:

Yes, but it is not even used by anything, so it is not required to checkout.

Ok thanks for clarified

[Slice]

10 hours ago, chris1111 said:

@apianti commit 4912 EdkCompatibilityPkg  is present in UDK2018

UDK2018 is not needed to update.

[Sherlocks]

i report bug about MatchOS 

5:951  0:000   - [01]: Disable panic kext logging on 10.14-10.14.3 Release kernel (c) vit9696 :: [OS: 10.14.5 | MatchOS: 10.14 | MatchBuild: no] ==> allowed by OS
5:951  0:000   - [02]: Disable panic kext logging on 10.14.4-10.14.6 Release kernel (c) vit9696 :: [OS: 10.14.5 | MatchOS: 10.14.5 | MatchBuild: no] ==> allowed by OS

 

https://sourceforge.net/p/cloverefiboot/code/HEAD/tree/rEFIt_UEFI/Platform/Settings.c#l1469

 

here is introduction

/* example for valid matches are:

10.7, only 10.7 (10.7.1 will be skipped)

10.10.2 only 10.10.2 (10.10.1 or 10.10.5 will be skipped)

10.10.x (or 10.10.X), in this case is valid for all minor version of 10.10 (10.10.(0-9))

*/

 

10.7, only 10.7 (10.7.1 will be skipped) . <----- it's not working

 

EDIT1

i will fix this bug

 

EDIT2

fixed

7:753  0:000   - [01]: Disable panic kext logging on 10.14-10.14.3 Release kernel (c) vit9696 :: [OS: 10.14.5 | MatchOS: 10.14,10.14.1,10.14.2,10.14.3 | MatchBuild: no] ==> not allowed by OS
7:753  0:000   - [02]: Disable panic kext logging on 10.14.4-10.14.6 Release kernel (c) vit9696 :: [OS: 10.14.5 | MatchOS: 10.14.4,10.14.5,10.14.6 | MatchBuild: no] ==> allowed by OS

Edited March 30, 2019 by Sherlocks

[Sander Spilleman]

6 hours ago, kuruu said:

 

Hi. I have a problem that I think is related to Clover.

 

I have a Z370N motherboard with 4 SATA ports. I have a PCI-E card with 2 SATA ports. They are all populated with 8TB disks in a mirrored ZFS array.

Boot drive is NVMe and I am using the latest Clover installer (4910) and Mojave 10.14.4

Upon booting after a CMOS reset/BIOS update, the disks appear in MacOS Mojave as expected. Upon subsequent reboots, the 4 ports on the motherboard do not register the disks. Sometimes, the disks randomly appear after a reboot.

Upon testing with APFS SATA disks, there is no such problem. This appears to be a problem limited to recognising ZFS disks on the motherboard SATA ports. The PCI-E attached disks are unaffected. 

 

It seems to be an issue with Clover because upon startup after a CMOS reset, Clover takes a while to scan disks and does not recognise my "LastBootedVolume" - upon subsequent boots, there is no lengthy scan it boots right up.

Has anyone experienced this? Any thoughts on a fix?

 

 

I have the same issue... I do see in the clover debug log (after a restart, not a shutdown) that clovers DOES see the discs, but but booting through to macOS the SATA drives are not there (both NVMe's are ok). Not even in system information....

Edited March 30, 2019 by Sander Spilleman

[Sander Spilleman]

On 3/30/2019 at 9:34 AM, kuruu said:

 

Hi. I have a problem that I think is related to Clover.

 

I have a Z370N motherboard with 4 SATA ports. I have a PCI-E card with 2 SATA ports. They are all populated with 8TB disks in a mirrored ZFS array.

Boot drive is NVMe and I am using the latest Clover installer (4910) and Mojave 10.14.4

Upon booting after a CMOS reset/BIOS update, the disks appear in MacOS Mojave as expected. Upon subsequent reboots, the 4 ports on the motherboard do not register the disks. Sometimes, the disks randomly appear after a reboot.

Upon testing with APFS SATA disks, there is no such problem. This appears to be a problem limited to recognising ZFS disks on the motherboard SATA ports. The PCI-E attached disks are unaffected. 

 

It seems to be an issue with Clover because upon startup after a CMOS reset, Clover takes a while to scan disks and does not recognise my "LastBootedVolume" - upon subsequent boots, there is no lengthy scan it boots right up.

Has anyone experienced this? Any thoughts on a fix?

 

 

I somehow managed to get this fixed om my rig.... Updated to the latest version and fiddles around with bios settings. See attached, my bios settings. I cant remember which settings I changed in my latest iteration, hence I'm sending you my whole BIOS profile. I'm on clover v4914 beta now....

ctrl-f2_setting.txt

Edited March 31, 2019 by Sander Spilleman

[mhaeuser]

On 3/24/2019 at 10:23 AM, Power Mac said:

Well, the "one" who told me, corroborated by a couple other devs, is a guide on the site of the one who shall not be named (but is active in the developers' corner): can't link anything because I don't want a ban, but I trust him deeply, and most of the times his guides and advice are a step ahead of everyone else's.

 

Let me second that real quick, utter rubbish, please stop spreading FUD. The kext data to link, i.e. the executable and the Info.plist, are put in a buffer that resides in the booter's Device Tree memory, then it is picked up by the kernel from there and linked into the kernel space, as any kext is. The mechanism used to inject kexts now is literally the Apple mechanism to boot without kextcache several versions ago.

[Slice]

ZFS related posts moved to dedicated thread. 

 

[Power Mac]

On 4/2/2019 at 9:47 AM, Download-Fritz said:

 

Let me second that real quick, utter rubbish, please stop spreading FUD. The kext data to link, i.e. the executable and the Info.plist, are put in a buffer that resides in the booter's Device Tree memory, then it is picked up by the kernel from there and linked into the kernel space, as any kext is. The mechanism used to inject kexts now is literally the Apple mechanism to boot without kextcache several versions ago.

I'm not a computer engineer, so please don't be aggressive. I understand what you and the others explained. I've been building hackintoshes for me and friends for about ten years, so I have no interest in spreading rubbish, nor am I naive enough to not be able to understand the meaning and implications of choices like this one, of a kext, flag or whatever. 
Sadly, I have no time to further discuss this, given that I've been experiencing random and quite fast KP reboots once or twice a day. The system never had a single issue, literally the only change I made this month was moving all my kexts from L/E to Extra, but I'm sure there is no relation: post hoc ergo propter hoc, right? This is going off-topic though, sorry for that.

[apianti]

17 hours ago, Power Mac said:

I'm not a computer engineer, so please don't be aggressive. I understand what you and the others explained. I've been building hackintoshes for me and friends for about ten years, so I have no interest in spreading rubbish, nor am I naive enough to not be able to understand the meaning and implications of choices like this one, of a kext, flag or whatever. 
Sadly, I have no time to further discuss this, given that I've been experiencing random and quite fast KP reboots once or twice a day. The system never had a single issue, literally the only change I made this month was moving all my kexts from L/E to Extra, but I'm sure there is no relation: post hoc ergo propter hoc, right? This is going off-topic though, sorry for that.

 

Yeah, no problem because this will be the last time I respond. No one said you were a computer engineer but I'm going to go ahead and say you have completely no idea what you are talking about. You've been building hackintoshes for ten years?? But yet you don't even know how clover works, also that clover doesn't even have an Extra folder, that you don't even know how to see what is causing the panic and fix it, that installing to /L/E is stupid for any kext you need to boot, because you won't be able to run the installer to upgrade, and also some kexts do not work properly if they are not injected, so no idea what you mean. No one said inject all your kexts, in fact I am now explicitly stating it to you for the FOURTH time, INJECT KEXTS THAT ARE NEEDED TO BOOT OR REQUIRE INJECTION AND PROPERLY INSTALL THE REST. For the sake of everyone in the world's sanity, stop reading tonymac! That website is full of trash and misinformation, and why every other hackintosh site literally will remove anything to do with that site, and even ban you for repeatedly doing it. Not to mention that you are far more likely to be banned from that site for just saying something inane than anywhere I have ever seen. I just googled install unsigned kexts and found several guides that literally are almost word for word copies, it's like no one there can actually do anything but look at the same site and make the same posts with the same wrong information. They don't even have consistent information, I will go over that below because I see this exact same block of text in multiple places on that site and it is wrong. Also, I really hope you don't use any of those tools from that site because you have absolutely no idea what they do and they sign stuff with an actual developer certificate so they can pretty much install any sort of malware and you'd have absolutely no idea unless you knew what to look for, which it's obvious you would not. And hilariously those tools are all available from the actual developers, tonymac just steals everything to make advertising money off unsuspecting people like yourself. There's very little useful information on that site and I only trust two people because I know that they research and go else where too, Rehabman and Toleda.

 

The previous three times, I stated to inject kexts needed for booting and that don't work unless injected:

 

Destroying this idiotic statement I see all over tonymac:

Injected Kexts live outside of "protected MacOS memory" *
...
* Note: I use the term "protected MacOS memory" in this guide as a generic descriptive term. In reality kext's installed in /L/E are loaded into MacOS's kernel memory which is 'protected' (IE: segregated) form application memory and execution memory. Everything running in kernel memory (including kexts) is actively managed and monitored by MacOS.

Doesn't realize that every kext must be in kernel memory or it couldn't work, also how would it be extending the kernel if it wasn't? You know, the main purpose of a kernel extension....? Every kext no matter what is placed into kernel memory.

Injecting a large amount of kexts can result in an unstable system.

This is somewhat true, but unless you have very little memory (less than the requirement for macOS) it's most likely not going to be any issue since at most this may be a few hundred MBs (which even that is extremely high and you are probably more likely injecting somewhere around a few to maybe tens of MBs). You actually have a higher chance of having too many devices cause more memory problems than this, also newer aptio fix helps alleviate this issue by placing the kernel in any random position that is still available for KASLR.

Many 3rd party kexts will not work correctly when injected by Clover.

Then it doesn't need injected. The only reason to inject kexts is to boot and because they need to be loaded and initialized before other kexts that are in the kernelcache, especially ones that are prioritized by the kernel.

 

EDIT: I forgot that the kext doesn't work because you injected the kext before its prerequisite kexts were initialized. If you force load those prereq kexts it will work, however you now run the risk of one of the injection only kexts that patch any of those kexts to possibly fail to do so.

Injected Kexts are not included in the kernel cache and thus are excluded form MacOS error checking.

I don't even know how to respond to this. This is just so utterly stupid. First, every kext is loaded by the kernel, checked, and initialized, no matter what. This scenario here would be equivalent to using kextload to only load a kext temporarily, it's not in the cache but it's certainly in kernel memory and checked....

Installing kexts in /Library/Extensions is the Apple endorsed and recommended location for all 3rd Party kexts.

Ok, that's wonderful, and has absolutely nothing to do with how to boot macOS because you can't really do that without injecting kexts or making special installers every time and constantly installing kexts every time you use the installer...

If you purchase a piece of hardware that requires the installation of a manufactures MacOS driver, the kexts will be installed in /Library/Extensions so why treat hackingtosh kexts any different ?

Because a hackintosh IS different, if it wasn't, clover would not be needed in the first place. You can install stuff into /L/E all day but if you need that kext to boot, because of my last point it's not really that helpful is it...?

 

EDIT: Typos.

 

EDIT2: I totally forgot about RampageDev, where he removed his posts from tonymac because they were being jerks, so they sent a DMCA request against his site because it had the same information. Or Mieze (who wrote like every network driver) got banned for pointing out that one of the drivers from tonymac was from an open source linux GPL driver, which requires the source code to be released and they refused. Why would they do that? Probably because it does something that they don't want people to know about. Not to mention literally everything on the site is stolen, modified(?), and closed sourced, which is pretty much against the license of almost every project. In fact, they are currently violating the clover license as well as they actually are not allowed to use the name of the project or authors without the written consent of the project.

Edited April 9, 2019 by apianti

[shrieken213]

There's a ticket on SourceForge about this. The installer fails to find the ESP partition of APFS-formatted Fusion Drives and instead installs Clover to the system root. To update I have to manually copy those files to the ESP partition. I'm not sure if the same issue occurs with AppleRAID volumes, APFS or not.

[apianti]

2 hours ago, shrieken213 said:

There's a ticket on SourceForge about this. The installer fails to find the ESP partition of APFS-formatted Fusion Drives and instead installs Clover to the system root. To update I have to manually copy those files to the ESP partition. I'm not sure if the same issue occurs with AppleRAID volumes, APFS or not.

Yes, known problem with all system volumes in a container partition. It is detection problem in installer, workaround is exactly what you are doing for now...

[Hackmac101]

8 hours ago, shrieken213 said:

There's a ticket on SourceForge about this. The installer fails to find the ESP partition of APFS-formatted Fusion Drives and instead installs Clover to the system root. To update I have to manually copy those files to the ESP partition. I'm not sure if the same issue occurs with AppleRAID volumes, APFS or not. 

https://github.com/corpnewt/CloverExtractor.git Use this script to install Clover in the right partition