New version to try

[larkost]

I have checked in a new version of InstaDMG into SVN. The changes is not all that big in terms of lines changed, but it has changed in one significant way: the upgrade packages now install inside chroot jails. This means that some of the problematic packages out there might now just work. This is especially true of installer scripts.

I am still working out all of the kinks from this version, but I would like to get more people to test this out. Thus far I am finding mostly changes that are improvements on my old images (odd corners seem to have not gotten previous updates), but I consider this all very experimental.

So if some brave souls would be so kind as to download the latest SVN version (188), try it, and report back that would be great. If you are not comfortable getting this version from SVN, then I am not going to recommend trying it for now.

[Rusty Myers]

Thanks for the update!

Here’s what I’m seeing, using InstaUp2Date:

**Just the first few updates shown, but each package that gets installed shows the same things.**

16:29:44 ######InstaDMG build initiated######
16:29:44 ######Mounting Mac OS X installer image######
Mounting the shadow file (/tmp/D6E519D1-5083-479E-9F4E-257C7FBB5BD0.dmg) onto the image.
Mac OS X installer image mounted
Running from cached image (./Caches/BaseImageCache/226663A2:76393a32d3ca132914acd4e16543f4a71561f650.dmg)
16:30:43 ######Beginning Installation from ######
Using Cached image, so skipping OS installation
16:30:43 ######Beginning Update Installs from ./InstallerFiles/BaseUpdates######
Installing MacOSXUpdCombo10.5.7.pkg from ../../Caches/InstaUp2DateCache/MacOSXUpdCombo10.5.7.dmg (1) using a chroot environment
mount_hfs: No such file or directory
Installing MacOSXUpdCombo10.5.7…..
Installing QuickTime76_Leopard.pkg from ../../Caches/InstaUp2DateCache/QuickTime76_Leopard.dmg (2) using a chroot environment
2009-05-19 13:57:57.702 installer[66315:3e03] *** -[IFRunnerProxy requestKeyForRights:askUser:]: unrecognized selector sent to instance 0x57525a0
2009-05-19 13:57:57.704 installer[66315:3e03] *** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘*** -[IFRunnerProxy requestKeyForRights:askUser:]: unrecognized selector sent to instance 0x57525a0’
2009-05-19 13:57:57.705 installer[66315:3e03] Stack: (
12086672,
9860332,
12115800,
12109140,
12109800,
1279280,
1300308,
1285300,
3808624,
7811272
)
Installing AirPortUtility.pkg from ../../Caches/InstaUp2DateCache/AirPortUtility.dmg (3) using a chroot environment
2009-05-19 13:58:07.376 installer[66369:3e03] *** -[IFRunnerProxy requestKeyForRights:askUser:]: unrecognized selector sent to instance 0x57519f0
2009-05-19 13:58:07.378 installer[66369:3e03] *** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘*** -[IFRunnerProxy requestKeyForRights:askUser:]: unrecognized selector sent to instance 0x57519f0’
2009-05-19 13:58:07.379 installer[66369:3e03] Stack: (
12086672,
9860332,
12115800,
12109140,
12109800,
1279280,
1300308,
1285300,
3808624,
7811272
)
Installing AirPortClientUpdate2009001.pkg from ../../Caches/InstaUp2DateCache/AirPortClientUpdate2009001.dmg (4) using a chroot environment
2009-05-19 13:58:30.663 installer[66421:3e03] *** -[IFRunnerProxy requestKeyForRights:askUser:]: unrecognized selector sent to instance 0x5794fe0
2009-05-19 13:58:30.665 installer[66421:3e03] *** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘*** -[IFRunnerProxy requestKeyForRights:askUser:]: unrecognized selector sent to instance 0x5794fe0’
2009-05-19 13:58:30.667 installer[66421:3e03] Stack: (
12086672,
9860332,
12115800,
12109140,
12109800,
1279280,
1300308,
1285300,
3808624,
7811272
)

Don’t know if the image works, or if those are errors, but it’s different from what i expected so I posted it.
Rusty

[larkost]

I think that the important question here is: Are you running an OS other than 10.5.x as your “host” OS?

10.4 does not work, and it has decided that we are officially abandoning 10.4 as a host OS. I am not adverse to submitted fixes to get 1.x branches to work on 10.4, but have no hardware to test or do development on that run 10.4. So I will break it there. Additionally future version are going to start relying on systems introduced in 10.5.

10.6… well I can’t comment on that on a public forum other to say that it does not work, and I am working on fixes for a future version of InstaDMG.

PS: as a warning to people, I am doing some major overhauls right now, and so am committing to the repository even when I have not tested things. So for the moment builds after rev188 might be broken. But I don’t think that that is the issue for thespider.

[Rusty Myers]

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

[samplem]

Yeah, 10.5.7 should run pretty seemlessly Spidey, I’ve been testing with it in InstaDMG for the past few days. Just tweaking some post-flight stuff today as well.

[Rusty Myers]

Yes, all is well. 10.5.7 is building great and InstaDMG still rocks!

[metajam]

I tried rev188 instaDMG.bash with the 10.5.7 Combo (running on 10.5.7 PowerMac G5 host) and it works. It applies the update and most of the other packages seem to be ok with one notable exception:

createUser.pkg

It seems that this package has created the target user [i]on my build machine[/i] rather than in the target image. It was working ok with r179.

I’ll see if I can figure out why.

[metajam]

I didn’t get much of chance to work on on the createUser.pkg problem so far. The postinstall script looks like it should be doing the right thing inside of a chroot.

The behavior when invoked from instaDMG r188 is like this:

1. The /Users/username directory is created inside of the target volume: correct.
2. The directory entries (via dscl) are created in the host system: not correct.

Makes me wonder if the dscl command is actually a frontend for a process already running outside the chroot (eg DirectoryService). That’s one possibility – and dtrace output from my dscl tests seem to support this (disclaimer: I’m a newbie at dtrace).

Perhaps some kind of blacklist would be useful where some packages can be excluded from the chroot treatment? The createUser package has been crafted to work nicely with a non-root target so perhaps better left that way?

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

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

[Author]

Posts