Folks,
I recently raised this problem, but didn't get a big response.
Mike Raffety <mike_raffety@com.swissbank.us.il> pointed out that this error
probably related to ...
a standard system error number; from
/usr/include/sys/errno.h:
#define EROFS 30 /* Read-only file system */
....
I looked at the list of "volatile-candidates" and did some sums on filesizes.
I discovered that I was upgrading ~22megs of files in /usr. Specifying "&"
(ie "replace") in the volatile-file seemed to make no difference. It was
determined to keep old and new versions, ie "&" works the same as "+".
So don't believe the space requirements described in 4.1.1_U1 System
Installation Manual. Check the list of files you get from "check-perm",
and addup the current filesizes - it's near enough the space you'll need
for replacements. This seems to be a problem which is specific to 4.1.3C
(Classic) upgrades.
-------------------------------------------------------------------------
Gordon Robertson, Head of Systems, Aberdeen University Computing Centre
Tel +44(0)224 273340
E-Mail : g.robertson@abdn.ac.uk
--------------------------------------------------------------------------
Here's my original query...
I sunupgrade-ed a number of clients and servers from 4.1.3 to 4.1.3_U1 and it
all went hunkey-dorey. Then I tried a standalone Classic running 4.1.3C, and it
went down the tubes. I got suspicious when I noticed the 1300-odd files in
volatile_candidates. I was right. This was a simple system with no
openwindows,sunview, games or demos. I set up a few "-" entries in
"volatile_files" changed the "+"s to "&"s and fired off sunupgrade. It got well
into catagory "usr" and then blew up as follows...
Error 30
Sunupgrade aborted
Does anyone know how to get round this?
I checked space available and have 10Megs in root and 13Megs in /usr.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:57 CDT