Jump to content
30960 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?

  • Like 1

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?

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.

Guest ricoc90

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)

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

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

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

@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

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

 

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.

@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

 

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

  • Like 1

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
  }
}
  • Like 1

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

@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

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

  • Like 1

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

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

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

  • Like 1

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

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

  • Like 1

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

 

 

×
×
  • Create New...