Uncompressed instaDMG images?

[chops]

I use DeployStudio for deployment, creating a base image using InstaDMG and following that in the DS train with the various combinations of packages I must deploy. For some reason my 10.6.4 base image going out to 2-year-old aluminum iMacs is causing a load of XDBG request errors. I have rebuilt the image a few times and re-scanned it with htiutil and asr, and messed with data rates, all to no avail. My network guy says the routers think everything is going quite well. Hmm.

The kicker is that only the base image has troubles. Once the packages start rolling everything is fine. And the iMacs boot too, though some of them are behaving strangely. Sooooo I read on the DS forums that non-compressed images write more smoothly to the clients. Sounds good, since it does seem like compression might be an issue on the client side, and I have disk space to spare on the server. Problem is, I can’t find a way to create an uncompressed, virgin (never booted) image.

Am I missing something? Does InstaDMG do this? If not, does anyone have any more ideas to throw my way? I’m supposed to start deploying on Monday and this isn’t going well at all…

Thanks in advance…

[chops]

So it’s Saturday and here I am. I decided to try to create my image differently, the InstaUp2Date way. Tried to checksum my custom pkgs (three createUser and the ClearReg) and got this in the terminal:
[code]sltools:InstaUp2Date chop$ ./checksum.py /instaDMG/InstallerFiles/InstaUp2DatePackages/* > checksums.txt
Traceback (most recent call last):
File “./checksum.py”, line 71, in
progressReporter.update(taskMessage=dataLine)
File “/instaDMG/AddOns/InstaUp2Date/Resources/displayTools.py”, line 105, in update
self.outputChannel.seek(lengthToOverwrite * -1, 1)
IOError: [Errno 22] Invalid argument[/code]
I’m using instadmg 384 in SL 10.6.4 on an iMac Intel Core 2 Duo.

Neglecting the home and family for yet another weekend… 😕

[dead2sin]

[QUOTE][u]Quote by: chops[/u][p]So it’s Saturday and here I am. I decided to try to create my image differently, the InstaUp2Date way. Tried to checksum my custom pkgs (three createUser and the ClearReg) and got this in the terminal:
[code]sltools:InstaUp2Date chop$ ./checksum.py /instaDMG/InstallerFiles/InstaUp2DatePackages/* > checksums.txt
Traceback (most recent call last):
File “./checksum.py”, line 71, in
progressReporter.update(taskMessage=dataLine)
File “/instaDMG/AddOns/InstaUp2Date/Resources/displayTools.py”, line 105, in update
self.outputChannel.seek(lengthToOverwrite * -1, 1)
IOError: [Errno 22] Invalid argument[/code]
I’m using instadmg 384 in SL 10.6.4 on an iMac Intel Core 2 Duo.

Neglecting the home and family for yet another weekend… 😕 [/p][/QUOTE]

Does it work on a single package?

Also, SVN shows that the latest version is 334. Where is the 384 number coming from? I tested using checksum.py on a single file and a whole folder using the latest SVN and it worked.

Nate

[larkost]

There are two completely separate issues here: 1) You are trying to solve a problem you are having broadcast-deploying an image by producing an uncompressed image 2) You are having trouble checksumming a bunch of items at once and re-directing the output of checksum.py to a file.

Another issue seems to be that you mis-typed rev334 as rev384. Since rev334 is the newest revision in the svn repository, and I only have a few modifications on my computer that will become rev335, I think that this is a safe assumption. If I were you I would make sure to cd to the root InstaDMG directory (and I don’t know why you have it as a directory at the root of your drive, I just have mine in a sub-folder of my home folder), and then ‘svn update’. I am just suspicious that there is something wonky with your setup.

So, now to the two points:

1) At this point InstaUp2Date is just a way of driving InstaDMG. If InstaDMG can’t do something, then InstaUp2Date can’t either. Eventually InstaUp2Date will subsume InstaDMG, but then I will just start calling it InstaDMG. But that is still some ways away. And while I would encourage you to use InstaUp2Date, it is not going to change the compression method on the output file.

So, making the huge (and I am skeptical of this) assumption that going with an uncompressed image is going to solve your problem you have two options:

a) Take the output image you already have, and use Disk Utility (or the underling command line utility) to convert the image to a “read-only” image, then re-scan for ASR.

b) Change the lines in InstaDMG that dose the conversion to a compressed image to be only read-only. The line for this in rev318 to the present (I have not been working on that file in a bit) is line 1167 (and probably 1170 for good measure) and the bit you are looking to change is “-format UDZO -imagekey zlib-level=6”. For a simple read-only image it would become “-format UDRO” (note that there is no ‘-imagekey’ for that.

But I suspect that there is something else going on here, and that you are not yet on the trail of your real problem.

2) The reason I suspect that there is an issue with your setup is that I can’t reproduce the issue you are reporting. Up till now I had never tried using a globed input to checksum.py (the * in ‘instaDMG/InstallerFiles/InstaUp2DatePackages/*’), nor had I tried redirecting output of checksum.py to a file. But I just did so with both my working version (in-development), and a rev334 checkout I just did. Both are working perfectly. I am at a loss as to what could cause that issue. Try without the globbing, and without the redirection and see what you get. Of course there is a current issue where tabs are a bit problematic when going to the terminal (they work fine going to files, and my output for a large glob shows that), so you have to replace the tabs in that case.

But remember, you are using svn to pull down the latest version, ie: the bleeding edge. I don’t promise that the latest version is anything like stable. I try to always make it the best version, but I am just putting in automated tests now, so there is still a lot of ground that is not covered.

[larkost]

While it is somewhat orthogonal to this conversation, since you are going over the network and it seems using broadcast. I do have a new bit of code in the repository that will take a dmg as input and do a whole bunch of tests on it to see what settings would get you the quickest local restore. It is in preview mode right now as I still have some more data I want it to collect, and I have to automate the collection of the data. The new tool is in rev336, and it is at AddOns/InstaUp2Date/dmgRestoreProfiler.py. The help on it should tell you everything you need to know.

[Author]

Posts