I asked for the difference between 4.1.3C and 4.1.3, and whether the
latter would run on a Classic. The short answer is that 4.1.3C is
nearly identical to 4.1.3, except that it has been modified to support
the Classic and LX hardware. (And so 4.1.3 will not work on these
hardwares.)
It appears that 4.1.3C has all the bugs (including security bugs) of
4.1.3, but that official patches have not been released. However,
some 4.1.3 patches apparently can be used on 4.1.3C (see below).
(Greg Limes said that the only difference is the added hardware
support, plus fixing *one* bug that was critical only in microSPARC
environments.)
A very complete explanation of the difference between 4.1.3 and 4.1.3C,
and various ways of handling the latter, was very kindly sent to me
by Christopher Lott (lott@informatik.uni-kl.de). I have enclosed his
entire message at the end, below, for the several people who asked me
to post what I learned.
My thanks to those who responded:
Steve Hanson, Wolfgang Ratzka, Robert Bonomi, Syed Zaeem Hosain,
Larry Hitz, Richard Tom, Greg Limes,
and especially Christopher Lott.
Thanks! Michael Johnson
fdmdjohn@ucf1vm.cc.ucf.edu
---- Here is the information sent to me by Christopher Lott. ------
<begin quotation>
In brief:
Releases 413 and 413C for the Sun4m architecture differ in the kernel
files under /usr/kvm/sys and files in the /usr/lib directory, just to
name a few. It appears that files immediately below /usr/kvm are
identical. In /usr/lib, at a minimum the files libc.* and ld.so are
different. There are also differences in some of the include files.
All of this means that you can't just copy a kernel from the 4.1.3C CD
and boot classics using a standard 4.1.3 /usr partition, because then
you'll use the old libc and ld.so. If you do this, any programs that
deal with time will probably dump core after reading the localtime file
(this was our experience). Examples are date, ps with -u option, ls
with -l option, etc. The releases are certainly binary compatible.
If you are determined to use a central copy of the /usr partition, I
have heard from people on the net that the only things you need from
the 4.1.3C distribution are the kernel files for the classic and the
revised /usr/lib/ld.so. These people have reported successfully using
a 4.1.3 /usr partition on the classics once the new ld.so is installed.
It is not clear whether the differences between the two versions of /usr
will effect running under certain circumstances.
***NOTE*** Solaris 1.1.1, a complete version of SunOS 4.1.3 for all Sun
architectures is expected in November 1993.
Genesis of 4.1.3C:
According to a reliable source, the 4.1.3C release is a direct port
of the 4.1.3 release to the classic/LX machines and incorporates none
of the patches released for 4.1.3. I guess this explains why they
did not name it 4.1.4, because it doesn't improve on 4.1.3, just
makes 4.1.3 available for more machines.
Experiment 1:
We booted and ran 4.1.3 on a Sun Classic BUT WITH /usr/lib MOUNTED
FROM A 4.1.3C PARTITION. This is why I'm fairly certain that the only
differences are the kernel and libc.
Experiment 2:
We booted and ran 4.1.3C on a Sun4c (IPX) successfully. Note that the
IPX was running a 4.1.3 kernel, because kernels for the sun4c
architecture are not distributed with 4.1.3C. However, the 4.1.3
distribution is included on the 4.1.3C CD.
PF7=ScrollUp PF8=ScrollDown PF9=Discard PF10=Switch PF11=Logd PF12=Cursor
Installation:
Here are a few critical questions to answer before looking at my list
of installation alternatives. I tried to explain our assumptions.
This list is certainly not complete.
Q1: Does every machine have its own copy of /usr?
If yes, see A1
Q2: Does /usr/openwin live on each machine?
If yes again, A1 is definitely for you
Q3: Do you run a central /usr server with 4.1.3 installed already?
If yes, any of A2-A4 is possible.
Now a few alternatives for installing 4.1.3C that we came up with.
In the release notes, sun says to use ``add_services'' to extract the
files from the CD. This essentially is alternative 2.
A1. /usr on each classic/LX
Use rdist to maintain consistency. This is simple, although lots
of work for all the installs. If a version of 4.1.3 with OW
exists on a central server, you can save space by mounting
/usr/openwin from that partition.
A2. Copy a 4.1.3C /usr onto the server under /export/exec/sun4.sunos.4.1.3C
This will require about 80Mb in /export if you leave out Openwin.
Useful for dataless or even dataful workstations. Again, openwin
can be mounted from a 4.1.3 partition.
A3. Boot the central server with 4.1.3C; i.e., upgrade to 4.1.3C.
Quite feasible if your whole installation is limited to classic/LX
machines. Not very realistic if you have other architectures,
because I don't think that Sun officially supports 4.1.3C on
PF7=ScrollUp PF8=ScrollDown PF9=Discard PF10=Switch PF11=Logd PF12=Cursor
anything but a classic/LX. But see experiment 2 above.
In the release notes, Sun states that sunupgrade as distributed on
the 4.1.3C CD does not work, but it is on the CD.
A4. Run classics/LXs with a 4.1.3 /usr and mount /usr/lib from a 4.1.3C
partition. You must edit /etc/rc.boot to mount the /usr/lib part.
This is clever, perhaps a little too clever. It will let you save
about 65Mb of files in /export/exec. See experiment 1 above.
Regarding patches:
At the present time (Aug 1993), there do not appear to be any patches
officially available for the 4.1.3C distribution, not even security
patches. The 4.1.3C release suffers from many of the same problems as
4.1.3 directly out of the box; the expreserve hole is one of them.
This made us very wary of booting and running 4.1.3C for good on our
central fileserver, a Sparc10, mainly because of the large number of
kernel patches that have been released for the sparc10 and for the
4.1.3 distribution in general. However, we installed 4.1.3-approved
patches for programs in the 4.1.3C /usr partition, including security
patches and OW patches. So far, so good. Due to kernel differences,
we did not even attempt to install kernel patches.
By the way, we chose the most conservative option: A2.
--- "Christopher Lott / Email: lott@informatik.uni-kl.de / Tel: +49 (631) 205-3334" "Adresse: FB Informatik - Bau 57 / Universitaet KL / D--67653 Kaiserslautern" <end quotation>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:26 CDT