Kext Wizard - Easy to use Kext Installer and more

[Dr. Hurt]

Since Lion by default doesn't have a kernel cache, and Chameleon by default does not load a manually created kestcache, I think you should add an option in the maintenance section to add a "UseKernelCache" to the boot.plist if the user selects the option to create a kernel cache.

[Andrew180]

Yes but that would load kexts only from S/L/E...

We need to create combo cache from both /E/E and S/L/E and use it at startup. Is it possible? How?

[Matty___]

Yes but that would load kexts only from S/L/E...

We need to create combo cache from both /E/E and S/L/E and use it at startup. Is it possible? How?

 

just copy the kext from e/e to s/l/e and your good to go

[Andrew180]

Yes it works but now i un-vanilled my system. But i can live with that. Thanks.

[nadieaqui]

Thank You. Great Tool.

[cain82]

I just want to give my big thanks for your work on this tool

 

...I think it needs some exposure in the community so it can become more widely adapted, as it deserves!!

 

This is a great community... so exchange, share, help out others to pay thanks to those who helped you out, and always say thank you. Lets keep it alive !

[Cyrus the Great]

hi

thanks for your tools

plz can you add option to create kernelcache for differ kernel like :

legacy_kernel

the tools only create cache for mach_kernel

[janek202]

Post me a terminal commands how to do that.

[Cyrus the Great]

Post me a terminal commands how to do that.

this the command that creat kernel cache for my kernel (cyrus_kernel):

sudo kextcache -system-prelinked-kernel -K /cyrus_kernel

 

may the option that specty the kernel name be good.

thanks

[BuXb]

Hi Janek202. As per "Please report me any bugs or ideas for new features" (I did NOT read through the pages, so a duplicate submission is well possible), here's some *constructive* feedback:

 

- when installing new kexts to E/E, as of now the mkext there does NOT get rebuilt automatically. I basically consider this a bug because it might lead to the kext which got installed to E/E and is not included in the mkext might not get loaded correctly. So now, after installing kexts to E/E, one has to click onto Maintenance, activate 'Extra/Extensions', rebiult mkext. Those extra steps should not be necessary. It would be great if you could fix that. If there is some kind of pro for not auto-rebuild E/E mkext, then please at least ad an option field "Auto-Rebuild mkext", which is *activated by default*; whoever does for some reason *not* want the mkext rebuilt can toggle it off.

 

- please have "Backup kexts that will be replaced" *activated* by default! In times of terrabytes HDs, looking at the tiny size of almost all kexts, and noting the security aspect of backups in general I don't see *any* reason why this option shall not be active by default. Thank you

 

- again regarding kext backups: when I first utilized your tool I was totally startled because even though I had ticked "Backup kexts that will be replaced" I did not find them! I installed to a different volume, and after booting into that volume and realizing I had to restore one kext, first looked into the extension folder there, being used to Kext Utility's approach to simply rename existing.kext --> existing.bak. Then I remembered having read something about a folder 'Kext Backup' being created. Analog to what Kext Helper (and I think OSX86Tools) used to do, I looked on / of the volume to which I had installed kexts to, but to my disappointment did not find any like folder there. After finding and reading your ReadMe I was very amazed that the default backup path is the Desktop of the user account one installed FROM, not the / of the volume on installs TO. That is very awkward, esp. if one installed from as root user (...), and also makes much less sense than backing up to the actual volume. Reason is evident I dare say: when, after running an install for a while, one realizes one has to revert to an older kext, it would be easy to do so just looking on / of that particular volume. The backup on the desktop of some user folder (which might even be on a completely different computer if one installed to a USB volume .....) might simply not be retrievable anymore.

 

Right now I "jerryrig" by, after installing kexts to another volume, MANUALLY creating a folder "Kext backup" on / of that volume, then copy the appropriate date/time folder into folder I created on the other volume.

 

Again, if there is some pro of choosing the current desktop as backup, then, instead of ONE line "Backup kexts that will be replaced" you could change that to "Backup kexts that will be replaced to / of destination", and a 2nd line "Backup kexts that will be replaced to current Desktop". Not too much space lost there, but a highly usable feature addition. And PLEEAASE , make "Backup kexts that will be replaced to / of destination" active by default

 

- after installing kexts to S/L/E, the option button jumps back onto E/E. Why? That's confusing because (esp. late @ nite .. ) I can make one doubt if one really chose the correct destination. This can be considered a bug. I think similar with "Target Disk": if one has chosen "S/L/E" and then changes the target disk, it jumps back to to E/E. But I am not sure about that right now (am not writing from OS X so cannot test)

 

Other than that, awesome tool! Makes deploying h'tosh soooo much easier (and I bet Hagar hates it because he kept on deleting my postings back then when I asked for exactly what you coded, labeling my requests 'forum spam' and eventually even blocked my account - and now look at the popularity).

 

Thank you Janek - RESPECT!

Bugs

[janek202]

- when installing new kexts to E/E, as of now the mkext there does NOT get rebuilt automatically.

 

It does. Installation checks if E.mkext exists. If it does it will be updated. I didn't wanted to confuse newbies with new "unknown" files. So basically, if you made an mkext in the Maintenance tab it will be updated after each kext installation.

 

- please have "Backup kexts that will be replaced" *activated* by default!

OK.

 

Reason is evident I dare say: when, after running an install for a while, one realizes one has to revert to an older kext, it would be easy to do so just looking on / of that particular volume. The backup on the desktop of some user folder (which might even be on a completely different computer if one installed to a USB volume .....) might simply not be retrievable anymore.

It shows in your desktop, so you can move it to the location you like. I don't want to keep this kexts like .bak or something, because I think it will be hard to find working kext among others like bak1, bak2, bak3 etc. But I think I will make directory [target disk]/Extra/Backups.

 

- after installing kexts to S/L/E, the option button jumps back onto E/E. Why? That's confusing because (esp. late @ nite .. ) I can make one doubt if one really chose the correct destination. This can be considered a bug. I think similar with "Target Disk": if one has chosen "S/L/E" and then changes the target disk, it jumps back to to E/E. But I am not sure about that right now (am not writing from OS X so cannot test)

 

It was the simplest way. I had to make something default so after you change partition with Extra and no S/L/E to the partition without Extra but with /S/L/E it won't stay selected on the wrong option. But I will try to make it better.

[BuXb]

It does. Installation checks if E.mkext exists. If it does it will be updated. I didn't wanted to confuse newbies with new "unknown" files. So basically, if you made an mkext in the Maintenance tab it will be updated after each kext installation.

LOL that's funny - the way I tested it was by DELETING the mkext and see if it gets built. I understand your reasoning - however it will slow down boot and display all these kexts and sub-kexts running down the screen. I think that will confuse nubies even more than a file in a (hidden) directory they will never see anyway.

But I think I will make directory [target disk]/Extra/Backups.

YIPPIE The Desktop location could remain as a toggleable option, if you decide to.

But I will try to make it better.

cool, thanks.

 

I also like your other utils and donated from your sig. Solidarności - you Polaks rock

 

Bugs

[Cyrus the Great]

this the command that creat kernel cache for my kernel (cyrus_kernel):

sudo kextcache -system-prelinked-kernel -K /cyrus_kernel

 

may the option that specty the kernel name be good.

thanks

hi janek plz add the above command to next wizard

thanks

[binghelang]

this is really a powerful tool, i love it! thanks alot! wao...

[tantan]

nr1 tool for all kext related works, thank you very much janek.

[Uloga]

How long does the permission fixing take average?

 

EDIT: nevermind, I was impatient;)

[Alessandro17]

How long does the permission fixing take average?

 

It starts by telling you that it needs 2 hours, but then it only takes a few minutes.

[XUTOS-83]

 

Hi, is certainly a stupid question but how do I know where should I install the Kext's files?

What is the default location?

 

Many thanks,

 

Vasco

[jazzyguy]

Typically you will want /system/library/extenstions for lion.

 

SL I would use the same, but any would work.

[jakiejake]

Awesome! Thanks

[RoateRight]

Installation and Maintenance can be executed for any OS X partition.

 

Why are my choices: Choose, Item1, Item 2

 

My partitions do not appear.

[digital_dreamer]

Great.

But does this new utility handle the rights of kext "correct" if i use kext utitlity works but next OS X Diskutility must repair all of them again.

Yes.

Maintenance: First it sets owner (root:wheel) and permissions (755) for the whole System/Library/Extensions. Some system kexts requires other permissions etc. so after that it repairs permissions on whole target disk using: "diskutil repairpermissions".

 

Installation: It sets owner and permissions only for newly installed kexts. Others aren't modified. After that it rebuilds cache.

 

So there's no need to run Disk Utility after using my application.

Don't know if this was addressed in this thread or not, as I haven't read it all. :-P

But, this is an issue I ran into awhile back and I found that the system expects 644 to be applied to the files and 755 to the folders/kext package.

So, running the following commands (or similar) fixes this minor issue:

 

chmod -R 755 /System/Library/Extensions
find /System/Library/Extensions -type f -execdir chmod 644 {} \;

 

It simply applies 755 to all the files/folders/kext packages, then finds just the files and applies 644 to them.

best regards,

MAJ

[AnssaienlyMac]

Awesome Job! works on ML DP1 (I'll test it on 10.8.1 & see if it works)

[mondial]

Phantastic, thanks!

 

Is it possible to order the loadedKext Export by columns (Path, Kext or version)?

If not, one goodie for the next release?

 

BTW: do you need german translation or is it already done, I don't know now here at office?

 

thx Mondi

[hshar]

Greeat app. Many thanks.