| United States-English |
|
|
|
![]() |
Managing HP-UX Software With SD-UX: HP 9000 Computers > Chapter 6 Removing Software Advanced Topics for swremove |
|
The topics discussed in this section are for those users who have a firm understanding of the commands and who want to have additional control over their software removal process. swremove default values can be changed in three ways: they can be individually overridden on the command line by specifying an alternative options file with the -X option or individually with the -x option=value option, they can be edited directly in the defaults file or you can use the GUI or TUI Options Editor Dialog to change them interactively. See Chapter 2 “Installing and Copying Software ” for more information. Software can be removed relative to the primary root directory (/) or relative to an alternate root directory. An alternate root is a non-root location that can function as the root of a stand-alone system; that is, a system that can be unmounted and function as a self-contained system. Any information files used in software removal are retrieved from the Installed Product Database (see “Installed Products Database ”) beneath this alternate root, not the IPD on the root volume. The difference in behavior between swremove and swinstall is that swremove checks for the existence of the alternate root file system when it is specified. The GUI "Target Path Dialog" will appear first when swremove -r is invoked. It asks you to enter an alternate root path on the local host or choose one from the list of registered shared roots on the system. The default shared root that appears in the "Target Path Dialog" will be /export/shared_roots/OS_700. If the alternate root directory you choose does not exist (that is, is not registered), an error is generated and the dialog that prompted you for the path to the alternate root file system remains displayed. SD-UX provides the swcluster command to install, list and remove software from diskless servers and clients. Its -r option removes only non-kernel software from the cluster. swcluster first contacts all booted clients in the cluster and unconfigures the software. It then removes the software from the clients and then from the server. For example, if you wanted to remove the UUCP software product from a local HP Series 700 diskless cluster using very verbose (-vvv) output:
swcluster also directs the rebuilding of diskless client kernels if any kernel software has been removed. Software removal occurs while the client systems are running, whether kernel software is selected for removal or not. The swcluster command identifies all booted client systems that have software selected for removal, then unconfigures the selected software on those clients. The software is then removed, first from the diskless client systems, then (unless the -n flag is used) from the server system. When a client system is not turned on (or is otherwise inaccessible), swcluster removes the software but cannot unconfigure the client. If no kernel build is required, the process is complete when the software has been removed from the server. If the selected software requires a kernel build, each diskless client system affected by the removal rebuilds its own kernel and then reboots. When a client system is not turned on (or is otherwise inaccessible), swcluster removes the kernel software but cannot rebuild the kernel. The system administrator should rebuild the kernel on such a system as soon as possible after the machine is re-activated. The remove mode supports the -n flag, which causes swcluster to skip the removal of software from the diskless server. This is useful, for example, if the software is already removed from the server and simply needs to be removed from the clients.
Patch software cannot be removed unless:
or
Dependents are enforced at Selection phase when the autoselect_dependent default is set to "true." This default determines if the system should automatically mark software for removal based on whether it depends on software you mark. During Selection phase, if a dependent will be left on the system in an unusable state because of the removal of another software object, a dialog shows it. The software object that the dependent requires is not removed. This error can be overridden by setting the enforce_dependencies option in the defaults file to "false". A WARNING will still be generated, but swremove will show that it is being overridden. When an object is selected (and autoselect_dependent is "true"), if there is more than one dependent available in the Software Selections Window, they are all automatically selected (not just the latest version of the dependent like swinstall dependency selection). When removing from a depot, dependencies are handled the same as the normal swremove. Dependencies handling is controlled by the defaults enforce_dependencies and autoselect_dependents. No compatibility filtering or checking is performed in any remove commands. There is nothing to be compatible with; software is already on the local host. Each separate version of a product along with its location directory is listed in the Object List. Selecting a multiple version implies a product:/location directory pair. By default, the location is not displayed in the Software Selection Window. It can be displayed using the Columns EditorView-[rtrif]Columns .. menu item. During the analysis phase, if the version of the product exists on the host but at a different location, a WARNING is generated. More than one version of a product can be selected during the selection phase. During the analysis phase, if the product exists on the host, it will be removed. If it does not exist on the host, the product is simply skipped. The analysis Product Summary Window gives a product-by-product summary of what will be removed if the remove phase is started. Multiple versions of products are inherently possible in a depot. No special handling or checks are required when removing from depots. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||