DYNIX/ptx V4.6.1 and Layered Products Software Installation Release Notes: Dual-Boot Environments


Appendix F
Dual-Boot Environments

A dual-boot environment is one in which a system boots back and forth between two versions of the DYNIX/ptx operating system. For example, after you have successfully upgraded to DYNIX/ptx V4.6 and if the host still has the previous V4.4/4.5 operating system available in an alternate partition (that is, preserved from the upgrade, not overwritten), you can boot back and forth between DYNIX/ptx V4.6 and V4.4/V4.5.


ATTENTION

Before operating your system in a dual-boot environment, be sure you have a complete understanding of how the changes required for dual-booting will impact your system. Furthermore, there are several additional issues to consider for clustered systems. Contact IBM customer services for assistance if you are unsure of the impact.


The first time you boot the system on DYNIX/ptx V4.6, disk labels are written to your boot and swap disk(s). Additionally, there may be other disks on the system that have been labeled.


ATTENTION

On single-node systems, disk labeling is automatically enabled on the first boot. On clustered systems, disk labeling is enabled after all nodes are booted to multiuser on V4.6 and have run the rolling_upgrade_complete script.


Because of the new disk labeling feature in DYNIX/ptx V4.6 and because IBM releases a supported software recipe for a given DYNIX/ptx release, extra steps must be taken each time you boot from one operating system to the other. For example, to reboot on your original V4.4/V4.5 root filesystem, you must unlabel disks for use when booted on DYNIX/ptx V4.4/4.5. Otherwise, you will be unable to access the desired disks. Likewise, to boot from V4.4/V4.5 to V4.6, you must label disks for use when booted on DYNIX/ptx V4.6. These limitations exist because DYNIX/ptx V4.4/V4.5 do not use disk labels.

You can decrease the number of disks that must be labeled and unlabeled by moving the commonly used disk partitions to a smaller set of disks.


Reboot DYNIX/ptx V4.4.x/4.5.x from DYNIX/ptx V4.6

To boot DYNIX/ptx V4.4/4.5 after a system has been booted to DYNIX/ptx V4.6, complete the following steps:

  1. Before rebooting the system, use diskown to save the disk label information for all disks on the system. This information will be needed when reverting back to DYNIX/ptx V4.6 in the future. For example:

    # /etc/diskown -m > /etc/diskown.save
  2. If the disk(s) containing the DYNIX/ptx V4.4/4.5 root and primary swap are labeled by the currently booted DYNIX/ptx V4.6, remove the disk label(s) during the reboot. To do this, boot on the DYNIX/ptx V4.4/4.5 root partition and add the -e flag to your bootpath. Additionally, set the bootflags to boot single-user mode so you can remove disk labels from other disks in a later step. For example:

    # /etc/bootflags -p -c 'f=2 n0=quad(0)pci(0)scsi(0)disk(0) -e'
  3. Reboot the system onto DYNIX/ptx V4.4 or V4.5:

    # init 6

    The purpose of this reboot is to remove the label from the disk(s) that contain root and swap. This must be done using the DYNIX/ptx V4.6 sak.dat.

  4. When the system reaches single-user mode on DYNIX/ptx V4.4/V4.5, remove the -e flag from the permanent bootflags. This option is not supported in the standalone kernels distributed with DYNIX/ptx V4.4 and V4.5:

    # /etc/bootflags -p -c 'f=2 n0=quad(0)pci(0)scsi(0)disk(0)'
  5. From single-user mode, remove the disk labels from any other disks that you wish to access while booted on DYNIX/ptx V4.4 or V4.5.

    1. Determine which disks have a disk label by using the lbledit command without any arguments. For example:

      # /usr/lbin/lbledit

      If the disk information that is output indicates any labels on disks you wish to use, then the disk label needs to be removed for the indicated disks.

      The /usr/lbin/lbledit command is not provided on the CDs for DYNIX/ptx V4.4.8 and earlier maintenance releases, nor DYNIX/ptx V4.5.2 and earlier maintenance releases. However, the /usr/lbin/lbledit command is automatically copied to the V4.4/V4.5 root filesystem during the upgrade to DYNIX/ptx V4.6.x.

    2. To remove a disk label from a disk, use the lbledit -r command. For example, to remove the disk label from sd5, enter the following command:

      # /usr/lbin/lbledit -r sd5
  6. Reinstall and reflash the console software for DYNIX/ptx V4.4/V4.5. See the NUMA Console Software Release Notes for details.

    This step must be performed because the V4.6 sak.dat and prxldr.elf are not supported on these older operating systems.


    ATTENTION

    The sak.dat and ptxldr.elf programs must not be installed while the operating system is running. Severe console I/O operation problems will occur if this is attempted.


    1. Shut down the operating system (init 0), power off the quads, and exit VCS.

    2. Rename the current VCS directory and the previous VCS directory in preparation to flash the console software firmware:

      1. Rename the current VCS directory to something like VCS46. The default directory is C:\VCS.

      2. If you saved the VCS directory from DYNIX/ptx V4.4/V4.5, rename it back as the current VCS directory.

      3. If you no longer have the VCS directory from DYNIX/ptx V4.4/4.5, reload VCS from the distribution CD that was provided with DYNIX/ptx V4.4/V4.5.

    3. Flash the console software firmware for DYNIX/ptx V4.4/V4.5, including the stand-alone kernel (sak.dat) and bootstrap program (ptxldr.elf).

  7. From the PTX Console window, click the Boot button to boot to single-user mode.

  8. If you plan to keep the host booted on DYNIX/ptx V4.4/V4.5 for an extended period of time, you must reflash the FC firmware recipe for the DYNIX/ptx V4.4/4.5 system. If you plan to reboot on DYNIX/ptx V4.6 within 24 hours, you do not need to reflash the older firmware recipe.

  9. If this is the first time you are rebooting on DYNIX/ptx V4.4/V4.5 and you deinstalled a layered product before the DYNIX/ptx V4.6 upgrade that you need to use, you must reinstall the product. Refer to Chapter 2 for a list of unsupported software that might have been deinstalled before the upgrade

    You only need to reinstall these products on the first reboot to DYNIX/ptx V4.4/4.5 as they will be available on any future reboots.

  10. If you performed the DYNIX/ptx V4.6 upgrade with the INIT ALT DISK DELTA procedure and the host had SAMS:Alexandria installed on DYNIX/ptx V4.4/V4.5 and you plan to use it after reverting back to DYNIX/ptx V4.4/V4.5, you must update Backup Toolkit scripts with the installalex script. Otherwise, required SAMS:Alexandria kernel components for DYNIX/ptx V4.4/4.5 will not be available. (Before the installation of DYNIX/ptx V4.6, you had to manually delete required Backup Toolkit kernel files that were not compatible with DYNIX/ptx V4.6.) For details, refer to the Backup Toolkit Release Notes.

    This step does not apply to upgrades performed with ALT DISK DELTA. In this case, the alternate disk partition was manually created before the required Backup Toolkit kernel files were deleted, hence these files were not deleted on the original root partition.

    You only need to reinstall the Backup Toolkit scripts on the first reboot to DYNIX/ptx V4.4/4.5 as they will be available on any future reboots.

  11. Boot the system to multiuser mode:

    # init 2

Reboot DYNIX/ptx V4.6 from DYNIX/ptx V4.4.x/4.5.x

To reboot a previously installed DYNIX/ptx V4.6 root partition after the system has been booted to DYNIX/ptx V4.4/V4.5, complete the following steps:

  1. If the disk(s) containing the DYNIX/ptx V4.6 root and primary swap are unlabeled by the currently booted DYNIX/ptx V4.4/4.5, you must write a disk label(s) during the reboot. To do so, boot on the DYNIX/ptx V4.6 root partition and add the -w flag to your boot path. Additionally, set the bootflags to boot single-user mode so you can add disk labels to other disks in a later step. For example:

    # /etc/bootflags -p -c 'f=2 n0=quad(0)pci(0)scsi(0)disk(3) -w'

    This step must be done using the DYNIX/ptx V4.6 sak.dat.

  2. Reinstall and reflash the console software for DYNIX/ptx V4.6. See the NUMA Console Software Release Notes for details.

    This step must be performed because the DYNIX/ptx V4.4/V4.5 sak.dat and prxldr.elf are not supported on DYNIX/ptx V4.6 and do not support the writing of disk labels required by the next step in this procedure.


    ATTENTION

    The sak.dat and ptxldr.elf programs must not be installed while the operating system is running. Severe console I/O operation problems will occur if this is attempted.


    1. Shut down the operating system (init 0), power off the quads, and exit VCS.

    2. Rename the current VCS directory and the previous VCS directory in preparation to flash the console software firmware:

      1. Rename the current VCS directory to something like VCS44 or VCS45. The default directory is C:\VCS.

      2. Rename the saved DYNIX/ptx V4.6 VCS directory back as the current VCS directory.

    3. Flash the console software firmware for DYNIX/ptx V4.6, including the stand-alone kernel (sak.dat) and bootstrap program (ptxldr.elf).

  3. From the PTX Console window, click the Boot button to boot to single-user mode.

  4. When the system reaches single-user mode, if the host does not already have the FC firmware recipe for DYNIX/ptx V4.6, reflash this recipe onto the FC subcomponents.

  5. Modify the disk label for the root disk to include the previous user-defined name and comment. Refer to the previously saved information in /etc/diskown.save and then use the diskown -w command to do so.

    # diskown -w -g -N rootdisk -C "root disk" sd0

    Do not include the -n option since the disk is already labeled as node-owned.

  6. Establish node ownership and add disk labels for each unlabeled disk that you wish to access while booted on DYNIX/ptx V4.6. Refer to the previously saved information in /etc/diskown.save and then use the diskown -w command to do so.

    For example, to make sd5 a node-owned disk with the comment oracle sd5 and the user-defined name oraclesd5, enter the following command:

    # /etc/diskown -w -g -n 0 -N oraclesd5 -C "oracle sd5" sd5

    To make sd20 a cluster-owned disk with the comment oracle sd20 and the user-defined name oraclesd20, enter the following command:

    # /etc/diskown -w -g -c 0 -N oraclesd20 -C "oracle sd20" sd20
  7. Boot the system to multiuser mode:

    # init 2

Automate Multiple Disk Label Changes Needed in a Dual-Boot Environment

This section provides sample scripts that can be used to automate multiple disk label changes in a dual-boot environment and describes how to implement these scripts so they are executed automatically at the appropriate system boot.


ATTENTION

Because each site configuration is unique, these scripts are not provided in electronic form on any distribution media. Instead, use them as examples to help plan and create your own site-specific scripts. If you plan to implement similar scripts at your site, it is highly recommended that you contact IBM customer services for assistance in doing so.

DO NOT implement these scripts as written for clustered systems.



Sample Shut Down Script to Save Disk Labels

The sample K01disklabelsave script uses diskown -m to save the disk label information for all disks visible to the host to the file /etc/diskown.save. It should be run on DYNIX/ptx V4.6 before booting the system to DYNIX/ptx V4.4/V4.5.

#!/bin/sh
#
# K01disklabelsave
#
# This script can be used to save the state of the current V4.6 disk label
# schema. This saved disk label information will be used to restore the state
# of the V4.6 disk label schema when rebooting to DYNIX/ptx V4.6.x after
# having been previously booted on DYNIX/ptx V4.5.x or earlier.

/etc/diskown -m > /etc/diskown.save

Sample Startup Script to Remove Disk Labels

The sample S011disklabelremove script uses /usr/lbin/lbledit -r to remove all disk labels during a system boot of DYNIX/ptx V4.4.x/4.5.x.

#!/bin/sh 
#
# S011disklabelremove
#
# This script can be used to remove disk labels 
# in the event that the user is rebooting to DYNIX/ptx 4.5.x or earlier
# after having been previously booted on DYNIX/ptx 4.6.x. 
#
# CAUTION! This script removes ALL disk labels, so the user should decide 
# if that is what is really intended before running this script.
#
# Remember that when you reboot again on DYNIX/ptx 4.6.x, any unlabeled disks
# must be relabeled using /etc/diskown.
#

/usr/lbin/lbledit | while read DEV LABEL TRASH
do
 	if [ "---" != "${LABEL}" ]
 	then
 		/usr/lbin/lbledit -r ${DEV}
 	fi
done

Sample Startup Script to Write Disk Labels

The sample S011disklabelwrite script uses diskown -w to create disk labels during a system boot of DYNIX/ptx V4.6.x.

#!/bin/sh
#
# S011disklabelwrite
#
# This script can be used to write disk labels in conjunction with
# K01disklabelsave and S011disklabelremove.  S011disklabelwrite takes the
# diskown.save state file and puts the labels that were saved back onto 
# the disks.
#
if [ -f /etc/diskown.save ]
 then
 	cat /etc/diskown.save |
 	while read -d : CFG
 	do
 		read -d : NAME
 		read -d : TYPE
 		read -d : OWNER
 		read COMMENT
 		if [ "---" != "${NAME}" ]
 		then
 			if [ "node-owned" = "${TYPE}" ]
 			then
 				/etc/diskown -w -g -n ${OWNER} -C "${COMMENT}" -N "${NAME}" ${CFG}
 			else
 				/etc/diskown -w -g -c ${OWNER} -C "${COMMENT}" -N "${NAME}" ${CFG}
 			fi
 		fi
 	done
 	mv /etc/diskown.save /etc/diskown.prev
fi

Automatically Make Multiple Disk Label Changes When the System Is Rebooted

If it is appropriate for your site, you can automatically run scripts you create for your site. These custom scripts should be run at the following times:


ATTENTION

Before automating the execution of any scripts that remove or write disk labels, be sure you have a complete understanding of how these scripts will affect access to the disks on the system. Contact IBM customer services for assistance if you are unsure of the impact.

The use of automated disk label scripts on clustered systems is not supported.


To enable custom scripts to automatically run at the appropriate system boot, complete these steps:

  1. Copy or move your custom script that saves disk label information to the /etc/rc0.d directory for the DYNIX/ptx V4.6 root filesystem. We suggest that you name this script K01disklabelsave so it executes at the proper time.

  2. Copy or move your custom script that removes disk labels to the /etc/rcinit.d directory for the DYNIX/ptx V4.4 or V4.5 root filesystem. We suggest that you name this script S011disklabelremove so it executes at the proper time.

  3. Copy or move your custom script that writes disk labels to the /etc/rcinit.d directory for the DYNIX/ptx V4.6 root filesystem. We suggest that you name this script S011disklabelwrite so it executes at the proper time.