- This topic has 7 replies, 3 voices, and was last updated 15 years, 10 months ago by
larkost.
-
AuthorPosts
-
June 3, 2009 at 10:20 pm #376379
blake
ParticipantI’m not having any luck getting my custom user creation .pkg to install with instadmg r200. Anybody else attempting to use r200 and having problems? Do I need to tweak my package builder setup? In this specific test I have specified the destination as / and checked allow custom location. If I install the package using the GUI it works as expected. What are the recommendations for these type of packages?
[code]
###### Beginning Update Installs from ./InstallerFiles/CustomPKG ######
Working on folder 01 (14:48:15)
Copying folder ./InstallerFiles/CustomPKG/01 into the target at /private/tmp/package.D2uhcH
Installing firstboot0.8.pkg from ./InstallerFiles/CustomPKG/01 (01) inside a chroot jail
installer: Error trying to locate volume at /
Removing the copied folder: /private/tmp/mount_folder.PA7eOj/mount_point.I8REyY/private/tmp/package.D2uhcH
Folder 01 done (14:48:23)
[/code]I’m happy to file a bug but wanted to double check my .pkg configuration with others before doing that.
Thanks,
BlakeJune 3, 2009 at 11:21 pm #376380blake
ParticipantGot a different error this time after deleting the cached dmg.
[code]
15:52:41 ###### Beginning Update Installs from ./InstallerFiles/CustomPKG ######
Working on folder 01 (15:52:41)
Copying folder ./InstallerFiles/CustomPKG/01 into the target at /private/tmp/package.KKF79q
Installing firstboot0.8.pkg from ./InstallerFiles/CustomPKG/01 (01) inside a chroot jail
/Volumes/files/instadmg/instadmg.bash: line 786: 37143 Bad system call /usr/sbin/chroot . /usr/sbin/installer -verbose -dumplog -pkg “$CHROOT_TARGET/$TARGET_FILE_NAME” -target /
Removing the copied folder: /private/tmp/mount_folder.aLtWjV/mount_point.0JTCWs/private/tmp/package.KKF79q
Folder 01 done (15:52:47)
[/code]June 4, 2009 at 2:09 am #376381larkost
ParticipantWhat 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).
June 4, 2009 at 8:09 pm #376384blake
ParticipantOk so the issue is resolved by using 10.5.7 as the host OS and using a 10.5.4 installer DVD image. The 1.4b4 version however works as expected.
June 4, 2009 at 9:22 pm #376386knowmad
ParticipantHate to co-opt someone else’s thread but… its expedient.
Larkost, is rev200 ready for prime time or are we still in the ‘don’t touch, I’m making incremental and unstable changes’ world you had mentioned several threads ago (at least I think it was you)?June 4, 2009 at 9:46 pm #376388larkost
ParticipantBlake:
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.
June 4, 2009 at 10:20 pm #376390blake
ParticipantI’m working on Snow Leopard. We gotta nail down our image building process before the WWDC build comes out. Looks like I’m sticking with 1.4b4 and some clean up scripting on boot to get that image done. Hopefully next week we can sort out a way to report InstaDMG issues with Snow Leopard and maintain the required NDA.
Also I would say that r200 is working well with Leopard. I reviewed the debug.log and my custom packages are being installed properly using the chroot jail.
Blake
June 4, 2009 at 10:29 pm #376391larkost
ParticipantI 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.
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed