[larkost]

It is there because the last time I did a from-scratch install of 10.5 that is the list and order of things I had to install. If you care to do a from-scratch install and record that it is not necessary, then please do and tell me. And we pretty much bypass all of the safeguards that SoftwareUpdate puts in place, so just because it is happy with it does not prove that it is not needed.

[larkost]

OK, the PPC thing was just a guess, but:

Can’t replicate = Can’t fix

Until someone can come up with what is actually going on here, there will be no fix. And I am unlikely to be able to figure this out, as I can’t get the problem to happen.

[larkost]

I have nowhere to test out proxied systems. A quick look indicated that the documentation on the python urllib2 module (what InstaUp2Date uses) seems to indicate that it should be reading the proxy information from the configuration framework. So in theory this should already be working. If you can figure out what has to be done to get urllib2 to work through your proxies, then I can try to add it, but short of that I don’t know what to do.

[larkost]

Just to repeat things: on Intel 10.5 things seem to be working just fine for me. All of my tests run just fine. I only own 1 PPC computer, and that has been my mail server for quite some time and so is not available for testing. As far as I can tell everyone who is having the problem is making their images on PPC. If this is not the case, then people need to be specific about this.

So I can’t fix what I can’t replicate.

[larkost]

Apple tends to have their people recommend that people create images on their newest hardware, but that is really to try and simplify the message going out. With InstaDMG I don’t think it matters what hardware you build on (if people find exceptions please tell me), but you do have to use “Combo” updates (InstaUp2Date will take care of that for you), and you have to make sure that the hardware you are targeting supports the “main line” of Apple’s current OS.

My one exception to my ambivalence about hardware is when it is new hardware that is not supported by the regular installers. Then I think if you are going to build an image for them that you should use the discs that came with them (not my usual insistance on “retail” or “reference” installers, but the grey ones that came in the box with the computers), and unfortunately you are not going to be able to use the InstaUp2Date vanilla catalog to help you.

To take the specific example of the new Mac minis and the newest iMacs: both shipped with a custom version of 10.6.3, and shipped on the same day as 10.6.4. So Apple had a custom version of 10.6.3 on them, and then built a special version of the 10.6.4 updater just for them (two different ones I believe). Because of this those two models (and presumably the Mac Pros that are on their way) will not be back in the “main line” of “regular” computers for images until at least 10.6.5. Presumably at that point everything will be back to normal and images will be back to being “universal”… until the next new hardware shipped, then that hardware will be need a new image for it.

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

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

It is a bad side-effect of some code I am working on to improve the display output everywhere. This was one of the two bugs I mentioned in the check-in notes. This is what I have been working on the last couple of evenings (but am going to do other things tonight).

[larkost]

Woops, that line was supposed to be commented out like the others I replaced. So I zapped it and a few others and that is rev334. Now I have to add a test because it is obvious that none of the current ones exercise that path.

[larkost]

I have determined that there is a bug for relative paths, and have a test for it now, but need to still yet fix the bug.

[larkost]

Nope, no new development yet. I am getting closer to being able to start the switchover, but right now the emphasis in my time is in reworking InstaUp2Date to get it ready to take the new development, and a lot on getting testing code in place so I am not so worried about things breaking, and can have more confidence that everything is working as expected.

[larkost]

The 10.5.8 updater will not work with the ‘-r’ flag. The chroot’ed installer code was put in place to handle the 10.5.7 and 10.5.8 updaters.

I have not been able to replicate any problems with the latest InstaDMG/InstaUp2Date running on 10.5.8 on Intel.

[larkost]

This all depends on what you want.

System Image Utility (SIU) does not directly have a command line option. However, the components that make up SIU are all useable from within Automator, and saved Automator actions can be called from the ‘automator’ command line utility. You can even put in some variables from the command line for things that can have Automator variables. So you can construct yourself a nice little work-flow from that.

At one point I tried arrange things so that I could use a SIU workflow as a back-end for InstaUp2Date (an optional one). However there are some real holes in this as a useable work-flow:

1) You have to choose all of the the items that you are going to have installed right from the start, and none of them can be in .dmg’s. The workflow will save hard-coded paths to the items you choose. This throws automated setup (ala InstaUp2Date) right out the window. I tried reverse-engineering the data structure that the workflow items pass between themselves, but this one bit is a bit opaque (passes a memory address to something).

2) You can use a .dmg as the OS source for creating the image, but you have to mount it yourself before calling the process. You can use a variable for the path, so there is some flexibility here.

3) Error handling is really bad. If something goes wrong you are not going to be able to reliably report what.

4) For the source volume you have to pass in a mounted volume location. And it will do all of the work of making a dmg and then scanning it.

But there are a couple of alternatives:

1) I was given the idea that one could create a package at a specific location that would be a meta-package pointing to the things you actually want to install. Then include just this package in the workflow. And change the package as desired. Workable, but not really a solution I liked.

2) Some folks over at the University of Edinburgh were working on [url=https://www.wiki.ed.ac.uk/display/DSwiki/Automating+the+creation+of+NetBoot+images]InstaNBI[/url], and had something working.

3) You could create the NBI set with a canned SIU workflow, and have it create a NetRestore image from a blank dmg file (to speed things up). Then you could open the NBI folder up, open the image inside, and replace the System.dmg file with one that you made with InstaDMG.

4) If you comb through how Mike Bombich’s NetRestore script works it would be fairly easy to create your own version of that information… but that is going to take a lot of testing.

PS… I have submitted a number of radars to Apple on this, and largely had them turned down. I have also had a couple of conversations with the manager in charge of SIU at Apple, but have yet to bring him to my way of thinking on these things. I will try more the next time I see him.

[larkost]

Ya, I missed it coming out. So the latest rev has it (rev320)

[larkost]

Maybe a silly note, but you are creating your 10.5 image while booted into 10.5, yes? Otherwise I know things are going to go wonky.

[Author]

Posts