ASR restore and other musings

[TrekSide]

I knew there was a better way to make consistent images. And now I found InstaDMG.
Big Thanks to all the people who have provided information here. Truly amazing: I’m totally new at this,
but I have managed to create working (basic OS) images in my first week of playing with InstaDMG,
by using the information in this forum. I am still a noob at this, but will do some more research. I’m glad
that the main InstaDMG script is in BASH, since I can [barely :)] get around in that. If/ when it changes
to Python: I am apprehensive about having success learning a new language.

I’m using
MacBook Pro 15″
SATA ExpressCard with multiple SATA drives
Booted from 10.6.2, creating 10.6.0 and 10.6.2 images

I’ve configured the InstaDMG paths so that most items are pointing to a different drive and SATA
busses, and I get tremendous speed for testing. Installer dmg and patches on one drive (referenced
via symlinks in the BaseUpdates folders), output folder on another drive and SATA cable, scratch
space on another drive.) Good stuff.

# -b Look for the base image in this folder (./InstallerFiles/BaseOS)
# -c Look for custom pkgs in this folder (./InstallerFiles/CustomPKG)
# -l Set the folder to use as the log folder (./Logs)
# -o Set the folder to use as the output folder (./OutputFiles)
# -t Create a scratch space in this folder (/private/tmp)
# -u Use folder as the BaseUpdates folder (./InstallerFiles/BaseUpdates)

I haven’t been successful with the -I option, and don’t understand what it does; -b seems to be the same to me.
I don’t understand what -J does, but maybe something to do with InstaUp2Date
I don’t understand what -K does; -c seems to be the same to me.
I don’t understand why both -b and -c exist. Maybe it’s for organization. I keep thinking one folder (with
numbered subfolders) for all the packages would be sufficient. Hmmm.

Here are some changes I’ve made for *my* workflow:
(I don’t want to make too many changes, of course: I don’t know how I will be able to migrate my changes to a
newer version of InstaDMG)

—–
I’ve noticed that when I ran InstaDMG there was some comment (in the logs? Dunno) about suggesting to use
–noverify instead of –nocheck. Maybe –noverify doesn’t work on an older OS like 10.4 or something, but for
my purposes (10.6.2) I made the change to –noverify for fun.

Changed this line
[code] /usr/sbin/asr restore –verbose –source “${ASR_FOLDER}/$ASR_OUPUT_FILE_NAME” –target “$TESTING_TARGET_VOLUME” –erase –nocheck –noprompt | (while read INPUT; do log “$INPUT ” detail; done)
[/code]
To this
[code] /usr/sbin/asr restore –verbose –source “${ASR_FOLDER}/$ASR_OUPUT_FILE_NAME” –target “$TESTING_TARGET_VOLUME” –erase –noverify –noprompt | (while read INPUT; do log “$INPUT ” detail; done)[/code]

Wait. Read on. I have better stuff to say than that. 🙂

—–
When I restore the final ASR image manually and option-booted to the [startup manager], the disk that I want to
choose has the name: “EFI Boot”

I added a line to change the Label of the volume so that when I option-boot it already has the name I want.
I don’t need need to do this modification at all, really, since it automagically gets fixed on the second boot anyway.
But still, I like it.

Added this:
[code] /usr/sbin/bless –folder “/Volumes/Macintosh HD/System/Library/CoreServices” –label “Macintosh HD”[/code]

Before this:
[code] /usr/sbin/bless –mount “/Volumes/Macintosh HD” –setBoot –nextonly | (while read INPUT; do log “$INPUT ” detail; done)[/code]

I’m probably blessing the system twice, but I didn’t have success/ know how to smoosh my label info in with the
original/ existing line.
I also didn’t know what variable to use for the volume name, so I hard coded it “/Volumes/Macintosh HD”

—–
I love the automated restore feature (-w and -y). I just start the script and walk away. When it is done I’ve
already booted into the new OS for another test.

I changed the blessing line so that it wouldn’t change the boot OS permanently, and only changes to the new OS
for the next boot. I like InstaDMG to automagically restore to a partition and boot. When I’m done checking
whether my latest small change is working I only have to select restart, and my main computer goes right back
to the main OS for more configuring and troubleshooting. Just a few more seconds of thinking-time shaved off
for me.

Added the –nextonly option for the bless command, to the existing line
[code] /usr/sbin/bless –mount “$TESTING_TARGET_VOLUME” –setBoot –nextonly | (while read INPUT; do log “$INPUT ” detail; done)[/code]

—–
But I couldn’t get InstaDMG to bless correctly until I made another change.
The original line uses “$TESTING_TARGET_VOLUME”. For my situation that appears to contain
“Volumes/EraseMe” (-w option)

But that volume name doesn’t exist anymore after the automagic ASR step. ASR has renamed the volume
“EraseMe” to “Macintosh HD” during the ASR process (because I use the -n option set to “Macintosh HD”)
So I changed the blessing line a second time by hard coding the newly restored partitions’ name:
[code] /usr/sbin/bless –mount “/Volumes/Macintosh HD” –setBoot –nextonly | (while read INPUT; do log “$INPUT ” detail; done)[/code]

I also didn’t know what variable to use for the volume name [yet? :)], so I hard coded it “/Volumes/Macintosh HD”.

—–
While I’ve been learning the InstaDMG and making tweaks, image after image after image, I’ve disabled some
things to speed up image creation: (only during this initial learning time using InstaDMG. I will reenable the items
when I need a more serious image.)

So I’ve temporarily disabled features to decrease image-creation time:

I’ve disabled the repairPermissions
[code]# /usr/sbin/diskutil repairPermissions “$TARGET_IMAGE_MOUNT”[/code]

I’ve disabled the entire for-done section following this line for quick testing
[code] log “Correcting symlinks that point off the disk” information[/code]

I’ve not included the 10.6.2 combo updater, and with the other tweaks I can turn around an image in 10min.
Usually I’m fighting a typo in some launchd scripts and I just want to know “does my script work now?” 🙂

—–
I’ve tested adding multiple accounts. And hiding some accounts. And it works.
Except for the first boot. The first boot always shows all of the accounts. After that first boot, the correct
accounts are always hidden. I wonder if there is some way to inject some file to force the first boot to hide the
appropriate account names.

—–
I wish there were option-commands to turn on and off:
Symlink fixing
Permission fixing

I wish there was an option-command to change the path to where I want to keep the cached/intermediate image
(That cached image concept is such a cool feature, by the way.)

I still haven’t figured out how to install metapackages like Developer Tools, when there are a bunch of extra
packages that are in another folder.
I bet iWork will be tough too. Dunno, yet.

That’s my braindump from my first experience with InstaDMG. “That’s my story and I’m sticking to it.”
It is truly magical to create a consistent image, and have it auto-restore and boot.
Thank you so much for this free tool.

[larkost]

So there are a lot of point to cover, and I am not going to cover everything:

1) The “-I” (capital i) specifies a specific image to use as the base image. The “-b” option specifies a folder to look for the first disc image and additional ones. Think of the former as the “new style”. The “-J” option allows you to specify the other disc that you want open the whole time (to round out the behavior that was in the “-b” option). I don’t actually expect people to be using the “-J” option very much.

2) A similar story goes for the “-K” option. The old way of thinking is that the was the “BaseUpdates” folder (-u) and the “CustomPKGs” folder (-c), I am moving away from having these folder hard-coded and towards having an arbitrary number given in the order you want installed from with the “-K” option. InstaUp2Date does not yet drive InstaDMG this way, but I would like to get to that.

3) The “restore after build” code was rather leftover. Other than touching it when I changed variable names it was pretty much exactly as I inherited it, and I have never run it. I am not sure if anyone else has used it at all, as this is the first bug-report on it. Since someone evidently is using it, I just to a pass through it tonight and made a bunch of changes to it. As it happens the project that I am playing hooky from with these changes is all about restoring images, so my mind was already primed for it. If you wouldn’t mind running it to see if it works, as I am not setup for it, so the code is un-tested. It will probably be checked in as rev257. The two main fixes:

a) Changed to using the /dev/ entry for the volume you are restoring to. You can provide the volume as a mount point, as a full dev entry (/dev/disk0s2), or as a partial dev entry (disk0s2). It will sanity check that there is a block device there, and that it is not the current root volume. This should take care of

b) I changed the bless system to better handle things (such as using /dev/ entries), and putting on the label. I also removed the -nocheck altogether, as a little longer restore is worth the verification for things like this (you don’t want a disk error messing with you).

4) The best way to install the developer tools is to just download them from ADC, then use the dmg directly. Since everything is in the right place on the dmg it will be in the right place durring the install. I only look in the first level of a dmg for installers to make sure I can handle the dev tools. Note that my imaging needs have not included the dev tools for a while, so I am not sure that everything is kosher with that install on 10.6. You might want to include an InstallerChoices file to get things right for your environment.

5) iWork installs cleanly. It is iLife that has all the problems (needs chroot, the iLife Updates have bigger problems and need InstallerChoices files to work).

[Author]

Posts