[larkost]

First set out a couple of facts:

– The target OS is never booted until well after the ASR image is create.

– Some executables from inside the target volume might get run by post-flight scripts (when run with chroot), but that is not really what we are talking about here.

The “/Users/${shortname}” is used by the target OS after it is booted (as in once you have restored the final image to a disk). This is the value that gets pushed into the DSLocal store. So it needs to be written in as the value that will be used, not the relative position when we are not booted from that volume.

[larkost]

In the dscl command the $dsNode has the target as part of it. The “/Users/$shortname” bit needs to be absolute because it will be used inside the running OS after it has been installed.

[larkost]

The problem with the iLife support update (and I suspect safari 4, but have not checked) is that they use Distribution scripts, and the installer program runs those outside chroot jails (even when run inside one). So it is actually checking what is on your host os, rather than checking what is in the target disk. So if you have already installed these things on the host OS the installer thinks it should install nothing.

I think (but have not had time to validate) that you can use an InstallerChoices file to get around this. Right now my hands are a little full (I just got laid off, am working on a coding portfolio, and am working on InstaDMG 2.0), but will get around to trying that in the near future.

And I am trying to come up with a generic way to prevent this class of problem, and have already filed a bug on this with Apple (as well as talking with one of the product managers at Apple who might be able to put some weight on this problem), and the only solutions might be for Apple to solve it, or for me to do some fancy-footwork with re-writing installers on the fly (I don’t have a good route on that one yet).

However, I do have an idea on a technique that would at least make these sort of problems show up as an error in the build process, rather than being left to discover in Q/A on the image.

[larkost]

The problem is that you are aiming at “/” so things are being created there. What you need to do in a installer script is aim at “$3/Users/${shortname}” etc…

Note that because of some weird behavior with dscl (it escapes chroot jails) even with the latest version of InstaDMG (the ones that use chroot jails) InstaDMG runs createUser outside of a chroot jail. It is a special case at this point, and with version 2 I hope to find a way around the need for a special case (doing that while keeping compatibility with 10.4 targets is going to take some doing).

[larkost]

Every now and again I file this as a bug with Apple. The tool should be smart enough to tell the difference, and I can’t think of a case where you would want a .plist.plist file.

[larkost]

My feeling is that disk IO is far and away the most important factor. If you watch a build it does not especially spike the processor or memory, and no matter how much memory you get you are not going to be able to fit the whole target disk into memory at one time, so IO is still going to be the limiting factor.

Now I will note that I have never been able to test on RAID. I am trying to get ahold of a couple of extra drive sleds for my main computer, and so that might change in the next month or so. I have heard that non-HFS volume can cause problems.

[larkost]

I am on Snow Leopard seeding, and have been seeing problems the whole way through. It might be that I accidentally fixed things with rev200, but I would be really afraid that things were escaping back out and installing on the host OS (that was a repeated problem).

So if it works it would be nice, but I don’t expect it to.

My work on InstaDMG 2.0 has been entirely on 10.6, and so that will be compatible (and then I will go back and make sure that it is compatible with 10.5.x also).

Oh… and I have been trying to get ADC to figure out how to handle the NDA issues, and have gotten a couple of emails essentially saying: “we are thinking about it”, but no resolution.

[larkost]

Blake:

Starting somewhere near 188 I put in code to use a chroot jail, and that requires walking a fairly fine line. I have not successfully tested that code since that revision on anything other that 10.5.6 or 10.5.7 (and mostly on the latter). In general I would always recommend running InstaDMG on the latest version of Apple’s current shipping OS. Mostly since that is exactly what I am doing, and since I am the only one currently contributing code….

Out of curiously (since you didn’t answer the question): what was the host OS you were using.

knowmad:

Right now rev200 is a very strong candidate for labeling 1.5, and people willing to be on the bleeding edge should use it. I have successfully build a number of images without real problems, and they seem to be working fine with only two problems that I am aware of:

1) /tmp is not being cleared out, rather /private/var/tmp is. It turns out we have had this problem for a while, and I am sitting on a patch for that (probably submit that tonight).

2) Packages that use distribution scripts that check on things on disk are doing so outside the chroot jail that they should be running in. And example of this is the latest iLife Support update. It will not install anything on an image if the host OS has it installed. I have filled a biug with Apple on this, but have not come up with a generic way we can either detect this, or solve it. But I do have two ideas along this line:

– I am working on putting installer inside a sandbox and severely limiting access to things. However this is as likely to have installers crash as to make them do the right thing.

– A work-around might be to use an new-style InstallerChoices file to manually turn on those choices. I am not sure who wins in this case: the InstallerChoices script or the Distribution script.

I have no plans to work on the second problem for the 1.x branch, but will look into this further for the 2.0 branch. but it might require Apple making a change in how the installer program runs distribution scripts to really work.

[larkost]

What is your host OS? Please note that the only version of MacOS X that rev200 is supposed to work on is 10.5.x (only tested on 10.5.6 and 10.5.7). It would probably also be helpful to post your debug.log for the run somewhere (do not cut-and-paste it here).

[larkost]

The easiest way to figure out what changes a setting like this is making on your computers is to use PacakgeMaker and have it watch for a “Snapshot Package” while you make the configuration change. Then you weed through the files that were changed while making the configuration change, and figure out what the best approach to distributing that change is.

If the change is fairly simple, and you don’t think that overwriting those files will clobber anything else, then you can use the product of the “Snapshot Package” in InstaDMG.

I honestly have never done this particular setting, so I can’t say how it will work out, but this would be the approach.

[larkost]

Just to amplify: 10.5 will put the ACL’s on any new home directory. This is normal. It will not be put onto directories that are already there (so migrated users might not get them), but since createUser does not create the home directly, but rather lets the system create it when you first log in, it will get the ACL’s.

[larkost]

The trick is that you probably don’t have that update on your booted OS. The whole problem here is that the Distibution script is looking at the base OS and making decisions on what to install based on what it finds there, rather than looking at the target disk. It is doing this even though it’s (sort-of) parent process is running inside a chroot jail that means it should not be able to see the host OS.

[larkost]

I was hoping that putting things in a chroot jail would solve this issue, but it looks like distribution scripts in a flat-package (like the iLifeSupport9.0.2 .pkg) escape the chroot jail. I am going to file a bug on this. But the solution to it is to use a InstallerChoices.xml file that chooses all of the packages inside the update. That should solve the problem. Until then I have a new bug to write up with Apple.

[larkost]

[QUOTE][u]Quote by: thespider[/u][p]Thanks, I’ll revert to the stable version. I’m using 10.5.7 on my host and building for 10.5.7.
Rusty

P.S. Building on Powermac G5[/p][/QUOTE]

Hmm… that could be why I am not seeing this problem. I only have Intel hardware to work on. Unless someone steps up to solve this I don’t know how it is going to get solved.

[larkost]

I just committed a new version of InstaDMG to the SVN repository. This is the next semi-stable version, and I would like some testing on it. It uses chroot jails, and so the current version of createUser will NOT WORK. But lots of other things that were having problems should now work.

This is a little bleeding-edge, so I would not recommend this (yet) for everyone, but my hope is that this is really close to a 1.5 release, and once I got going in making changes I really got going. I am hoping that this will be the cap-stone on the 1.x versions of InstaDMG, and am working on a 2.0 version already (still just fragments).

I have a lot more information in a post to the developer mailing list:

[url]http://groups.google.com/group/instadmg-dev/t/424dc142520ef9e[/url]

Re-doing createUser so that it will work in the new environment is the first thing on my plate for this weekend.

[Author]

Posts