I too had a problem which required the dumping of caches after
upgrading to 10.3.7. Mine was a spinning beachball after login was
complete. It was characterized by the following in the log...
automount[415]: objc: FREED(id): message markDirectoryChanged sent to freed object=0x1807200
...
kernel: nfs server automount -nsl [415]: not responding
Cleared the caches and all is well...so echoing what everyone else
seems to be saying. Upgrading via radmind or sneakernet, always empty
those caches.
Jeff Abernathy
Saint Louis University
Geoff Lee wrote:
On 18 Jan 2005, at 02:28, John Anthony Grigutis wrote:
On Jan 17, 2005, at 12:17 PM, Geoff Lee
wrote:
I have a lab of 30 machines which all work
perfectly except when one tries to mount a USB pen drive. Sometimes it
will work fine and mount and other times it will not. When the drive
fails to mount, it appears in system profiler but not in Disk Utility;
basically the machine knows there's a USB device there but doesn't see
that it's a storage device. Re-starting the machine will usually cause
the drive to mount OK a few times but the problem comes back fairly
swiftly.
Have you upgraded to 10.3.7 recently?
Yup.
If so, you might have run into the same
problem I had. Check your /private/var/log/system.log when you plug in
a USB flash drive. You might see an entry like this:
kextd[84]: a different version of dependency extension
/System/Library/Extensions/IOSCSIArchitectureModelFamily.kext is
already loaded
Hmm... this entry does indeed appear!
/usr/sbin/kextstat showed that version 1.3.7
was loaded, but version 1.3.8 was what was in
/System/Library/Extensions/ (via System Profiler).
The problem … caches. The system was using a cached version of that
extension instead of reloading the new version.
We use radmind to push out updates to all our machines. Normally,
radmind (/private/etc/hook/radmind.hook) deletes
/System/Library/Extensions.kextcache &
/System/Library/Extensions.mkext if it sees newer extensions, but
apparently it wasn't enough this time.
I also use radmind and had suspected it could be something of this
nature. My radmind script merely touches /System/Library/Extensions
(ostensibly causing the cache to be re-built on re-boot) but as you say
this doesn't seem to have been sufficient.
Me thinks this also might explain some other
reports I've seen regarding 10.3.7 and FireWire hard drive problems.
Probably... there are three IOSCSI related plugins that load with
incorrect versions (4 on one of my machines). I imagine this throws the
whole subsystem somewhat.
Deleting the caches you suggest on a couple of machines does seem to
have fixed the problem. I'm going to investigate a bit further and see
if I can find out why the usual method of touching /S/L/Extensions was
ineffective. I'll report back to the list with my findings.
It's great when someone else has the exact same problem (and even
better when they've found the solution!)
Thanks a bunch,
-geoff
______________________________________
Geoff Lee <email@hidden>
Computing Support, Architecture
School of Arts, Culture and Environment
University of Edinburgh
20 Chambers St,
Edinburgh, Scotland,
EH1 1JZ
Tel: +44 (0)131 650 8020
______________________________________
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Client-management mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/client-management/email@hidden
This email sent to email@hidden
|
