non-interactive, non-GUI installation of MCR on Linux
Jeff Frontz
According to one of the technical solutions pages (http://www.mathworks.com/support/solutions/data/1-5RW56L.html), I should be able to:
o perform non-interactive, non-GUI installation of MCR on Linux, execute the following command:
./MCRInstaller.bin –P bean421.installLocation=”desiredInstallPath” –silent
However, if I run the command:
./MCRInstaller.bin –P bean421.installLocation=”$PWD" –silent
I get lots of curses-based output from "InstallShield Wizard" and then
The wizard cannot continue because of the following error: Invalid command line option: –P is not a valid command line option (1001) (403)
WARNING: could not delete temporary file /tmp/ismp002/7807159
WARNING: could not delete temporary file /tmp/ismp002/7917361
WARNING: could not delete temporary file /tmp/ismp002/693538
Anyone know the mojo to make it go?
Thanks,
Jeff
Jeff Frontz
I suggest that future Matlab software installation packages for Linux be constructed using native linux tools like rpm so as to avoid the baggage associated with Windows-based software.
"Jeff Frontz" <jeff....@gmail.com> wrote in message <gs84pn$l4i$1...@fred.mathworks.com>...
Ripley
Why distribute the MCR? Or anything except a link?
I typically run the executable for the first time on a dev box identical to the deployed boxs which creates a compatible ctf and MCR. Then I place that ctf and MCR on a server along with the .exe. The link I distribute to users is actually a link to a bash script that checks the user box for an MCR and then sets the path to the server MCR if needed and runs the executable on a Linux server.
Its worked fine for years. Sometimes client boxes in Hong Kong or other large latencys seem to take a long time to startup but they work reliably once up.
Jeff Frontz
> "Jeff Frontz" <jeff....@gmail.com> wrote in message <gs84pn$l4i$1...@fred.mathworks.com>...
> > I'm trying to perform an unattended installation of MCR on linux.
> >
>
>
> I typically run the executable for the first time on a dev box identical to the deployed boxs which creates a compatible ctf and MCR. Then I place that ctf and MCR on a server along with the .exe. The link I distribute to users is actually a link to a bash script that checks the user box for an MCR and then sets the path to the server MCR if needed and runs the executable on a Linux server.
>
> Its worked fine for years. Sometimes client boxes in Hong Kong or other large latencys seem to take a long time to startup but they work reliably once up.
I'm assuming your "client boxes in Hong Kong" have some sort of network connectivity back to your mother ship. My application is an embedded system, where the user (or, more likely, the field service technician) will install software on the base system at some remote/isolated location-- one where there is potentially no grid power, let alone network connectivity-- or at some secure location where the user does not want to allow the system to connect to anything outside.
I also need to provide a boot-strapping procedure for the development environment--ideally, this is a script-driven, non-GUI, self-contained process that automatically pulls appropriate software/archives out of a repository (or off of a DVD) and readies a standalone virgin system for use as a development box ("script-driven", "self-contained" and automatic so that there is reduced chance of error and thus a high degree of certainty in reproducibility).
Jeff
Stephen Lienhard
> "Ripley " <n...@no.com> wrote in message <gtfndh$mi5$1...@fred.mathworks.com>...
> > "Jeff Frontz" <jeff....@gmail.com> wrote in message <gs84pn$l4i$1...@fred.mathworks.com>...
> > > I'm trying to perform an unattended installation of MCR on linux.
> > >
> >
In the past I would do an install on a clean machine, take the mcr directory it generated, zip it up, and write my own install routine which for the most part was unzipping the file and adding the directory to the Path. Even on windows it was that straight forward unless you were working with the com compiler.
Stephen
Jeff Frontz
>
> In the past I would do an install on a clean machine, take the mcr directory it generated, zip it up, and write my own install routine which for the most part was unzipping the file and adding the directory to the Path. Even on windows it was that straight forward unless you were working with the com compiler.
>
It's only "straight forward" if you know what the installation mechanism actually does. Did it add a library over there in that obscure directory? Did it create a header file over there? Did it modify that stock configuration file in that hidden directory? Or, in the case of MCR, did it create a machine-specific cache file that won't work anywhere else (and thus turns the whole thing into a brick when I put it on read-only media)?
Yes, I could use tripwire or other things, but the point of an installation script is to eliminate the need to know every last thing that's done to get a piece of software up and running. If I really need to understand it all, then just send a tar file with a set of instructions for tuning any existing files and let me do the installation myself. In fact, I'd much prefer that to the "install shield" hokum that hides all from me but sometimes works and sometimes doesn't.