--- At Sat, 15 Mar 2008 15:10:38 -0700, Duane Murphy wrote:
>I like the idea of using a different extension and then renaming after
>the permissions changes.
I take it back. If timeing is an issue here, this solution doesn't work.
A full cache update would still be missed if the file is renamed and the
folder touched during the cache update.
A staging area would be best. One change; everything in the folder is
always correct.
I guess we may have to rely on /tmp. :-(
...Duane
--- At Sat, 15 Mar 2008 15:10:38 -0700, Duane Murphy wrote:
>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
...Duane
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden
This email sent to email@hidden
