Mac GUI Bootloader using rEFIt

As eluded to in a previous post, I used rEFIt to manage the GUI bootloader of our iMacs.  This simplifies the boot menu when dual booting an imac.

Working with rEFIt

rEFIt creates a GUI bootloader for Macs.  It is very easy to work with.  Simply install it and navigate to the /efi/refit folder and open refit.conf using the Texteditor.  The .conf is very well laid out and describes in sufficient detail which parts control what aspect of the GUI.

I have created a .bmp logo which I have dumped in the refit directory, referenced it in the .conf file and uncommented the line from the script.

For obvious safety reasons, I have uncommented the ‘disable all’ line from the .conf file so that the only options for booting the Mac is the internal disk.  By default all methods are displayed in the GUI meaning that users can boot from external USB, CD and from the network.  You can, if you prefer, select which of these items you’d like to disable if you prefer not to disable all of them.

You can select which partition or what Operating System takes priority in booting up.  Like the other options, the commented lines within the .conf give details instructions on this, but basically W=Windows, L=Linux, and so on.


Using Iceberg to redistribute Mac software

A continuation on the previous post of how to automate the Lion deploy process…

As with the last post, check the foot of the post for references.

Working with Iceberg Package Manager

Some software that we use can only be installed from the App center without the option to download first.  This makes it difficult to obtain an installer to roll out to client machines.  Luckily, with the help of Iceberg, this isn’t an issue.

Iceberg is able to lift most installed packages right out of the Applications directory and package them into a .pkg ready for redistribution.  Some packages aren’t as simple as that and we will get in to those later in the section.  For now let’s focus on the simple…

Download and install Iceberg, which you can grab from here:

Launch Iceberg and from the toolbar along the top of the screen, select File>New project.  For a basic package, like our example of Texteditor, we can stick with the core template package.  Name the package appropriately and continue to the next screen.

Iceberg New Project Wizard

In the new window, expand the name of the package from the left hand pane and select Files.  In the central pane, right click Applications and select Add Files…

Add files to the Project

Navigate to the location of the installed application and double click it.  Press OK to the popup about absolute paths, if applicable.  You should know see the application under the Applications header.

Adding files to the project

Next, click on the Settings tab from the left hand pane.  Here you can amend the details of the package to reflect that of your own business.

Change the default name to something appropriate to you

From the toolbar along the top of the screen, select Build and Build again.  Close the window when it is complete.  By default Iceberg saves the built pkg to the current users home area.  The directory is named after the package itself.  The .pkg will be in the sub directory named Build.

As I mentioned earlier, this method works for the majority of applications, but not all of them.  Some applications that I found NOT to work this way were Xcode, Office 2011 and McAfee 1.1.

If you skip down to the references at the bottom of this document, you will get a good example from another blogger detailing the process to repackage Office 2011.  I found that this was didn’t work very well with Xcode 4.3.2 so had to go about that another way.  Also McAfee I couldn’t repackage at all using Iceberg as the main .mpkg calls upon a further four .pkgs all with their own post and preflight scripts.

Deploying McAfee

The McAfee .mpkg invokes four smaller .pkg’s making it quite difficult to automate.  The way I found to get past this was to copy the installer to the client machine using the file copy task in DS.  Then to a script that runs at the end of the workflow, I added the following line:

Sudo installer –pkg /users/administrator/desktop/mcafee.mpkg –target /

It’s not the cleanest method, but it works.  I then have a cleanup script that runs after this one which deletes the .mpkg.

Deploying Xcode 4.3.2

This was the most challenging package I faced when configuring the deployment.  Like McAfee, the .mpkg for Xcode invokes another .pkg, Mobile Device Framework.  The only way I was able to get around this was to split this up into two packages.  Package one installs the Mobile Device Framework, and the second installs Xcode.

Before we can look at any of this, we will need the download.  To get this, you need to create a free developers account and login to the following site: 

Once the installer has finished downloading, mount the .dmg.  Right click on Xcode and select Show Package Contents and navigate to Xcode>Contents>Resources>Packages and copy MobileDevice.pkg to the desktop for easy access.

Launch Iceberg, and like before create a new project.  This time, we will be creating a Darwin Package so select the appropriate package type from the menu and name the project.  Before completing the package, I usually copy the MobileDevice.pkg to the newly created project folder.  This keeps everything together should I need it again at a later date.

From the project window, expand the package by clicking the down arrow on the item in the left hand pane.  From the list, click on Scripts.  Simply drag and drop the MobileDevice.pkg into the bottom window and ensure the checkbox to the left of it is ticked.

Adding the Mobile Device Framework to the Project

The next thing we need to do is create a postflight script and link it to the Installation Scripts window as shown in the above screenshot.  The script takes the form of:



Sudo installer –pkg “$1/Contents/Resources/MobileDevice.pkg” –target /

Once you have written the script, name it postflight and verify that it doesn’t have an extension of any kind, then make it an executable by running the following command in the terminal:

Sudo chmod a+x /path/to/postflight

Copy the newly created script to the project directory, for the same reasons that we copied the MobileDevice.pkg there earlier.  Now drag and drop to the postflight area of the Installation scripts of the project window, ensuring that the checkbox to the left of postflight is ticked.

Once you have done this, build the project and leave it to one side.  Now we need to create the package for Xcode itself.  To do this we need to install Xcode on a test machine and be sure to install any extras like iOS simulators from Xcode>Preferences>Downloads.

When you are happy with the Xcode installation, we need to run a small command from the terminal to ensure permissions are correctly set before we can capture it:

Sudo chown –R root:wheel /Applications/

Launch iceberg and create a new project, same as last time – a Darwin package.  Expand the package so that you can see the Files tab.  Under Applications, rightclick and select Add Files.  Within the new window that pops up select Applications and choose Xcode.  That’s all there is to it!  Build the project and move both project directories to your deployment server’s Packages repository.

As mentioned earlier, I took a lot of influence from Mr derflounder’s blog when trying to package Office 2011 and Xcode 4.3.2.  I highly recommend a thorough read of his comments before undertaking these deployments.  You can find links to his blog at the bottom of this post.



Download the installer for Xcode from the developers site here:

Iceberg User guide:


I had a lot of ideas and help from this insightful blog.  Here is a link to one of his posts, which helped me repackage Office 2011:

Another useful post from derflounder:




Deploying Lion & Windows 7 to iMacs

Well I’ve been pretty busy lately working with Mac’s which is something I don’t do very often.  We have finally gotten round to automating the rollout of our Mac lab.  I used a combination of tools as we dual booted the iMacs with Lion and Windows 7.  To deploy the Mac side of things, I used DeployStudio.  I used rEFIt to manage a GUI bootloader to switch between Lion and Win 7.  To rollout Win 7, I used an altered Task Sequence from MDT 2012.  Here is how I managed to get it all working…

Please see the foot of this post for references…

The theory

Deploystudio is a fairly straightforward package.  Firstly, you create your deploy server via the DS assistant.  Then create a netboot image – this is basically the mac version of a WinPE though a lot larger in size, nearly 2.5 GB!  The netboot image is a striped down version of the Mac OS and is what we boot into when running a workflow.  As well as giving us access to the features of DS, we can also access tools found in Utilities; disk and network utilities, terminal, etc.

From the DS admin tool, we can amend our workflows and create new ones.  We can add packages for deployment and we can monitor the ongoing deployment tasks to clients.

When it comes to automating the installation of applications we can use the Iceberg package manager running on a target machine, to capture the apps and then copy them to the deployment server.  Some packages require more work than others, hence in our main deployment workflow we have multiple package installation bundles as some software is happy to be installed from the netboot image, others require to be installed at next boot.

As we are dual booting the iMacs, we will be using rEFIt to manage a GUI boot loader, giving the user a graphical interface in which to select whether the mac boot into Lion or Windows 7.

Our master workflow will partition the drive in a way, which will allow us to install Windows 7 after the successful installation of Lion.

The Deployment process

Once we have the server setup we can turn our attention to the deploy admin utility and begin the deployment process.  The deployment process itself couldn’t be simpler.  Much the same as MDT 2012, we will boot to the netboot image and select the workflow we want to run.  Once we click the play button, the workflow does its thing and requires as much interaction from the user as defined in the workflow configuration.

Before delving into that, we’ll have a look at how to create a Deployment server.  The instructions for setting up and configuring the server have been influenced by the instructions within the DeployStudio manual, which is referenced at the end of this document.

Configuring the server pre DeployStudio

DeployStudio should be installed on a server platform; any form of Leopard or Lion will suffice.  We will be making some changes to the services running on the server.  To do so, open Server Admin.

DeployStudio, DS, doesn’t work well across subnets so you need to ensure that the server you are installing to is on the same subnet as the machines you will be deploying to.  You need to ensure you have a static IP and if the server itself does not have DNS running, then it should have knowledge of the appropriate DNS server.

Only AFP and Netboot services need to be configured, OpenDirectory can also be configured but is not a requirement.

AFP, Apple File Protocol, allows us to share images scripts and files across the network.  All we need to do with this service is ensure that Guest access is set to default and then start the service.

We cannot configure the Netboot service until we have created a netboot image, but we will discuss what has to be configured here.  With Netboot selected in the left hand pane, select Settings>General.  Check Ethernet, ensuring that you select the correct Ethernet port if you have multiple Network ports on your server.

Netboot Settings from Server Admin

Netboot Settings from Server Admin

From the bottom of the main window, check off the image and data locations.  Ensure that you SAVE NOW, as you won’t be able to complete the following step if you haven’t done so.

From the tab along the top of the main window, select images.  Verify that the netboot image that you created using the DeployStudio Assistant is visible.  Select it, save and start the service.

From Workgroup Manager, create a deployment admin account.  This is the account that will be used to login to the netboot image and run the workflows.  It is important to ensure the password is very secure as with any admin account.

Back on the Server admin, we need to ensure that the admin account just created has correct permissions to the Public directory as this is where the DeployStudio repositories will be stored.  To do this, select the server from the left hand pane and choose File Sharing from the top of the main window.  Select share points and then select Public.  Under the Permissions section of the window, use the + button to add the newly created deployment admin account to the permissions manager.  Ensure that the admin has Read & Write permissions, save and exit.

Setting the permissions for the Deploy Admin account

Setting the permissions for the Deploy Admin account

With public still selected, click browse and then New Folder and call it DeployStudio.

Installing and configuring DeployStudio

Download Deploystudio from here:  Once you have it downloaded, go ahead and install it.

Once installed, open DeployStudio Assistant which can be found in /Applications/Utilities.  From the list of options, select Setup a DeployStudio server.

DeployStudio Assistant

In the next window enter the server address followed by the port number, which will look something like this:  <– Default port number.

The username and password will be the account that we created in the last stage, the deployment admin user.

In the next window select whether this server will be a master or a replicator.  Select the appropriate option and move onto the next screen.

This window is for the repository settings.  Ensure that you select Network Sharepoint so that the repository is accessible throughout the network.  Continue to the next screen.

Create the path to the repository, which if you followed the instructions when configuring the file sharing settings for the server, will be under Public.  The syntax for this field will look similar to this:


Enter the username and password for the deployment admin account and continue on to the next screen.

Unless you require email notification, you can skip past this screen.

The network security window; ensure that com.deploystudio.server is highlighted from the drop down menu.  Select the appropriate interface for your setup and leave the port number as the default 60443.  Verify that the Reject Unkown computers box is UNCHECKED.  Continue to the next screen.

This is the user group window.  If you require more stringent security settings, you can only allow access to specific user groups.  These groups must be created in the Workgroup manager although users can be added to the groups at any time.  Continue to next screen.

This screen allows you to enable or disable Multicast.  Even if your network is incapable of working with multicast, it is not advised to disable it at this point as you will not be able to change it at a later date.  It’s best practice to leave this enabled.  Continue to update the server settings and hit OK when the process is complete.  The server has been configured, next up is the creation of the netboot image.

Creating a netboot image

Launch the DeployStudio Assistant and select Create a DeployStudio Netboot set from the menu.  Read the service information window and continue to the next screen.

Netboot Creation Window: Name the image

Give the system a sensible name, UID, Language and time server.  Continue to the next screen.

This windows allows you to specify a particular server to connect to as priority, along with an alternative – if you were to have a master and replicator DS server.  The syntax this takes is as follows:

The authentication screen allows you to enter a default username and password for logging into the netboot image.  Be warned that entering a default user and filling in the password field means that any time the netboot image is loaded, these fields will be pre-populated and the operator will be able to launch which ever workflows they wish.

To get around this, you can simply disable the netboot service from the Server Admin tool.  This is the advised approach regardless of pre-populating the user and password fields.

There is also an option here for a VNC username and password.  This is here so that admins can remotely connect to the netbooted client and view the status of the deployment.

Once you have made your choices here, move on to the next screen.

The options window allows you to select what extras you want to include into the netboot image.  Some package installers require the use of Python or Ruby so it may be an idea to include those in your image.  Make your choices and move to the final screen.

It’s important to leave the destination location as the default:

/Library/NetBoot/NetBootSP0  <– that’s SP zero, not an O.

If the location doesn’t already exist it will be created.  Click continue and that’s the netboot image complete.

##Important:  Once the netboot image is ready you will need to start the netboot service from the server admin.  This process was described in the previous section; Configuring the server pre DeployStudio.##

An overview of the DeployStudio Admin tool

The DS Admin tool allows us to create the workflows, which we will use to deploy Lion, packages, scripts files and folders, etc. to our client machines.  Down the left hand side of the utility we have various tabs.

Clicking on Activity will display currently running workflows, their progress and client name.

The Computers tab shows the known computers to the DS, this list can be pre-populated by use of serial number or MAC address.  The advantage of this being that we can assign computer names, IP addresses and other things to specific MAC addresses/serial numbers.

The workflows tab will be the most frequented tab of the utility.  This is where we can create our own workflows, as depicted in the below screenshot:

An Overview of the DeployStudio Admin tool

The featured workflow in the screenshot is fairly complex, partitioning the disk, installing the OS, copying files, installing software, and finally running the software update utility when the system boots in for the first time.  We will look more at building workflows in a later section.

The Masters tab lists the captured and ready to be rolled out Lion images.

The Packages tab details all of the packages that have been uploaded to the DS repository.  It also lists any package sets that will install multiple packages in the one shot.

The final tab, Scripts, displays all of the stored scripts in the DS repository.  It also allows for you to create your own shell scripts for deployment.


The master workflow that we will be using contains a partitioning step, which will ready the drive for the installation of Lion and Windows 7.  It is important that Windows 7 is installed last.

By default there are a couple of workflows already created.  Some of these we will use; some of them can be removed from the list.  The ‘Create a master from a volume’ is the workflow used to capture a Lion image on the target machine, which will be used as the master base image of which will be installed on all Macs.  This is ready to go right out of the box and requires no adjusting.

The recovery workflow is a custom one I made that will reinstall a working thin Lion image.  Most useful when testing software installs and needing a fresh image without any software pre installed.

To create a new workflow, have the workflows tab selected in the left pane and then click on the plus symbol in the middle pane at the bottom of the window.

To add new tasks to the workflow, click on the plus sign next to the text ‘drag tasks here’.  This action will open a third pane to the right of the central pane.  This pane shows all of the tasks that can be added to a workflow.  Some examples of these tasks would be install a package, restore an image, create an image, partition a disk and so on.

The documentation for DS is pretty extensive so I won’t go into too much depth here, we’ll just look at a few of the main tasks that can be incorporated into a workflow.


As the title suggests, this task will partition the drive.  You have the choice of customizing the partition yourself but the task comes with some default options.  For example, you can format the drive for a single Mac OS installation or you can set it up for a dual installation of Mac and Windows or even a triple boot Mac, Windows and Linux!

Adding the Partition task to a workflow

When choosing a dual or triple boot partition using the sliders, you can easily adjust the size of each partition.  Mousing over the partition will display a pencil icon in the upper right corner of the partition which allows you to edit the title of said partition.

From the screenshot above you will note a couple of other things.  The first is that you have the option of choosing the target disk for this action to be performed on.  To fully automate the deployment process, it can be a good idea to change this from ‘user selected’ to first available disk.

The second item to take note of is the check box at the bottom of the window labeled ‘Automate’.  Checking this box will automate this step and require no interaction from the user.


This task restores an image to a partition.  As you’ll see below, there are many options for configuring on this task.

Adding the Restore task to a workflow

From now on, the target volume can be set to ‘previous task target’.  We need to select the type of file system the image was created in, usually HFS and then obviously select the image to be used.  These images, or masters as DS refers to them as, are the images that would be captured using the default ‘Create a master from a volume’ workflow.

The rest of the options are pretty self-explanatory.  We can change the name of the volume if we want to, but seeing as we named it something sensible in the previous Partition task there is no need to rename.  The only option I changed here was to uncheck the recovery partition checkbox, as we are unable to work with multicasting.

Ensure that the automate checkbox is ticked and move on to the next task.

Hostname Form

This task is optional.  It allows you to name the machine.  If you have prepopulated the computers tab within DS with either the serial number or MAC addresses of the Macs then when this task is displayed, the name given in the Computer tab will already appear as default name.

Unfortunately you are unable to automate this task.

Package Install

As the name suggests, this task is for the installation of software packages.   You can either install singular packages or use a package set to install multiple items.

This task is fairly straightforward.  As with every other task, select the drive you wish to install the software to and then select the software item or the software set to be deployed.  As you can see from the screenshot, you have the usual check box for automate, and a second one for postponing the item/set until the first boot.  Selecting this check box will copy the installers onto a temp directory on the local disk and will invoke them upon the next reboot.  You also have a check box to ignore failures, this can be useful if an item installs but has some loss of functionality due to lack of Internet connection or user interaction.

Adding a Package to the workflow

To create a package set select the Packages item from the left hand windowpane and click the plus sign from the bottom of the pane.

The packages tab from the DS Admin tool

You can now add packages to these sets by dragging items from the main packages tab and dropping them on the name of the set you wish to add them too.  We’ll look at how to add software to the DS server in the section titled Repositories.


By default, the DS repositories are stored in /Shared Items/Public/DeployStudio/.

The repository directory

This is where we need to place items that will be used within the deployment.  There are a few folders to take note of; Packages, Files and Scripts.  These all link back to the DS Admin tool we just looked at.  To import software we need to have the .pkg/.mpkg’s stored in the packages folder.  Similarly, if we want to use the scripts or the copy files tasks in our workflow, we’d need to have the files and scripts located in the appropriate folders.

Installing Windows 7

We will be using MDT 2012 to install Windows 7.  I have created a specific Windows to mac Task Sequence which runs much the same as any other TS.  The TS runs a diskpart command which tells setup to install to the third partition as Mac uses the first.  The only other change to note here is that the Bootcamp drivers could not be deployed conventionally as Out-of-the-box drivers, but were instead deployed as an application.

Apart from these two modifications, the roll out is the same as any other.


DeployStudio has a very detailed guide that includes walkthroughs.  It can be found here:

Replacing Screen inverter in an HP Pavillion dv2500

This week I have been looking at an HP Pavillion dv2500 that had an intermittent backlight.  The backlight would flicker on if you opened and closed the screen, leading me to believe it was the LCD inverter cable that sits in the hinge of the screen.  After taking the laptop apart and replacing the cable the problem persisted.  The only solution remaining, aside from replacing the screen, was to swap out the actual inverter board.  A fairly simple process:

1.  Remove the screw covers on the laptop lid, and then remove the screws.

2. Using a credit card or something similar, snap open the lid.

3.  Remove the lid, exposing the screen and the inverter which sits between the hinges underneath the screen.

4.  Unscrew the two screws to the left and right of the board, and unplug the LCD cable and power lead.

5.  Replace the inverter board and reassemble the laptop.


Sorry for the lack of photographs in this post, I had to do this job in a rush.