OpenSolaris Successor: OpenSXCE (Part 1)

[OpenSXCE Mascot with Illumos Logo]

Abstract:

Solaris, once the standard in workstations, became the standard for datacenter server. Sun Microsystems had open-sourced Solaris, referring to it as OpenSolaris. Oracle, purchased Sun, released Solaris 11 upon the OpenSolaris foundation, and closed OpenSolaris. Various forks were made from the OpenSolaris code, Illumos being one of the most popular across various commercial businesses, but only OpenSXCE was successful in creating multiplatform SPARC and Intel editions. As of May 2005, Martin made his second release.

[OpenSolaris Logo]

History of OpenSXCE

Sun used to distribute a Solaris Express Community Edition (SXCE) and Solaris Express Developers Edition (SXDE) - but when Sun was preparing to drive towards Imaging Packaging system, these were canceled. OpenSolaris's final release supported both SPARC and Intel. One of the early forks from OpenSolaris was Illumos. Their premier distribution was OpenIndiana. OpenIndiana promised to also support SPARC and Intel, but people waited for years. Martin Bochnig invested the time into releasing an initial SPARC release of OpenIndiana, called MartUX. The Illumos and OpenIndiana team did not integrate his work, the wiki pages associated with his effort were purged, but Martin eventually released OpenSXCE - a fully SVR4 compliant SPARC and Intel release! At first, there was 2013.01 release, next came 2013.05. Martin was encouraged to possibly rename his distribution, to remove his name, and choose a more fitting title - OpenSXCE was born.

First Impressions

Considering the complexity & effort, the first 2013.01 DVD was impressive. The booting on SPARC actually worked, but the disk was only a live DVD. Clearly, he was close, and the community was amazed that he was able to do what former SPARC engineers from Sun Microsystems, who found their way to Illumos & OpenIndiana, were unable to accomplish!

A Pause and Moving Ahead...

Personal concerns forced me to severely curtail my community activity, much of the SPARC test equipment was placed into storage. As responsibilities started to clear more recently, the resurrection of SPARC equipment resumed.

[Sun Microsystems UltraSPARC 60 Desktop]

The Test Beds

A Microsoft Windows XP laptop with Hyperterimnal became the serial console for all servers.

Populating V120's with 15K drives began. Initial installations of SPARC Solaris 10 Update 10 had started, to ensure the platforms were functional. A single slim-line CD-ROM drive on a V120 platform with 3 Gigabytes of RAM would make a reasonable test-bed for a CD based Text based installer.

An Ultra 60 workstation with 2 Gigabytes of RAM was running a multi-terabyte file service using flash to accelerate the ZFS performance, but it's video card drop dead about 1 year ago. The Ultra60 has 2 Gigabytes of RAM and a DVD on-board, so it would still be reasonable for a DVD installer test.

[Solaris Logo]

The control case: Solaris 10

Solaris 10 can no longer be installed from a CDROM, but only from a DVD drive. Many older Sun platforms do not have DVD drives, and some DVD drives which fit those platforms are not always recognized.

Solaris 10 Update 10 has a nice feature where identical drives can be installed as a mirrored ZFS root during installation. This functionality was thoroughly tested by pulling drives out of the V120 while running an application which was performing constant writing writing to the disks, and a second application which was performing constant reading from those same disks - no indication of any hardware issues were noted by the applications, except error reporting on the console. The applications did not experience any degradation, even when drives were re-inserted, and resync'ing.

The resync'ing process for ZFS drives in a broken mirror takes seconds for short breakage durations, in contrast to other platforms where re-syncing a broken mirror would take hours, or sometimes days with larger drives. The applications on the Solaris 10 platform continued to operate flawlessly. during the operation.

[ZFS: The Default File System for OpenSXCE]

Second Impressions: OpenSXCE and Text Install

Windows Client Setup

If the terminal selection was not set to VT100 from the start, or Hyperterm was not correctly set to use Vt100, then the GUI might not operate as expected. Once the terminal was properly set up to use VT100 and Hyperterm was supposedly set up to use VT100 emulation, The installation went quickly. Most of the most common defaults were pre-selected, to make installation much easier.

SCSI Disk Drive Format

One of the two SCSI disks were not formatted, so I needed to drop out to a command line and format the disk. The "format" command was well known by my, but most people who use IDE, ATA, SATA, and USB drives are probably not familiar with the process. The process to conduct the format would have been nice had it been documented, but honestly - I don't remember seeing any recent UNIX operating system take people through that process automatically during the install process. The format command indicated it would take a little over 1 hour to format the drive - it took close to 24 hours to format the 72 Gigabyte 15K drive! (I am glad I did not have a 900 Gigabyte SAS drive, since even a hardened user might have thought there was a problem when such a format could have taken a week!)

Installation Notes

The installation documentation and process inform the user that the mirroring of the ZFS hard drives could be done after installation. This is a nice touch, since Solaris 10 Update 10 does this from the start as an option in the installer. This gives the user an opportunity to provide parity with Solaris 10 Update 10, without adding the complexity to the installer.

Install Experience

The installation was extremely quick - much faster than what I was expecting! I walked away during the install and it was completed when I returned. I will watch during my next install to time it properly. This truly beat Solaris 10 Update 10 install, hands-down.

There is an option to review the installation log, at the end of the install. The Hyperterm vt100 emulator appears to have been lacking since the screen split into 2 sides, where the left hand side seemed to scroll correctly, but the right hand side did not. Die-hard UNIX administrators would know that the [control][l] could be used to perform a refresh when the text screen became corrupt. It would have been nice to have such a warning, for new-be's - but I have not honestly seen such warnings for many years with textual installers.

Post-Install Experience

Pressing the [F8] key from the Hyperterm emulator did not initiate a reboot, at the final screen, as expected. There was a warning during the installation that function keys occasionally do not work from the emulators, and a user could revert back to using [ESCAPE] with a numeric aterwards. This worked flawlessly, the reboot started immediately after pressing [ESCAPE] followed by an [8].

Another thing which caught me by surprise, the root user was not allowed to log in from the serial console after installation, but the additional user specified during install MUST be used. I may have missed this during the installation warnings, perhaps it should be more clearly noted on the install screens.

There were some odd errors noted, with an "ldom" service, which did not surprise me since I was running on older SPARC hardware which did not support LDom's (or more recently known as Oracle VM for SPARC.) This functionality should only work on modern processors.It would be nice to have a check for old hardware and silently exit, or at least indicate that this is expected behavior on this class of hardware.

Amazing to me, there was no problem with the installation coming up in a fully functional way, with networking operating the way it was supposed to. This was some nice attention to detail.

Full Internet-Based Upgrade

The root user automatically provided a note which offered to upgrade the text installation from an external internet based repository. This was a wonderful addition, being able to use System V Revision 4 standard packaging formats for upgrading the OS from the internet! People may have noted that Sun (and later Oracle) decided to move from SVR4 packaging to a proprietary packaging format to get this feature, when clearly moving to a proprietary format was never needed for this functionality.

The internet upgrade time was 1 hour and 55 minutes, which was provided by the SVR4 packaging system. This was very nice forethought by the distribution! The command to boot into the new boot environment was provided by the upgrade process - kudos again to the distribution! The instructions were not as clear as they could be, for the process to reboot into the new boot environment, for new users.

Everything was not perfect. I lost my network functionality after the network upgrade from the internet. The process for mirroring the root disks with ZFS was not as clean as I had hoped.

[Sun Microsystems UltraSPARC IV Systems]

Final Thoughts

My first impression of the new system can be summed up in a single word: impressed. How could a part-time programmer from Eastern Europe do what was promised and could not be delivered by former staff of Sun Microsystems? Truly, this is "hat's off" time to Martin, I hope OpenIndiana or Illumos take some of his work "side-stream" or "upstream", and someone hires him to work on Solaris based engineering project!