[dmgraham]

[QUOTE][u]Quote by: macshome[/u][p]SIU creates NetBoot or Netinstall .nbi sets. InstaDMG creates an ASR deployment image.[/p][/QUOTE]

I realize that SIU creates the NBI structure, but there is an ASR-ready install DMG within it (i.e., /Volumes/NetInstall/System/Installation/Packages/System.dmg). Pulling this image out of the resulting NBI set would be trivial. Also, I wonder if a custom workflow could be created to customize the output.

I guess I’m just wondering what the reasoning was behind starting entirely from scratch rather than using what Apple supplied and just adding and/or modifying workflows.

[dmgraham]

[QUOTE][u]Quote by: Patrick+Fergus[/u][p]If you’re creating an image that has to support a particular machine where the computer-specific release is newer than the reference release, you are stuck building it on that hardware (such as the Early 2008 MacBook Pro at my desk whose sole function is to run InstaDMG to support deployment). Once the reference release is newer than the computer-specific release, you’re free to build on any machine that will run the reference release.[/p][/QUOTE]
Which is exactly what I’ve always done (thanks for validating this), although to be honest I never actually compared build numbers. To be on the safe side I’ve always rebuilt my images with whatever reference release from any significantly different new hardware. The difference is that now with IDMG starting with a new reference release is so much simpler than the old method of rebuilding the entire thing by hand.

Now as to the question of what the real differences are between [url=https://www.afp548.com/forum/viewtopic.php?showtopic=20253]InstaDMG and SIU[/url] with custom workflows.

[dmgraham]

So that I understand you correctly, when you are referring to the “10.x.y+1 Public release” are you referring to a combo updater or a new OS rollup which has been released to manufacturing for new retail DVDs? If you are referring to a combo update, does Apple have a policy of guaranteeing new hardware support in OS revs when nothing changed between the rev and when the machine-specific version of that OS originally shipped? I haven’t ever tested this theory since I’ve always just used the newest machine install disc for image creation, and would love to find out that this is reliable.

TIA!

– Dave

[dmgraham]

[QUOTE][u]Quote by: knowmad[/u][p]using the most current is just a matter of making an image of the most current you have… pretty easy to do.[/p][/QUOTE]

I agree, but was responding to your claim about “changes to base image will be minimal for hardware dependancies over time.” I don’t think it appropriate to push an image forward to newer hardware — although the reverse is nearly always the case — just because an image “loads beautifully”. My experience have given me a nearly opposite opinion on the matter; namely that changes to a base image will be a near certainty for hardware dependancies over time. Rarely does new CPU, chipset, graphic card or other hardware changes NOT necessitate a base OS image update (NB, obviously minor revs usually don’t have the same impact).

I’m simply trying to understand the best practice for maintaining [i]forward compatibility[/i] in an IDMG configuration.

[dmgraham]

[QUOTE][u]Quote by: Patrick+Fergus[/u][p] if you can obtain the same updates from Apple when Apple intentionally authored the package to work on any possible computer it might be installed on, you’ll cover any possible problems that might arise from moving your build to another kind of machine.[/p][/QUOTE]

That makes perfect sense. I’ll hope that I don’t run into any more standalone installer issues like the Admin Tools update, which I’ve reported already BTW.

Thanks!

[dmgraham]

I don’t think it’s enough that an image [i]boots[/i] for it to be correct. There may be drivers, kexts or other bits included in some newer hardware releases that boot with the universal image but don’t run reliably and/or suffer performance issues. Shouldn’t we be concerned with using the install DVD from the most current hardware release as our base OS? It’s either that or use some sort of directory compare utility to make sure we’re not missing important updated files…

[dmgraham]

OK, so I guess if I use a snapshot image I’m still going to have to remove the Apple updates and use SU to start from that point forward anyway. It’s likely not going to be materially different than removing all current Apple updates and dropping in a combo updater(maybe a few extra install packages). I suppose that does make sense, and should likely be included in the documentation which covers best practices for maintaining a clean list of Apple updates.

None of this applies to custom packages I think, which — for me at least — is the primary benefit to this imaging methodology. As my software requirements change over time I don’t want my customizations to [i]ever[/i] be included with my base image.

[dmgraham]

[QUOTE][u]Quote by: Patrick+Fergus[/u][p][i]Although I use a dry run through SU to figure out what pkgs I need, I use the standalone downloadable installers for the various Apple software updates.[/i][/p][/QUOTE]

The SU versions of the software are always the most current. For instance, if you download the current Server Admin Tools 10.5 from Apple’s downloads page it contains buggy and outdated automator actions for the System Image Utility. I wasted three hours of my time trying to find out why something was working only to discover that the updated actions are currently only available via SU

[QUOTE][p][i]Are you using the packages from SU (“Install and Keep Package”)?[/i][/p][/QUOTE]

Yep; well actually download only. It seemed to me the simplest method of making my image current so I don’t have to individually download each package, and because I can ensure that I’m getting the most current and applicable version of the updates based on [i]my[/i] image.

[dmgraham]

[QUOTE][u]Quote by: knowmad[/u][p]please define for those of us who don’t know…. what is SIU[/p][/QUOTE]

My apologies. The System Image Utility (SIU) is part of the free Server Admin Tools supplied by Apple to create NetBoot disk images and NetInstall configurations. It allows you to create custom workflows based on Automator which are quite similar to the options in IDMG except it’s entirely GUI driven.

For instance, you can start with an image of the install DVD and customize the packages, add user accounts, apply system config settings (e.g., directory services, computer name, etc), enable automated install, add packages and post-install scripts, partition/erase the install volume, etc. In fact, some of the items which feel a bit kludgy with IDMG like adding user accounts is a five-second operation with SIU. It seems to me that the time spent developing IDMG could be better spent on enhancing or adding to the SIU automator actions.

I’m new to this so I’m sure there are some things I’m overlooking, which is why I’m trying to find out what the benefits are of each.

[dmgraham]

[QUOTE][u]Quote by: knowmad[/u][p]One of the major reasons for doing things the InstaDMG way is avoid having the system tied to specific hardware, as well as avoiding all the extra stuff that is auto created on first boot/login/etc. If you used a snapshot, you would lose those benefits.[/p][/QUOTE]

I don’t think so. Your post is based on limited maintenance from 10.5 through 10.5.2. If you were able to support all your hardware through a 10.5.11 version lifetime I think you’d change your mind. In fact, that’s pretty rare since the need to support new hardware will force you at some point to start with a new base OS, which is in fact a snapshot in and of itself.

[dmgraham]

[QUOTE][u]Quote by: Patrick+Fergus[/u][p]iTunes installed via instaDMG works for me–what errors are you getting?[/p][/QUOTE]

Recent QuickTime, Front Row, and iTunes updates via SU download multiple packages in a format I’m not used to.

For instance, iTunes comes in a folder with a iTunes.dist alias whose original is in a Packages folder along with three pkg files.

iTunes/
iTunes/iTunes.dist
iTunes/Packages/
iTunes/Packages/AppleMobileDeviceSupport.pkg
iTunes/Packages/iTunesAccess.pkg
iTunes/Packages/iTuensX-7.6.2.dist
iTunes/Packages/iTunes.pkg

Looks like InstaDMG ignored the .dist file, and I’m not really sure if it’s an essential file or not, so I wasn’t clear about just installing the remaining packages separately. Interestingly enough, if you download iTunes 7.6.2 from the Apple site it comes in as an mpkg, which should work, right? It’s a lot easier to download new updates by running SU form the last OS build so I can update my InstaDMG config.

[dmgraham]

[QUOTE][u]Quote by: Patrick+Fergus[/u][p]I know that the longest part of my instaDMG process is the ASR scan, which wouldn’t be helped with a snapshot. But, I’m not installing bunches of custom software either.[/p][/QUOTE]

It’s not so much the length of time it takes to build the DMG, but mostly for clarity. For instance, newer Apple updates replace older ones, but it’s not always clear which ones. In the case of an OS update, it’s very clear that the 10.5.2 combo update replaces 10.5.1, but does it also replace other security updates? I’m guessing that it will be a chore to keep the install packages accurate and in the proper order after 10, 20, or 30 or more updates. It would seem to make sense at some point to draw a line in the sand and move forward with an AppleUpdates folder unencumbered by prior security updates, patches and OS updates.

– Dave

[dmgraham]

[QUOTE][u]Quote by: macshome[/u][p]I suppose you could do it that way so that there are less packages to keep track of, but really it doesn’t matter much since we are applying them in an automated way.[/p][/QUOTE]

It sure would make it easier since Apple updates are often distributed this way. For instance, I tried to drop in the iTunes 7.6.2 update from Apple but it didn’t work. Any pointers?

[Author]

Posts