Are snapshots possible?

[dmgraham]

I’ve been creating and deploying images The Old Way, and am beginning to see the light. That said, I have a few images which are perfect as they are and would like to keep them but apply the new concepts moving forward. I tried using my existing image as a base but it continues to look for an actual OS X install disc instead. In addition to my current need, wouldn’t it be beneficial to allow for snapshot images so that we don’t have to continually install the same updates and patches every time we build an image?

[Patrick Fergus]

Both of your questions are asking for some sort of restore-from-ASR-image functionality. Josh probably has an opinion whether or not snapshots will be part of instaDMG.

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.

[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

[knowmad]

what you say makes sense, however (imo) I think it overlooks something.
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.

As for updates, order and necessity, its really not that hard nor that time consuming. I will post my screen grabs from my work process for figuring this out but…. Its really not bad at all.
My process:
Create my IDMG image using those updates I am certain of (like full point combo updates). Install to a ‘test’ machine, almost any will do. Run AU, screen grab the resulting list, maybe mark them all as download only, then run it again and let it install. Lather, Rinse, Repeat until there are no more.
Now you have screen grabs listing which items were installed in what order, and a folder containing all your downloads. Note and remove the hardware specific items from the list and your done.
I did the whole process once with 10.5.1 and once with 10.5.2 as starting points. Took a little less than 30 minutes each time. Between full point releases I simply note the new security fixes and add them as they come out. Usually they are rolled into the next combo update.

Reading this over it sounds like more work than it is, I cannot stress enough how surprised I was to find it really was a short and painless process.

If someone with far better programming skills than I were to either A) Automate the process including screen grabs and downloads, or B) Create a nice little program that simulates* the process and thereby speeds things up… that would be beyond cool…. but unexpected.

*By simulate I mean a program that contacts AU and tells it ‘this is a 10.5.1 machine with these updates installed, what’s next’… then lists those as installed and does it again and etc without having to actually install them in between or even really have a 10.5.1 machine to begin with. I know it can be done, I just don’t think it is worth the effort.

[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.

[Patrick Fergus]

I think the only time you’d really need to reassess the needed packages is when a 10.5.x release occurs. Otherwise, you can just run Software Update on a freshly restored machine, figure out the needed updates, and tack them onto your AppleUpdates folder.

When 10.5.3 is released, it will likely roll up security updates that are more than a week or two old. In that case, grab your retail CD and do a retail installation (or you could run instaDMG and remove all your AppleUpdates and CustomPKGs, and then restore that installation onto a drive. More work, but it will get you to the same place). Have the retail installation poll Software Update to figure out what updates are needed, install them, and repeat running Software Update until no updates are available.

Extra work? Yes. Time consuming? A bit. Does it beat spending eight or ten hours recreating your build to support new hardware? Heck yes.

I think that it might also make sense in the above process to apply the newest OS release (e.g. 10.5.3) [i]first[/i] and [i]alone[/i] and then run Software Update again. SU should be smart enough to handle the installation order and prerequisites (so you don’t download SuperSoftwareUpdate2008-001 along with 10.5.3 when SuperSoftwareUpdate2008-001 is rolled into 10.5.3 and unnecessary for separate download and installation), but you never know.

– Patrick

[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.

[knowmad]

[QUOTE][u]Quote by: dmgraham[/u][p]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.[/p][/QUOTE]

hmm, you may be right but so far… IDMG has created for me an image that loads beautifully (and runs nicely too) on every non-laptop (I have non to work with) I have thrown it at, from a 400mhz G4 all the way up to an 8-core mac pro, plus all the iMacs in between. If its working that well…. something tells me that my changes to base image will be minimal for hardware dependancies over time.

check out: [url]https://www.afp548.com/article.php?story=20080218214146959[/url] for another perspective of what a single image done this way will work on.

[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…

[knowmad]

using the most current is just a matter of making an image of the most current you have… pretty easy to do.

[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.

[Patrick Fergus]

Apple’s arrangement is as follows:

10.x.y Public release

10.x.y Computer specific release. This is the current case with Early 2008 MacBook Pros. This release includes drivers that aren’t available on the public release of 10.x.y, and you won’t be able to get this release unless you purchase the hardware. But if you don’t have the hardware, you shouldn’t worry about supporting it. You can make an InstaDMG build on a computer-specific release, and it [i]should[/i] work on all previous equipment. If you can wait, though, you can save yourself effort by waiting for…

10.x.y+1 Public release. This will roll up support for machine-specific releases of 10.x.y.

So let’s say you’re making your build on the first shipping Mac Pro (which supported Tiger). Six months from now Apple has released 10.5.5, and the newly introduced MacBook Helium is released with a machine-specific build of 10.5.5. When 10.5.6 is released, if you make an InstaDMG on your 2007-era Mac Pro with any starting point in the 10.5.x line (including 10.5.0 retail) and update to 10.5.6, you will have the current drivers needed for the MacBook Helium.

Thanks,

– Patrick

[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

[Patrick Fergus]

[i]> 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?[/i]

Just a combo updater.

[i]> 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]

I may slightly be misunderstanding the question, but I think you’re asking if Apple releases Mac OS X 10.5.2 and the Early 2008 MacBook Pro comes with 10.5.2, are they interchangeable? Likely not–the revision included with the computer is likely newer than the downloadable revision.

FWIW, here’s Apple’s relevant KBase articles:

What’s a “computer-specific Mac OS X release”?
[url]http://docs.info.apple.com/article.html?artnum=25784[/url]

Mac OS: What is a Reference Release?
[url]http://docs.info.apple.com/article.html?artnum=58070[/url]

Mac OS X: About This Mac “build” information (includes a list of reference release build numbers)
[url]http://docs.info.apple.com/article.html?artnum=106176[/url]

Mac OS X versions (builds) included with Intel-based Macs (includes a list of computer-specific build numbers)
[url]http://support.apple.com/kb/HT1159[/url]

[i]>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.[/i]

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.

When Apple did release a version of Mac OS X that was [i]not[/i] backward compatible, it was worth a KBase article:

Using NetBoot, Netinstall, ASR images with a MacBook Pro (2.4/2.2GHz) or iMac (Mid 2007)
[url]http://docs.info.apple.com/article.html?artnum=306051[/url]

Included in that KBase article is the firmest statement of backwards support I can find:

“If you have Mac OS X 10.5 Leopard, you can use the Leopard imaging tools to create a Mac OS X 10.5 image which is universal and supports all hardware that meets the minimum system requirements.”

– Patrick

[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.

[Author]

Posts