Jump to content
ErmaC

Clover General discussion

22,333 posts in this topic

Recommended Posts

Slice, I svn diff, and terminal give me nothing. I build r4251 with ./ebuild.sh, still give me log like this on Dell Precision M3800.

 

attachicon.gifpreboot.log.zip

 

You said Official Clover cannot have "Preparing for kext injection...", what that mean sorry? Am I doing something wrong? Or miss something?

 

syscl

Let think about

    MsgLog("Preparing kexts injection for arch=%s from %s\n", (archCpuType==CPU_TYPE_X86_64)?L"x86_64":(archCpuType==CPU_TYPE_I386)?L"i386":L"", SrcDir);

archCpuType==CPU_TYPE_X86_64 => "x86_64"

archCpuType==CPU_TYPE_I386 => "i386"

It came from

#if defined(MDE_CPU_X64)
	cpu_type_t archCpuType=CPU_TYPE_X86_64;
#else
	cpu_type_t archCpuType=CPU_TYPE_I386;
#endif

How it can be other value?

Share this post


Link to post
Share on other sites
Advertisement

Hi, is there something changed in r4250? I have tried to build r4250 and give me "Thinning failed". I have to force archCpuType=CPU_TYPE_X86_64 to make it boot, otherwise the archCpuType is corrupted?

 

Here's the log from r4251(same with r4250 when I reverted).

 

 

 

attachicon.gifpreboot.log.zip

 

Two days ago, I had the same problem, if I tried to compile myself with BuildClover (10.12.6 xcode8) I had that error, if I tried booting with file from SF, there was no problem (same rev)... I downgraded-compiled, downgraded-compiled ... until I found the last rev I could compile without this error ( it was 4232 I think)..

 

Now I cannot confirm because since I updated to Xcode9, buildClover 4.5.5 -> 4.5.6 and clover to rev4247 I was able to compile sucessfully

 

As you are not using buildClover, and already commited > 4247 then maybe problem is xcode, are you using xcode 8?

Share this post


Link to post
Share on other sites

Let think about

    MsgLog("Preparing kexts injection for arch=%s from %s\n", (archCpuType==CPU_TYPE_X86_64)?L"x86_64":(archCpuType==CPU_TYPE_I386)?L"i386":L"", SrcDir);

archCpuType==CPU_TYPE_X86_64 => "x86_64"

archCpuType==CPU_TYPE_I386 => "i386"

It came from

#if defined(MDE_CPU_X64)
	cpu_type_t archCpuType=CPU_TYPE_X86_64;
#else
	cpu_type_t archCpuType=CPU_TYPE_I386;
#endif

How it can be other value?

Why not just:

(archCpuType==CPU_TYPE_X86_64)? L"x86_64" : L"i386"

Edit

Ok,  there's a 3° possibility to be L"", so archCpuType is not set (CPU_TYPE_X86_64). maybe the mach_header is changed or running on a modded kernel?

Make it test with:

MsgLog("Preparing kexts injection for arch=%s from %s\n", (archCpuType==CPU_TYPE_X86_64)?L"x86_64":(archCpuType==CPU_TYPE_I386)?L"i386":L"none", SrcDir);

 

Edit

Since Sir Matgen84 receives "ApppleAPCICPU" on kextd  ... looks the kernel to have problems to me, just on the mach_header and cannot get the cpu_type_t. Please post it.

Share this post


Link to post
Share on other sites

Edit

Since Sir Matgen84 receives "ApppleAPCICPU" on kextd  ... looks the kernel to have problems to me, just on the mach_header and cannot get the cpu_type_t. Please post it.

Nah, he gets the AppleAPCICPU kextd stall because FakeSMC isn't being injected (thinning failed)

Share this post


Link to post
Share on other sites

Nah, he gets the AppleAPCICPU kextd stall because FakeSMC isn't being injected (thinning failed)

Why thin a 64 bit executable like AppleALC.kext then? I mean, no need to do that, is ready to be loaded by the mach-o parser.

Anyway patch the kernel from byte 0 is bad. looking better to his lo, kexts aren't prelinked, so thinning is not working (file not found or bad parser). Just suppositions.

Edited by vector sigma

Share this post


Link to post
Share on other sites

Why thin a 64 bit executable then? I mean, no need to do that, is ready to be loaded by the mach-o parser. or I guess

 

I'm not a coder, but I'd say because archCpuType is empty, as seen in his preboot.log:

 

Preparing kexts injection for arch= from EFI\CLOVER\kexts\10.13

See: https://github.com/Clover-EFI-Bootloader/clover/blob/master/rEFIt_UEFI/Platform/kext_inject.c#L24

Share this post


Link to post
Share on other sites

I'm not a coder, but I'd say because archCpuType is empty, as seen in his preboot.log:

 

Preparing kexts injection for arch= from EFI\CLOVER\kexts\10.13
See: https://github.com/Clover-EFI-Bootloader/clover/blob/master/rEFIt_UEFI/Platform/kext_inject.c#L24

 

But this can happen only if this does not work:

struct mach_header {
	uint32_t	magic;		/* mach magic number identifier */
	cpu_type_t	cputype;	/* cpu specifier */
	cpu_subtype_t	cpusubtype;	/* machine specifier */
	uint32_t	filetype;	/* type of file */
	uint32_t	ncmds;		/* number of load commands */
	uint32_t	sizeofcmds;	/* the size of all the load commands */
	uint32_t	flags;		/* flags */
};

 archCpuType is determined by cpu_type_t... and is bad (not a 32 bit cpu, nor a 64, nor both) somehow

Share this post


Link to post
Share on other sites

@Slice, from @cekepawon report, there's something funny, thinning fail occurs when the first time inject Shiki.kext in both my case and @Matgen84's case(still not sure). Another possible: memory issues around string between UnisysVers and ShortOSVersions?

 

Will try once back to home.

 

syscl

Share this post


Link to post
Share on other sites

For those who experienced archCpuType missing issue, please try this one.

r4252-p1.zip

I narrowed down the issue and now the issue should have gone(work on M3800).

 

@Slice, why we need this piece of code? This is the place that cause the archCpuType issue

CHAR16            UniSysVers[6];
  CHAR8             ShortOSVersion[6];
  INTN              i;
  for (i = 0; i < 6; i++) {
    ShortOSVersion[i] = Entry->OSVersion[i];
    if (ShortOSVersion[i] == '\0') {
      break;
    }
    if (((i > 2) && (ShortOSVersion[i] == '.')) || i == 5) {
      ShortOSVersion[i] = '\0';
      ShortOSVersion[i + 1] = '\0';
      break;
    }
  }
AsciiStrToUnicodeStrS(ShortOSVersion, UniSysVers, 6);

If GetOSVersionKextsDir return null, then we should not declare local variable ShortOSVersion. I used my version that the issue has gone.

 

syscl

 

Share this post


Link to post
Share on other sites

For those who experienced archCpuType missing issue, please try this one.

attachicon.gifr4252-p1.zip

I narrowed down the issue and now the issue should have gone(work on M3800).

 

@Slice, why we need this piece of code? This is the place that cause the archCpuType issue

CHAR16            UniSysVers[6];
  CHAR8             ShortOSVersion[6];
  INTN              i;
  for (i = 0; i < 6; i++) {
    ShortOSVersion[i] = Entry->OSVersion[i];
    if (ShortOSVersion[i] == '\0') {
      break;
    }
    if (((i > 2) && (ShortOSVersion[i] == '.')) || i == 5) {
      ShortOSVersion[i] = '\0';
      ShortOSVersion[i + 1] = '\0';
      break;
    }
  }
AsciiStrToUnicodeStrS(ShortOSVersion, UniSysVers, 6);

If GetOSVersionKextsDir return null, then we should not declare local variable ShortOSVersion. I used my version that the issue has gone.

 

syscl

OSVersion="10.12.6" while folder named "10.12".

If GetOSVersionKextsDir return null then condition if(null)

  if ((SrcDir = GetOSVersionKextsDir(ShortOSVersion))) {
    MsgLog("Preparing kexts injection for arch=%s from %s\n", (archCpuType==CPU_TYPE_X86_64)?L"x86_64":

@Slice, from @cekepawon report, there's something funny, thinning fail occurs when the first time inject Shiki.kext in both my case and @Matgen84's case(still not sure). Another possible: memory issues around string between UnisysVers and ShortOSVersions?

 

Will try once back to home.

 

syscl

I may propose some memory leak or wrong pointer.

Share this post


Link to post
Share on other sites

@Slice

I think GetOSVersionKextsDir has already taken care of 10.xx.xx:

AsciiStrnCpyS(FixedVersion, 16, OSVersion, 5);

Here's the patch for r4252 

Index: rEFIt_UEFI/Platform/kext_inject.c
===================================================================
--- rEFIt_UEFI/Platform/kext_inject.c	(revision 4252)
+++ rEFIt_UEFI/Platform/kext_inject.c	(working copy)
@@ -311,23 +311,6 @@
 
   // syscl - allow specific load inject kext
   // Clover/Kexts/Other is for general injection thus we need to scan both Other and OSVersion folder
-  CHAR16            UniSysVers[6];
-  CHAR8             ShortOSVersion[6];
-  INTN              i;
-  for (i = 0; i < 6; i++) {
-    ShortOSVersion[i] = Entry->OSVersion[i];
-    if (ShortOSVersion[i] == '\0') {
-      break;
-    }
-    if (((i > 2) && (ShortOSVersion[i] == '.')) || i == 5) {
-      ShortOSVersion[i] = '\0';
-      ShortOSVersion[i + 1] = '\0';
-      break;
-    }
-  }
-  AsciiStrToUnicodeStrS(ShortOSVersion, UniSysVers, 6);
-  DBG("OSVesion: %a, ShortOSVersion=%a, uni-vers=%s,\n", Entry->OSVersion, ShortOSVersion, UniSysVers);
-
   if ((SrcDir = GetOtherKextsDir())) {
     MsgLog("Preparing kexts injection for arch=%s from %s\n", (archCpuType==CPU_TYPE_X86_64)?L"x86_64":(archCpuType==CPU_TYPE_I386)?L"i386":L"", SrcDir);
     CurrentKext = InjectKextList;
@@ -366,8 +349,10 @@
     FreePool(SrcDir);
   }
 
-  if ((SrcDir = GetOSVersionKextsDir(ShortOSVersion))) {
+  if ((SrcDir = GetOSVersionKextsDir(Entry->OSVersion))) {
     MsgLog("Preparing kexts injection for arch=%s from %s\n", (archCpuType==CPU_TYPE_X86_64)?L"x86_64":(archCpuType==CPU_TYPE_I386)?L"i386":L"", SrcDir);
+    CHAR16 UniSysVers[6];
+    AsciiStrToUnicodeStrS(Entry->OSVersion, UniSysVers, 6);
     CurrentKext = InjectKextList;
     while (CurrentKext) {
       DBG("current kext name %s Match %s, while sysver: %s\n", CurrentKext->FileName, CurrentKext->MatchOS, UniSysVers);

Please give this a try and see if this work on your computer as well(I mean not corrupt previous kext inject function as well)

 

r4252-p1.zip

 

syscl

 

Share this post


Link to post
Share on other sites

@Slice

I think GetOSVersionKextsDir has already taken care of 10.xx.xx:

AsciiStrnCpyS(FixedVersion, 16, OSVersion, 5);

Here's the patch for r4252 

Index: rEFIt_UEFI/Platform/kext_inject.c
===================================================================
--- rEFIt_UEFI/Platform/kext_inject.c	(revision 4252)
+++ rEFIt_UEFI/Platform/kext_inject.c	(working copy)
@@ -311,23 +311,6 @@
 
   // syscl - allow specific load inject kext
   // Clover/Kexts/Other is for general injection thus we need to scan both Other and OSVersion folder
-  CHAR16            UniSysVers[6];
-  CHAR8             ShortOSVersion[6];
-  INTN              i;
-  for (i = 0; i < 6; i++) {
-    ShortOSVersion[i] = Entry->OSVersion[i];
-    if (ShortOSVersion[i] == '\0') {
-      break;
-    }
-    if (((i > 2) && (ShortOSVersion[i] == '.')) || i == 5) {
-      ShortOSVersion[i] = '\0';
-      ShortOSVersion[i + 1] = '\0';
-      break;
-    }
-  }
-  AsciiStrToUnicodeStrS(ShortOSVersion, UniSysVers, 6);
-  DBG("OSVesion: %a, ShortOSVersion=%a, uni-vers=%s,\n", Entry->OSVersion, ShortOSVersion, UniSysVers);
-
   if ((SrcDir = GetOtherKextsDir())) {
     MsgLog("Preparing kexts injection for arch=%s from %s\n", (archCpuType==CPU_TYPE_X86_64)?L"x86_64":(archCpuType==CPU_TYPE_I386)?L"i386":L"", SrcDir);
     CurrentKext = InjectKextList;
@@ -366,8 +349,10 @@
     FreePool(SrcDir);
   }
 
-  if ((SrcDir = GetOSVersionKextsDir(ShortOSVersion))) {
+  if ((SrcDir = GetOSVersionKextsDir(Entry->OSVersion))) {
     MsgLog("Preparing kexts injection for arch=%s from %s\n", (archCpuType==CPU_TYPE_X86_64)?L"x86_64":(archCpuType==CPU_TYPE_I386)?L"i386":L"", SrcDir);
+    CHAR16 UniSysVers[6];
+    AsciiStrToUnicodeStrS(Entry->OSVersion, UniSysVers, 6);
     CurrentKext = InjectKextList;
     while (CurrentKext) {
       DBG("current kext name %s Match %s, while sysver: %s\n", CurrentKext->FileName, CurrentKext->MatchOS, UniSysVers);

Please give this a try and see if this work on your computer as well(I mean not corrupt previous kext inject function as well)

 

attachicon.gifr4252-p1.zip

 

syscl

I tested in QEMU.

Снимок экрана 2017-10-19 в 6.46.20.png

Снимок экрана 2017-10-19 в 6.46.08.png

Снимок экрана 2017-10-19 в 6.45.03.png

As you see only Other folder taken into account.

Share this post


Link to post
Share on other sites

Also noticed here, there are no default archCpuType for 10.7:

if (Arch != NULL && StrnCmp(Arch,L"x86_64",StrLen(L"x86_64")) == 0) {
  archCpuType = CPU_TYPE_X86_64;
} else if (Arch != NULL && StrnCmp(Arch,L"i386",StrLen(L"i386")) == 0) {
  archCpuType = CPU_TYPE_I386;
} else if (Entry->OSVersion != NULL) {
  UINT64 os_version = AsciiOSVersionToUint64(Entry->OSVersion);
  if (os_version >= AsciiOSVersionToUint64("10.8")) {
    archCpuType = CPU_TYPE_X86_64; // For OSVersion >= 10.8, only x86_64 exists
  } else if (os_version < AsciiOSVersionToUint64("10.7")) {
    archCpuType = CPU_TYPE_I386; // For OSVersion < 10.7, use default of i386
  }
}

Share this post


Link to post
Share on other sites

Oh, I see, seems this is 10.7.x, so GetOSVersionKextsDir use "/EFI/Clover/kexts10.7." as folder. Please give me a few minutes...

 

syscl

Share this post


Link to post
Share on other sites

@Slice Please try this one.

attachicon.gifr4252-p2.zip

Thank you,

syscl

In addition to the problems (arch, kextd ...) I saw "Unsupported CPU on receptor" when booting. I don't know if it's important: seems to be first time under my Core i7 system. Thank you

Share this post


Link to post
Share on other sites

In addition to the problems (arch, kextd ...) I saw "Unsupported CPU on receptor" when booting. I don't know if it's important: seems to be first time under my Core i7 system. Thank you

So r4252-p2 not work on your system? Could you provide the preboot.log by pressing the F2 when boot?

 

Thank you in advance,

 

syscl

Share this post


Link to post
Share on other sites

So r4252-p2 not work on your system? Could you provide the preboot.log by pressing the F2 when boot?

 

Thank you in advance,

 

syscl

I have not yet tried r4252-p2. The message appears in commits r4248-4251 and before, on my system.

 

Edit: Now, I try your version. See preboot.log 

 

All work, I can boot normally. But there is always ""Unsupported CPU for receptor" messages.

 

I don't know if it will continue to work when I compile commits on my system.  I re-create several times ~src folder with Build_clover.command 4.5.6: so far without success

 

Thanks

preboot.log.zip

Share this post


Link to post
Share on other sites

I have not yet tried r4252-p2. The message appears in commits r4248-4251 and before, on my system.

 

Now, I try your version ans post preboot.log 

 

Thanks

I don't have the permission to download the preboot.log.. why??

 

By the way, can r4252-p2 boot (because I cannot see your boot log)?

 

syscl

Share this post


Link to post
Share on other sites

I don't have the permission to download the preboot.log.. why??

 

By the way, can r4252-p2 boot (because I cannot see your boot log)?

 

syscl

I edit my previous post

Share this post


Link to post
Share on other sites

I edit my previous post

Because I saw @cecekpown said that you also have archCpuType issue in previous version, your log shows that my r4252-p2 solved the archCpuType issue.

 

I haven't see CPU receptor problem in log and don't find it in code as well... Weird...

 

syscl

Share this post


Link to post
Share on other sites

Because I saw @cecekpown said that you also have archCpuType issue in previous version, your log shows that my r4252-p2 solved the archCpuType issue.

 

I haven't see CPU receptor problem in log and don't find it in code as well... Weird...

 

syscl

As I say before: I don't know if it will continue to work when I compile commits on my system.  I re-create several times ~src folder with Build_clover.command 4.5.6: so far without success for previous version. Compile Ok, Boot no.

 

 CPU receptor problem appears only on screen when I boot.

 

Sorry for my bad english

Share this post


Link to post
Share on other sites

As I say before: I don't know if it will continue to work when I compile commits on my system.  I re-create several times ~src folder with Build_clover.command 4.5.6: so far without success for previous version. Compile Ok, Boot no.

 

 CPU receptor problem appears only on screen when I boot.

 

Sorry for my bad english

Have you noticed when this message occurs? Like which version you first saw this message?

 

syscl

Share this post


Link to post
Share on other sites

is nvda_drv=1 necessary to boot with (space) mode?

i cant boot with (space) selected arguments, if nvda_drv is not selected or is in boot-args.

its using nvidia official driver.

but if i dont use (space) mode, without nvda_drv only use nvidiaweb in clover config, i can boot just fine.

my board is not compatible with nvram builtin, so i use EmuVariableUefi-64.efi. 

 

nvram shows nvram_drv=1

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

Announcements

  • Similar Content

    • By STLVNUB
      *Put the script into its own folder as it will create other folders*
      What is BTB?
      Script file to clone and help build Clover or Opencore repos
      Script will create link to itself in /usr/local/bin/bob
      Script SHOULD fix up any stray bobs you may have.
      Then you only need to type bob. and a parameter
      "a" for ACID repo, official
      "d" for ACID repo DUET build
      "c" for CLOVER
      "e" to erase UDK Folder
      Easier typing bob than.....usual stuff
      YOU WILL NEED TO cmod+x THE SCRIPT
      Enjoy
       
    • By cvad
      View File Bootdisk Utility
      Make bootable USB Flash Disk for MAC OS X with Latest Clover bootloader revision fast and easy by one click! under OS Windows.
      Special utility from cvad & russian MAC community for new hackintosh users.
       
      Enjoy...
       
      For more information and complete instructions please see this topic.
       
      Anyone who likes the program, please support its Community Score.
       
       
      Feel free to "Rate File"
      Submitter cvad Submitted 04/28/2013 Category Bootloaders  
    • By PropoFlexWX4
      After hearing that OpenCore is so much better than Clover, and that it will probably be able to boot Big Sur before Clover does, I decided to take the jump.
       
      Running Catalina 10.15.5 18F101 with OC 0.5.9.
       
      So far I like the result. The OS feels faster, boots faster.
      And absolutely everything works (sleep, network, etc...)
       
      So, that's it? Is there anything else I have to do?
×