Get info at image time to use during first boot

[ehemmete]

I am working on a Casper Imaging workflow. I have a login item that runs and prompts the installer (technician) for the proper time zone, the domain to bind too, and the appropriate OU for the computer account. This is written to /tmp/detailsForCasper.txt. Then in my main imaging configuration, I have a copyDetails.sh that copies the file from /tmp to /Volumes/Macintosh HD/Users/Shared where it is referenced by a first boot script that sets the time zone and binds the system.
This all works well if the target drive is named Macintosh HD, but fails if it is named something else (rare but it happens). Does anyone know of a way to get the target drive value from Casper Imaging? $1 doesn't seem to work in this situation.

[nessts]

since this is a "login item" can we assume this is happening at the first boot?
if so, just use /

[gregneagle]

Expanding on nessts reply:

You say "it is referenced by a first boot script".
So that script should just reference "/Users/Shared/detailsForCasper.txt".

-Greg

[ehemmete]

Sorry, I guess I wasn't clear enough. The login item runs while booted from an external drive or netboot for Casper Imaging. I need the data in the first boot script though, so I am trying to copy the file from the external boot drive to the internal newly imaged drive.
Process like this:
1) boot from external Casper Imaging
2) query installer for details, write to /tmp
3) image internal drive
4) copy details to internal drive *** This is where the problem is. I can't guarantee that the internal is called Macintosh HD
5) reboot
6) first run script reads and uses details

Also I am doing it this way because I haven't been able to get SystemUIServer to display dialogs unless a user is logged in. So asking during first boot hasn't worked.

[nessts]

well here is another thought, since i don't know the answer to your question.
why not just make smart configurations for each possibility, and then have the user choose the right configuration to install, and then in each configuration have a specific package that sets the timezone and OU and whatever else you are setting? make the base configuration have everything else and the 2-n smart configurations have the one extra package that defines the necessary stuff, and make it simple, assuming that each timezone likely has a corresponding OU and there are not tons and tons of options.

[mm2270]

Todd's suggestion makes sense, but really only if it doesn't require dozens of different Smart Configurations. I had worked with someone at a company once that had literally dozens of OUs the Macs could be bound to, so creating a separate binding config in their JSS for each one, or even separate Smart Configurations in Casper Admin simply wasn't an option. And it was constantly changing, so they had to come up with something they could enter at imaging time, kind of like what you're doing.

So, let me ask, is the mounted drive for imaging always the same disk identifier? For example, if you do a 'diskutil list' does it always show up as, say, disk1s2 at imaging time? If so, try the following. Its a little kludgy, and it could break as easily as your original script if that disk ID changes-

theDisk=`diskutil info disk1s2 | awk -F"/" '/Mount Point/{ print $NF }'`

In my tests with a thumb drive that has spaces in it, it returns the full name. Same with a disk with no spaces. But you'd have to use that variable with quotes around it in your copy line or you could run into problems with the shell not escaping the spaces. So something like-

cp /tmp/detailsForCasper.txt "/Volumes/$theDisk/Users/Shared/"

[ehemmete]

mm2270 - thank you for the idea. I am under the impression that disk identifiers can change on each boot, but I will play with it and see what happens.
I am working for a client that has 5 domains and about a dozen OUs that Macs might go in per domain, so Smart Configurations won't work here, but thanks for the idea nessts.

[mm2270]

@ehemmete, yeah, its certainly possible they would change each time, which is why I said it could be as faulty as relying on the target volume being named 'Macintosh HD'

One thing I can think of is to build the script to grab all disk identifiers, minus any related to disk0 since that would be your boot drive (the external drive?) at imaging time. then use that to loop through each ID with a 'diskutil info' command and read something back to help pick the right volume. Maybe the format (hfs) or size of the disk - I assume any possible plugged in thumb drives wouldn't be anywhere near the size of your internal volumes. Or something else?

Of course another possibility is to just make sure you rename the target disk to Macintosh HD as part of your imaging. That way you don't have to mess with your existing script.

Can't really think of any other good ways to tell your script what the target volume chosen is.

Let us know how this all turns out after your tests.

EDIT: Actually, I'm incorrect. The internal volume seems to be listed under disk0 all the time, even when booted from an external volume. I just had to boot off an external for an imaging session and decided to take a peek and Macintosh HD is listed as disk0s2. Given that, it shouldn't be all that hard to locate the internal HD in your script.

[ehemmete]

Yeah, renaming the drive at image time seems to be the way to go. To bad Casper Imaging doesn't seem to have that built in.
There is a chance of having multiple internal drives, so I tried to put some logic into my script. It cycles through disk0 through disk5 and checks for a protocol of SATA and then prompts the user to confirm the disk found is the boot volume. I assume the boot volume is on slice2 of the disk.
Here it is if anyone wants to use it:

#!/bin/sh


# check for Macintosh HD
success="false"
hasMacHD=$(ls /Volumes | grep "Macintosh HD")
if [ "$hasMacHD" != "Macintosh HD" ]; then
# see if we can figure out which volume should be Macintosh HD
# assume that the internal drive should be Macintosh HD
# assume that slice 2 should be Macintosh HD
    for i in {0..5}
    do
    echo "Checking disk$i"
    if [[ "$success" != "true" ]]; then
        protocol=$(diskutil info disk"$i" | grep Protocol: | cut -d " " -f 21)
        if [ "$protocol" == "SATA" ]; then
            volume=$(diskutil info disk"$i"s2 | grep "Volume Name:" | cut -d : -f 2)
            rename=`/usr/bin/osascript <<EOT
            tell application "SystemUIServer"
                    activate
                    set buttonReturned to button returned of (display dialog "If $volume is your boot drive click OK")
            end tell
EOT`
            if [ "$rename" == "OK" ]; then
                        diskutil rename disk"$i"s2 "Macintosh HD"
                success="true"
            else
                /usr/bin/osascript -e 'tell application "SystemUIServer" to display dialog "Please rename your boot drive to Macintosh HD and try again"'
                exit 1
            fi
        fi
    fi
    done
fi

[mm2270]

The script looks good. Glad you got something working.

FWIW, I recall asking for a feature request way back to the JAMF team if they could make Casper Imaging a little more intelligent about how it selects the drive to image. The fact that the Config needs to know the name of the hard drive to work is kind of insane. Especially since products like DeployStudio have had the functionality to select 'first available drive' for years now. It doesn't care what the drive is named, but Casper Imaging does, or at least it used to. Perhaps that's been addressed, not sure.

And with a Pre-Stage imaging session you might think this would be a non-issue, but think again. We just got some brand new 13" Retina MacBook Pro's in and they had their hard drives named "Untitled 1" I thought I was seeing things, but they were both named that way. Apple may be getting a little sloppy, but the point is, if we got a batch of these in and threw them into a Pre-Stage image workflow they all would have failed b/c the drive wasn't named "Macintosh HD" DS on the other hand wouldn't have blinked and renamed them to Macintosh HD in the process.

Just sayin' :)