Update NFS automounts from the terminal

If you’ve used Disk Utility1 to set up automounts — or you recently upgraded to Mountain Lion and found that the GUI for editing NFS mounts has disappeared — and find yourself needing to quickly update the records, this tip is for you.

We moved a bunch of NFS shares from one server to another over the weekend and needed to update the mount records on all clients that aren’t using our LDAP-based automount records. A handful of Macs with manually-configured NFS shares had lost access to these relocated shares. Disk Utility stores its mount records as (non-binary) plists in  /var/db/dslocal/nodes/Default/mounts. One of the lines in a mount plist contains the server:/path/to/share line for that automount.

To update the mount record, do the following using root privileges:

  1. Find the plist that contains the path you need to update in /var/db/dslocal/nodes/Default/mounts.
  2. Use your favorite text editing tool to update the path record, or replace the entire plist with one that contains the updated record.
  3. Run automount -vc to flush the cache and read in the updated information.

That’s all there is to it. I leave it as an exercise for the reader to combine all the steps into a deployable, scripted solution.


1. If you’re using OS X 10.5, it’s in Directory Utility.

Create a Leopard to Snow Leopard Upgrade NetInstall Image

UPDATE (10/15/09): I’ve gotten mixed results from some individuals who’ve tried the workaround with 10.6.1. I’m working on and testing an extended workaround that should fix the problem for everyone. Look for that info soon.

— — — —

UPDATE (10/13/09): I’ve updated the article (and posted it as new) with a workaround for the issue that prevented additional packages from being installed. I submitted the bug that this workaround avoids to Apple — id #7247968 — on September 23, 2009.

— — — —

This post is a Snow Leopard update to a process I wrote about when Leopard (10.5) came out. This post will tell you how to create a NetInstall image that will upgrade a Mac running Leopard to the latest version of Snow Leopard in one step. It will also work to upgrade a Mac running Tiger to the latest version of Snow Leopard.

What You’ll Need

  1. A 10.6 software license, or individual retail copy of Leopard, for each computer you are upgrading from Leopard or Tiger to Snow Leopard — this is easily overlooked, so let’s keep things legal.
  2. A read/write disk image (.dmg) of a Mac OS X v10.6 Snow Leopard Install DVD (i.e. not shipped with a computer). You’ll convert this to read-only after making a small modification to one of the files.
  3. One build computer running Snow Leopard with the latest version of Snow Leopard’s Server Admin Tools installed (10.6.0 as of this writing).
  4. A computer running OS X Server providing NetBoot services — Tiger, Leopard, and Snow Leopard Server will all work
  5. A copy of the OSUpgrade.pkg found on the Install DVD at /Volumes/Mac OS X Install DVD/System/Installation/Packages. This is a hidden folder, so use Go to Folder from the Finder’s Go menu to reveal it.
  6. Optional: the latest Combo Updater — 10.6.1 as of this writing. (Yes, it’s not a Combo Update, but only because it’s a .1 updater.) Continue reading

Can I boot Snow Leopard in 64-bit mode?

UPDATE: Please read Update 2 at the bottom of this post before using a 64-bit kernel as your default.


With Snow Leopard making its appearance this Friday, August 28, 2009, some people may be wondering whether they’ll be able to boot their Macs in 64-bit mode. Only Intel Xserves will boot this way by default. If you want to boot your desktop or mobile Mac in 64-bit mode, you’ll need to take some additional steps. The first is checking to see if your Mac has a 64-bit-capable EFI. If the output of the following command is EFI64, you’re good. If not, you’re out of luck.

    ioreg -l -p IODeviceTree | awk -F'"' '/firmware-abi/{print $4}'

Once you’ve verified it’s possible, you have a couple options for making your Mac boot into 64-bit mode. I’d try them in this order. First, to affect the current boot only, hold down the ‘6’ and ‘4’ keys during bootup. Once you’ve verified it works and are comfortable with it, you can make the change permanent by adding an ‘arch=x86_64’ boot flag to your com.apple.Boot.plist, like so:

    sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.Boot \
    'Kernel Flags' 'arch=x86_64'

UPDATE 1 (8/28/09): Apple has a couple new (and one older) knowledge-base articles pertaining to this topic.

  1. Mac OS X Server v10.6: Macs that use the 64-bit kernel
  2. Mac OS X Server v10.6: Starting up with the 32-bit or 64-bit kernel
  3. How to tell if your Intel-based Mac has a 32-bit or 64-bit processor

UPDATE 2 (8/29/09): This post has received quite a few hits, so I now feel the need to include some educational material about why Apple chose to make Snow Leopard boot with a 32-bit kernel by default.

The primary reason is for compatibility with third-party software, particularly software that requires kernel extensions. Probably the most widely know examples of software that depends upon kernel extensions, or kexts, are VMware Fusion and Parallels. If you use these to run Windows or Linux on your Mac, you’ll want to keep using a 32-bit kernel. Virtualization software needs direct access to the hardware normally controlled by the kernel (CPU, RAM, Disk) in order to “fool” operating systems into thinking they’re installed on “real” computers. The kernel extensions allow them to do this.

Kexts must be written specifically for 32-bit or 64-bit kernels. They are not interchangeable. Applications, on the other hand, can run at 64-bit even if the kernel is 32-bit. As far as your 64-bit CPU is concerned, the kernel is just another application. It’s a very important application — in the sense that it is code that is executed on a processor — whose job it is to arbitrate demands on the system’s resources. Most applications don’t have direct access to the CPU, RAM, or other physical devices, but make requests of the kernel instead.


UPDATE 3 (9/1/09): John Siracusa’s new article on Snow Leopard was posted today. Then entire thing is great reading, but I’m linking to the section that addresses 64-bit vs 32-bit here.

Create a Tiger to Leopard Upgrade NetInstall Image

(UPDATE: If you’re interested in a Snow Leopard upgrade process, please see this post for updated instructions.)

adminertia : an admin at rest tends to stay at rest and an admin in motion tends to want to return to rest as soon as possible.

When Leopard was first released, I was almost grateful that it didn’t work reliably with Active Directory since that flaw provided me with a valid excuse for not having an upgrade procedure ready to roll when upgrade requests started trickling in from my users. I knew that by the time Apple got around to releasing an update that made Leopard work well with AD, the number of requests would have increased significantly. I needed to have a method of handling them in a timely manner.

Walking around the building with an installer DVD or a FireWire drive in hand doesn’t exactly rank as timely, nor does it rank as anything close to what I want to be doing with my time. NetBooting from a copy of the installer DVD is a slightly better option, but that would require applying a handful of OS and security updates after the initial install in order to bring each computer up-to-date. NetBooting with a NetRestore set created with Mike Bombich‘s (otherwise) excellent software is not an option because it can’t upgrade a computer, only overwrite it.

Because I have chosen not to use Radmind in my environment, it seemed my options for creating a more or less automated upgrade to take Macs running 10.4.x directly to the latest version of Leopard were severely limited. After much despair, head scratching, and a little behind-the-scenes investigation, I discovered that Leopard’s System Image Utility could be wrangled to accomplish my goal.

Continue reading