| Upgrade Information: Page One |
IMPORTANT
PLEASE READ THIS NOTE CAREFULLY IF YOU INTEND TO PERFORM A NON-DESTRUCTIVE UPGRADE FROM SCO UnixWare 2.0.x to 2.1.x
This document was included in the SCO UnixWare Upgrade Kit SV507058 (if purchased from Fujitsu Computers Ltd.).OVERVIEW
This document has been produced to highlight problems that may affect the non-destructive upgrade of SCO UnixWare 2.0.x to 2.1.x on teamservers, and to suggest ways in which the problems can be avoided.
It is intended to supplement the documentation provided with the SCO UnixWare upgrade product, not to replace it.
It cannot be emphasised too strongly that all documentation provided be thoroughly read, and understood, before a non-destructive upgrade is attempted.
This note focuses on problems that may be encountered when performing a non-destructive upgrade systems with the following configurations:
Problems on Servers with more than one SCSI channel
Background
On occasion, the non-destructive installation option is not presented because the installation package cannot locate the system disk. This note gives guidance on steps that must be followed to ensure that the non-destructive option is not denied for this reason.
Note that the non-destructive installation option may not be offered for other reasons, such as lack of disk space.
Understanding the problem
It has been established that, in order for a non-destructive installation to be offered, a pre-install script tries to locate the system disk, and ensures that the system disk contains a UNIX kernel image that is a suitable candidate for upgrade.
SCO UnixWare defines the system disk as device 0 on the first SCSI channel (channel 0).
Channel 0 is defined as that mapped to the SCSI controller with the lowest memory address.
Using this algorithm, the "real" system disk may not be chosen by SCO UnixWare - it may choose device 0 on a different SCSI controller as the candidate for upgrade. In this case, no operating system image is therefore found, and the non-destructive installation option is not offered.
It is therefore possible for any system that has more than a single SCSI controller to be affected.
If the destructive option is selected, then the 'real' system disk will be rendered unusable, and any data on the 'false' target will be destroyed
The following notes should be read in conjunction with the manuals provided with the upgrade.
All the information provided must be thoroughly studied and understood before an installation is attempted.
If you do not understand any step, DO NOT attempt to install the system before seeking clarification.
It is assumed that the person performing the upgrade is familiar with the SCO UnixWare operating system and teamserver hardware. These notes do not attempt to give in-depth guidance on how to accomplish each step described.
Overcoming the Problem
In general, the solution is to prevent the system accessing any discs apart from the system disc. In some cases this can be done by removing the discs, but in some other steps are necessary. These are described for Mylex, powerARRAY, and Adaptec controllers in the next three sections.
It is essential to label all disks removed, and to ensure that they are replaced in exactly the same position.
As with any other major upgrade, it is imperative that all data is backed up, and the backup verified, before commencing.
Servers with Non-System Disks Connected by Mylex DAC960-PL
A typical configuration will have the system disk connected to on-board PCI SCSI, and Mylex driving non-system disks in a peripheral cabinet.
In this case, the SCO UnixWare upgrade mechanism will identify a Mylex logical device (e.g. channel 2 device 0) as the first bootable disk, and hence select this as the system disk. No SCO UnixWare system slices are found on this device, and so a non-destructive upgrade is not offered.
The Mylex channel will be selected in this way because the Mylex controller's configured memory address (as seen in the DCU or resmgr output) is lower than that of the second on-board SCSI channel.
The problem can be overcome by disabling the BIOS on the Mylex card, and then either disconnecting all the discs controlled by the Mylex, or removing the dak software driver for the Mylex before starting the upgrade, and reinstalling it when the upgrade is complete.
