update(8) update(8)
NAME
update - update operating system
SYNOPSIS
/etc/update -r file
/etc/update -a|-c [-o] [-e]
/etc/update -h
DESCRIPTION
The operating system update consists of updating the Reliant UNIX
operating system software, i.e. the software on the "Reliant UNIX"
CD-ROM. The operating system is for the most part packaged in PKG for-
mat.
The update, or to be more exact the /etc/update command, is controlled
using options. An overview of the options available can be found using
the /etc/update -h command (see also OPTIONS).
The operating system software is the same as is used in a new instal-
lation of a system. That is to say, there are no special update pack-
ages or update products. This ensures that both the new customer and
the update customer have a system that is functionally identical.
There is always only one "Reliant UNIX" CD-ROM for an operating system
release, and this can be used to update your system from various ear-
lier operating system releases to the new operating system release.
The update procedure can only update your system from an old to a new
release, and not vice versa.
Only software on the "Reliant UNIX" CD-ROM can be updated. This means
that both the operating system and the optional products installed
later from the "Reliant UNIX" CD-ROM by the customer are updated.
Software that is not on the "Reliant UNIX" CD-ROM cannot be updated as
otherwise, for example, an automatic update would not be possible.
Included in this is the software from add-on products that the custo-
mer installed from separate CD-ROMs (COMM-SW-CD-ROM-MI, CD-ROM-SYS-MI,
TV-SW-CD-ROM-MI etc.). This software is, however, detected and pro-
cessed if it contains dependencies relating to the operating system
software, provided that these dependencies were made known to the sys-
tem and thereby coded.
OPTIONS
-c (check) Turns on CHECK mode. This is the alternative to ARMED
mode. In CHECK mode, the update does not change the system, which
means that it can be called in this mode at any time. (Only the
CHECK run log is stored on the system disk.) The update test pro-
cedures try to detect any problems that could prevent an update.
If such problems are found, a warning is generally output that
this problem can cause an error in ARMED mode and the update then
continues. In some circumstances, a problem preventing an update
Page 1 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
also causes the cancellation of further tests in CHECK mode. This
is the case if it is not possible to continue working properly
(example: the installation medium is not available).
The steps of the update are only executed "virtually". This
means, for example, that the package installation (pkgadd) tries
to install a package in such a way that situations that might
prevent an update are detected. The following are among the items
checked:
- the system run level
- package dependencies
- disk space and number of inodes
- conflicts with previously installed packages
- incompatibilities with installed add-on products
- the consistency of the kernel components (the kernel is not,
however, activated)
The history remains unchanged in CHECK mode.
-a (armed) Turns on ARMED mode. This is the alternative to CHECK
mode. In ARMED mode, the update changes the operating system
software, i.e. it updates it.
The steps of the update are executed "really".
The read and write mode of the history is changed in ARMED mode.
The update test procedures are also executed in ARMED mode to
detect problems that might prevent an update. If such problems
are found, an error is generally returned and the update aborted.
(If an error occurs, the abort can be avoided by using the -e
option.)
-o (OTIP = Only The Installed Packages) In the standard case (i.e.
without the -o option) all packages in the basic operating system
are updated or installed. This is also the recommended procedure.
There is, however, also the option of only installing packages
that are already on the target system by specifying the -o
option. This means that no package is installed for the first
time, only existing packages are updated.
If, for example, a customer deleted the SIacc package due to a
lack of hardware to optimize the disk space available, the
/etc/update -a -o ... command installs all the packages in the
basic operating system with the exception of the SIacc package.
Page 2 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
Note:
1. Inconsistencies between the packages caused by arbitrary dele-
tions are retained since the update cannot recognize why the
packages were deleted. For example, there is no point in
deleting a SIcdin package and leaving the SIcdinM language-
dependent part on the system.
2. The -o option affects the basic operating system packages
only. The rule for optional products installed by the customer
(by means of sysadm using the "software_prod" -
"products_on_CD" menu items) from the "Reliant UNIX" CD-ROM
that they are only installed if they are already on the system
still applies. So, for example, the RAID software is only ever
installed (updated) if it was already on the target system
before the update.
3. Some operating system updates require that specific packages
be installed for compatibility reasons, even if they were not
on the target system before the update; i.e. the -o option has
no effect on these packages. The system informs you of this:
Example:
--------------------------------------------------------------------------
+++ INFO: Scanning root disk for installed packages ..
+++ INFO: You have chosen OTIP. The following packages may need
+++ to be installed for consistency reasons even
+++ though they may not already exist:
dwb, SIecnpw, SIerrlog, SIerrlogM, SIlar, SImabi, SImb2dbg, SIsysY, SItc20
--------------------------------------------------------------------------
-e (errors will be skipped) In the standard case, (i.e. without the
-e option), the update aborts in ARMED mode if an error prevent-
ing an update occurs. This is useful and does not cause any prob-
lems since the reentry ability of the update means that following
error recovery the update resumes where it was aborted and con-
tinues. By selecting the -e option you can, however, ignore this
and continue the update if errors occur. This is useful in some
exceptional cases. The -e option should, however, be used with
care; if errors are ignored, they can be the root cause of other
problems. The result of an update using the -e option cannot be
predicted if errors occur. For that reason, only experienced sys-
tem administrators who can also interpret the side effects should
use the -e option.
Page 3 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
Note:
1. There are a few error situations that result in an error ter-
minating the update despite the -e option being set. This hap-
pens if the update cannot be continued properly. This is the
case, for example, when:
- the installation medium is not available. The packages
could therefore not be installed "virtually";
- the operating system version found on the system disk is
not a suitable basis for the update installation: the
update database contains no information as to how the "old"
operating system version could be migrated to the "new"
operating system version.
2. The -e option is only useful in ARMED mode. If an error that
could prevent an update is detected in CHECK mode, a warning
is output and the update continued.
-r (read all parameters from file) In addition to the command line
interface, the update has a call interface via a control file.
Both interfaces are mutually exclusive: you either specify the
required parameters in the command line, or you use a control
file which contains the required parameters. The control file can
have any name and the -r option must be specified as a parameter.
If, for example, you created a control file with the name
config.update in the /home/julia directory, you call the update
using:
# /etc/update -r /home/julia/config.update
Note that no other command line parameters are permitted once the
-r option is selected.
There is an example of such a control file containing the
synopsis and additional notes (/etc/update.cfg) in the SInus
package.
It is easier to prepare a completely automatic update (e.g. via a
batch job) using a control file.
-h (help) Displays the command synopsis.
Page 4 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
THE LOG
The update informs you both in CHECK mode and in ARMED mode about the
individual actions that have taken place. The messages that are
displayed on screen are also written to a file, which means that you
always have an overview of the completed actions even when you are not
present at the time. The log contains the messages from all calls of
the same update, from both CHECK runs and ARMED runs. This simplifies
considerably the tracing of the actions in terms of when they
occurred. You must note, however, that the last update run is located
at the end of the file.
The individual actions are separated visually from each other to
improve clarity, since this log extends over several pages. Individual
update calls are delimited by corresponding messages ("run of UPDATE
started at [date]" or "run of UPDATE ended at [date]"). Within the
update calls, the actions are defined more precisely by keywords:
INFO You are informed of "normal" operations. You are given this
information on the current processing status on the active
system. No actions are necessary.
WARNING You are informed of unusual operations. This information
has different impacts depending on the update mode:
1. CHECK mode
There is a problem that needs closer inspection. This
problem, if not resolved, can lead to an error (ERROR),
i.e. usually abortion of the update, in ARMED mode.
Action: Resolve this error. (Remark: you can see from
the context how best to proceed. You can ignore the
WARNING if this is indicated explicitly.)
Note that one problem can be the origin of other prob-
lems. If is therefore a good idea when a number of WARN-
INGs are returned to resolve the first one and then
repeat the update in CHECK mode.
2. ARMED mode
There is a problem that needs closer inspection. This
problem will not prevent an update but it should be
resolved as soon as possible. Action: Resolve the prob-
lem as soon as possible.
ERROR Informs you of operations that prevent updates. The program
normally terminates (i.e. if the -e option is not set).
Page 5 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
1. CHECK mode
There is a problem that also results in the program
being terminated in CHECK mode since there is no point
in continuing. This is, for example, necessary if a
large part of the test cannot be executed at all because
the installation medium is invalid. Action: Resolve the
problem and restart the update.
2. ARMED mode
There is a problem that results in the program being
terminated since there is no point in continuing.
Action: Resolve the problem and restart the update.
Please note that the statement about ERRORs and WARNINGs can always
only refer to the current update run, since the update itself cannot
decide if a WARNING that occurred earlier is still valid and must be
counted. A special case arising from this is when the same update
attempt has to be called repeatedly (reentry); here, only the WARNINGs
(which do not abort the update in ARMED mode) that occurred during the
current run are counted. However, since the log contains all calls of
the update attempt, you can also reference the earlier WARNINGs by
paging back through the log. The update will advise you of this.
PROCEDURE
The update works through a series of actions, informing you at all
times of the current state of progress. These actions are performed in
both CHECK mode and ARMED mode. The CHECK run provides a detailed
overview of the actions to be expected during the "actual" update.
Update of 5.43 -> 5.44: Since you are moving here from a 32-bit to a
64-bit operating system, the system is restarted automatically in
ARMED mode during the update. You do not need to intervene in any way.
AUTOMATIC OPERATION
General
The update was developed with "unattended operation" in mind. That
means that no interaction with the user is required once it starts.
The update either ends with successful execution or an appropriate
return code if an error occurs. This gives the user the option of
being able to execute the update within batch runs or other automated
program runs.
It makes sense, for example, to execute the update when the system is
not busy to avoid interaction with other processes. A practical approach
is, for example: you had installed the SInus package, executed an update
in CHECK mode and received information from the update that your system
is ready for the planned update. You carried out a backup and would like
to perform the update on Friday evening. You can ensure that the instal-
lation medium is mounted for batch execution, the default file systems
are mounted, and the system is in the recommended single user mode.
(Your batch file can naturally also take care of this.)
Page 6 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
Example of a batch file (pseudocode):
/etc/update -r /etc/update.myconfig.check
/* my control file for CHECK mode */
IF [ update is successful in CHECK mode ]
THEN /etc/update -r /etc/update.myconfig.armed
/* my control file for ARMED mode */
IF [ update is successful in ARMED ]
THEN [ reboot the system ]
ELSE [ wait for the system administrator ]
FI
ELSE [ wait for the system administrator since CHECK was unsuccessful ]
FI
Update return codes
The /etc/update program called delivers a return code once it is fin-
ished. This return code can be analyzed to establish the
success/failure of this update process and initiate appropriate
actions automatically.
The /etc/update command delivers the following return codes:
0 The /etc/update command was completed successfully. The current
update operation was successful: No ERROR (ARMED mode) or ERROR
and WARNING (CHECK mode) occurred.
1 The current update operation was not successful. The /etc/update
command returns an error: An ERROR (ARMED mode), and an ERROR or
a WARNING (CHECK mode) occurred.
2 The current update operation was not successful. The /etc/update
command was called incorrectly.
3 The current update operation was not successful. The /etc/update
command was interrupted (SIGINT).
99 The /etc/update command returns an error: An internal error
occurred.
THE rcU INTERFACE TO EXTERNAL PROGRAMS
The update offers the option of including external procedures (pro-
grams). This functions in a similar way to the rc2 scripts of the
operating system. For that reason, these external procedures are also
called rcU (run commands Update). They must be stored in a defined
directory and contain the following interface conventions. These
external procedures are executed by the update in ASCII sequence.
Page 7 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
The external procedures permit among other things:
- execution of customer-specific actions
- processing of applications from third-party vendors
- intervention in the update even after delivery of the CD-ROMs.
The external procedures are supplied with the necessary information by
the update and must, for their part, report the success/failure of
their activity to the update using their return code.
The SInus package contains an example of such a procedure which con-
tains the interface definitions and further notes
(/var/sadm/install/update/rcU/U00template).
PROCEDURE (COOKBOOK)
You received the "Reliant UNIX" CD-ROM containing a newer version of
the operating system than that which is running on your system.
Preliminary tests
It makes sense to check the system as soon as possible (weeks before
the actual update) to allow the early detection of problems.
1) Installing the update tool
To do this, insert the "Reliant UNIX" CD-ROM in a CD-ROM drive that
you can access from the system you want to update. Install the
SInus package using sysadm via the "software_prod" menu item.
2) Mounting (mount)
Mount the installation medium. (In this example locally in the CD-
ROM drive):
# mount -F hs /dev/ios0/sdisk00xs0 /SInus
x = SCSI-ID (RM600 = 6, RM600-E = 0, RM400 = 5)
3) Calling (update)
Call the update in CHECK mode:
# /etc/update -c
The update now executes a range of tests. The entire operation is
logged in the /var/sadm/pkg/.prot.update file. The individual test
steps are identified by keywords.
Page 8 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
The update lasts approx. 30 - 60 minutes in CHECK mode. Once finished,
it outputs a report containing the following:
- if and which problems (ERRORs and WARNINGs) occurred and how they
can be resolved;
- which software was installed;
- which other actions were executed.
You now have an initial impression of whether your system is ready for
an update. Extract the exact error descriptions from the
/var/sadm/pkg/.prot.update test log. Solutions are suggested where
possible. Repeat the update in CHECK mode once the errors have been
resolved. Only when the update has been completed successfully in
CHECK mode does it make sense to perform an update in ARMED mode
(although always possible).
If incompatibilities with add-on products or software from an external
source are reported, contact the regional office responsible or the
third-party software supplier. This is particularly important if you
are updating from 5.43 to 5.44. You should therefore pay special
attention to the section below entitled "UPDATE AND ADD-ON PRODUCTS".
Final tests
Immediately before the update in ARMED mode, you should execute
another test run. The report on the update in CHECK mode is naturally
only valid if no system-relevant changes were made to the system in
the time up to the update in ARMED mode. Since this could not be ruled
out in the previous weeks, repeat Step 3). If possible, execute the
test under the same conditions as you want to execute the update in
ARMED mode.
No problems should generally occur now.
The update
Once the update has been completed successfully in CHECK mode, execute
the update in ARMED mode.
0) Data backup
You performed a data backup.
1) Switch to single user mode.
This is strongly recommended. (The update can also be started in mul-
tiuser mode; this mode is only advisable for experienced system
administrators who can resolve errors themselves should they occur.)
# init s
Page 9 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
2) Starting the network
If you want to mount the installation medium using nfs, you must
start the network via which you can reach the installation medium.
Example: network on the lce:
# sh /etc/rc2.d/S69inet start
3) Mounting (mount)
Mount the installation medium. (In this example locally in the CD-
ROM drive):
# mount -F hs /dev/ios0/sdisk00xs0 /SInus
x = SCSI-ID (RM600 = 6, RM600-E = 0, RM400 = 5)
4) Calling (update)
Call an update in ARMED mode:
# /etc/update -a
The system is now updated. You are informed of the progress.
The updates lasts approx. 0.5 - 3 hours. The duration depends on the
type of update, the speed of the installation medium, the volume of
software to be updated, the system configuration etc.
What to do in the event of errors
If the procedure is disrupted because of errors, you will be offered a
possible solution. Resolve these errors. Because the update is re-
entrant, you can restart it without having to work your way again
through actions that have already been completed. The update knows the
history and is continued from the point where it was interrupted. You
should start the update as follows:
⊕ If the problem arose when updating to 5.43 (i.e. update without
automatic reboot), you should invoke the update using the same com-
mand again, e.g.:
# /etc/update -a
⊕ If the problem arose when updating from 5.43 to 5.44 (i.e. update
with automatic reboot), the update informs you how to initiate re-
entrant mode:
Page 10 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
- If the abort happened before the automatic reboot (i.e. 5.43
is still active), you should invoke the update using the same
command again, e.g.:
# /etc/update -a
- If the abort happened after the automatic reboot (i.e. 5.44 is
already active), boot the system in multiuser mode because it
is now in single user mode as a result of the error:
# init 2
An rc2 script now resumes control again.
⊕ If the problem arose when updating from 5.44 (i.e. update without
automatic reboot), you should invoke the update using the same com-
mand again, e.g.:
# /etc/update -a
The update is continued from the point where it was interrupted.
You could also start the update again in CHECK mode. The update in
CHECK mode also knows the history and also only starts from the point
where the error occurred.
Caution:
Please remember that re-entrant mode is dependent on the history being
read. If you introduce inconsistencies before you restart the update
(e.g. manually delete packages already processed), the update will not
be able to recognize this. It assumes in this case that these packages
have already been updated; the resulting inconsistencies can cause
errors.
You have to continue an interrupted update as quickly as possible in
ARMED mode. Do not leave the system in a "half updated" state for a
long period of time. In the case of updates where there is no
automatic reboot, (5.43 -> 5.44), you should not reboot if an error
occurs before the update has finished as otherwise unforeseen problems
may arise when 'older' software and previously updated software are
being used together.
Many commands under Reliant UNIX store temporary files in /tmp that
you require. Please make sure that a "private" cron job does not clean
up the directory at update runtime.
The update can only be started once at the same time.
Page 11 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
Examples
Mounting various installation media
Note: The following abbreviations are used:
Sys1C = startup system with CD-ROM
Sys1D = startup system with disk
Sys2 = system to be updated
Mount the installation medium located on/in:
Example a): CD-ROM located locally in the CD-ROM drive of the machine
to be updated:
# mount -F hs /dev/ios0/sdisk00xs0 /SInus
Example b): CD-ROM in the CD-ROM drive in a machine accessed using
nfs:
[Sys1C] # mount -F hs /dev/ios0/sdisk00xs0 /cdrom
[Sys1C] # share -oro,root=Sys2 /cdrom
[Sys2] # #Start the network since the system is in single user mode
[Sys2] # mount -F nfs Sys1C:/cdrom /SInus
Example c): Disk with a local copy of the installation CD-ROM:
# mount -F ufs /dev/ios0/sdisk00xs0 /SInus
Page 12 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
Example d): Disk with a copy of the installation CD-ROM in a machine
accessed using nfs:
[Sys1D] # mount -F ufs /dev/ios0/sdisk00xs0 /mnt
[Sys1D] # share -oro,root=Sys2 /mnt
[Sys2] # #Start the network since the system is in single user mode
[Sys2] # mount -F nfs Sys1D:/mnt /SInus
Starting the network when the installation media are mounted by nfs
The network is normally "down" in single user mode. It is therefore
necessary to start this network to establish the connection between
the machine with the installation medium [Sys1C] and the machine to be
installed [Sys2] via nfs. The procedure for starting the network
depends on the interface used:
Example a): Network on the lce (Lan Controller Ethernet):
# System [Sys2] is in single user mode:
sh /etc/rc2.d/S69inet start
# [Sys1C] should now be accessible, i.e.
ping [Sys1C]
# or
showmount -e [Sys1C]
# should work.
# Then mount installation medium:
mount -F nfs [Sys1C]:/cdrom /SInus
Example b): Network on the lct (Lan Controller Token Ring) and
Example c): Network on the lcf (Lan Controller FDDI):
# System [Sys2] is in single user mode
PATH=$PATH:/opt/bin
# stop the network
# (some old releases do not do this with init s)
sh /etc/rc2.d/S68lct stop # (or S68lcf stop for FDDI)
# CMX must be started
sh /etc/rc2.d/CMX start
sh /etc/rc2.d/S68lct start # (or S68lcf start for FDDI)
sh /etc/S69inet start
# [Sys1C] should now be accessible, i.e.
ping [Sys1C]
# or
showmount -e [Sys1C]
# should work.
# Then mount installation medium:
mount -F nfs [Sys1C]:/cdrom /SInus
Page 13 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
Transferring configuration files
The configuration of the operating system is defined, among other
things, by the configuration files. These system configuration files
are retained when the update is installed. Therefore, you do not need
to save these files separately before the update installation begins.
The configuration files include, for example:
/etc/conf/cf.d/mtune
/etc/conf/cf.d/stune
/etc/cron.d/queuedefs
/etc/default/login
/etc/inet/services
/etc/mail/mailsurr
/etc/profile
/etc/shells
/var/spool/cron/crontabs/root
Some configuration files may have changed when upgrading from one
operating system version to another. The changes are entered in your
configuration files automatically during the update installation. Each
file that has to be changed is first saved by creating a copy of the
file. The names of the copied files are created by adding a suffix to
the existing file name. This ending contains the name of the future
operating system version (so that the backup files can also be
assigned uniquely at a later time). For example:
'/.profile' will be saved as '/.profile.preSINIX-Y5.43B0040'
These backup files are also retained following the update installa-
tion, but can be deleted manually if required at a later time.
The update now tries to incorporate the necessary changes in the
existing configuration files. If this succeeds, the modified confi-
guration files will be used in the future. These configuration files
will not be overwritten when the operating system packages are loaded.
While you will be informed of this, you do not need to do anything
here. For example:
Trying to update your '/.profile' automatically.
/.profile was modified
If, for whatever reasons, the necessary changes cannot be incorporated
in the existing configuration files (e. g. because the differences are
too great), standard configuration files are copied to the system disk
- as with a new installation. In this case you will receive the
appropriate warning. For example:
Page 14 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
+++ WARNING: Unable to modify the '/.profile' configuration file automatically.
+++ '/.profile' is deleted to ensure that you get the new '/.profile'.
+++ The file currently active is backed up as '/.profile.preSINIX-Y5.43B0040'.
+++ We will use the newly installed file temporarily.
+++ Please combine the newly installed
+++ /.profile and your
+++ /.profile.preSINIX-Y5.43B0040 into a
+++ /.profile later.
This warning will be noted in the log and you will also receive a cor-
responding electronic mail. (Please note that the statement about
WARNINGs can always only refer to the current update run. If reentries
are necessary, the configuration files will of course only be updated
once; such WARNINGs are then noted earlier in the log.)
The update installation is continued.
If the update installation has been completed successfully (without
ERRORs), you will be referred to any problems that may have arisen.
For example:
+++ INFO: Report for 'update -a' :
+++ INFO: We detected the following during the UPDATE runtime:
+++ Number of WARNINGs : 5
+++ Number of ERRORs : 0
+++ INFO: Excellent! The current UPDATE installation run ended successfully.
+++ (Please look at the WARNINGS in the log file named
+++ /var/sadm/install/../pkg/.prot.update)
+++
+++ Please reboot your system as soon as possible.
+++ Make sure that you have read the entire log file
+++ and that you are quite familiar with the results reported by
+++ the UPDATE installation.
You can look at the WARNINGs in the log and should resolve them as
soon as possible.
The configuration files that the update installation was not able to
update automatically, should now be updated manually (i.e. before the
reboot). This is necessary because some configuration files are only
used in the boot phase of the system. In the case of a manual update,
you should proceed as described in the example below:
Change to the directory containing the relevant configuration file, in
this case /.profile. Here you will find
- the file .profile.preSINIX-Y5.43B0040
(= the .profile file you saved prior to the update. This is the
configured file that was valid in the "old" operating system ver-
sion.)
Page 15 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
- the file .profile
(= the new, unconfigured file. This file is valid in the "new"
operating system version.)
Load both files into an editor. Then search in the
.profile.preSINIX-Y5.43B0040 file for the entries you made yourself
(e. g. variable definitions etc.) as well as the entries made by add-
on products (these can generally be identified by comments). Add these
entries to the .profile file. And that's it.
Please note the following:
Under no circumstances should you reactivate the "old" configuration
files, neither by loading them from the backup tape, nor by renaming
the *.preSINIX-* files to their "old" file names. The "new" operating
system version requires the files in their "new" format.
UPDATE AND ADD-ON PRODUCTS
As already mentioned, the update can only install software located on
the installation medium, though dependencies on add-on products are
considered. This is particularly relevant for the 5.43 -> 5.44 update:
Add-on products that can no longer run under 5.44 may place the suc-
cess of the update in question. A multi-stage concept therefore exists
for handling add-on products:
⊕ You should carefully read the CHECK run log even if the report does
not indicate warnings. The CHECK run log informs you of packages
and associated products that can no longer be used following the
update. The update handles incompatible products in accordance with
the type of incompatibility:
- Incompatible products are reported
- Products containing kernel components but which do not influence
the basic system if they are not in the kernel are deactivated.
- Products that impair the operability of the system, or cause
other serious problems because of their incompatibility, are
deleted.
⊕ Please contact your local SNI office or the supplier for the
respective add-on product in good time to get a more recent (compa-
tible) version of the particular product. You can then install this
new version when the operating system has been updated.
TYPICAL ERROR SITUATIONS AND THEIR SOLUTIONS
There are some typical error situations, the cause and resolution of
which we will show below using examples.
Page 16 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
Problem:
------------------------------------------------------------------------------
+++ INFO: Rebuilding kernel ...
The UNIX Operating System will now be rebuilt.
This will take some time. Please wait.
/opt/conf/pack.d/nb/space.c 18: [error]: 2324 Undefined: 'NBMAXSESS'
/opt/conf/pack.d/nb/space.c 18: [error]: 2112 Constant expression expected
/opt/conf/pack.d/nb/space.c 18: [error]: 2032 Negative dimension not allowed
/opt/conf/pack.d/nb/space.c 19: [error]: 2324 Undefined: 'NBMAXNAMES'
/opt/conf/pack.d/nb/space.c 19: [error]: 2112 Constant expression expected
/opt/conf/pack.d/nb/space.c 19: [error]: 2032 Negative dimension not allowed
/opt/conf/pack.d/nb/space.c 20: [error]: 2142 Illegal initializer
/opt/conf/pack.d/nb/space.c 21: [error]: 2142 Illegal initializer
2086 c1: errors: 8, warnings: 3
[error]: 9025 /usr/ic/bin/cc : frontend error while compiling file \
'/opt/conf/pack.d/nb/space.c'
ERROR: '/opt/conf/pack.d/nb/space.c' will not compile properly
+++ ERROR: There is a problem in your kernel configuration files.
+++ It is not possible to build a new kernel. Please
+++ check your kernel configuration files.
+++ See idbuild(1M) for details.
+++ INFO: We will now copy a new standard kernel onto your system
+++ to permit a system reboot.
------------------------------------------------------------------------------
Cause:
The /etc/conf/cf.d/mtune file could not be updated automatically.
Therefore all parameters that were entered in the mtune file by the
add-on products are undefined. The newly loaded mtune file is on the
system as well as the mtune.preSINIX-Y5.43B0040 file, which is the
mtune system file backed up before the update.
Solution:
Copy the parameters that are undefined in the mtune file from the
mtune.preSINIX-Y5.43B0040 file. In concrete terms:
# cd /etc/conf/cf.d/
# grep NBMAX mtune.preSINIX-Y5.43B0040 >> mtune
Ready. Restart the update which then continues on from the unsuccess-
ful "Rebuilding kernel" stage.
Page 17 Reliant UNIX 5.44 Printed 11/98
update(8) update(8)
Problem:
-------------------------------------------------------------------------------
+++ INFO: 87 of 87 packages still have to be updated.
+++ Loading skeleton from /SInus/sinix/543/T1/skeleton ...
+++ WARNING: Loading of skeleton from /SInus/sinix/543/T1/skeleton could fail:
Processing Package DC/OSx (skeleton) from </SInus/sinix/543/T1/skeleton>.
/etc/conf <no longer a directory>
/tmp <no longer a directory>
/usr/spool <no longer a directory>
unable to stat filesystem mounted on </cdrom>
Space checking failed.
Installation of DC/OSx (skeleton) was suspended (interaction
required).
-- processed 1 of 1 packages (100 %) --
+++ This may cause a fatal error in armed mode !
-------------------------------------------------------------------------------
Cause:
The system is inconsistent: A file system (in this case /cdrom) is
referred to as "mounted" (i.e. has an entry in the mnttab), but is not
available.
The same problem occurs if, for example, the df command is called.
This problem typically occurs if file systems are mounted using nfs
but the connection no longer exists.
Solution:
To make the system consistent: unmount the relevant file system.
Page 18 Reliant UNIX 5.44 Printed 11/98