Mythical(?) double-compression, and syntax question

[Allister Banks]

This isn’t exactly InstaDMG specific, but more focused on the final deployment steps, so I hope this is an agreeable forum to post in:
I overheard somewhere a hint that after prepping a deployment image, compressing the asr-ready dmg a second time(through an unspecified method) results in a somehow more optimal restore image. I’m wondering if anyone was able to confirm/deny the benefit, and if it does help, how one may go about accomplishing the second compression(supposedly the “image from folder” option in Disk Utility removes(vacuums?) free space, so maybe it’s some variation of that.)

Also, I thought I might share the command I run when restoring an image locally, to contrast with the options DeployStudio uses:
[code]
asr restore –source /OutputFiles/10-01-09.dmg –target /Volumes/RestoreMe –erase –verbose –noprompt –buffers 1 –buffersize 32m –puppetstrings -noverify
[/code]
whereas DeployStudio omits the buffering section, but tags on 2>&1 to the end of many lines, which I can only assume is denoting targets in bash?

I’m hoping someone could be so kind as to enlighten me and explain why what I’m using works. Does the buffering options directly relate to cache on the source and destination HD’s?
I was a staunch advocate of NetRestore until being kindly told to move on, and DeployStudio has a lot more overhead to set up and run locally on an external firewire service drive, so this has been serving me well since.

Thanks for your time and attention, I would be more than happy to post any follow-ups to this question on the MacEnterprise Deployment and ACN mailing lists.

Allister Banks

POINT
http://www.pointconsultants.com
646.502.4708
368 Broadway Ste. 303
New York, New York 10013

[larkost]

Other than the redirection of stander err to standard out (2>&1) the caching bit is all covered in the asr man page. Please read that. Then you want to read up on bash output redirection.

I know nothing about needing to run asr across an image a second time. I did read a hint of this over on the DeployStudio site, but suspect that they are being bitten by a problem in hdiutil’s method of creating images with 10.6 that SIU has also been choking on. There is something about the size of the resource forks (due to compressed data in there) that it is choking on in some step. I suspect that this is the real cause of DeployStudio’s woes. Somehow the path that InstaDMG takes has proven to be a both a bit faster than SIU’s, and immune from this particular problem.

[Author]

Posts