A word of warning - ASD OS tests are not currently designed to be run over NetBoot. In our testing we've seen several false positives and some tests (like NIC tests) even seem to hang. But considering the benefits, this is definitely something to try out and maybe even implement, once you know how to work around a few known issues.
Also, the EFI tests seem to work just fine.
The Workflow
We start by creating a NetBoot set from each ASD image using System Image Utility:
-
Mount the ASD OS image, launch SIU and add the devices supported by the test to the “Filter Computer Models” action.
-
Name the NBI by the test version (for example 3S145.nbi)
-
Mount the EFI ASD image and rsync the contents under the new NBI, i.e.:
# rsync -au ./Volumes/3S144\ ASD\ EFI/ ./3S145.nbi/efi -
Copy the NBI to your deployment server
The annoying part about this is of course having to do this on the same major OS version that's in the ASD image (which go back as far as 10.4 for 108 and 116). We have a machine with 3 partitions (10.4-10.6) set aside for this.
116 and 108
For some reason, the NBI created by 10.4 SIU will result in a kernel panic during boot. Even if you create the set on an Intel machine. Luckily the workaround is quite simple:
-
Create the NBI using SIU as usual (saved into /Volumes/nb/asd/3S116.nbi in my case)
-
Mount the original ASD 116/108 image (/Volumes/ASD\ Dual\ Boot\ 3S116) and then:
# cd /Volumes/ASD\ Dual\ Boot\ 3S116 # ditto mach_kernel /Volumes/nb/asd/3S116.nbi/i386/mach.macosx # ditto System/Library/Extensions.mkext /Volumes/nb/asd/3S116.nbi/i386/mach.macosx.mkext # ditto usr/standalone/i386/boot.efi /Volumes/nb/asd/3S116.nbi/i386/booter
Client & Server
A single ASD may support more than one Mac model which makes matching a machine with it's corresponding ASD a bit more involved. I chose to have a server-side script do the heavy lifting - it takes the machine's model ID as an argument and then scans the whole ASD NBI repository for each NBI's NBImageInfo.plist file for a matching string in it's EnabledSystemIdentifiers array, returning the NBI name, if successful. With this method, you don't have to make any changes to the client script — just keep adding new ASD images as Apple releases them using the workflow outlined above.
And what about EFI?
The client-side script accepts one optional parameter — “efi”. If set, this will change the bless behavior to set the boot file to the EFI test's boot.efi binary. The EFI tests seem to work just fine over NetBoot without any weird false positives so far.
Some older tests (namely 3S108 and 3S116) came as one big DMG, with the EFI and OS tests on the same partition. You have to do a bit more preparation with these. For example, to make 3S116 fit our workflow, I mount the image and then:
# rsync -au /Volumes/ASD\ 3S116/System/Library/CoreServices/.diagnostics ./3S116.nbi/efi
# cd ./3S116.nbi/efi
# ln -s diags.efi boot.efi
If you use DeployStudio, you can create 2 workflows — “Boot ASD OS” which runs asdbless.sh as is, and “Boot ASD EFI” which runs asdbless.sh with the efi parameter.
In closing, I have a feeling this will all be integrated into AST some day (it would just seem logical), but until that day comes, this method gives pretty good results.