New user of InstaDMG -> General questions.

[ryse]

Hi All,

I am a new user of InstaDMG, so bare with me on the n00b questions 😀

Our goal was to create one BASE(Vanilla OS – No Packages) image for all Mac’s which support 10.5.. We accomplished this by creating a workflow using Apple’s System Imaging Utility. We used the 10.5.4 Retail DVD as the source. This method was using “Net Install.” ( It runs the installer over the network ) .We decided to move away from the tool when we noticed that it was not as granular as we would have liked it. This is where InstaDMG came into light. It provided the modularity we were looking for. We pushed out the new ASR Image which was outputted by the tool and were surprised to watch the machine just boot up. We figured it would run the full install just like the Netinstall method…

1. I thought that the purpose of doing the “Net Install” method was so that during the actually install it would be able to detect the model it was running on and install the correct drivers etc. Will deploying the ASR image created by InstaDMG work for all models as well? We dropped this down on a Power PC model and Intel Model and it worked fine and noticed during the InstaDMG process it actually copies the base system over the the ASR image it creates. I Understand that technically it is a BASE OS which was never booted, but I’m confused on where the hardware detection comes in? Does this happen on first boot? Could someone please shed some light on this for me…

2. Does it matter which Machine the InstaDMG process is run on? I noticed the following code in the script which makes me wonder..

[code]
# Format the DMG so that the Installer will like it

# Determine the platform

if [ “$CPU_TYPE” == “ppc” ]; then
log ‘Running on PPC Platform: Setting format to APM’ information
/usr/sbin/diskutil eraseDisk “Journaled HFS+” $DMG_BASE_NAME APMformat $CURRENT_IMAGE_MOUNT_DEV | (while read INPUT; do log “$INPUT ” detail; done)

elif [ “$CPU_TYPE” == “i386” ]; then
log ‘Running on Intel Platform: Setting format to GPT’ information
/usr/sbin/diskutil eraseDisk “Journaled HFS+” $DMG_BASE_NAME GPTFormat $CURRENT_IMAGE_MOUNT_DEV | (while read INPUT; do log “$INPUT ” detail; done)
else
log “Unknown CPU type: $CPU_TYPE. Unable to continue” error
exit 1
fi

[/code]

Thanks in advance!

[larkost]

Welcome to the fold!

First off I will mention that you might want to look at my InstaUp2Date (included in the InstaDMG distribution), and especially at the vanilla.catalog file. With it and a 10.5 DVD image you can pretty quickly have a vanilla image that has most of the latest updates (I am a little behind right now). It will still boot to the first-run path (video with sound, first time registration , etc), but now will be very close to being up-to-date.

Now on to some direct answers:

1) At this point there is little to no differences on what is installed by the installers based on what hardware it is running on, especially if you are using “Retail” disks like you are (which is highly, highly encouraged). There are a couple of clinkers: if you don’t have a DVD drive the DVD player won’t be installed, and some of the newer MacBooks/MacBook Pros have videos showing how to use the finger swipes that are not included in either the retail disks or the updates. So the install that we capture in InstaDMG will run virtually everywhere (that that version of the OS supports).

MacOS X itself takes care of loading the appropriate drivers at boot time. It then caches this for faster subsequent boots. But there is no driver nightmare like there is on the Windows side: every MacOS X install supports all of the hardware that that version supports. This is why you can make external FireWire drives that will boot all of Apple’s current hardware (there is a minor trick to this, more on that later), or move a hard drive from one computer to another.

That being said, that there are certain things that get made specific upon the first boot, but this is less machine-specific and more randomly generated IDs. If you then copy a computer after first boot these can come along for the ride and get in the way in odd corners. InstaDMG avoids these nicely.

2) I would run the InstaDMG process on you latest computer for 2 reasons: The first is that newer computers have faster and larger disks than old computers and InstaDMG is hungry for both disk speed and space. The second is that later computers have newer hardware, the specific example of this would be a DVD drive. If the installers don’t detect that then they don’t install the DVD Player. The is a binary decision, and it does not matter what DVD drive you have. Who knows how this might change if Blueray ever gets included in Macs….

And the bit of code that you found is due to a peculiarity in the Installer DVD code that apple has written. If it is running on Intel hardware then it will only install to a GPT format drive and if it is PPC it will only install to Apple Partition Map drives. This does protect PPC hardware that can only boot APM, but it is a bit odd for Intel hardware since it will boot from partitions on either format (or even Microsoft’s MBR format).

This leads me to the note from above: if you want to create a FireWire drive that will boot both PPC and Intel hardware then the format needs to be APM (PPC limitation). If you have a PPC machine handy you can make this easily and it will just naturally boot Intel computers (assuming the version of the OS supports that hardware). If you want to create the drive from an Intel computer then you are left with two options:

– Hack up the installer to bypass this little bit of code. I have seen this done and it works fine from that point on

– Install the OS to a GPT formated drive, then copy (block mode) the volume to your FireWire drive.

InstaDMG of course can help you in this by creating a block-copy-ready image that you could then push down. Just to emphasize this: the only difference between the two installs is the disk formats, the volumes on those disks are identical.

[ryse]

larkost – Thank you for your in depth response! 💡

I am pleased to be a apart of the instaDMG community. You and your team have truly done a great job.

I took your advice and looked over InstaUp2Date -> This looks like a really nice add on. The theory of having a catalog file for different imaging scenarios, with nesting capabilities makes a lot of sense. That same theory is exactly what we are working towards, although we are going to store these packages out on a server (software repository). This repository will be broken up into different categories and based on the machine name it will determine which software packages to provision into the vanilla image after it is laid down. This leads me to my question… Is there a particular reason why both instaup2date and instaDMG are including the packages inside of the outputted ASR Image VS storing them out on a server? In a large deployment scenario with multiple sites it would be quite the task to build out and maintain different images based on all of the different software requirements for a large organization. It would be easier to build and maintain these catalog file’s in a central spot. Just a thought..

Thanks again for answering my previous questions…

[larkost]

I am not sure I completely understand the direction of your question, so I am going to try two approaches to answering it:

1) With InstaUp2Date you can feel free to store both the .pkg containing dmg’s and the catalog files on a http server, you just have to make sure that all the references in your catalog files are of the http variety. InstaUp2Date will pull all of the packages down locally into the caches as I was not sure how much I wanted to trust the network connection with such a big burst of information. This is one of the decisions that I am going to review for the next round. I think that the checksum issues can be dealt with. But I deliberately made sure that catalog files could be used remotely with the idea in mind that there could be central places to get the vanilla catalog.

2) The output of InstaDMG is ready for ASR restore, and that takes about 14 minutes with my base image on an iMac (7 to restore, 7 to verify). Anything that involved also putting custom packages on afterwards really belongs in a deployment system, and InstaDMG is not one of those. It only produces a “base” image. We do take the idea of what can go into a “base” image a bit farther than most, but it sounds to me like you would be well off to pair InstaDMG with something along the line of [url=http://www.apple-scripts.com/?q=node/5]PKGImage[/url] (note: this is not a endorsement, I have never used the product) as your deployment tool.

[Author]

Posts