EFI and Thunderbolt firmware updates

Late last week we received a shipment of Thunderbolt MacBook Pros.

This week Apple released the MacBook Pro EFI Firmware Update 2.1 and the Thunderbolt Firmware Update 1.0.

Based on past experience, I expected to have to install these manually: launching the updater, shutting down, then holding the power button to get into “firmware update mode”…

Imagine my surprise when:

• Munki downloaded and installed the EFI Firmware update
• Munki rebooted the MacBook Pro
• The EFI firmware updated automatically(!)
• The machine rebooted again.
• Munki downloaded the Thunderbolt Firmware Update
• Munki rebooted the MacBook Pro
• The Thunderbolt firmware updated automatically(!)
• The machine rebooted again.
• The machine came up normally and ready to use.

Completely automatic firmware updates. Is this a first, or did I miss something?

Advertisement

More Intel Firmware updates: EFI

Apple released a bunch of EFI firmware updates for Intel Macs yesterday. Unfortunately, since to run EFI firmware updates you must run the updater app, shutdown the machine, then hold down the power button until it starts flashing, there is no way to automate these updates.

The best you can do is to write a script that checks the firmware versions and notifies the admin(s) that a machine needs an update. Then you schedule a visit and manually apply the update.

If anyone has a better idea – I’m all ears.

Automating Intel firmware updates II: Revenge of the SMC

I’ve extended my script to automate SMC firmware updates on Intel Macs to handle more models – this version covers every model we have in use here.

Here is the script, since WordPress will mangle it.

Automating Firmware Updates

Apple recently posted a firmware update for the MacBook that they claim addresses the spontaneous shutdown issue. If you have a lot of MacBooks at your site, you’ll have lots of fun visiting each one and doing the update.

It turns out that this updater can be run via command-line; either remotely via ARD or ssh, or via a local script on the machine. This opens up the possibility of automating it.

Radmind, 10.4.8, and Intel

Quite a while back, I did a series of posts on using radmind to update a machine from 10.3.x to 10.4.x. A major element of the strategy, developed by Andrew Mortenson, was to copy vital tools and their needed libraries to a “cache” directory and coerce the OS to use those copies instead. This worked around problems to reared their heads when radmind replaced those tools and libraries while it was updating the filesystem.

While working on building a radmind loadset for 10.4.8, I discovered that if I used my current script to have radmind update an Intel Mac from 10.4.7 to 10.4.8, that the machine would hang when the script attempted to reboot the machine. You could manually reboot it, and the machine would come up fine. This behavior seemed very similar to what happened when trying to go from 10.3.x to 10.4.x before I implemented Andrew’s technique. It seemed that Andrew’s technique didn’t go quite far enough. There was much discussion of the issue on the radmind-users mailing list, and Ian Ward Comfort of Stanford came up with a solution. It takes Andrew’s ideas, and builds on them in two ways:

1. It dynamically determines if any tools or required libraries need to be cached, using Apple’s otool tool.
2. If /usr/lib/dyld is being replaced, it calls all the tools using a chroot-ed environment so that the cached version of dyld is used. This was the key change for the 10.4.7 to 10.4.8 update on Intel – without the chroot-ed environment, the OS was calling dyld in its original location after radmind had swapped it out, leading to a crash.

In my testing, this technique works perfectly. Here is Ian’s script, and here’s a link to the tool-caching bit of code. I did a lot of hacking to meld Ian’s code with mine, and I’ll probably post my version of the script soon.

More on CrossOver Mac

I was asked for more detail on how I cleaned up my Tcl/Tk libraries so that CrossOver would run:

I just removed the extra Tcl/Tk libraries we had installed, leaving me with the libraries that ship with 10.4.x for Intel (radmind made this easy to do) and that worked. I did not need to actually _install_ any TclTkAqua libraries. We had installed these older libraries back with Panther for a Tcl/Tk app we deployed; it appears they are no longer needed in Tiger, as Tiger ships with its own Tcl/Tk libraries.

Looking at what radmind changed, it looks like

sudo rm -rf /Library/Frameworks/Tcl.framework
and
sudo rm -rf /Library/Tcl

will produce the same result.
The OS-supplied Tcl libraries are in /System/Library/Framworks/Tcl.framework and /System/Library/Tcl and should be left alone. If you use any other apps that rely on Tcl/Tk, you’ll probably want to test them after you make this change…

CrossOver Mac Beta 1

I’ve been playing with the beta released yesterday. Some first impressions:

• It works. I installed MS Project 2003, ran it, printed to a printer defined in the OS X print system, and saved a file to my home directory, all without too much effort.
• Not very enterprise/multiuser friendly out of the box – lots of stuff gets installed by default in your home dir; specifically ~/Library/Application Support/CrossOver/. There seems to be an ability to “publish” a “bottle” (VirtualMachine-equivilent) so that all users of a Mac can access it — making a copy of the bottle in Library/Application Support/CrossOver/, but I had trouble making it work across users. CrossOver wanted to crash a lot in this scenario. Even when it did work, the drive mapping/folder redirection still wanted to access the original user’s home dir. I’m sure all of this can be overcome with proper config, but the configuration tools are immature.
• I initially had some trouble running CrossOver the first time because I had some third-party Tcl libraries installed in /Library/Tcl; once those were removed, CrossOver ran.
• The Windows, uh, windows run inside a X11 window manager – as a side-effect, this means that if you have a multiple monitor setup, any window that wants to open in the center of the screen will likely end up split half on one monitor and half on another.
• The X11-based windows look pretty good, though, and toolbars look right, without the X11 ‘wrapper’ around them.
• I noted some oddities when moving and resizing windows – where the window would suddenly jump away from the cursor.
• You don’t get the Windows “resize-from-any-side” behavior; you have to use the resize widget in the lower right corner.

If they get this right, this could work very well in my environment: I could package up a Windows app via CrossOver and use my existing tools (radmind) to push it out to an Intel Mac. It’s unlikely that I’d be able to do the same with Parallels or VMware, with their disk images. For a Mac user that needs access to just one or two Windows apps (like MS Project or Visio), this might be nearly ideal.

It’s exciting

Yesterday, I installed Windows XP on two Intel Macs using Apple’s Boot Camp. Today, I used the Beta release of Parallels Workstation to install Windows XP and Red Hat Enterprise Linux 4 on an Intel iMac.

Boot Camp makes installing Windows XP on a Mac as simple as can be imagined. (If installing an OS could ever really be called simple.) Parallels Workstation is definitely more techie-oriented: a novice would quickly give up, I think. But it does work. Some key shortcomings of the Parallels solution:

1) No sound (yet).
2) Full-screen mode doesn’t work (yet).
3) No support for USB (yet).
4) Networking support is more primitive – it looks like you can use Ethernet or Wireless, but not both.
5) No support for CD or DVD burning
6) No mounting of actual volumes – only drive images are supported.
7) Graphics performance is less than when booted directly into WinXP.

Several of these limitations are supposed to be addressed before the final (non-beta) release.

But the advantages are nice, too:
1) No need to reboot just to run one Windows app.
2) Support for Windows 3.1 through Windows 2003 Server.
3) Support for multiple flavors of Linux, FreeBSD, Solaris, etc.
4) The drive image for the virtual machine can be anywhere – on an existing partition or on a FireWire or USB drive. The Boot Camp solution can only boot Windows XP from a partition on the primary internal drive.

An appealing option would be a way to use the same Windows XP partition to either boot directly into XP, or to boot a VM. This way you could get top performance when you needed it, or maximum convienence when in OS X. You can do that now by using both Boot Camp and Parallels, but you have to maintain two seperate Windows installations: one on an actual drive partition, and one in a virtual drive image. Double the disk space and double the work!

One the other hand, since the VM and the actual hardware look like two different pieces of hardware to Windows, it might be problematic to use the same OS image for both modes. Other operating systems might not have these issues, though.

But these are exciting and interesting times to work with Macs – new possibilities seem to appear every day.

Boot Camp shenanigans

Apple’s new Boot Camp Assistant pulls a neat trick: if you have a single Mac OS X partition on your startup drive – it allows you to non-destructively repartition it and add a partition to install Windows XP.

But what if you’ve already partitioned your drive? Boot Camp Assistant refuses to run and tells you you must have a single partition. Do you really need to reformat to play with Apple’s new toy?

No.

I’ve since installed XP on a MacBook Pro that had already been set up with three partitions without having to repartition. Here’s how I did it:

1) Started up the MacBook Pro in Target Disk Mode.
2) Connected it via FireWire to an Intel iMac.
3) Used Disk Utility (on the Intel iMac) to reformat one of the unused partitions as FAT32
4) Unmounted the MacBook Pro and shut it down
5) Booted the MacBook Pro and held down the option key, and inserted the XP install CD.
6) The XP install CD showed up in the boot picker; I selected it and booted from it.
7) Installed XP as normal.

I imagine that steps 1 and 2 could be replaced with booting from the OS X install CD – the key is that you can’t reformat a partition to a different disk format on the startup disk when you are booted from it, since the entire disk must be unmounted. I haven’t tested this theory (yet).

Universal AppleScript applets

I hadn’t seen this documented anywhere else, and just stumbled across it… I wanted to update several AppleScript applets that were PowerPC applications into Univeral binaries.

Note I’m talking about the sort of AppleScript applications that one builds with Script Editor and saving the script as an application – not AppleScript Studio apps.

When you save an AppleScript in Script Editor, there are several options in the File Format menu. If you choose “application”, you’ll get a PowerPC-only app. However, if you choose “application bundle”, you’ll get a Universal app.

So open your AppleScript apps in Script Editor, and resave them as “application bundles” and you are set!