Re: Installing a kext on 10.5 (Leopard)
Re: Installing a kext on 10.5 (Leopard)
- Subject: Re: Installing a kext on 10.5 (Leopard)
- From: Dean Reece <email@hidden>
- Date: Sat, 15 Mar 2008 10:59:17 -0700
On Mar 15, 2008, at 10:35 AM, Duane Murphy wrote:
Hi Folks,
I'm installing a kext in /System/Library/Extensions. On Leopard we
are having trouble with the kext cache for a boot partition not
getting updated properly when the kext is installed. Of course this
results in the system becoming unbootable because the cache is out
of sync (at least that's what the output at boot time says).
We are following the usual guidelines, but I get the idea that the
usual guidelines may not be appropriate for Leopard.
The installer puts the kext folder into /System/Library/Extensions
then we do the chmod, chown dance to set privileges correctly, then
finally touch /S/L/E.
I believe that on Leopard, kextcache is launched as a result of
using the new FSEvents mechanism. This in turn causes kextcache to
be kicked off when the folder is installed before the privilege
dance can be finished causing the cache to get out of sync.
kextd is watching the extensions folder, so the final touch you do
should (re)trigger the cache rebuild.
If you are doing a touch after the kext install & perm dance, and the
cache is not being rebuilt correctly, you need to file a radar.
It has been recommended to me previously to do the privilege dance
outside of /S/L/E and then move the kext into /S/L/E. The question
then becomes where is a good place to stage the kext? And is this
the right thing to do?
Yes, it is the best thing to do on any version of OS X, since it
guarantees you won't end up with a partially installed or updated kext
if the system crashes at just the wrong time.
On Leopard, kextd watches /S/L/E and it might rebuild more than once
if the mod date of /S/L/E changes multiple times during your
installation process. Using mv will make the kext installation
atomic, so the kext can't be partially installed. As long as the
final touch happens within a few seconds after the mv, kextache will
only be run once.
The target directory should be on the same volume as /S/L/E and
support privileges (ie not have the "ignore privileges on this
volume" switch turned on).
Is just using /S/L appropriate?
You should not modify /S/L; that is only for Apple. In the future, we
may provide a condoned staging area for this and/or a kext install
script that you can just run from your installer, but for now, you
need to find some other place to do this.
/tmp seems scary to me. Seems to easy (and to common) to remap to a
different volume for expert users.
It is certainly possible, though the worst-case side effect of it
being on a different volume is that the mv degrades to a cp. As long
as you always followup with a touch of /S/L/E , then kextcache should
rebuild with your complete kext (please file a radar if not).
Alternatively, you can install your kext with a different extension,
and rename it to foo.kext after you've completed the install/perm
dance. Then, one final touch to /S/L/E and you should be good.
Seems like this change to kext loading could affect lots of
installations if I am correct.
I am not aware of other reports of this, so if there is a bug in the
cache rebuild logic, it isn't being widely seen or reported.
Thank you for your comments and recommendations.
Cheers,
- Dean
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden