Troubleshooting Mac OS X Kernels w/ dmesg

The first thing that loads in OS X is the kernel. The kernel is how users interface with hardware and sets the stage for interaction by probing for each driver that needs to be loaded and tracking what is found. The presence of everything about the system is tracked when the kernel loads as well as pertinent boot parameters. Even if you’re booting in verbose mode, most of this probably happens too fast to notice. You might be able to pause it, but you’re still trying to react to things too quickly in many cases. That’s where the dmesg command comes into play, which lets you review and control the messages since the system has booted. The dmesg command also looks at some diagnostic messages after the system is due booting, such as when a new interface is detected. The dmesg command allows for more than what you can see in console, except explicitly for I/O related kernel messages after boot, rather than all the pesky OS stuff you might otherwise see, such as snarky little “spotlight can’t index this or that” kind of errors. Instead, dmesg output is only a few screens, easily readable that focuses on the system hardware & I/O interfaces. Using dmesg is pretty easy. Even if you’ve su’d, you need to run sudo in front of it each time, but there’s no need for any parameters: sudo dmesg You can use -n for the level of errors or -s to constrain the buffer size, but in Mac OS X you likely don’t need to do either as there’s not a ton of information. If you’re looking for something specific, such as information on an AirPort interface, just grep it out: sudo dmesg | grep AirPort Overall, dmesg is helpful for stuff like this: vnic0: promiscuous mode enable failed Apparently, Rajesh Koothrappali couldn’t find any booze… Or this: USBF: 23952.350 AppleUSBEHCI[0xffffff800b7dc000]::Found a transaction which hasn't moved in 5 seconds on bus 0xfd, timing out! (Addr: 4, EP: 2) I had a bad drobo on the system… Which I might have known by the fact that the Finder froze when plugged in. But I always like to see it in the logs. Swap out one drive, message goes away, drobo loads just fine. Have I mentioned recently I’m liking the low end drobos less and less…

Sync'ing iTunes Libraries

I recently spent a few days trimming down the amount of space consumed by my home folder. In so doing I discovered a number of things I could be doing better with regards to utilization of my drive space. So I decided to offload most of my media (photos, movies, etc) off my laptop and onto my Mac Mini server. I also decided that one thing I’d like to live on both is iTunes. Note: Before you do anything in this article you should verify you have a good back up. Also, both machines will end up needing to be Authorized for your iTunes account. There are a lot of ways to keep two iTunes libraries in sync. There are also a number of 3rd party tools that can help you do so. I tested all the tools I could find and decided I’d rather just script it myself. Scripting a synchronization operation in Mac and Linux always seems to come down to a little rsync action. Given that rsync is a little old in Mac OS X, I started out by updating rsync to the latest (3.0.7) using the steps provided on (I added using /tmp):
mkdir /tmp/rsyncupdate cd /tmp/rsyncupdate curl -O tar -xzvf rsync-3.0.7.tar.gz curl -O tar -xzvf rsync-patches-3.0.7.tar.gz cd rsync-3.0.7 curl -o patches/hfs_compression.diff curl -o patches/crtimes-64bit.diff curl -o patches/crtimes-hfs+.diff patch -p1 <patches/fileflags.diff patch -p1 <patches/crtimes.diff patch -p1 <patches/crtimes-64bit.diff patch -p1 <patches/crtimes-hfs+.diff patch -p1 <patches/hfs_compression.diff ./prepare-source ./configure make sudo make install sudo rm -Rf /tmp/rsyncupdate /usr/local/bin/rsync –version
Provided the version listed is 3.0.7 then we have a good build of rsync and can move on with our next step, getting a target volume mounted. In this case, I have a volume shared out called simply Drobo (I wonder what kind of RAID that is?!?!). Sharing was done from System Preferences -> Sharing -> File Sharing -> click + -> Choose Drobo and then assign permissions. The AFP server is on an IP address of For the purposes of this example, the username is admin and the password is mypassword. So we’ll do a mkdir in /Volumes for Drobo:
mkdir /Volumes/Drobo
Then we’ll mount it using the mount_afp command along with a -i option:
mount_afp “afp://admin:mypassword@” /Volumes/Drobo
Now that we have a mount we’ll need to sync the library up. In this case, the Music directory on the Drobo has a symlink from ~/Music. This was created by copying my Music folder to the drobo and then rm’ing it (fails when trying from Finder):
rm -Rf ~/Music
Then using ln to generate the symlink:
ln -s ~/Music /Volumes/Drobo/Music
Now sync the files. I’m not going to go into all of the options and what they do, but make sure you have permissions to both the source and the target (using the username and password from the user whose data your changing helps):
/usr/local/bin/rsync -aAkHhxv –fileflags –force –force-change –hfs-compression –delete –size-only ~/Music/iTunes /Volumes/Drobo/Music
Note: If you get a bunch of errors about operations failing then consider disabling the Ignore ownership on this volume setting for any external media you may be using. Now fire up iTunes on the target machine and make sure it works. At this point, I could also share out the Music folder from my laptop and sync back as well, which would effectively allow me to make changes on both machines. However, for now, I only want to make changes on the laptop and not the desktop so there’s no need for a bidirectional sync. Once the sync is complete, we can tear down our afp mount:
diskutil unmount /Volumes/Drobo
Now that we can sync data, we still need to automate the process as I’m not going to want to type all this every time I run it. First up, I’m going to create a .sh file (let’s just say /scripts/
touch /scripts/
Then I’m going to take the commands to mount the drive, sync the data and then unmount the drive and put them in order into the script:
/bin/mkdir /Volumes/Drobo mount_afp “afp://admin:mypassword@” /Volumes/Drobo /usr/local/bin/rsync -aAkHhxv –fileflags –force –force-change –hfs-compression –delete –size-only ~/Music/iTunes /Volumes/Drobo/Music /usr/sbin/diskutil unmount /Volumes/Drobo
Once created, the script should be run manually and provided it succeeds then it can be automated (ie – creating a LaunchDaemon). If it works after a little while, then you can consider synchronizing your iPhoto and anything else if you so choose. Also, I ended up actually using ssh pre-shared key authentication and doing rsync over ssh. That allows you not to put the password for a host on your network into an unencrypted form in a script. You could do some trickeration with the password, but you might as well look into pre-shared keys if you’re going to automate this type of thing to run routinely. Finally, I also later ended up removing the iTunes Genius files as I started to realize they were causing unneeded data to sync and they would just rebuild on the other end anyway. Hope this helps anyone else looking to build an iLife server of their own!

NAS, Clouds & Backup

NAS (Network Attached Storage) devices are a popular alternative to providing centralized file services to smaller environments. This includes devices such as the Seagate BlackArmor, the DroboShare NAS and the Netgear ReadyNAS Pro. These are inexpensive as compared to an actual server, they require less management and they often come with some pretty compelling features. But one of the primary reasons to buy a NAS can end up being a potential pain point as well: they require less management than a server because they can’t do as much as a server can. For example, the option to replicate between two of them. Most have NAS to NAS replication built in. However, that replication ends up being dependent on having two of them. But what if you just have a machine on the other side of the replication, want to back it up remotely compressed or want to back up to a cloud environment. Well, if it’s not the same daemon then you’re typically stuck with CIFS, NFS, HTTPS (WebDAV) or FTP. The devices don’t typically give you the option to push directly from it nor to run a daemon that non-proprietary device can connect to directly, so you’d have to use a client to do the offsite sync. One example of how to do this would be to use JungleDisk and an Amazon S3 account. JungleDisk would mount the AmazonS3 storage and the NAS storage (all share points). You would then use a tool such as ChronoSync, Retrospect (Duplicate scripts not backup scripts btw) or even rsync to backup the device over CIFS. It’s not pretty, it’s extra latency and management, but it would work. The reason you would do synchronization is that if you attempt to backup (a la Retrospect Backup Scripts) then you’d send big, monolithic files over the wire. The smaller increments of data you can send over the wire the better. Another tool that can do that type of sync is File Replication Pro. That would actually do blocks instead of files, pushing an even smaller increment of data over the wire. There are certainly other services. You could even open up the firewall (for just the specific ports/IP addresses requiring connectivity, which is always a potential security risk) and have a remote backup service come in and pull the data sync over FTP, CIFS or WebDAV (if you want to stick with a cloud backup solution), but those types of services are a bit more difficult to find. The same is pretty much the same for cloud based storage. With the exception that instead of a built-in feature you’re either looking for a built-in feature or an API that allows you to develop your own. The moral of this story, if you use a NAS or a cloud-based solution and you want to back your data up, then your options are limited. Keep this in mind when you decide to purchase a NAS rather than, let’s say, a Mac OS X Server running on a Mac Mini with some Direct Attached Storage (DAS) connected to it.