“Fixing” the broken Solaris Management Console Oracle won’t fix

In my detailed article about the Sun Microsystems ecosystem of the late 2000s, I mentioned an issue I ran into with the latest (leaked) patchset for Solaris 10, the one from 2020, available on Archive.org. Sun does not make Solaris 10 patches and patchsets from 2014 and later freely available online, restricting them to big enterprise customers with expensive support contracts. The same restrictions apply to mere support documents for Solaris 10, so that issues documented by Oracle, including causes and possible solutions, are only accessible to those with support contracts.

The specific issue I ran into is that after installing the 2020 patchset, the Solaris Management Console, a GUI application written in Java with which you can manage certain aspects of your system, would no longer work. It would start up, but any settings panel you tried to load would throw up an RMI_ERR: error unmarshalling return, rendering the SMC effectively non-functional. This problem is documented in Oracle Doc ID 1559490.1, but of course, the Cause and Solution sections are hidden. I like weird commercial UNIX configuration GUIs, so even though you can do all of the SMC’s tasks with command-line tools, I still want it to work.

Judging by the error and the countless references to Java updates, it’s easy to figure out that the root cause is an updated version of Java installed by the patchset that the SMC doesn’t like. You’d think uninstalling any relevant patches would solve the problem, but I tried that and it didn’t make a difference, so I was hoping Oracle perhaps had a later patch to fix the issue, or perhaps a proper workaround to get the SMC working again. Well, a screenshot of the remainder of that Oracle Doc ID mysteriously materialised on my Ultra 45 this morning, and it turns out that Oracle just… Doesn’t care.

Honestly, I can’t blame them. Solaris 10 is old, outdated, pure legacy, and the very small number of organisations still using it are probably using it in Solaris Zones on servers anyway, and definitely not as a workstation/desktop operating system. There is zero incentive for Oracle to waste any time trying to fix this issue that, let’s be honest, really only affects one person in the entire world: me. Still, I wanted it fixed, and so I brute-forced a solution.

It’s pretty straightforward: just change your default Java version back to one that the Solaris Management Console can work with. While I have Java 1.6.0 and 1.8.0 installed on the Ultra 45, with 1.6.0 being the default, the SMC will only work when 1.5.0 is set as your default Java version. There’s a wide variety of ways to do this, ranging from hatchets to scalpels, but considering nothing else on Solaris 10/SPARC on the Ultra 45 relies on 1.6.0 or later (as far as I can tell, at least), I took a hatchet approach and just changed the /usr/java symlink so that it pointed to 1.5.0 again.

cd /usr
rm java
ln -s jdk/instances/jdk1.5.0 java

It’s that simple. Like I said, there are far more elegant ways of doing this, down to various scripts and other things to force only the SMC to use this specific Java version, but it’s not worth the effort to figure that out, and this works just as well. So, just in case there’s ever going to be a second person looking to fix this problem, here you are.

You weird, weird person.