Dear Sun Managers:
Here is the summary of responses to my questions of a week and a half ago
regarding installation of Solaris 2.1. I actually went ahead with the
installation before I had gotten any responses, but I subsequently received a
few responses which corroborated what I discovered during the installation. I
also have some battle-scar "tips" to share with those of you who have yet to
do your first Solaris 2.x installation. :-)
---><---
With regard to using a "/var" slice, I asked the following two questions:
1) Is the Solaris 2.x "suninstall" with its new default partition size
calculations smart enough to handle a separate /var "slice"
automatically?
2) If not, for an "entire release" installation, how much can I reduce
the root slice when I create a /var slice, and what is the minimum
size for /var?
In fact, the new "suninstall" is quite smart about calculating partition sizes
and spreading the software across slices and disks according to your
specifications. As usual, there is some extra padding in most slices, which
you might want to manually trim back. (Of course, you can't figure out how
much smaller you could have made things until *after* you install a particular
configuration and actually see how full the various slices are.) The / slice
is bigger, even with a separate /var, than under SunOS 4.x, apparently to make
room for the dynamically loadable kernel.
Note: I had originally planned to preserve my /usr/local and /export/home
partitions (which are on a separate disk) from SunOS 4.1.3 and remount them
after the installation, with the old /usr/local on the new /opt. However, it
turns out that some packages in Solaris 2 install files into /opt, so you are
kind of forced to redo your old /usr/local if you want these packages (which
are SunDiag, the end-user AnswerBook, cg12 support, gt support, and XGL). For
reasons which I discuss below, this turns out to be a good thing anyway.
---><---
My next question concerned swap space in Solaris 2:
3) Given the new "virtual swap space" implementation in SunOS 5.x, does
anyone have good heuristics for sizing swap slices in the new
environment?
As Hal Stern pointed out, an article of his addressing this very issue
appeared in the system administration column of the January issue of
Sun_World. Over-simplifying somewhat, whereas the rule of thumb in SunOS 4.x
was that total virtual memory ~= swap space, the rule for Solaris 2 is that
total virtual memory ~= (physical RAM - kernel RAM + swap space). This is
good news for those of you with tremendous amounts of RAM who don't want to
devote entire disks to swap space.
---><---
My final two questions dealt with trying to get information about the sizes of
various packages so I could get an idea of just how "entire" an installation I
wanted to do:
4) Does "pkgchk" output sizes for packages? If so, perhaps someone
could mail me the output of this command for an entire release
installation.
5) Qualitatively, is the potential space savings even worth the effort
of customizing the installation to this extent? I want all of the
new Solaris items, plus the binary and source compatibility packages,
at least temporarily, but I don't need the things for backward OS,
NIS, or window support.
The capability of "suninstall" to descend into packages within groups within
clusters (ad nauseam) makes these questions pretty much moot. As you select
and deselect packages, "suninstall" dynamically updates the disk space
requirements for each slice on-screen, so you can experiment with
configurations to your heart's content. You can toggle back and forth between
software selection and disk configuration to get things just the way you want
them. As it turned out, the potential space savings in / and /usr for leaving
out the features I mentioned was minimal; there was more to be gained by
fine-tuning what went into /opt. (Oh, for those who care: "pkginfo -l",
rather than "pkgchk", will give space usage for an installed package.)
---><---
Here are miscellaneous things I learned which others might find useful:
1) Upgrading to Solaris 2.x is a good time to consider reformatting all disks
involved and building new filesystems on all slices. Both "format" and "mkfs"
can now put volume and filesystem labels, a "volume table of contents" and
related items on disks. It also appears that "format" now handles SCSI disks
in a more native fashion. You don't have to reformat or "newfs" preserved
filesystems, since the filesystems are upward- and downward-compatible (as
long as you don't make use of the new features), but now is as good a time as
any to go for it...
2) If at all possible (and if you haven't already done so), change the
broadcast address on your network to use all ones in the host bits, instead of
the SunOS 4.x default of all zeros. If you want the upgraded machine to be a
client of an existing NIS server, then suninstall itself will try to bind to
the server during the installation. While it appeared to work before I
changed the broadcast address on our network, there were some subtle and
sporadic problems which went away when I re-did the installation after
changing our broadcast address. It's got to be done eventually anyway, so you
might as well do it now...
3) If you are planning to install the full Solaris 2.x AnswerBook, then you
might want to deselect the "end user AnswerBook" during suninstall, so that
you can install it later on the same disk/slice with the system AnswerBook and
perform a "merge", as described in the documentation.
I'm sure there were other things, but they don't come to mind right now. All
in all, I found the new suninstall even smarter and more convenient than the
SunOS 4.x version.
Before signing off, I would like to thank the following people for responding:
csdnet!ilbeig@uunet.UU.NET (Amir Ilbeig)
Robert.Chur@Central.Sun.COM (Robert Chur)
stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
randy@aslan.nlm.nih.gov (Rand S. Huntzinger)
--
Thanks and Good Luck,
Greg Jumper
TRW Signal Processing Facility
jumper@spf.trw.com
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:27 CDT