The Solaris Migration FAQ is intended for sysadmins and programmers in the process of migrating from Solaris 1 to Solaris 2. For a more general FAQ on Solaris 2, we recommend the Solaris 2 FAQ by Casper Dik.
Much of the contents of this FAQ are derived from Casper's work, by permission. We are always looking for additions, corrections and suggestions.
That depends -- on you, your situation, your application mix, etc. Some year Solaris 1 will go the way of the 3/50 -- it'll still be around, but Sun will no longer support it.
You don't have to upgrade immediately, but you should be planning your upgrade path by now.
Solaris 2.0 only ran on desktop SPARCstations and a few other Sun machines.
Solaris 2.1 and 2.4 and later come in two flavors, SPARC and x86.
Solaris 2.1 and up for SPARC run on all SPARCstations and clones, as well as all models of the Sun-4 family. The old FPU on the 4/110 and 260/280 is not supported, so floating point will be slow, but it does work.
All version of the Openboot PROMs should work under Solaris 2.x.
A Solaris port for the PowerPC is underway. IBM will be selling systems with Solaris pre-installed and shrink-wrapped for people who bought a different OS with their PowerPC. The first systems are expected to be 66MHz 601s and 603s. (SunExpert 11/94)
Solaris 2.1 and 2.4 for x86 has been released to end users. It runs on a wide range of high-end PC-architecture machines. "High-end" means: 16MB of RAM and an 80486 (or 33MHz or faster 80386DX). It will not run on (for example) your 4 MB 16MHz 386SX. Also, floating point hardware (80387-style) is absolutely required in 2.1. Starting with Solaris 2.4 for x86, a floating point co-processor is no longer required, though still recommended. All three buses are supported: ISA, EISA, MCA. Some PCI devices are supported, though full bus nexus support for PCI is not there.
To summarize all this, Jim Prescott and Casper Dik supply this chart:
Solaris SunOS OpenWin Comments
1.0 4.1.1B 2.0
4.1.1_U1 2.0 sun3 EOL release (not named Solaris)
1.0.1 4.1.2 2.0 6[379]0-1[24]0 MP
1.1 4.1.3 3.0 SP Viking support
1.1C 4.1.3C 3.0 Classic/LX
1.1.1 4.1.3_U1 3.0_U1 4.1.3 + fixes + Classic/LX support
1.1.1 B 4.1.3_U1B 3.0_U1 1.1.1B + SS5/SS20 support
1.1.2 4.1.4 3_414 The "final" 4.x release (SS20 HS11)
2.0 5.0 3.0.1 sun4c only
2.1SPARC 5.1 3.1 Dec '92
2.1 x86 5.1 3.1 May '93
2.2SPARC 5.2 3.2 May '93
2.3SPARC 5.3 3.3 Nov '93
OpenWin 3.3 is X11R5 based: Display
PostScript instead of NeWS, no SunView.
It is still primarily OPEN LOOK.
The Spring 1995 OpenWin will be Motif
and COSE-based.
2.3 edition II SPARC Special Solaris 2.3 distribution for
Voyager and SparcStation 5
2.3 hardware 5/94 SPARC ??
2.3 hardware 8/94 SPARC Supports S24 (24 bits color for SS5),
POSIX 1003.2, Energy Star power management
and SunFastEthernet + patches.
2.4 5.4 3.4 From this moment on, the SPARC and x86
releases are in sync. Q3 '94
Adds motif runtime and headers (not mwm).
2.4 hardware 11/94 First SMCC release of 2.4
2.4 hardware 3/95 Second SMCC release of 2.4 (includes support
for booting from SSA). Last release to
support Sun4 systems (4/1xx, 4/2xx, 4/3xx,
4/4xx).
2.5 5.5 3.5 Nov '95. Supports Ultra-1 systems.
Includes CDE 1.0.1.
2.5 hardware 1/96 Supports Creator frame buffers on Ultra-1.
2.5.1 5.5.1 3.5.1 May '96. Supports Ultra-2 and Ultra
Enterprise systems. Includes CDE 1.0.2.
The complete and often updated list of Solaris x86 hardware options can be obtained by sending an email message without subject/body to:
or:
x86-hwconfig@Cypress.West.Sun.Com
This address currently sends out info on Solaris 2.4.
Any SS10, SS20 or SS600 series system with SuperSPARC MP.
Any system containing a 24-bit frame buffer (ZX, SX, S24). SS5, SS10 and SS20 Systems can run Solaris 1 if a different frame buffer is used.
The SPARCstation Voyager.
The XDbus machines SS1000/SC2000.
All Ultra series machines.
A full install of 2.2 is supposed to be 164 MB, but that doesn't include swap. Here is a net exchange between Casper Dik and Gil Tene:
In article <1993Apr2.083549.19177@fwi.uva.nl>, Casper writes:
|> >How much disc space does SOLARIS take up ? That is should we buy a
|> >424MB disc or get a 1Gb disc to put it on :-)
|>
|> Solaris 2.x takes about as much diskspace as SunOS 4.x:
|>
|> Partition/Slice Solaris SunOS
|> / 10MB 8MB
|> /usr 78MB 90MB
|> /var 10MB 10MB
|> /usr/openwin 83MB 83MB
|>
Gil replies:
On my system, with a full Solaris installation (EVERYTHING selected)
+ gnu's binary stuff for solaris (off of the Catalyst CD) installed
in /opt I see a similar situation to the above plus :
16852 /opt/SUNWabe
19 /opt/SUNWcg12
7968 /opt/SUNWdiag
721 /opt/SUNWgt
14609 /opt/cygnus-sol2-1.0
(output from "du -k -s /du/*")
- SUNWabe is the end user answerbook stuff. (vi, mail, Deskset tools
etc, etc)
- SUNWcg12 is (obviously) cg12 support.
- SUNWdiag is obvious too.
- SUNWgt is support for gt boards.
- SUNWits is the xgl3.0 library (it has libPEX5.so.1 in there too).
- cygnus-sol2-1.0 is the gcc2.0+tools stuff. I have gcc2.3.3 on
another partition and that takes about the same space as 2.0 does.
Another important note: The full Solaris 2.1 answerbook takes up 164MB
on disk. I highly recommend installing it and not using it off the
CD ROM drive. It's much more usable (faster) this way. And it always
stays around -- even when you have something else in the CD ROM drive.
Yes, that is possible. All partitions other than the system partitions (typically /, /usr, /var and /opt) can be shared by the two OSes. All partitions, including the system partitions, can be mounted and accessed by either OS.
The easiest way to set this up is to do separate suninstalls on two different disks. Then just choose the appropriate disk at boot time with the PROM's "boot" command.
Setting up both OSes on one disk is a little harder, but not much. You need to partition the disk to allow for both OSes. Almost any partition layout is possible, but one common setup might be:
a: / for Solaris 2
b: swap (shared)
c: The usual (whole disk)
d: / for Solaris 1
e: /usr for Solaris 1
g: /usr for Solaris 2
Again, it's most reliable to use suninstall to do the installations. If for some reason you choose not to use suninstall, make sure you run installboot for both bootable partitions.
With this setup, you choose between the two OSes in the PROM's "boot" command as follows:
To boot Solaris 2: boot
To boot Solaris 1: boot disk:d
Note: In boot PROM versions <= 2.5, the "disk:d" syntax is not supported , and the PROM cannot boot from root partitions that begin or end beyond 1GB.
Yes. You need the Solaris network transition kit available from Sun. However, this kit does not include the securenets patch. Patch 101363-08 supposedly fixes this. This patch includes all of the nskit, so there's no need to get more than just the patch.
Yes. In Solaris 2.6, NIS is an integral part of Solaris. To run NIS under Solaris 2.5 or 2.5.1, you can use the NIS Kit, more correctly known as NSKit 1.2. NSKit 1.2 is available on the Server Supplement CD included in the Solaris 2.5 and 2.5.1 Server media kits.
Unless you are running a version of Solaris earlier than 2.5, the Solaris media kit is the right place for you to find NIS or NSKit. If you are running a version of Solaris earlier than 2.5, perhaps now is the time to consider an upgrade to Solaris 2.6.
Note: NSKit is part of the Server media kit because you only need NSKit to provide NIS services. NIS client support is built in to all versions of Solaris 2.
As with SPARC, there is an emulation mode that should run the majority of well-behaved SVR3 and Xenix binaries. Most SVR3 stuff appears to work under Solaris 2.4.
Applications from any other vendor's standards-conforming 386/486 SVR4 should also run.
However, some vendors have made incompatible changes to their SVR4 release and programs linked on those versions may not work. Future versions of Solaris 2 for Intel will address some/most of those incompatibilities. Unixware is one of the offenders.
Most commercial software that ran on Solaris 1 either will run in BCP mode, or is available for Solaris 2, or is being ported now. Solaris 2.3 BCP mode finally supports statically-linked executables.
You can obtain a list of official 3rd party porting commitments, maintained by Sun's "Solaris Demand Center", by sending electronic mail to sparc_products@thegift.sun.com -- this is an automatic reply server. The list shows what third party applications are currently available for Solaris, and lists expected dates for many more.
You may also wish to use the Web interface to this database.
A list of freeware (some "public domain", but mostly copyright- but-freely-distributable) [as well as commercial software??] that has been ported to Solaris 2 is posted monthly to the newsgroup comp.unix.solaris by ric@updike.sri.com (Richard Steinberger). Look for the subject "Solaris SW list. Monthly Post.".
If you can't wait, the list is also available via anonymous FTP from updike.sri.com.
Finally, Steve Christensen maintains a Web database of freeware for Solaris at Sunfreeware.com.
There are too many of these changes to include in this FAQ, but here are some key ones:
This information can be found in the Solaris 2 Transition Guide -- Appendix A (commands), Appendix B (system calls), Appendix C (files).
This guide has undergone some changes from 2.0 and 2.1 and beyond. Several manuals have ended up being combined into this single manual. This manual discusses administrative transition and developer transition issues.
You can consult the online Solaris 1.x to 2.x Transition Guide.
Solaris 2 uses the "Content-Length:" header to tell the MUAs where messages should be split. Unfortunately, few other OSes support this convention. Instead, the old convention, ``split on "From " lines'' is used most of the time. Those mail readers expect extra lines with "From" to be escaped with ">".
Workaround: add "E" to the mailerflags of the local mailer. Edit /etc/mail/sendmail.cf on your Solaris machines 2, adding E to F= on the line that reads:
Mlocal, P=/bin/mail, F=flsSDFMmnP, S=10, R=20, A=mail -d $u
so that it becomes:
Mlocal, P=/bin/mail, F=EflsSDFMmnP, S=10, R=20, A=mail -d $u
Vacation was moved from /usr/ucb (in Solaris 1) to /usr/bin. Unfortunately, the full pathname must be specified in your .forward.
Workaround: add a link to /usr/ucb/vacation in /usr/bin on Solaris 1 machines, and add a link to /usr/bin/vacation in /usr/ucb on Solaris 2 machines.
In SVR4, there is a mode called "mandatory file locking" which is represented by an "l" in the group execute field. This mode is not supported over NFS, and so such files are by default unreadable and unwriteable on NFS clients. Unlike most permissions, mandatory file locking is enabled by a combination of two bits. The set-group-id bit is set and the group execute bit is cleared. If all other bits are cleared, this appears as symbolic mode 2000.
In ls -l output, such a file might look like this:
-rw-r-lr-- 1 me mygroup 0 Nov 11 11:11 myfile
On BSD-derived systems such as Solaris 1, this same combination of bits has no meaning, and appears in ls -l output as an uppercase S in the group execute field, for instance:
-rw-r-Sr-- 1 me 0 Jan 1 00:01 myfile
Note that normally a file intended to have set-group-id behavior is an executable file, and so both bits are set and a lowercase s is used, for instance:
-rwxr-sr-x 1 me 0 Jan 1 00:01 myfile
Such a mode might be set inadvertently if a non-executable file were in a directory tree that had a recursive chmod g+s applied to it:
host% ls -ld mydir -rwxr-xr-x 1 me 0 Jan 1 00:01 mydir host% ls -l mydir -rw-r--r-- 1 me 0 Jan 1 00:01 myfile host% chmod -R g+s mydir host% ls -ld mydir -rwxr-sr-x 1 me 0 Jan 1 00:01 mydir host% ls -l mydir -rw-r-Sr-- 1 me 0 Jan 1 00:01 myfile
When this same file is viewed on a Solaris 2 system, the "S" becomes an "l", and if on an NFS file system, is unreadable. You can apply a "chmod g-l" to fix the problem if you have write access to the file. Otherwise, you'll have to find someone that does.
Also note that Solaris 2.x will attempt to prevent you from setting mandatory file locking inadvertently. Any attempt to chmod g+s on a non-executable file will generate an error:
chmod: WARNING: Execute permission required for set-ID on execution for myfile
Instead, you must explicitly specify "g+l", or use symbolic mode.
The other machine (an NFS server) is running 4.1.x and needs a patch to update its network lock daemon (lockd). If you don't install the patch on the server, file locking will not work on files mounted from that machine.
The lockd patches are 101817 (for 4.1-4.1.2), 100988 (for 4.1.3), 101784 (for 4.1.3_U1) and 102264 (for 4.1.4).
There is no C compiler included in Solaris 2. The /usr/ucb/cc script you are executing is a wrapper for the SunSoft C compiler which calls the native C compiler with the /usr/ucb includes and libraries. You need to get yourself a C compiler. Alternatively, you may have forgotten to put the proper link from /usr/ccs/bin/ucbcc to /opt/SUNWspro/SCxxxx/cc in place.
Sun has dropped their old K&R C compiler, supposedly to create a market for multiple compiler suppliers to provide better performance and features. Here are some of the contenders:
SunPro, SMCC, and various distributors sell a new ANSI-standard C compiler on the unbundled (extra cost) SPARCcompiler/SPARCworks CD-ROM. There are some other nice tools there too, like a "make tool" and a visual diff (interactive diff).
You have to license and pay per concurrent user.
Cygnus Support and the Free Software Foundation make the GNU C compiler for Solaris, a free software product. Source code and ready-to-run binaries can be installed from the CDware CD (volumes 4 or 5).
Like all GNU software, there are no restrictions on who can use it, how many people can use it at a time, what machines it can be run on, or how many copies you can install, run, give away, or sell.
Cygnus sells technical support for these tools, under annual support contracts.
The Cygnus distribution includes: gcc (ansi C compiler), gdb (good debugger), byacc (yacc repl), flex (lex repl), gprof, makeinfo, texindex, info, patch, cc (a link to gcc)
The Cygnus compiler on uunet is starting to show its age a bit. If you want to compile X11R5, you can get the latest version of GCC in source code, from the usual places (prep.ai.mit.edu or one of the many mirrored copies of it). Build and install that compiler using the Cygnus gcc binaries. Or get tech support from Cygnus; they produce a new version for their customers every three months, and will fix any bug you find.
Gcc is available from the GNU archives in source and binary form. Look in a directory called sparc-sun-solaris2 for binaries. You need gcc 2.3.3 or later. You should not use GNU as or GNU ld. Make sure you run just-fixinc if you use a binary distribution. Better is to get a binary version and use that to bootstrap gcc from source.
GNU software is available from:
Solaris ships with everything you need, except for the compiler. All of these live in /usr/ccs/bin and /usr/ccs/lib. If you still can't find it, make sure you have the following packages installed on your system:
ranlib?The functionality provided by ranlib in SunOS 4.1.x is now
merged into ar. It is no longer necessary to run ranlib
on archive libraries. Fix makefiles that require ranlib
by replacing it with /bin/true.
In Solaris 2.5, ranlib has returned for makefile
compatibility, although it actually does nothing.
The C library has exploded. The manual page may give an indication where to find a specific function.
Those libraries are essentially split over two directories; /usr/lib and /usr/ccs/lib.
Important libraries:
bcopy, bzero and friends?They are in /usr/ucblib/libucb.so. The b* functions are replaced with the ANSI-C equivalents. Look in the Solaris 2 FAQ for more details.
In Solaris 2.5, these functions are once again in libc.
You're probably linking with libucb. (Readdir in libucb.so wants you to include sys/dir.h, but many Solaris 1 programs included <dirent.h>, consequently, you're mixing native <dirent.h> struct dirent with libucb readdir(). The symptom of this mixup is that the first two characters of each filename are missing. Make sure you use the native compiler (default /opt/SUNWspro/bin/cc, which may not be in your PATH), and not /usr/ucb/cc.
Routines that support encryption, such as makekey(), are restricted by federal law from export outside of the US, so are broken into a separate package called the "Encryption Kit." (This is a change from Solaris 1, where there were two versions of the operating system, a domestic version and an export version.)
The encryption kit is part SOLE-P and can be ordered through your normal sales channel or via Sun Express (1-800-USE-SUNX).
BCP is a standard part of Solaris 2 which allows you to run your SunOS binaries unchanged under Solaris 2. As of Solaris 2.3, both statically and dynamically linked binaries are supported.
Nothing. Just run your application as usual. Solaris will recognize that your application is a SunOS application and automatically execute it using the BCP libraries.
Since BCP simply provides a different path into the kernel than native Solaris 2 applications use, the additional overhead of running SunOS applications in BCP is minimal. Note, however, that the performance characteristics of any application may change when moving from one version of the operating system to another.
The vast majority of SunOS applications will work using BCP, but there are some things which BCP does not support. Applications which do any of the following will not work using BCP:
Also, applications may not work if they:
Applications which do none of the above things should work properly using BCP. If you have an application which you believe follows the above rules but still does not work using BCP contact your local service provider.
Sun has a variety of resources you can use to help port your application to Solaris 2. The Solaris Migration Tool can help you do the port yourself. Or you can get porting assistance from the Solaris Migration Centre, or from Sun Consulting. Please note that there may be a fee for porting services.
Most shell scripts will run unchanged. If you do have a problem with a shell script that cannot be solved by simply changing the PATH variable used by the script to find commands, the scriptran tool, which is part of the Admigration Toolkit, can help you convert your shell scripts for use with Solaris 2.
No. BCP is intended to make migrating to Solaris 2 faster and easier. It is not meant to be a long-term solution, and does not support the debugging features generally considered necessary for new software development. In the long run, we strongly encourage you to develop portable application code which can be compiled and run native on Solaris 2. In many cases existing source code simply can be recompiled for Solaris 2. If source code changes are required, you may be able to automate them using the Solaris Migration Tool.
In brief, the problem is that statically linked Solaris 1 apps won't look at the NIS (yp) passwd and group maps unless a "+" line appears in /etc/passwd and /etc/group. A default NIS client 2.3 install will not have "+" lines in these files.
The underlying issue is discusssed in the Solaris 2.3 Binary Compatibility Manual, pages 6-7. This manual is in the Solaris 2.3 Software Developer AnswerBook, which is part of the Solaris 2.3 SDK.
The following simple program, statically linked under Solaris 1, shows the problem when run under Solaris 2.3 BCP.
#include <stdio.h>
#include <pwd.h>
main(argc,argv)
int argc;
char *argv[];
{
struct passwd *pw;
if (argc >= 2)
if ((pw = getpwnam(argv[1])) == NULL)
printf("No passwd entry for %s\n",argv[1]);
else
printf("uid = %d\n",pw->pw_uid);
}
To resolve the problem, first edit /etc/nsswitch.conf.
Replace:
passwd: files nis group: files nis
with:
passwd: compat group: compat
Then add a "+" line to the end of /etc/passwd and /etc/group.
Consult the man pages for nsswitch.conf(4), passwd(4), and group(4) for a more detailed explanation.