Summary: Upgrade Server to Sol9, what about packages and compiled software

Hello,
   Sorry for the later summary, but of course I wanted to finish the
upgrade before writing.  Thanks to the following (in no particular order)
for responding:
 John Elser <jElser@ck8.uscourts.gov>,
Tim Evans <tkevans@tkevans.com>,
Kevin Buterbaugh <Kevin.Buterbaugh@lifeway.com>,
Kevin Reichhart <KReichhart@yantra.com>,
David Foster <foster@dim.ucsd.edu>,
"McCaffity, Ray (Contractor)" <McCaffityR@epg.lewis.army.mil>

   Basically everyone said that they would definitely upgrade vs. install
from scratch - This is what we did and everything came out fine!
   David Foster also included some helpful notes as well as a Sun
blueprint document (see the end of this email).


   First we coppied the disk with our OS file systems (/, /var, Etc) to a
"new" disk that we weren't using for anything, so that we could revert
back to the old disk in the event something unexpected happened.  At the
suggestion of a few list members I had looked into live upgrade, but
wanted to understand the inner workings of live upgrade a bit more through
experience before trying it out on our primary server.  We coppied the
partitions from the existing disk to the new disk by
dumping it to a file with ufsdump, and then restoring that file to
mounted partitions on the new disk.  We originally tried using
ufsdump piped directly into ufsrestore, but got lots of error messages about not
being able to restore files because they were not on the volume.
   We next installed boot blocks on the new drive with:
installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t12d0s0

   Once we switched disks around so that the copy of our OS disk was c0t0,
and successfully booted from the "new" disk, we made sure that the latest
recommended patch set was installed and then commented out all unnecessary
partitions in /etc/vfstab (home partitions, /export).  Before starting the
upgrade we deleted /etc/init.d/sshd, /etc/rc3.d/S75sshd, /etc/ssh/, and
/etc/ssh2/ because we wil be using OpenSSH
now instead of the comercial SSH client and server we have been using.
   After booting from the Install CD (apparently you can't boot from the
DVD), letting the installer copy itself to our swap partition, and then
using the DVD to perform the upgrade (which took about two and a half
hours) we rebooted and fixed a few minor things which the upgrade had
broken:
   We restored our own /etc/init.d startup script for samba (it had been
replaced with a script for samba which gets installed in /usr/sfw),
restored our slightly C2 security tweaked copy of the Makefile in /var/yp
(it had been overwritten with a new Solaris 9 version which we will soon properly
modify as we did the Solaris 8 Makefile, and recreated our sendmail.cf
from the .mc file which we luckily still had (the old sendmail.cf file did
not work with sendmail 8.12.2) so that VirtUserTables
(per-domain email aliases) and GenericsTable (rewriting of outgoing email
addresses) kept working.

   Here are the notes that David forwarded along, as well as my original
post below.  Thanks again to all who encouraged that I not reinstall.


----------
Blueprint document provided by David Foster:
http:// www.sun.com/blueprints
Part No.: 806-5333-10 Revision 01, April 2000

----------
SOLARIS_UPGRADE_CHECKLIST  11-29-01  DSFoster

--------------------------------------------------------------------------------
Upgrade Troubleshooting Tips

Before starting an upgrade, please check for these common problems.

I. BACKUP!

Do a level 0 dump of all filesystems before doing anything under this document.

II. /etc/vfstab

- Comment out all NFS entries.
- Check for multiple swap entries. Comment out all except for one simple
  disk based swap partition.
- Comment out all data (or non-O.S.) partitions.
- Make sure root partition is on slice 0
- Having entire O.S. in slice 0 is OK.
- Make sure there are no /dev/md/ devices. If any exist, see DISKSUITE section
below
- Make sure there are no /dev/vx/ devices. If any exist, see Volume Manager
  section below

III. FSCK

- Make sure devices to fsck are 2 GB or smaller.
- Boot from cdrom and run fsck by hand to fix problems prior to upgrade.

IV. LINKS

- Watch out for links that use absolute paths. Upgrade will overwrite links
  that it can't reference. This could cause the partition to run out of
  disk space.
- Remove packages that will make changes to automounted directories.
- If symbolic links exist from /var/sadm, either restore the files on
  the /var partition or do a full install.

V. /var

- Make sure /var is under root or a separate partition. /var should not be
  a link.
- /var/sadm must not be a link or a separate partition.
   Must be directly under /var.
- If symbolic links exist from /var/sadm, either restore the files on
  the /var partition or do a full install.
- Run upgrade.chk to make sure /var/sadm/install/contents is not corrupt.
- Make sure /var/sadm/softinfo/INST_RELEASE exists and the contents look like;
  OS=Solaris
  VERSION=2.3
  REV=0


------------------------------------------------------------------------------
DISKSUITE

DISKSUITE needs to be disabled on OS disks prior to the OS upgrade.

The actual upgrade procedures for DISKSUITE-systems are
found in different places depending on the version of DiskSuite.
You might want to check Appendix D of the Solstice Disksuite 3.0 through 4.1
Administration Guide.  For DiskSuite 4.2 and above, there is a seperate
installation and upgrade document.

Make certain that the new version of Solaris that you are upgrading to
can support the version of DiskSuite you are running, otherwise it
may be necessary for you to upgrade DiskSuite as well.

------------------------------------------------------------------------------
VOLUME MANAGER

Volume Manager must be disabled on OS disks prior to upgrade of the OS.
Refer to the Volume Manager Installation Manual for complete procedures
for upgrading Solaris with Volume Manager.  Even if you are not upgrading
Volume Manager, it is necessary to perform some upgrade functions with
Volume Manager - these steps are documented in the VxVM Installation
Guide.


----------

> > Hi all,
> >    I'll be faced with this project in the coming months and wanted to see
> > what you all think.  We have an E250 running Solaris 8, along with various
> > SunFreeware packages and software we compiled ourselves (all in
> > /usr/local).  I am pondering upgrading the server from Solaris 8 to
> > Solaris 9 vs. installing Solaris 9 from scratch - I have never been much
> > of an upgrade guy, I prefer to keep my data partitions (home, mail spool,
> > Etc) and instal from scratch wherever possible.  My concern in doing this
> > however, is that I would still like all of my 3rd party software in
> > /usr/local to work once I upgrade.  The compiled stuff will probably work
> > fine (depending on any configuration files which may live in /etc),
> > however I would like to retain the ability to uninstall or upgrade one or
> > more SunFreeware packages at a later date.  IF I install Solaris 9 from
> > scratch, there goes my package database correct?  I can't scheme a way to
> > keep package info for the SunFreeware packages so I can later interject
> > them into a new package database (after installing Solaris 9).  I can't
> > just copy over the package database from Solaris 8 for obvious reasons (it
> > will hose the package database from the Solaris 9 install).
> >
> >    What are folks typically doing in this kind of situation?  I look
> > forward to your responces, and of course will summarize.
> >
> > Thanks,
> > Ivan Fetch.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers