Very Computer

We've just upgraded one of our main servers from 2.3 to 2.4.

It didn't go without a hitch.

The first thing that happened was this: the upgrade
process hung.  After opening a terminal window and
running ps we found that the upgrade process was
running fsck -m /dev/dsk/c2t2d0s0.

Truss told us that this hung reading from standard input.
Typing return in the console window made it continue
but fail.

The error, of course, was that the disk in question was 4GB
in size.  In which case you need to fsck the raw device.

Commenting the disk out in /etc/vfstab did work, but wasn't proper (as
recommended in the install notes) because the disk did contain
installed files.

Now for the second, much bigger problem.

After restarting installtool (restarting the install is easy, it doesn't
require a reboot which is pretty slow from CD), it ran for
a while and then crashed.

Truss told me that is crashed after reading all the pkgs fils and the
contents files.

Finally, in despair, we decided to remove all the .<num> packages that
are installed by installpatch.

Only then the upgrade did work.

Summarizing I can say that upgrading disks > 2GB doesn't work nor
does it work on heavily patched systems.

Casper

Quote:>Finally, in despair, we decided to remove all the .<num> packages that
>are installed by installpatch.

>Only then the upgrade did work.

Did you actually use pkgrm/backoutpatch on them, or just get rid of
the *.<num> directories under /var/sadm/pkg?

Presumably Solaris 2.4 overwrites the 2.3 version of every file the
2.3 OS packages put there, so it doesn't much matter if there are
records of those patches. But did you restore the ones that corresponded
to non-OS packages (e.g. compilers) afterwards?
--
Ruth Milner                            NRAO                  Socorro NM

: We've just upgraded one of our main servers from 2.3 to 2.4.
: It didn't go without a hitch.
: After restarting installtool (restarting the install is easy, it doesn't
: require a reboot which is pretty slow from CD), it ran for
: a while and then crashed.

I don't think I've ever trusted anyone's install or upgrade programs.
I've always found it safer to
- isolate system-specific info from system files or have it generated
by separate configuration programs, none of which live in the same
place as system files
- keep things cookie-cutter, even on servers
- when upgrading, blow away / and /usr and load the new cookie cutter

I've found that rebuilding the server from ground-up has, in
every instance (on a 400+ node network) been faster than sitting
around waiting for an upgrade program to do its thing. maybe it takes
a bit more effort on my part, but it gets the system back up lots
faster so the users can get back to work...

-bacon
but I'm also lazy

I did a pkgrm of all the .<num> packages on the system.
(even those of the SPRO compilers and other patched software)

When autoinstall crashed, I cd's to /a/var/sadm/pkg (all filesystems
where still mounted under /a.)
Then did a pkgrm -R /a *.[1-9]*
and typoes a lot of y<return>s.

Quote:>Presumably Solaris 2.4 overwrites the 2.3 version of every file the
>2.3 OS packages put there, so it doesn't much matter if there are
>records of those patches. But did you restore the ones that corresponded
>to non-OS packages (e.g. compilers) afterwards?

No, net yet anyway.  The record is kept in two places: the .<num>
package files under /var/sadm/pkg but also in /var/sadm/install/contents.
Restoring just the package files would not be enough.
If you are worried about keeping your system info complete,
you can first move the directories under /var/sadm/patch away.
Then reinstall the patches (which effectively doesn't change a thing on
your system, except that the new files are saved).
Then you can remove the new directories in /var/sadm/patch and
put the old ones with the old save files in place.

After that I also had to remove the patch directories by hand (the
upgrade system could no longer detect that patches had been installed)
(no wonder)

Casper