[larkost]

The –instadmg-scratch-folder option does exactly that. It does not speed up InstaUp2Date in any way (there is really no place where having multiple disks is going to help with downloading or checksumming), but it does provide this option to InstaDMG for the -p/–process image.

[larkost]

You can’t store the checksum of the final vanilla image, since there are a lot of things in the image that get the date that the image is created (the receipts for instance). So two vanilla images that are functionally equivalent are not going to have the same checksum either internally, or of the DMG (side note: I do want to create a tool that I can use to create checksums for images where two runs would result in the same checksum, and use this in validation. But that is necessarily going to be slow, and would really only serve to help me tell when I have broken something during development).

I do plan on using a checksum to do this, but one that combines the checksums of the inputs (installer dvd + installers + installer choices files, including settings and possibly an InstaDMG “compatibility number”, done in order). I have sketched this out already, but it absolutely requires something like InstaUp2Date to drive it, while at the same time requiring that the same component be driving the selection of the cached image. I am tentatively calling this idea “break-points”, and am still figuring out how they are going to work (beyond automatically setting one after the combo update).

[larkost]

I have the original video that I used there (it was actually first in my Macworld presentation, but that was not recorded), and I am planning on making another one for my talk at MacSysAdmin in Sweden (higher quality). If I get accepted for the MacTech conference I will probably use it there as well.

I tried putting it up online once, but the video got re-compressed by the service I was trying to use, and was not really useable that way. I have been thinking about re-doing my home server, and if I do that then I can probably host it locally without those problems. But since that is probably going to wait until sometime after the new Mac minis start appearing as refurbs, I should probably just lay down a narration track, and see if we can host it on AFP548.

Just one more thing for the list…

[larkost]

There are now two questions here:

1) Why not cache the vanilla image (base image + combo + other updates)?

The answer here is that I do have a design in mind to do essentially this, but it requires that at run-time the system knows that nothing in the process up to the the point of caching has changed. Unfortunately with pure InstaDMG this idea was too complex, and I had to drop it. Making sure that the image is correct trumps speed (although the latter is also a goal). But with the merge of InstaUp2Date that I have had in the works for a long time now this becomes possible because everything is checksummed (so I can validate things), and InstaUp2Date/InstaDMG can tell explicitly when things change. I am still working out a lot of the details, but rest assured that this is planned.

For the moment though, the best thing to do is to grab a second fast external disk and use the option to use two drives durring image creation. This really drives down the time.

2) Allister saw the compression of the base image that is still hanging around in code. I tried to compress the base image a long time ago, figuring that I could make it take up a bit less room, and probably gain a bit of speed out of it (since disk I/O is what kills us). But something in it blew up every time, and at the time I was under some pressure to get the other features (base image caching) running, so it got put off. I should go back and validate that again….

[larkost]

I just put in what I think might be a fix (I don’t have this in a test rig yet). Try rev302 and see if it is fixed for you. Thanks for the report.

[larkost]

The new computers (like all new computers that Apple has ever produced) come with a special build of MacOS X. This version is the only one that works on those computers at the time they are released, and it is only certified to work on the computers that it ships with (they usually work on other computers, but that should not be depended on). So a generic build not working on those computers is completely expected.

There ultimate solution is to wait until the next “dot-release” of MacOS X (at the moment it should be 10.6.4), at which point apple has (almost) always put the machine-specific components for new hardware into the (combo) update. Then you would make the next image with the 10.6.4 Combo update and all would be well with the world (until the next round of new hardware).

In the mean time you have two options:

1) Make an image specifically for those new computers, and make it on one of those new computers using the disk that came with them as your source DVD. I would really caution against using this image on any other models, but it might work fine (I always worry about hidden problem like the fans not working correctly for a given motherboard).

2) Use your normal image, but before allowing that image to boot (unsuccessfully as you have seen), boot from the installer DVD that came with the computer. The run it through an upgrade install, and you should have a working computer that (mostly) conforms to your image.

The latter solution is better if we are only talking about a few computers, and the former is better if we are talking about a lot of new computers.

[larkost]

You have probably posted in the wrong section on this forum. You probably want the [url=https://www.afp548.com/forum/index.php?forum=18]Server Questions and Answers[/url] section.

[larkost]

The fix for this is not in 1.6b2, but is in the version in SVN. It is because the installer looks to the booted volume rather than the target volume, but I figured out a trick to work around this. It was put in in rev266, but 1.6b2 was rev261.

[larkost]

As Allister alluded to the InstaDMG script is not going to handle it well if you try to run two instances at once on a computer. The mounting of the update dmgs is going to be the first problem (the current implementation naively assumes that images are not mounted already and it is not well defined what happens if something is already mounted). The second problem is that I wrap a chroot jail around a background daemon and that code is not going to work out well if run concurrently.

If you need to make concurrent images, then a image farm is probably a good solution.

[larkost]

You do not need the checksum in the file name in catalog files. Putting it there is probably not going to hurt anything, but it is not really going to help at all (and you will wind up with cache files with the checksum put in twice). The only place that the checksum will appear in the name is in the auto-downloaded InstaUp2Date caches, where it is used to speed up finding appropriate items.

[larkost]

I am not seeing a problem at this point. Don’t post partial commands, post the full setup otherwise it is not possible to re-create in troubleshooting. I would aslo dump your caches to make sure that you don’t have something odd there, and restart to make sure that you don’t have anything is-mounted. At this point InstaDMG does not handle it well when dmg’s are already mounted. I have thought about that a bit, but don’t have a better solution than just failing, and I don’t like doing that in the middle of a job. Partially because InstaDMG does not do a good job handling that at this point.

I am running another round right now to confirm, and then will run a cache-free round after that.

[larkost]

I just put in a fix for this (rev294), the problem was that you can’t take the log10 of zero and that is what I was trying to do when there were no items in a particular folder.

[larkost]

Try rev293. I put in some changes last night that might help… but this is experimental since I have been monkeying with the heart of InstaDMG.

[larkost]

This is the oldest part of the InstaDMG code, and one that actually is on my list to replace next. The problem here is that InstaDMG assumes that anything in its folders is either a DMG or a folder, but I have already been thinking of relaxing that rule… but had not quite gotten there in InstaDMG. I will try to put that fix in sooner… but no guarantees since I will be a bit busy with personal life stuff for the next 3 weeks.

But since it is specifically FireFox that you are putting in you have a few options:

1) If you are not doing any customization of FireFox, but are just repackaging, then rejoice, this is no longer necessary. I put in code a while ago to handle “naked” apps inside dmg’s, such as FireFox (that and Adium were my primary use-cases). So this line in your catalog file will get you what you want:

[code] Firefox 3.6.3 http://download.mozilla.org/?product=firefox-3.6.3&os=osx&lang=en-US sha1:ad9857fc2868b48784f53442ab7fe401b85bbe22[/code]

This functionality has been there for a while now, but I did not publicize it because I thought there was a bug. But it turns out that there is no bug, I was just thinking about it wrong.

2) Wrap what you already have in a dmg, and get the checksum for that.

And the reason that you are showing an older revision on InstaDMG is that rev266 is the last change on the InstaDMG file. Recently my changes have been happening in CreateUser and InstaUp2Date, so those have newer revisions while the InstaDMG file has not been changed. Weird little quirk of SVN, probably one I should look into working around at some point.

[larkost]

I just want to emphasize/clarify one point that Rusty glossed over: InstaDMG can’t run these sort of scripts for you since it only runs when you are creating the image, not while you are deploying it. So to make this happen you have to install something in the image that will do it for you (or use something in your deployment tool, or your subsequent management tool). Once you have these scripts packaged up, InstaDMG will be happy to help you install them.

When I do this sort of thing it is almost always with a LaunchDaemon, and I have been pushing recently to make sure that my scripts are all smart enough that they can be run at every boot and not slow things down when they are not needed. Partially this is because I am not using any real management tool for the installed computers, and this is taking its place, and partially this is because my computers can wander a bit before they make it to my subnet, and once they are there I want them looking like I set them. So special-case reasons, but I still think that it is generically good advice.

[Author]

Posts