Jump to content

Rebuild Prelinkedkernel in Yosemite for El Capitan


jsl
 Share

64 posts in this topic

Recommended Posts

if you can boot with clover that means that the problem is in the bootloader or the in the bootloader configuration “the flags”

ok do you need the latest version of clover to boot your system the version that include the hex fixes

or can you also boot your system let’s say going back 2 or 3 version of clover before they made the hex changes and added the fixes

remember not all system or motherboards are all the same and they require different configurations

maybe your motherboard requires a bootloader with the hex fix and mines not

ok i know that you have run a lot of test lately but i will like to find out what the problem is as much as you do

so try with a version of clover before they made the changes to the hex to see if you can still boot the system with clover or not

that way we can know for sure if the problem is related to the hex code fix

if you can’t boot after going a few versions or builds back that means that maybe you should try the ones in 3266 

1 by 1 to see if they work for you

to boot my system i only need 3 kexts extensions

 

FakeSMC-v6.16.1372.pkg

IOAHCIBlockStorageInjector.pkg  “latest version”

VoodooTSCSync-6.pkg  “also latest version” i need this kext because i have i7 5820 with 6 cores

 

the rest of my kexts are just drivers that are not require to boot the system 

audio and lan etc etc

 

so install only what is necessary to boot the system then after you are able to boot the system 100%

then you can install additionals kexts later

make sure are you use the same bios definitions in both bootloaders

if you use let’s just use mac pro 5.1 bios as an example in clover , use that same bios version in enoch

once again good luck

is better to go trought this now before El Capitan comes out

so you don’t have to deal with this later

and have El Capitan up and running as soon as it comes out

The most stable version of Clover for my system is v.3253

But I'll try v.3266 to see the difference as soon as possible.

Link to comment
Share on other sites

cd /Volumes/El\ Capitan
sudo kextcache -system-prelinked-kernel
sudo kextcache -system-caches

Thanks for your advice which is the same as Toleda's.

However these terminal commands are not working for my Hackintosh (4 different PCs) and Real Mac (2 MacBook Airs).

I don't know why.

My testing procedures as the following:

1. Boot to Yosemite in MacBook Air's internal HD

2. Plug El_Capitan USB flash in which 10.11DP2 was in /Volumes/El_Capitan (no difference even it's inserted during booting)

3. In Yosemite execting:

    cd /Volumes/El_Capitan

sudo kextcache -system-prelinked-kernel

sudo kextcache -system-caches

4. No change in /Volumes/El_Capitan/System/Library/PrelinkedKernels/prelinkedkernel

5. only change in /Volumes/Yosemite/System/Library/PrelinkedKernels/prelinkedkernel

So I was confused. Why it did not work in real Mac too !

Link to comment
Share on other sites

cd /Volumes/El\ Capitan
sudo kextcache -system-prelinked-kernel
sudo kextcache -system-caches

I have run this code from my Yosemite partition on my El Capitan partition, the terminal code works for me. ( tested on my hackentosh)

Link to comment
Share on other sites

You think like this

cd /Volumes/El\ Capitan
sudo kextcache -system-prelinked-kernel
sudo kextcache -system-caches

or not?

Maybe some people confuse the writing command!!!

Your 10.11 Partition is located at /Volumes/El\ Capitan (/Volumes/"El Capitan") and mine is at /Volumes/"El_Capitan").

I don't think I was confused for this.

Do I ?

Link to comment
Share on other sites

Looking at kextcache_main.c  cd (change directory) to a different Volume does nothing. Only the current Volume will be update.

Ok, as I've understand it. Anyway is here:http://www.opensource.apple.com/source/kext_tools/kext_tools-384.1.4/kextcache_main.c

Thanks for your explanation and support.

Up to now you are the first and only one who really understand why I have been bothered and suffered from this problem.

I don't know why it works for someone else if it's supposed not working by theory.

  • Like 2
Link to comment
Share on other sites

Hi,

I had face similar kernel panic issue, what i did is removed this line in my boot.plist. I also tested that this lines is causing the kernel panic.

Hope it works to you.

<key>Kernel</key>

<string>/System/Library/Kernels/kernel</string>

  • Like 2
Link to comment
Share on other sites

also because is not required!
...and at least should be

<key>Kernel</key>
<string>kernel</string>
 

otherwise is like telling Chameleon that you have /System/Library/kernels/kernel inside a   /System/Library/kernels

 

specifing "kernel" you are telling Chameleon tha inside /System/Library/kernels he can find "kernel".

Is the reason why attempting to specify the original path is stupid and can cause issue.

 

EDIT

 

ok, "/" at the beginning matter

  • Like 1
Link to comment
Share on other sites

also because is not required!

...and at least should be

<key>Kernel</key>
<string>kernel</string>
 

otherwise is like telling Chameleon that you have /System/Library/kernels/kernel inside a   /System/Library/kernels

 

specifing "kernel" you are telling Chameleon tha inside /System/Library/kernels he can find "kernel".

Is the reason why attempting to specify the original path is stupid and can cause issue.

Thanks a lot to you and ncmontas:

Both of you save my time and give me a great help.

This "Kernel=kernel" in org.chameleon.Boot.plist works for me in 10.11DP6 now !

  • Like 2
Link to comment
Share on other sites

Bro, remove those key.

This is only if you want to have a "amd_kernel" in /System/Library/kernels/  ...and you want use that istead of the original.

 

/System/Library/kernels/kernel is loaded by default in 10.10+, without use that key in org.chameleon.Boot.plist. :yes: 

  • Like 1
Link to comment
Share on other sites

also because is not required!

...and at least should be

<key>Kernel</key>
<string>kernel</string>
 

otherwise is like telling Chameleon that you have /System/Library/kernels/kernel inside a   /System/Library/kernels

 

specifing "kernel" you are telling Chameleon tha inside /System/Library/kernels he can find "kernel".

Is the reason why attempting to specify the original path is stupid and can cause issue.

 

EDIT

 

ok, "/" at the beginning matter

 

 

 

Agree,  you can use the kernel specifying "kernel" or anything as a value, but i have removed this since removing this line does not cause any issue, which is the least working configuration for me.

  • Like 1
Link to comment
Share on other sites

 Share

×
×
  • Create New...