dfbills.com blog

After begrudgingly installing a carpet in my apartment, I finally got around to running my trusty Roomba Red.  I fought and fought with it, but it just wouldn’t start up on the carpet.  When I started it near the edge, it would turn away.  When I forced it to go over on the carpet, it would reverse itself off.  If I pushed it while running into the center of the carpet, it would just scurry around in reverse gear.

I did a bit of searching and it turns out my friend Roomba doesn’t like dark carpet.  The fix was to tape white paper over the cliff sensors to trick it into seeing a sensor reflection.  Good thing I don’t have any cliffs in my apartment!

Does Apple’s excellent Time Machine backup software make your hard drive grinding away every hour?  Well of course it does!  And that’s a problem when you can hear it while trying to sleep.

It turns out that you can adjust these settings as they are controlled entirely by launchd.  Instead of my usual command-line approach, I decided to use the graphical Lingon app.

Launch the app and find the com.apple.backupd-auto file under system daemons and adjust the “Run it every” setting.  I set mine to 12 hours- now Time Machine runs on my laptop when I plug in my external drive and every 12 hours after.  Perfect for a good night’s sleep!

Update: Unloading and reloading the LaunchDaemon will enable your new settings:

sudo /bin/launchctl unload -w /System/Library/LaunchDaemons/com.apple.backupd-auto.plist
sudo /bin/launchctl load -w /System/Library/LaunchDaemons/com.apple.backupd-auto.plist

Note: these settings are reset to system default after most system updates.  Simply re-apply to fix.

For some reason the utility for changing the password in iPhone 1.1.3 is broken. You cannot use passwd to change password or you will have to restore the system. I found a great workaround online which uses perl.

perl -e 'print crypt("PASSWORD", "XX")."\n"'

Simply replace "PASSWORD" and the two character hash "XX". Then, take the resulting hash and replace the "alpine" password hash in /etc/master.passwd for both "root" and "mobile".

To fix iPhone Installer.app 3.0 “Error package download failed” on firmware 1.1.3, make sure to install “Community Sources.”

To respring the iPhone via terminal:

launchctl stop com.apple.SpringBoard

At some point during the day today, I lost all audio on my iPhone.  The typing noise, lock “switch” sound and most importantly- phone audio ceased working.  A quick Google search revealed a fix at iPhoneAtlas.

“...the problem appears to be that the iPhone “forgets” which mode it is in, erroneously thinking that it should still send audio through the audio jack instead of the earpiece.  Unplug then re-plug headphones or any other compatible device into the iPhone’s audio jack several times.”

This fix did indeed work on mine.  Odd since I hadn’t plugged earphones into the iPhone in at least a week.

The latest in my epic struggle with Leopard.  Now, on my Mini!

Apparently Time Machine in 10.5.2 does not like my Intel Mac Mini environment.  At the time of posting, I only found one other reference to my latest Leopard error: “Backupd Waiting for index to be ready.”  I’m hoping that there will be more…

For the record, here’s what I was seeing for 18+ hours in my console:

2/12/08 11:12:27 PM /System/Library/CoreServices/backupd[212] Backup requested by user
2/12/08 11:12:27 PM /System/Library/CoreServices/backupd[212] Starting standard backup
2/12/08 11:12:27 PM /System/Library/CoreServices/backupd[212] Backing up to: /Volumes/External Backup HD/Backups.backupdb
2/12/08 11:12:27 PM /System/Library/CoreServices/backupd[212] Event store UUIDs don’t match for volume: Macintosh HD
2/12/08 11:12:27 PM /System/Library/CoreServices/backupd[212] Backup content size: 45.2 GB excluded items size: 7.0 MB for volume Macintosh HD
2/12/08 11:12:27 PM /System/Library/CoreServices/backupd[212] No pre-backup thinning needed: 54.26 GB requested (including padding), 60.98 GB available
2/12/08 11:12:27 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (909 > 0)
2/12/08 11:12:32 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:12:40 PM kernel jnl: disk2s6: flushing fs disk buffer returned 0x5
2/12/08 11:12:42 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:12:57 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:13:17 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:13:42 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:14:12 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:14:42 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:14:43 PM /usr/sbin/ocspd[222] starting
2/12/08 11:15:12 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:15:14 PM kernel jnl: disk2s6: flushing fs disk buffer returned 0x5
2/12/08 11:15:42 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:16:12 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:16:42 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:17:12 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:17:42 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:18:12 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:18:42 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:19:12 PM /System/Library/CoreServices/backupd[212] Waiting for index to be ready (906 > 0)
2/12/08 11:19:18 PM kernel jnl: disk2s6: flushing fs disk buffer returned 0x5

This command will help you find which app is preventing a disk from ejecting.

lsof | grep YourDriveName

Since I’m on a bit of a performance tuning hunt this week, I decided to find out why my hard drive was grinding away this morning.  (With a load average of 2.6)

Turns out, it was my old friend build_hd_index.  This horrible little app is part of Apple Remote Desktop.  It is designed to index the hard drive at a default time of midnight on all systems that are managed by Remote Desktop. Seems innocuous enough- that is until you hear it churning away late at night on several computers.

So now we have Spotlight, locate, Time Machine and build_hd_index indexes of the hard drive and they all grind away at all hours of the day and night.  The unfortunate thing is that only Spotlight is away of the “special” status of Time Machine’s Backups.backupdb database.  All the others just thrash away.

So without further ado- here’s how to disable build_hd_index:

sudo chmod a-x /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Support/build_hd_index

Keep your friends close and your enemies even closer.

update: A few people have written me to say that turning off the “generate reports” option in the Sharing/Remote Management panel will keep this from happening but this seems to have no effect on my system.

update 2: A better fix: manually reset the data collection policy by removing the file com.apple.ARDAgent.plist file in /Library/Preferences as Apple recommends.  (This does not seem to always do the trick)

sudo rm /Library/Preferences/com.apple.ARDAgent.plist

update 3: laptopleon pointed out that nulling the privileges can break macosx server system updates.  I’ve updated the chmod command to simply remove execute privs.

update 4: Apple has posted a Knowledge Base article: “Apple Remote Desktop: How to disable build_hd_index.”  Not sure that this is a definitive solution.

Ever wonder what is spotlight working on right now?  This command will query the filesystem for you.

lsof | grep mdworker