I tried to post this once before, but it has been 2 days, and I
don't see it, so here it is again.
There IS a confirmed bug in sunupgrade going from 4.1.3_U1 to 4.1.4.
There have been several discussions about why you would want to do
this upgrade, but I don't care about that. I just want you to know
there is a bug.
My original bug report to Sun Technical Support was that I would run
out of space in /usr during the upgrade (4.1.3_u1 to 4.1.4 only,
plain 4.1.3 to 4.1.4 did not have the problem). I gave specifics and
hints to the technical support person (who shall remain unnamed to
prevent flooding him with email), and he sent the following reply.
As a summary, use '#' instead of '&' in the volatile_files list
originally generated by 'check_perm -v'; however, PLEASE READ
THE DISCLAIMER FROM SUN TECHNICAL SUPPORT AT THE BOTTOM.
====================================================================
Lee,
I've spent the past few days loading OS's and upgrading several times
and in different configurations.
First, I installed Solaris 1.1.1 (4.1.3_U1) on a SS5. Then I upgraded
to Solaris 1.1.1 rev B. I kept about 1/2 of the files with "+" and
the rest with "&".
At first I got a message stating "4.1.3_U1 not supported". I went
into /usr/sys/conf.common/RELEASE and changed 4.1.3_U1 to 4.1.3, and
check_perm -v was happy.
This upgrade ran flawlessly and the files with a "+" had the .413
tag and the files with "&" did not have the tag, as was expected.
I then ran check_perm -v again to upgrade to Solaris 1.1.2 (4.1.4).
I changed all of the entries in /usr/tmp/volatile_file from "+" to
"&" and of course this should not save a file with .413_u1 tag. And
as you already know, after running sunupgrade - it did save the files
with .413_u1 tags. I made oversize partitions in anticipation of
this to prevent running out of space.
I started from scratch and did the exact same steps as before up to
the point where things had run expectedly.
I mounted the Solaris 1.1.2 cd to /usr/etc/install/tar.
I ran check_perm -v.
I edited the /usr/tmp/volatile_file in the following way:
:%s/+/\&/ which changes all "+" to "&".
Of course we know that the above edit is basically useless.
I changed all the "&" to "#" on /usr/bin entries (all of them).
I did the same on /usr/ucb/vacation, /usr/lib/libplot.a, and /usr/games.
These files were picked randomly.
I changed all of the "&" back to "+" on /usr/etc/install/*.
I changed all of the "&" to "-" on /usr/diag/sundiag/*.
I then went to single-user and cd /usr/etc/install/tar/sunupgrade/shell.
Ran sunupgrade -v -x/usr/tmp/volatile_file.
These are the results after rebooting:
Files with "&" were created but also saved with .413_u1 tag (the bug you
reported).
Files with "+" had the same results as above (as advertised).
Files with "-" were not upgraded and retained their original date (as
advertised).
Files with "#" were upgraded but there was NOT a file saved with a
.413_u1 tag (the results we expected to see with "&").
I am in the process of filing a bug report on this and hopefully it
will be re- solved in a future release. I can not call this an
official fix yet, as I would like Engineering to take a look and make
sure using "#" instead of "&" doesn't break anything. I have not run
into any problems doing this in our lab environment however. I'll
keep you posted as soon as I receive any more info on this. You can
post this to newsgroups if you'd like as long as the following
statement is included in the post:
********************************************************************
THIS IS NOT A SUPPORTED FIX OR WORKAROUND AT THIS TIME! THE ABOVE
PROCEDURE DID NOT CAUSE ANY PROBLEMS ON STANDALONE MACHINES IN OUR
LAB ENVIRONMENT. THE ISSUE HAS BEEN BROUGHT TO THE ATTENTION OF
ENGINEERING AND THEY WILL MAKE A FINAL DETERMINATION ON IT.
********************************************************************
-snip - (a SunService Support Person who this poster left unnamed) -snip-
SunService
Chelmsford, MA
-- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ///// Lee Lindley Information Technology MTS rgltl@attme.cnet.att.com /| //// AT&T Microelectronics, PWB Headquarters, Richmond, VA, 804-226-5849 //| /// "What's the use of all this sophisticated equipment if it won't do ///| // what I want" -- Karen when her upgraded system printed the fonts ////| / in her complex docs differently. /////| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:25 CDT