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?
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.
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.
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.
Continue reading “Automating Firmware Updates”
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:
- It dynamically determines if any tools or required libraries need to be cached, using Apple’s
/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.
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
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…
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.