Contribute
Register

Enabling TRIM botches everything why???

Status
Not open for further replies.
The solution from Cindori don't work for me. If I try setting the nvram boot arguments, I get this:

nvram boot-args=kext-dev-mode=1
nvram: Error setting variable - 'boot-args': (iokit/common) general error

I followed the guide anyway, but I had to use 'sudo' for every command and after reboot there isn't trim enabled.

Can I install the trim patch from Multibeast with "
kext-dev-mode=1" in the /Extra plist without going into trouble?

Edit: Same problem with the
Chameleon SSD optimizer. After every reboot, the two programs want to disable the kext-signing, but it seems they can't – as I in the terminal.

I'm also getting the "Error parsing plist file" in the boot-screen and it waits 5 seconds, but then
continues booting.
 
The solution from Cindori don't work for me. If I try setting the nvram boot arguments, I get this:

nvram boot-args=kext-dev-mode=1
nvram: Error setting variable - 'boot-args': (iokit/common) general error

I followed the guide anyway, but I had to use 'sudo' for every command and after reboot there isn't trim enabled.

Can I install the trim patch from Multibeast with "
kext-dev-mode=1" in the /Extra plist without going into trouble?

Edit: Same problem with the
Chameleon SSD optimizer. After every reboot, the two programs want to disable the kext-signing, but it seems they can't – as I in the terminal.

I'm also getting the "Error parsing plist file" in the boot-screen and it waits 5 seconds, but then
continues booting.

Have you resolved the 5 seconds problem?
 
I installed MB without TRIM. i enabled it by Chameleon SSD and today after a week with no problems it happen again.
why? who can i fix that ****?!
 
I found a solution to my 5 second problem credit to Dan

http://bytesandbolts.com/os-x-10-10-yosemite-ga-x58a-ud3r-hackintosh-install/

Finally got the system working, but got strange error at boot about not being able to parse plist, ‘Error parsing plist file, Errors encountered while starting up the computer. Pausing 5 seconds’. For some reason the com.apple.Boot.plist at /Library/Preferences/SystemConfiguration was corrupted with kext-dev-mode=1. This conflicted with the MultiBeast plist in /Extra/org.chameleon.Boot.plist, which also contained a kext-dev-mode=1 entry. Deleting the com.apple.Boot.plist plist fixed the issue.
 
So I managed to get a glorious upgrade of my Snow Leopard Hackintosh to Yosemite onto an SSD. I moved and deleted stuff and then it crapped out and it could only have been a TRIM issue on the end.

I have done a fresh install and followed the instructions here and it is working....but for how long?

Basically how do I check that TRIM is enabled? Does the kext dev mode = 1 enable TRIM, or does it just enable me to enable TRIM. If so when I try using the TRIM app by Cindori I run it as planned and do the reboot and I get the same message as before the reboot and am in a loop? Do I need the Cindori app to run or does the multibeast TRIM enabler actually enable a native trimming system, or just the ability to enable another one? Am I being dim......probably.

Thanks for your help if you can
 
TRIM is not needed on modern SSDs. Go read about it on the OEM SSD sites. The firmware on the drive is OS independent (at least, it is on Crucial and Samsung drives - the ones I checked). All you need to do is give the drive firmware some idle time to do garbage collection.
You can do this by setting the Energy saver mode to give your build 30-45 minutes of idle time before it goes to sleep. The more files you delete, the more time required for garbage collection.

Enabling trim requires a kext to be modified to work on non-Apple SSDs. Modifying the kext destroys the signage. OS X will not run a non-signed kext any more without turning off the sign check. Every time you do an update, the sign check is turned back on, resulting in the circle/slash on a grey field. indicating the presence of unsigned kext.
 
I think this is where mine failed also. With TRIM enabled, my BIOS settings reverted to IDE...really didn't think that was possible. Then of course, there is the moment of panic when you can't access your cloned drive or Time Machine backup because you booted in IDE mode. I'm in the process of a re-install, so we'll see what happens. I'm still wondering about using the AppleACPIPlatform rollback. I'll work out the sound issues later, as usual.

And another little tip... my TM backup was on a USB 3.0 drive plugged into a USB 3.0 port. Obviously, the installer won't see it during the registration screens because USB 3.0 support is not enabled until you do so in MultiBeast. Sort of a "duh" moment for me. Now, of course, restoring a TM backup over USB 2.0 means I'll be sitting here for a week - it says 18 minutes...uh huh - but at least it's possible.


Hey Caruso81 - Just a thought of how a situation like this could be sped up. That is by changing the layout of where data is stored. Could always have your user data on another volume/disk? that way there would be less to restore back over the slower connection. i.e just settings/plists/library and cache files.
 
Status
Not open for further replies.
Back
Top