This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallAnywhere
- :
- InstallAnywhere Forum
- :
- InstallAnywhere setup stuck on Mac (wheel of death)
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Oct 22, 2010
07:40 AM
InstallAnywhere setup stuck on Mac (wheel of death)
Hi all,
Has anyone of you encountered the following problem: I start my installer on a Mac, I get the first screen which asks me to click on the little padlock to authenticate myself, but when I click, nothing happens and the installer becomes unresponsive, the cursor turns into the "turning wheel of death" after a few seconds, and I must force-quit the installer.
I rebooted the machine in case it was some sort of temporary condition, but it didn't change anything. I tried on another machine, and there it works fine. The machines are similar (in particuler they have the same OS version).
So I guess there's something odd on the machine which prevents InstallAnywhere from working properly, but I don't see what it is. Any idea would be greatly appreciated 🙂
Has anyone of you encountered the following problem: I start my installer on a Mac, I get the first screen which asks me to click on the little padlock to authenticate myself, but when I click, nothing happens and the installer becomes unresponsive, the cursor turns into the "turning wheel of death" after a few seconds, and I must force-quit the installer.
I rebooted the machine in case it was some sort of temporary condition, but it didn't change anything. I tried on another machine, and there it works fine. The machines are similar (in particuler they have the same OS version).
So I guess there's something odd on the machine which prevents InstallAnywhere from working properly, but I don't see what it is. Any idea would be greatly appreciated 🙂
(5) Replies
‎Oct 25, 2010
07:04 AM
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
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
‎Oct 27, 2010
04:52 AM
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).
After this, I get the "-60031" error (I see it because I became root in a Terminal window in ordre to launch the setup).
‎Nov 12, 2010
06:42 AM
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 underCFBundleExecutable , 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 forZGExecutable , 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
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
- 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
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