Interim S10U1 Update Design: 1. Introduction This design addresses the need to upgrade a S10 GA system to a S10U1 system that has Zones installed and configured until a full design can be completed. The interim solution must be thought of as an update and not an upgrade. An update consists of installing patches and new packages only. An upgrade consists of removing obsolete packages, installing new packages, and upgrading existing packages. This interim solution only works when updating within the same release of Solaris (such as going from Solaris 10 GA to Solaris 10 Update 1). The interim solution will not work when upgrading to a later release of Solaris (such as upgrading from Solaris 10 to Solaris 11). 2. Requirements Patch and package installation must be to an alternate root. Currently installing patches and packages to an alternate root with Zones installed on that alternate root does not work. Release Engineering needs to be engaged to create a special DVD with the patches and new packages on it. This project will require that there will be no packages removed when updating from a S10GA to S10U1 system. No packages can be obsoleted from S10GA to S10U1. No packages can be split from S10GA to S10U1 and no files can be removed. These are the rules when updating to another release but need to be mentioned here so no exceptions to the rule are allowed. 3. Assumptions 3.1 Instead of upgrading the system in a traditional sense this solution will install the patches necessary to bring the system and the non-global Zones installed on the system to the same file level as an upgrade would have done. It will also install any new packages that need to be installed based on the existing metacluster previously installed. 3.2 A single DVD with the installation data and the data needed for the interim solution will need to be constructed. An additional directory structure needs to be added for the interim solution. This directory structure will be as follows: .../Solaris_10 / \ UpgradePatches ... / The Patches directory will contain the patches needed to bring the S10 GA Zones system up to an equivalently updated S10U1 system. The new packages will be contained in the Product directory and should not require any extra changes done by Release Engineering. 3.3 A CD solution will not be supported for the interim solution due to the time constraints, complexity of the problem and the likelihood the all the patches and new packages won't fit on CD. Currently there are 235 S10 patches that take up 772Mb of disk space uncompressed. If compressed using bzip2 they take up 297Mb. The space needed by new packages is unknown at this time but will only add to the amount of free space needed. A mini-root takes up 400Mb. If the patches need to be on a bootable CD then the mini-root along with the patches and packages need to co-exist and there's just not enough plastic. At this point in time all the compressed patches and the mini-root take up 697Mbs. Bits on the CD are limited to 670 MB's. 3.4 The Live Upgrade program will continue to not work when non-global Zones are installed for S10U1. It will detect non-global Zones and halt the upgrade. 3.5 A combined net install image created from the CD1...CDN and Lang CD, will not be able to be used to upgrade a system with Zones. Only a net install image created from a DVD can be used to upgrade a system with Zones installed. A DVD directly mounted is also supported. Note that a CD generated image can be used to upgrade a system without Zones installed. 4. Design Overview There are 2 areas that need to be developed for this project. 1. pfinstall (upgrade program), ttinstall and Solaris Wizard GUI front end 2. A update script that handles installing/backing out patches and installing the new packages. The current Upgrade program will be modified to invoke the "Update Via Patches" script, This script will install patches and packages based on the metacluster currently installed. The upgrade program will determine if the interim solution is needed by detecting any valid non global zones on the system. If one or more non global zones are detected, the UVP script will be invoked. If no non global zones are detected then the normal upgrade program will be executed to upgrade a non Zones system. 5. Design 5.1 The Upgrade portion of the design will be as follows: 5.1.1 pfinstall(1M) (upgrade command) must determine if the system being upgraded has non global zones installed if it does and all of them are in an upgradeable state (see table 5.1.1.2) then it will continue to upgrade the system with the UVP method. If pfinstall detects Zones are installed and the mini-root is booted from a CD or CD created net install image it will halt and display a message stating that their system can only be updated with a DVD or a DVD created net install image. If some Zones are in an "incomplete" state the upgrade will quit notifying the sysadmin to fix there "incomplete" non-global zone. There is currently code in pfinstall that detects if an upgrade is to a system with installed non-global Zones and exits. This code needs to be changed to invoke UVP if applicable. 5.1.2 Upgrade currently attempts to resume an interrupted installation. This functionality will still exist for the interim solution. If upgrade detects a resumption of the program it will behave as it currently does, skipping any analysis it has already performed. It will invoke the UVP script regardless of whether it is resumed from an interruption or a initial invocation. See section 5.2.5 for details on resuming the upgrade. 5.1.3 There are 2 GUI's available for the sysadmin to use to update their system, ttinstall (text based GUI), Solaris Wizard (Java based GUI). Both ttinstall and the Solaris Wizard will be modified to support upgrading a S10 GA Zones system to S10U1. The Launcher program will not need modifications since it is responsible for handling mounting/unmounting CD media and this project will only support an update from DVD media and a net-install image. The 2 front end app's previously mentioned will need to produce a GUI that will display the progress of the upgrade and display any warnings or errors. The progress itself will be maintained by the UVP script. The UVP script will write the zone being installed and the patch/pkg to stdout. Pfinstall will redirect this data so it can be displayed by the appropriate interface. 5.1.4 The return codes from UVP and their meanings are listed in table 5.1.1.1 below. ttinstall and pfinstall will display an appropriate message depending upon the return code passed back by UVP. 5.1.5 The libraries used by pfinstall and ttinstall already determine which metacluster is being upgraded. They will determine the dynamic list of packages to install based on the metacluster installed and provide a path to a file containg the list of those packages to UVP. 5.1.6 Sysadmins currently are able to select and deselect specific packages and clusters, reallocate disk space and add locales. This type of customization will be disabled for the interim solution. If a jumpstart profile is used pfinstall will act accordingly based on the following table: Jumpstart keyword behavior ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ install_type accept root_device accept backup_media quit layout_constraint quit cluster ignore geo ignore locale ignore package ignore patch ignore An appropriate message will be displayed if keywords are found that will be ignored or cause the program to quit. During the testing of a jumpstart profile (pfinstall -D ...), pfinstall must also detect if the S10 GA system has Zones installed. If it does then it must display an appropriate error stating the above keywords are only supported if additional keywords are part of the profile. If a GUI is being used the code paths and the panels that allow the previously mentioned customizations must be bypassed so the sysadmin doesn't have the opportunity to modify unsupported features. 5.1.7 When updating a release to another micro release S10 -> S10U1 the Patch Analysis code currently checks to see if any patches will be removed, downgraded or accumulated. The analysis code will be bypassed since the UVP script will handle these conditions. The code that determines which patches are going to be installed gathers the information from the freshbitted packages in the Product directory. Release Engineering must ensure that the patches applied via the freshbits process match the patches UVP will be installing. This will only be calculated for the Global zone. The UVP script will be responsible for not downgrading patches for the non-global zones. 5.1.8 Upgrade checks for modified editable files and makes a copy of them if they have changed. With UVP, This will not be done. It is up to the patches themselves to manage their editable files. Table 5.1.1.1 UVP return codes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Return Code Meaning 0 upgrade was successful 1 upgrade failed and system needs to be restored from backup 2 upgrade failed and action is required by sysadmin before attempting the upgrade again 3 upgrade failed, not enough File System space available. No changes have been made to the system. 4 upgrade failed, patch dependency failed. No changes have been made to the system. 5 upgrade failed, pkg dependency failed. No changes have been made to the system. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Table 5.1.1.2 Zone states ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Zone state What happens ~~~~~~~~~~ ~~~~~~~~~~~~ installed Zone to be upgraded Zone ignored TODO.... Add screen shots of the new GUI and text. Also add screen shots of any changed screens. 5.2 The UVP script will be designed as follows, in the following order : 5.2.1 Display package and or patch being installed so progress can be tracked by a human. The UVP script will write to a file and the upgrade program will be responsible for displaying the information appropriately depending on the interface being used. 5.2.2 Detect incompatible and uninstalled dependent packages and display an appropriate message resulting in execution being halted if any are found. First on the global zone and then on all non-global zones. 5.2.3 Detect incompatible, obsolete and uninstalled required patches. First on the global zone and then on all non-global zones. Write an appropriate message to the log resulting in execution being halted if any are found. If an incompatible, obsolete and uninstalled required patch exists on the global zone non-global Zones will still be checked so a complete list can be provided to the admin. 5.2.4 Determine the amount of space needed to install all the patches and packages for the global and non-global zones. Need to account for any non-global zone occupying their own File System and any others sharing one File System. Since each patch, when installed, creates a backout package we need to dynamically calculate how much space will be needed to store the backout packages. This will only be an estimate of how much we *think* we need based on the subset of patches being installed. Since patches can contain multiple packages, which some may not apply, and unless we do a patch installation dryrun to figure out more closely how much space is needed, this check may over estimate the space needed. This project will not be doing a dryrun to determine space needed. There's also additional space needed in the var/sadm/pkg//save/pspool directory to copy files from the new packages that are going to be installed. An estimate of the space needed also needs to be calculated. Once the space needed has been estimated it will be compared to the space available. If there is not enough space UVP will exit with an appropriate error code, see table 5.1.1.1. 5.2.5 Install new packages applicable to the installed metacluster based on the packages already read in and dependency checked. The default nature of pkgadd is to install a package to the global zone and then all non-global Zones. This behavior will not be changed. If a package fails to install, it and all previously installed packages will be removed from the global and non-global Zones. If any package fails to be removed the sysadmin will need to restore their system from backup or fix the un removed package. If new packages from the S10u1 update media are already installed they will be detected and skipped. This could happen if the upgrade is interrupted or a genesis patch is installed. If the update is interrupted via a user interruption (cntrl-c) or a power outage, only a list of packages not currently installed will be installed to the global zone and subsequent non-global zone(s). 5.2.6 Install the patches from a mounted DVD or directory from a net install image to the global Zone. The default nature of patchadd is to install the patches to the global Zone and then the non-global zones. This behavior will not change. If any patch fails to install to a global or any non-global zone all previously installed patches will be backed out from all global and non-global Zones. Also all packages previously installed will be removed from all Zones. If any patch or package fails to backout the sysadmin must restore their system from backup. If the update is interrupted via a user interruption (cntrl-c) or a power outage, only a list of patches not currently installed will be installed to the global zone and subsequent non-global zone(s). see table 5.2.6.1 for failures modes 5.2.7 To make this solution consistent with a regular upgrade, the following files will need to be modified with the appropriate values: /var/sadm/system/admin/CLUSTER /var/sadm/system/admin/INST_RELEASE /var/sadm/system/admin/.clustertoc /var/sadm/system/admin/.platform /var/sadm/system/admin/services/Solaris_X /var/sadm/system/data/locales_installed /reconfigure /etc/release The /etc/release file needs to be modified via a special patch or with installf(1M) so its pkg database entry matches its File System value. 5.2.8 Return success status to pfinstall. This program will be delivered by the SUNWsibi package and will live in /usr/sbin/install.d on the mini-root only and its interface level will be "obsolete" with a "Sun Private" commitment level. UVP CLI: /usr/sbin/install.d/patchUpdate -z [-r] [-a] [-v] -p -n -R Options: a) Analyze system n) A file containing the pkgs to install p) Process ID of parent r) If installation was halted pass -r to resume the installation. R) Alternate root v) Debug the script z) File of non-global Zones that are to be installed. Table 5.2.6.1 UVP Failure modes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Type of failure Global Zone non-global Zone pkg in installing patch not found on system ignore ignore incompatible patch found quit quit required patch not found quit quit Not enough space to install patches quit quit Pkg dependency not installed quit quit Later revision of skip installation skip installation patch installed of earlier revision of earlier revision patch patch ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Note: This table is not complete and will probably be modified in the future. 6. Issues Currently when a patch fails in a non-global zone patchrm is called in the non-global zone and fails. This needs to be fixed before the recovery from a non-global zone can happen. What happens when installation fails and the recovery code can't return the system to its previous state? That is a risk we are taking and the risk is probably higher with this solution then any regular upgrade since the Zones technology is new and the state of non-global zones can be quite different between them. Sysadmins will have to restore from a previous backup. 7. Notes All dependency checking and installation messages will be written to the var/sadm/system/log/upgrade_log file. If an upgrade_log file already exists it will be renamed to upgrade_log_.