CoNetrix

Blog: OSX

I'm a big fan of using dd to do byte for byte copies of disks and partitions.  However, I've noticed the performance of dd in OSX is usually pretty poor.  Most people recommend toying around with the 'bs' option (for byte size) to find the optimal copy "chunk" size.  I've always had the best results using bs=512k, but even that didn't seem to help when I was recently trying to copy the contents of an old hard disk to a new one.  Both disks were connected to the internal SATA controller, but I was only getting a 15 MB/s copy rate. 

When running the command, I used the device specifications as enumerated by 'diskutil list' (e.g., dd if=/dev/disk0 of=/dev/disk1 bs=512k).  However, after some research, I found that you can place an 'r' in front of the disk# specification to access the "raw" disk and significantly improve performance.  So, I tried "dd if=/dev/rdisk0 of=/dev/rdisk1 bs=512k" and I started getting a 90+ MB/s copy rate. 

General, OSX, Apple,
 

I had recently upgraded a Mac user to the v10 PGP client and registered them with the bank's PGP Universal Server.  Everything seemed to work fine, but the user later discovered that PGP would prevent them from shutting down their machine if their iPod was attached.  Other devices didn't seem to affect the shutdown process.  I did some research and found this was a known issue.  The fix was to simply update the client from v10.0.0 to v10.0.2.  Obtaining the v10.0.2 update proved to be trickier than expected, but with a coworker's help I was able to download the update and put it on my USB thumb drive.  With update in hand, I strolled over to the bank and quickly installed the update off my USB drive (ensuring the customer this simple procedure would fix their problem).  When the computer rebooted, I pulled my thumb drive out and waited for the PGP screen to come up.  When it did, I had the customer enter their PGP Wholedisk passphrase.  After a couple of failed tries, PGP accepted the password and began to load OSX.  Then, the OS crashed! 

The user told me that happens sometimes after he misses his PGP password, so he simply restarted and tried again, this time putting the password in correctly the first time.  It ended the same way however.  At this point, the room became very hot and I started to sweat profusely.  I was sure I had just trashed this guys' machine by applying this simple update.  I'm sure he was starting to think the same thing too.  I sat down at his machine, wondering what in the world my next step was going to be, and then it hit me.  "I wonder if PGP needs something off the installation media (my USB drive) to update the boot process?"  I shut down the machine, plugged my USB drive back in and powered it back on.  I logged in to the PGP screen, the OS started to load...loading....loading....loading... OSX login screen!  Suddenly, the temperature in the room dropped drastically.  I had the user log in, I removed my USB drive and rebooted again.  Everything came up perfectly.... much to my relief. [more]

One other note about PGP and OSX upgrades...
In some cases, PGP will modify the system partition table enough that OSX upgrades (in my case, Leopard to Snow Leopard) won't be able to identify the currently installed OS.  This makes doing an in-place upgrade impossible.  The fix is to simply open Disk Utility, select the system disk, select the Partition tab, resize the system partition by dragging the bottom right corner up, then right back down (this should enable the "Apply" button), click Apply (confirming the change), exit Disk Utility.  The OSX upgrade should be able to correctly identify the currently installed OS after this.

Security and Compliance, OSX, PGP, Mac,