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: "Duane Murphy" <email@hidden>
- Date: Sat, 15 Mar 2008 15:10:38 -0700
Dean,
Thank you for the information. I think there are some things we can try
and do in here.
Something that might not have been clear is that we are also counting on
the boot partition to be updated by kextd/kextcache. This has been the
significant issue. We have not seen this problem with installs that do
not have boot partitions. However, with boot partitions, we see this
problem intermittently. Maybe hanving the boot partition in the process
changes the cache update in ways that others are not seeing.
I'll file a bug report, but reproducing this is a difficult. It just
feels like some kind of timing issue.
>As long as the
>final touch happens within a few seconds after the mv, kextache will
>only be run once.
This is, I think, where the timing issue comes in.
1. The kext is copied into /S/L/E by the Package Installer
2. Presumably, the cache rebuild starts as it notices the folder changed
3. chmod, chown, touch the kext
4. But the cache rebuild is still in progress so no update occurs
5. Restart
6. Can't reboot
I've changes our script to make sure that kextcache runs after the
touch, but I believe kextcache is actually _still_ running from the
original copy and doesn't actually finish.
I like the idea of using a different extension and then renaming after
the permissions changes.
I've run into a process like this before, where an update is missed
because the data changes during the process. The solution I have used is
to keep updating until there are no changes. Updating just once,
especially for a lengthy process like rebuilding a file cache, can miss
a mid-update change.
--- At Sat, 15 Mar 2008 10:59:17 -0700, Dean Reece wrote:
>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.
...Duane
_______________________________________________
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