Did you try to build a very simple setup (one that just creates a dummy file), for comparison? I did this, the simple setup works while the real "big" setup is broken (with the helper tool dialog). PS: I found that I created the setup with wrong parameters in the "build" panel, I used "Without VM" instead of "With VM". Much better now. ... View more

I have the exact same problem. It's driving me mad, I assume the installer is launched repetitively by launchd, but can't seem to find anything ins /Library/Launch* to support this. If I find something I'll say it here. PS: rebooting sloves the issue, so it's either a transient config that get trashed when rebooting, or some other background program that repetitively launches the setup... ... View more

I assume you are on Windows? I have a similar problem, which could be worked around by using Java 1.7. For some reason the installer has trouble with Java 1.8 for the language selection. HTH ... View more

pv7721 wrote: Sometimes, it's easier if you simply remove it. Hey, I have the same problem... I have removed the registry, but the problem still occurs. Reproduced on 2 different machines (so the hypothesis that the registry was corrupt by simultaneous writes is unlikely). Any other idea? Thanks. ... View more

just got this error too I'm on a Mac, using IA2010, but not using a "Mac" setup, I generate an "Unix" setup to be able to use batch (silent) install (the usual Mac-friendly setup built by IA doesn't work in batch mode) I'm pretty sure I've been able to use this uninstaller in the same conditions before... --- I re-ran the setup to upgrade my product. This time, the Uninstaller worked. I'm re-making a clean build of the setup to retry and see if it's a transient issue. --- OK after a setup rebuild... I think all was not rebuilt on the first try, in fact. ... View more

Basically you need to go to the "Build" panel, there you have the "Build Configurations" tab, inside you have another panel with "Build Targets/Distribution/Tags/Locales" => you select the "Distribution" tab, there at the bottom you have "Merge Module/Template options", you must activate the "Build Merge Module/Template" toogle box. Now if you build it will create just a merge module (also unselect the "Web installer" and "CD-Rom Installer"). ... View more

It's not managed by InstallAnywhere. IA provides a rather generic framework which is good for installing files, and then for Operating System specifics it depends. a) You have to create the .plist file yourself, for instance make a template file "xxx.plist.template" then use the IA "Modify Test File" action to obtain the right .plist for the context (unless there are no parameters to be set at install time) b) you put the plist into the Folder by simply using a "Copy File" action in IA. c) There are several possibilities here, it's really a MacOS X question. You have to read and fully understand the "launchd" documentation, it's quite versatile. ... View more

Had similar problems, in fact when you "become root" in InstallAnywhere you don't really become root. You become "effective UID root" while your "real UID" is still whatever it was before (but not root), which is what happens when you run a "setuid program". This is Unix stuff, if you want more explanation you can google "real and effective UID unix", there are a lot of articles about this subject 🙂 The bottom line is: you're almost "root", but not completely, and while it's enough for, say, copying files into the system, some commands ("sudo" in particular) see the difference. To solve this, you can either modify the InstallAnywhere setup to inject a little C program which does a "setuid(0);", which turns your program into a real root program. That's what I had to do and it's quite complicated 😕 Another, easier, trick is to use the same technique (a C program which becomes root), but use it in front of each command and script you run from InstallAnywhere. Here's a program which works, let's call it "fix_uid": #include #include #include int main(int argc,char *argv[]) { setuid(0); printf("\nFIX_UID\n"); system("id"); printf("\n"); execv("/bin/sh",argv); } Note that this is NOT a security risk. "setuid(0)" only works when you're already root, that is, you have the setuid set. The security risk lies in the program which started "fix_uid", and in our case, it's InstallAnywhere, which is (thanks to its own authentication mechanism) setuid root. (Gosh, I hope it's not too unclear...) Anyway, once you have this program, you use it to prefix your commands. For instance, instead of writing: launchctl -c ... you write: {path to fix_uid}/fix_uid -c "launchctl -c ..." Hope this helps. ... View more

IMHO the problem is Java. Jave is missing a few features like symlinks, chmod, getpid() (although there's a trick to get the pid)... Sure, these features are not always available on all operating systems; but saying "if it's not available on all OS it's not in Java" is seriously limiting Java as a system tool (and byt the way I think all OS have getpid()). Java for applications: OK. Installers: could be better. That being said, InstallAnywhere does an impressive job demonstrating that Java can be used to make installers anyway. Now InstallAnywhere could indeed provide some "actions", or even just code sample, to deal with symlinks and other OS oddities. Well, that's what is forum is for, isn't it? 😉 ... View more

For what it's worth, to work around this limitation, I turn symbolic links into .SYMLINK files which contain the link text. For instance: ls -l lrwxrwxrwx ... foo -> bar I convert this way: ls -l -rw-r--r-- ... foo.SYMLINK cat foo.SYMLINK bar Then I have a bit of Java code which scans the install dir for .SYMLINK files, for each file it reads the contents and use "ln -s ..." to create the right symlink. Not very elegant but it works. ... View more

FOUND IT! the path is too long. Somewhere in the exec chain, it gets corrupted, so the program cannot be launched. I guessed it by looking in the system log (/var/log/system.log), I think I already checked that but didn't realize what was going on. I saw it again today and suddenly I guessed: Nov 12 13:10:54 micmac authexec[32834]: executing /Users/admin/Desktop/xxxxxxxxxxxxxxxxxxxx.app/Contents/Resources/install.app/Contents/MacOS/xxxxxxxxxxxxxxxxxxxxxx�;w~\z}6{ the characters at the end of the line are garbage. I then moved the seutp to "/", this shortened the path by 21 characters and it was sufficient to have it work. Apparently the limit is around 150 characters, which seems large, but in fact as large as it should... So, I'm quite stuck with that, either I change my setup name (which currently contains the product name, version and operating system) to something shorter, or I ask my customers to run it from "/"!!! :eek: Now it somehow bears a feeling of "deja vu". I wonder if I stumbled on the exact same bug in the past... EDIT: yes, I already found that problem less than 2 months ago, and totally forgot about it. I'm getting too old for this job 😕 EDIT 2: here's the solution I use, in case other people encounter this strange issue: - take the .zip and expand it, you get a {setup}.app directory, where {setup} is the name of your setup (for me it's something like PROD_12_SP3_P4567.server.MacOSX_10_5) - go into {setup}.app/Contents/Resources. There you have another setup {setup}.app again. This is the real setup: the first one is only there to ask for the admin password, then it executes the real setup with some MacOS X Api subroutine which allows to run root processes. - rename it, for instance to "inst.app". - edit "inst.app/Contents/Info.plist", it's a XML file, look for the name of the setup, it's under CFBundleExecutable , the line reads {setup} , replace it with inst - rename "inst.app/Contents/MacOS/{setup}" to "inst.app/Contents/MacOS/inst" => now you have a properly shortened sub-setup. We just have to tell the first setup to use the new name. - go back up into the {setup}.app/Contents directory and edit the Info.plist there. This time look for ZGExecutable , under it you have Contents/Resources/{setup}.app/Contents/MacOS/{setup} , replace this with Contents/Resources/inst.app/Contents/MacOS/inst , you're done Note: MacOS X has some kind of cache, sometimes when you edit the Info.plist file the Finder doesn't notice. In particular you may get an app icon with a "forbidden" sign drawn over it. To work around this, simple duplicate (copy then paste) the setup app, the copy will "reset" and it will work where the original stays desperately broken... Hope this helps. --Weelyn ... View more

yes, I used "sudo" to become root, then I started the Setup directly. The first screen shows up but it's grayed out and there is a message beside the padlock "setup is authenticated". After this, I get the "-60031" error (I see it because I became root in a Terminal window in ordre to launch the setup). ... View more

thanks for your answer, pv7721 yes it requires the user to authenticate to become root and when I click on the padlock, it gets stuck instantly. With "ps" I can see the process is just eating up cpu time, looks like it's in an infinite loop. Now, I cheated by becoming root *before* running the setup ("sudo"...), and I get a funny behavior: 2010-10-25 13:50:54.242 Setup[37819:10b] osError = -60031 I've looked up that error in MacOS X, it's not very clear but it seems to be related to either authentication problem (which is odd since I'm root now) or executable corruption, i.e. something's wrong somewhere in the program but not sure what. Maybe those two issues (infinite loop and error -60031) are related, that is, maybe the first setup tries to launch something which fails, and (actively) waits for it (which would be odd, but who knows). Thanks again, and don't hesitate if you need more info. I'm not completely stuck as I can use another machine, but of course this is scary, if it happens on a customer machine... Regards, --weelyn ... View more