Wednesday Nov 30, 2005

A known bug with the Sun Studio 11 compilers and tools installer

Due to a dependency that wasn't noticed in time, there is a small problem with the Sun Studio 11 installer on Solaris platforms. The installer is supposed to work with any Java 2 JVM. Unfortunately it will not in fact work with any JVM that is pre 1.4. One of two symptoms may occur. Either an exception during deserialisation, or an exception stating that the class com.sun.install.products.Product was not found.

If you experience this issue, and you have a 1.4 or later JVM available on your machine, simply set your PATH so that that version of java is first. If you do not have a 1.4 or later JVM, then you will need to install one. You should install the full JDK, since the installer will then not offer to reinstall it.

I believe this problem was introduced when I added support for Zones to the installer. I switched to a later release of the Installer SDK, which introduced the dependency on a 1.4-only class.

Wednesday Jul 13, 2005

product-server style installation

I'm currently working through some issues with product-server style installs. The idea being that you install the Sun Studio compilers and tools on a big machine with lots of disk and network bandwidth, and then multiple machines can NFS mount the installation directory instead of having to install the product. I've had some feedback to the effect that what people really want is to run the installers for each architecture directly on the server and just tell each installer to use a different directory (which would then be shared). Currently, we don't support this. We only support running the installer on the same architecture as the product it installs. One way people have of trying to make this work better for them is to use the -R (alternate root dir) flag to force every modification of the system to be under some directory. That way, you can NFS mount the server on an appropriate architecture client with the right root-access flags, and do the install without worrying about modifying the client system. I have a hard time recommending this though. For one thing, it makes it hard to patch the product. So in the current release, there really isn't a nice solution.

For the next release, I've already done something to ameliorate the problem with -R and patching. It turns out that patchadd really only wants to see a certain single file before it will "believe" that a directory is a valid root filesystem and apply patches. So I've made the installer startup script fake up that single file in the -R case. Although this is not a formal Solaris interface with an assigned stability level, I've been told by the engineering group concerned that it is unlikely to "ever" change.

The next thing I did was look at what, if anything, prevented the packages from the two Solaris architectures being installed on the same machine (without alternate root). Solaris says that the tuple {name, version, architecture} must not already have been installed, otherwise this constitutes an attempt to overwrite a package (rather than a fresh install). Also, the package in question must have fewer instances installed than the maximum specified in the package info file. All the packages in the product have a large number for MAXINST, so that shouldn't be a problem. Naturally, the version number will be the same for the same package on the two architectures, if they come from the same build. So we have to hope that the ARCH is unique. It turns out that this is the case for all but two packages in the product, which have ARCH=all on both cpu types. This is clearly wrong for one, and arguable for the other, so I've made the change so that all the packages have distinct ARCH on the two different CPUs.

Next the question is what do you have to do to get the Install SDK code to allow you to install on an architecture different from that specified in the package. This seems to be very easy. There is an internal install property that you can set, but if the installer itself doesn't set it, it comes from the Java system property os.arch. So you can just run the installer with -Dos.arch="sparc" and install your SPARC product on an AMD64 server. There is one problem with this, which is that there is a native-code executable which forms part of each installer. One of the things it seems to be used for is to find out how much disk space is available. So when you trick the installer into cross-installing, it does warn about insufficient disk space. I have not yet researched whether it is possible to provide multiple versions of this executable.

Anyway, progress is being made, and if anyone has any product-server use cases they'd like supported, please feel free to leave a comment or email me.


Monday Jul 04, 2005

Just FYI

For the people who keep hitting my blog from a google search for "Sun Studio 10 cracks", why not go here and see how you can get Sun Studio 10 for free, legitimately.


Friday Jun 24, 2005

More on installing Sun Studio 10 compilers and tools with zones

I need to add a piece of information to yesterday's blog entry about zones. The Install SDK toolkit we used to build the installer for Sun Studio 10 compilers and tools was a pre-zones version. Therefore, it doesn't run pkgadd with the -G flag. This means you'll get the product installed into all zones when you run the installer. It also means that if you choose a new directory for the install, the installer will know to create it in the zone you're running in, but not in the other zones. That will cause the installer to hang, since pkgadd will be sitting there asking whether you want to create the directory in the other zones. You can work around this by pre-creating the directory in each zone.

This doesn't work as well as I would have liked. Rest assured that it is a high priority for me to smooth out these wrinkles for the Sun Studio 10 upate 1 compilers and tools installer.

Tags: ,

Thursday Jun 23, 2005

Installing Sun Studio 10 into a non-global zone

I've seen reports that the Sun Studio 10 compilers and tools won't install into a non-global zone. Unfortunately I wasn't up to speed on Zones during the time we were developing that release, so the installer wasn't developed with zones in mind. It turns out that it "nearly" works. The testing I have done shows that a default install in the global zone works fine, and this install is then visible to non-global zones. So that's one workaround. The failure in the non-global zone is due to a particular package attempting to create symlinks in /usr/ccs/bin during it's post-install phase. The default non-global zone configuration is a so-called sparse root zone. But if you configure a whole root zone, then your non-global zone isn't sharing /usr with the global zone, and the failure won't happen. You can even just remove inherit-pkg-dir dir=/usr (leaving three other directories shared with the global zone) while configuring your zone. That's the second workaround.

We've updated the package for the next release of the product, so that it doesn't create the symlinks, so Sun Studio 10, update 1 compilers and tools will install cleanly into a non-global zone.

There is also a hack way to get it to work in a default sparse root zone. I am in no way recommending this, but if you manually install SPROcc, ignoring the errors about the symlinks, and create the appropriate entry in /var/sadm/install/productregistry, then the installer will see that the package is already installed, and won't try to install it. Therefore it will never see the pkgadd failure, and will report a successful install.

Tags: ,

Monday Jun 13, 2005

A quick note about uninstalling Sun Studio 10 compilers and tools

There is a known bug in the Sun Studio 10 compilers and tools uninstaller. This is documented in the release notes of the product, but I've seen a number of people get bitten by it recently, so I thought I'd post about it here. Essentially the problem is that the uninstaller startup script, batch_uninstall_all doesn't work unless you have $DISPLAY set to a valid X display. This tends to be an unexpected requirement, since uninstalling this way doesn't start up a GUI. The issue arises because of the way the Java awt classes behave. Certain classes want to initialize themselves, and attempt to connect to the X server in order to do this. Unfortunately this happens at startup time, not when GUI code is first called. Since the uninstaller classes can be run with an interactive GUI, they do contain GUI code, and so do need to talk to the X display at startup.

The easiest workaround for most people is simply to set $DISPLAY to point to a valid X display (and to set the X server to allow root on the computer running the uninstaller to connect to it). However, this is not possible for everyone. So the other way round this is to make sure you are using a Java VM which is at least version 1.4, and to set the system property java.awt.headless=true. You can manually emulate the uninstaller script by running each uninstaller class in turn, but with the property set

For example:

machine# cd /var/sadm/prod/com.sun.studio10
machine# java -cp . -Djava.awt.headless=true uninstall_Sun_Studio_Software -nodisplay -noconsole
machine# java -cp . -Djava.awt.headless=true uninstall_Documentation -nodisplay -noconsole
machine# java -cp . -Djava.awt.headless=true uninstall_Source_Distribution -nodisplay -noconsole

In the next release of the product, the uninstall script will automatically take care of this. It will check the JDK version, and if it is suitable, will set the system property automatically, otherwise it will exit with an explanatory message.


Thursday Jun 02, 2005

Installer simplification gaining traction!

I'm starting to hear comments that some upper-management types aren't very pleased with how many files you have to download to install the Sun Studio software from a so-called web image. Aha - then a single download file per platform would be better then? Cue my cunning plan.

Wednesday Jun 01, 2005

What to uninstall?

The current installer for the product I work on automatically generates an uninstaller. Unfortunately, this is sometimes less than ideal in it's action.

One example of this is that the installer generates a license file, but the uninstaller doesn't make it go away. This is due to the file not "belonging" to any package. I am currently investigating ways round this problem. It seems easy enough for SVr4 packages, but I haven't found the right answer for RPMs yet.

Another issue that can arise is with components that are shared between releases of the product. At the moment, this only affects Linux, where we install some supporting "system" RPMs along with the the product packages. If you install two different releases of the product, and then uninstall one of them, it is possible that the "supporting" RPM will be uninstalled, leaving the remaining product less functional.

The third issue with the uninstaller is that it is not the exact inverse of the installer. That is, if you do a full install followed by a full uninstall, you don't necessarily end up with an unchanged system. Again, this is due to "supporting" items being installed. For instance, on Solaris we (optionally, but by default) install patches.

I think it would be more intuitive if uninstall were the exact inverse of install. This seems to be a good argument for splitting the current installer into a separate "system preparation" step, which would do patching, add the right JDK, etc. and the actual product install. Product install would be exactly reversible. The system prep would not necessarily provide an easy way to reverse it's effects, and certainly would not be undone by the product uninstaller.

Wednesday May 18, 2005

Installer simplification

As I mentioned previously, one of the sources of complexity in our install process is that we provide two different media - a physical CD and a web download. This wouldn't be an issue, except for the fact that the two images are different. If you install with either method, you should end up with identical bits on your machine, but the code that runs to get them there is different. There is a historical reason for this.

Back before I worked in this group, there was a perception that download of our software was problematic. Therefore the install was split into several "chunks", each of which was intended to be self-sufficient. Then it was noticed that this wasn't very convenient if you want the whole product, so code was added so that the sub-installers could be glommed together on the fly. Unfortuntately it didn't prove possible to support batch-mode install of the glommed-together thing. So you have the choice of a combined interactive install, or individual batch installs.

Although this was done with the best of intentions, I now believe it to have been misguided. We could remove a huge amount of documentation and testing overhead if we adopt a new strategy. This proposed strategy is to have only one image (per platform), which is the current CD image. For customers with slow or unreliable internet connections, we already provide a physical media kit for a nominal cost. For people with fat pipes, they won't care about downloading the whole CD image. Everyone wins, because the quality of the installer will be driven upwards by the simplification of the code, documentation and testing.

The image could be provided both as a tarball, which you unpack and run, and as an .iso file which can be burned to a CD and run on a different machine.

Friday May 13, 2005

A few quick remarks about installers

One of the things I work on here at Sun is creating the installer for the Sun Studio product. This is the native compilers, ide, performance anyalser etc. - not to be confused with Sun Java Studio.

I've been working over the last several releases to improve both the quality of the installer, and the customer's experience in using it. Unfortunately, I don't get a large amount of feedback on how I'm doing, so anyone out there in blog-land, feel free to email me if you have comments. I currently have the opportunity to start over with a blank sheet, since I've been asked to come up with an installer for an internal prototype our group is working on. So now is a good time to reply!

Anyway, one of the problems I see with the current installers is that there is a combinatorial explosion of possibilities, which makes it

  • hard to test, hence hard to achieve high quality
  • hard to document
  • hard to use
The problem is that we support three different platforms, with three different install methods, and two different delivery media. We run on Solaris on SPARC and x86/x64, and on Linux. We provide GUI, CUI interactive and batch (silent) install modes. And we deliver physical media and web download. That's eighteen top-level combinations, before you even start considering install options.

A second challenge that we have is that the current installers conflate two subtly different activities together. We do system preparation and product installation all mixed in together. An example of a system preparation function would be installing a Solaris patch, or installing an extra system RPM on Linux. Product installation proper should only consist of installing the product packages and creating any configuration files required by the product. An example of a configuration file would be the license.dat file containing the serial license. The fact that these two activities are not cleanly separated makes it hard to use a server-based install approach, where numerous clients can NFS-mount the software from a central server. It also has implications for uninstalling, particularly where multiple releases of the software are installed on the same system.

So, there are a couple of issues. I'll try to expand on what I might do about it in the next post in this category.




« June 2016