[larkost]

Ok.. that was my mistake. I forgot that some things get set before we process the command line flags. I think I have now wrapped up everything that needs to be delayed, and have a new version with this correction in rev 139. Thanks for the bug report.

[larkost]

InstallerChoices.xml files go in the same folder as the BaseOS disk. This information is probably in the PDF version of the instructions, but not the text one in the copy you have. A couple of days ago I changed the text version as well, so the next version to go out will have that change in documentation.

[larkost]

In SVN, and on the dev wiki there are some new instructions. I am not saying that they are in great shape yet… but at least they got some work.

[larkost]

First off, I would not suggest installing the developer tools that are included on the installer DVD. Those are really out of date. Go to developer.apple.com and download the newest version. Once you do so, you can use the whole downloaded dmg as your source. This is how I do it. The only downside is that in doing this you have to also instal WebObjects and Dashcode.

And I can’t really tell what error you are getting, because you don’t give what version you are using, so the line number does not line up with anything. But it looks like the error you are seeing is in the middle of the “sanity check” section, which means that your folder structure is not matching up right. But I am having to make guesses based on shaky information, so I can’t give you a better guess than that.

[larkost]

Being able to change the temp directory is a good idea. So I just checked in code to do so. It now uses the -t flag to specify such a directory. The revised version is available as rev 119 in the svn repository.

[larkost]

knowmad, you might be able to get that to work by naming the resulting ASR dmg according to the checksum of your base image. You will need use hdiutil to get the checksum, as it is not the SHA1 checksum, but rather the one that diskutil uses internally for the dmg.

You will have to carefully clean out your folders to make sure that you don’t get the wrong thing in there.

But I think that a better approach would be to use the same method for image creation that I use:

1) Get all my InstaUp2Date packages and catalog files updated

2) Build latest base image using InstaUp2Date + InstaDMG

3) Put the ASR image on a FireWire HD that also has a boot image on it (actually an old version of my base image)

4) Restore this onto my test machine

5) Test, and find the problems

6) Change the pkg’s on my build machine with what I think I need to change to correct the problems

7) From the test machine connect (with AFP) to my build machine and run the installers (maybe copying them locally)

8) Test, find problems, recycle to step 5 until I get things right

8a) If I feel like I need to start clean, cycle back to step 4

9) Everything looks fine (or I have to go home for the night), so cycle back to step 1

Since everything has to work with .pkg’s this means that everything is very repeatable. Sure there are some things that this is not going to work for, but it has worked for me very well. When I am really feeling good about one installer and bad about another I sometimes trigger the next build while I am still in the middle of 4-8, so that I have less to install on a cycle.

[larkost]

[QUOTE][u]Quote by: hetjan[/u][p]Can’t you just create one build-train with your base needs and use the output file as a cache in another build-train?[/p][/QUOTE]

At the moment you would have to do a lot of trickery to get this to work out. Or a bit of re-writing of InstaDMG.

I do have more long-term ideas, but those are going to have to wait some time if I am going to be the one to implement them.

[larkost]

First off… a bit of a clarification/correction. The process is:

1) InstaDMG looks at the dmg that is designated the “main” OS disk and asks that for it’s internal checksum (I parse the output of ‘hdiutil imageInfo ‘ for this). It then checksums the installerchoices.xml file (if it exists), and uses a combination of that as the name to look in the cached image folder.

2a) If a cached image is found it opens it and skips on to step 4

2b) If no cached image is found it opens that “main” OS disk (and any other disks) makes a new target image and starts the install.

3) Once the base OS is installed it is closed off, and moved to the cached image folder (this step can be skipped if caching is disabled)

4) The cached image is now opened with a shadow file sitting on top of it to take the changes, and the installation proceeds.

I have done a bit of thinking in the same direction (as I was writing the caching code in fact), and had some ideas but also discovered that a lot of it is really hard to do right.

The main problem that I ran into in my thought exercises was that the 10.5.x upgrades are really the first thing that needs to go on top of the base image, so that would be the obvious place to put in a cache point. However, it is also something that changes on a regular basis. I have some reservations about getting too many cached images. I already think that there will be too many produced when people are playing around with creating their installerchoices file (this was what prompted me to make the command-line switch to turn off caching). Remember: every cached image is at least a couple of Gigs big (mine are 11 Gig). Start multiplying that and we get silly fast.

Oh.. and a side note: I plan on going back and compressing the base image cache files to being compressed. At the moment they are taking up too much space. I just need to have the time to check it, and am busy on other projects.

There are some issues about what things on top of that might do depending on what files are in the Base+Combo, these files are likely to change on a regular basis, and it is going to be difficult to know where to draw the line.

There is an idea out there to try and make more use of shadow files, and even to try and layer them, or use union mounts to achieve the same results. But that is going to take a lot of testing before I am going to trust it… once again time I don’t have at the moment.

Oh… and at the moment it would be difficult to use “long-form” command line switches. I vaguely want to move InstaDMG to Python (mostly to make it easier to grab error information but also to make it easier to put a GUI on top of it), and if that happens then it will be easy to use long-form command line switches.

[larkost]

There is a postflight buried in the growl installer (I just dug it out) whose main purpose is to open the prefpane. You are seeing that in action. This would probably be worth to mention to the growl people that they should try and detect then the installation volume is not the same as the boot volume. This would actually be rather simple:

[code]
if [ “$3” == “/” ]; then
do your stuff
fi
[/code]

I am going to post it to their google group right now.

[larkost]

Since we are in the InstaDMG forum, I would guess that he is looking to auto-update the image he is building during an InstaDMG run. I played around a little bit with chroots for InstaDMG for another purpose, and found that the installer was able to walk right out of one without blinking (this is actually a known limitation of chroots for root). I would suspect that systemupdater would do the same thing.

There is also the large issue that SoftwareUpdate pulls down non-Combo updates (that is good for individual computers, bad for imaging). This issue is probably a deal-breaker for actually using softwareupdate.

I also have reservations about an automated system for doing this at all. One of the really nice things about the workflow is that you wind up with an image that you can trust (this assumes that you are making incremental changes on an image you trust). If you were to use softwareupdaate to update things you would have untrusted things in there constantly, and could have various things depending on network conditions while you were working. I worked on InstaUp2Date with the idea that users could share a common few base images, meaning that all of us would be able to test and troubleshoot those images collectively while then putting our own bits on top of that image. Most of the ease of update, and more of the testing.

[larkost]

Requiring a reboot is not so much a deciding factor, as more of a usual consequence. And the reason that most of them require a reboot is that they just changes something in the underlying OS services. But in the case of InstaDMG they don’t touch the truly underlying OS, so it is not an issue.

[larkost]

The reason for the split is that you want the OS level updates to happen first. Actually you want things to happen in a specific order, and this helps a little bit with that. In InstaUp2Date I went even farther in splitting things up. Other than that, the two sections are exactly the same.

[larkost]

I have plans to look into all of these updates a bit later (since I have 600 computers that need their updates), and I think that it might work to get the installer put on the computers, but they are still going to need someone with the admin password applying them at the console (to hold down the button).

Specifically on the MacBook Air one, it does require a reboot, but it does not require anyone holding down the power button, so I think that it actually needs to be installed on the computer itself (since I would guess a component goes into firmware). So that one is probably a bad example.

[larkost]

I have not investigated AppFresh, and am a little uneasy about automating things too much on this part. I certainly want to make updating easier (and a few ideas for a GUI are rumbling about in my head), but part of the whole point on InstaDMG (and by extension InstaUp2Date) is to make images that you can depend on. My idea with catalog files is that we can share them with each other and so everyone knows that they have a good image, and when there is something wrong with one, we can troubleshoot it together. So far there is not enough mass behind this yet, but that will probably have to wait until there is a GUI.

If the system were to automatically pull down updates, then everyone would have their own version of the “base” image, and we are back to square one (albeit a faster square one).

There is probably some middle ground here, but it is going to take some work. I would also suspect that AppFresh would require some convincing to look at the target DMG rather than the host OS. You might want to talk to the developers of AppFresh about that possibility. Once I get through the couple of big projects I have going now I can look back into this direction.

[larkost]

The InstaUp2Date code is in the same repository (and it SVN, not CVS) as InstaDMG:

http://code.google.com/p/instadmg/

specifically:

http://code.google.com/p/instadmg/source/browse/#svn/trunk/AddOns/InstaUp2Date

Note that the instructions have gotten a little stale, and I am not going to have time to update them for a few weeks at least. I will happily take submissions for updated documentation (or even code).

[Author]

Posts