Ignite-UX Custom Configuration Files Table of Contents Abstract ..............................................................................................................................................6 Introduction .........................................................................................................................................6 Typographic Conventions ......................................................................................................................
Renaming a cfg clause in an INDEX file .........................................................................................21 Creating a new cfg clause from an existing clause ...........................................................................22 Removing a configuration file from a cfg clause ...............................................................................22 Removing a script from an INDEX file ......................................................................................
_hp_hide_other_disks ...........................................................................................................100 _hp_saved_detail_level .......................................................................................................100 _hp_os_bitness .......................................................................................................................101 _hp_force_autoboot .............................................................................................
Creating new files .....................................................................................................................158 Adding new menu entries to a file...............................................................................................159 Using an "append" file ..............................................................................................................160 Updating a menu entry in a file .......................................................................
How do I recognize if a disk exists or not from within a configuration file? ..........................................206 How do I create the CD equivalent of a tape created by make_boot_tape? .....................................207 How do I enable the X server and CDE during a golden image install? ...............................................211 Summary.........................................................................................................................................
Abstract Ignite-UX for HP-UX addresses the need for system administrators to perform operating system installations, deployment, and recovery, often on a large scale. It provides the means for creating and reusing standard operating system configurations. Additionally, Ignite-UX delivers the ability to archive operating system configurations, and to use these archives to replicate systems, with the added benefit of speeding up the process.
Typographic Conventions The following typographical conventions are used throughout this document. audit(5) An HP-UX manpage. "audit" is the name and "5" is the section in the HP-UX Reference. On the Web and on the Instant Information media, it may be a hot link to the manpage itself. From the HP-UX command line, enter "man audit" or "man 5 audit" to view the manpage. For more information, refer to man(1). Book Title The title of a book.
| Separates items in a list of choices. When used as part of a file name, this placeholder variable refers to the Media Access Control (MAC) address of the Ignite-UX client system under /var/opt/ignite/clients. This may also be referred to as Link-Level Address (LLA). This indicates a directory created by Ignite-UX that has a fixed format containing the date and time it was created, for example "2004-01-12,15:23".
Configuration files and INDEX files This section discusses the contents of configuration files and INDEX files to help you understand the purpose of the files, not to document what is occurring in the files. The INDEX file The file /var/opt/ignite/INDEX is used during cold-installs. The following example only has one cfg clause; usually there are more.
The CINDEX file The CINDEX file is very different from the INDEX file. The CINDEX file is created and managed by the make_net_recovery command. The format of the CINDEX file is the same as the INDEX file. For example: # cat /var/opt/ignite/clients//CINDEX # This file is used to define the Ignite-UX configurations # and to define which config files are associated with each # configuration. See the ignite(5), instl_adm(4), and # manage_index(1M) man pages for details.
# init _hp_root_disk="8/16/5.6.0" init _hp_root_grp_disks=1 init _hp_root_grp_striped="NO" ... In this case, a recovery archive has been selected. (This also indicates that a recovery archive may have been recovered onto this system at some time in the past.) The global config.local file The file /var/opt/ignite/config.local is included by default into all new cfg clauses in the /var/opt/ignite/INDEX file. For this reason, configuration data stored in this file is used on all new installations.
Configuration also has an order of precedence when you are booting a system. The precedence is as follows: 1. The first 8 KB of the installation file system has the highest precedence since it is the first configuration read by Ignite-UX. 2. During media installations, if there is a LIF file called CUSTOM on any device, this file is loaded and parsed after the configuration from the installation file system has been processed.
You can now use the instl_dbg command to print out the fully parsed configuration (The –D option points it to a per-client directory containing the files it needs. The –f option designates where to write the parsed configuration). This will occur with and without the config file being present in the per-client directory: # instl_dbg -D . -f /tmp/client.with.config # mv config config.save # instl_dbg -D . -f /tmp/client.with.no.
The cfg clause needs the following information: 1. 2. 3. 4. A name (for example, HP-UX B.11.11 Default) A description (see the description keyword) A list of one or more configuration files referenced by this cfg clause One or more configuration files that define software that may be installed 4 When a cfg clause is selected (it has been set to TRUE and nothing of higher precedence changes this), its configuration files are processed in order and evaluated.
/var/opt/ignite/recovery/2004-01-12,15:23 # ll *cfg -rw-r--r-1 root sys 3032 Jan 12 15:24 archive_cfg -rw-r--r-1 root sys 963 Jan 12 15:24 control_cfg -rw-r--r-1 root sys 7223 Jan 12 15:24 system_cfg The main difference is that the three configuration files end up in a single LIF file on the tape when the recovery tape is created. The order of precedence here is unimportant since the tape is the only device used and all of the configuration files are concatenated together into one LIF file (CONFIG).
manage_index -t -s script_file_name [-p] [-v] [-i index_filename] manage_index -w -c cfg_clause_name [-v] [-i index_filename] manage_index -x -c cfg_clause_name [-v] [-i index_filename] Note: The examples presented are for illustration purposes only; they show the intended purpose of the command and use fictional configuration files, index files, and scripts.
Once a release identifier has been determined for the configuration file, the manage_index command behaves as though it was given that release identifier with the –r option. 5 In the following example, if you subsequently tried to add a configuration file based upon a release, it would not work because none of the configuration files contains an operating system release in their path names. However, you can add a file based upon a release if you first add the expected information in the path.
scripts { "/var/tmp/script_a" } On the Advanced tab in the Ignite-UX GUI, the sample script appears so it can be selected and run by a user. The scripts clause in the INDEX file is global in scope; scripts defined here are available for selection with any cfg clause in the INDEX file. You should be careful not to define scripts that make assumptions about the release they will be run on or are not portable across all HP-UX releases.
cfg "testing two" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" } $ manage_index -d -r B.11.11 -i /var/tmp/test/INDEX $ cat INDEX ...
"/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" }=TRUE Listing the names of cfg clauses in an INDEX file The following syntax for the manage_index command lists the names of all of the cfg clauses in an INDEX file: manage_index -l -c cfg_clause_name | -r release ] [-o] [-v] [-i index_filename] For example: $ cat INDEX ... cfg "testing" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.
Listing the name of the default cfg clause in an INDEX file This form of the manage_index command enables you to see which cfg clause is the current default cfg clause: manage_index -l -o [-v] [-i index_filename] For example: $ cat INDEX ... cfg "testing" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" } cfg "testing two" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.
Creating a new cfg clause from an existing clause Using the following form of manage_index, you can easily to create a new cfg clause from an existing clause: manage_index -n existing_clause_name -c new_clause_name [-p] [-v] [-i index_filename] For example: $ manage_index -n "testing" -c "old testing two" -i /var/tmp/INDEX $ manage_index -l -i /var/tmp/INDEX testing two testing old testing two Removing a configuration file from a cfg clause Earlier you learned how to add a configuration file to a clause.
cfg "testing" { description "testing clause" "/var/tmp/config_c" "/var/tmp/config_a" }=TRUE cfg "old testing two" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" } In the previous example, you removed a specific configuration file from the cfg clause “testing”. The following example removes config_c from all B.11.11 clauses: $ manage_index -t -f /var/tmp/config_c -r B.11.11 \ > -i /var/tmp/INDEX $ cat INDEX ...
$ manage_index -a -s /var/tmp/script_a -i /var/tmp/INDEX $ cat INDEX ... cfg "testing two" { description "testing clause" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" } cfg "testing" { description "testing clause" "/var/tmp/config_c" "/var/tmp/config_a" }=TRUE cfg "old testing two" { description "testing clause" "/opt/ignite/data/Rel_B.11.
In conjunction with the earlier form of manage_index used to list out the names of cfg clauses in an INDEX file, the preceding command can be used to ensure that all of the configuration files referenced in an INDEX file are present and, as far as can be determined, correct.
You can use the –b option when you want to operate on all of the unbundled product filesets in a depot and the –B if you want to operate on all product filesets within a depot. You can use the –p and –f options to modify what the –b option does (although you cannot use them with the –B option). The –p option creates one bundle for every product in the depot, making –B unnecessary. When used with the –b option, the command only processes products that are not already contained within a bundle.
package the bundle in the depot. The example swpackage command contains the path given to PSF “as is”. You may need to change the path to the PSF file in the example if you change your current working directory or move the PSF file. With the –r option, you can specify a revision for a bundle. This allows you to create bundle wrappers with revision numbers, enabling you to better manage changes to software.
"PB_Sept_2007,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP". * Package Phase succeeded. ======= 08/30/07 16:25:13 EST END swpackage SESSION With swlist, you can verify that all of the patches are now contained within the bundle: # # # # # # swlist -d @ /var/opt/ignite/depots/Rel_B.11.23/patches Initializing... Contacting target "test"... Target: test:/var/opt/ignite/depots/Rel_B.11.23/patches # # Bundle(s): # PB_Sept_2007 1.
* Source: test:/var/tmp/psf.28291 * Target: test:/var/opt/ignite/depots/Rel_B.11.23/patches * Software selections: * * Beginning Selection Phase. * Reading the Product Specification File (PSF) "/var/tmp/psf.28291". * Reading the bundle "PB_Sept_2007" at line 11. * Selection Phase succeeded. * Beginning Analysis Phase. * Analysis Phase succeeded. * Beginning Package Phase. * Packaging the bundle "PB_Sept_2007,r=1.1,a=HP-UX_B.11.23_IA/PA,v=HP". * Package Phase succeeded.
In the preceding example, note that most of the output is not shown. If you wanted the ls patch PHCO_33976 to have its own wrapper bundle, you could have instead used –b and changed the bundle name, revision, and so forth and created a new bundle to hold the patch. The following example demonstrates what happens when you use the –o option to create a PSF. It also shows how you can then use the PSF with swpackage to implement the changes yourself.
# swpackage -s ./PB-Sept_2007.psf -xlayout_version=1.0 \ > -xreinstall_files=true -d /var/opt/ignite/depots/Rel_B.11.23/patches ======= 08/30/07 16:55:31 EST BEGIN swpackage SESSION * Session started for user "root@test ". * Source: test:./PB-Sept_2007.psf * Target: test:/var/opt/ignite/depots/Rel_B.11.23/patches * Software selections: * * Beginning Selection Phase. * Reading the Product Specification File (PSF) "./PB-Sept_2007.psf". * Reading the bundle "PB_Sept_2007" at line 11.
The –i, -c, and –o options are discussed in the "The make_bundles first form" section. The following examples show what happens when you use the –p and –f options with the make_bundles command. These examples do not have a depot with any bundles, so the–b option has no effect. The first example uses the –p option to show bundles being produced at the product level: ======= 08/31/07 14:24:04 EST BEGIN swpackage SESSION * Session started for user "root@test ". * Source: test:/var/tmp/psf.
# make_bundles -b -f -i /var/opt/ignite/depots/Rel_B.11.23/patches Generating list of unbundled filesets... Generating swpackage PSF... ======= 08/31/07 14:30:41 EST BEGIN swpackage SESSION * Session started for user "root@test ". * Source: test:/var/tmp/psf.29995 * Target: test:/var/opt/ignite/depots/Rel_B.11.23/patches * Software selections: * * Beginning Selection Phase. * Reading the Product Specification File (PSF) "/var/tmp/psf.29995". * Reading the bundle "b_PHCO_31622_SYS" at line 11.
/opt/ignite/bin/make_bundles {-p|-f|-B } [-i] [-c category] [-o psf] [-l file| product/fileset...] depot_path Note: With this form of the command you cannot give the bundles you are creating a name. The most useful form of this command involves giving the –o option to create a PSF that can be used for subsequent packaging. In this example, you create some of the same bundles that were created in previous examples.
Using the instl_dbg command Introduction The instl_dbg command is often overlooked but offers valuable functionality in testing the effect of a change in a configuration file. This section introduces some of the useful functionality of instl_dbg and how it can be combined with the itool command to rapidly prototype and test configuration changes.
This runs the itool user interface as though it were running on the client system. 15 You must run itool as root. Important: Do not change time-related information in the Ignite-UX GUI unless the system you are on is considered non-production; altering the time information changes the system clock. Configuration changes are saved into the configuration file in the per-client directory.
With the –d option, you can get instl_dbg to print out the expected size of the volumes it creates and what the impacts are for each file system. The expected output of percent (%) used is also shown with the file system type. If the disk does not contain enough space, the amount shy (KB) column indicates the additional space needed. # instl_dbg -D .
With the –s option, the value of all variables, sw_sel objects, and usage models are shown. The information is quite detailed. From the information for sw_sel objects, you can tell if sw_sel has been selected, if it has been selected because of a dependency, or if it has been unselected because of an exrequisite. The variable information provides the name of the variable, the value that it holds, the type of variable, and whether the variable is visible (based on the setting of visible_if).
type: string visible: 0 Effects var: _hp_pri_swap Effects var: _hp_min_swap Effects var: _hp_disk_layout Effects var: _hp_root_grp_disks ... ======= Use-Model Attributes: ====== Use model name: "Create /export volume" selected: 0 selectable: 1 visible: 1 Use model name: selected: selectable: visible: "Create separate volumes (/usr, /var, ...)" 1 1 1 Using the –f option, the instl_dbg command also provides a completely parsed version of the configuration.
... init sw_sel "b_PHSS_28764"=FALSE init sw_sel "b_PartitionManag"=FALSE # sw_sel "perl" will be loaded due to other software. (cfg "HP-UX B.11.11 Default") { ... sw_source "core" { description="HP-UX coreSoftware" source_type="NET" source_format=SD sd_server="10.0.0.60" sd_depot_dir="/var/opt/ignite/depots/Rel_B.11.11/core" sd_command_line=" -xpatch_filter=*.
_hp_disk_layout+={"Modified LVM Layout"} init _hp_disk_layout="Modified LVM Layout" (_hp_disk_layout=="Modified LVM Layout") { # Disk/File system Layout: volume_group "vg00" { usage=LVM physical_volume disk[_hp_root_disk] { } # end pv_options max_physical_extents=2500 logical_volume { mount_point="/stand" disk[_hp_root_disk] usage=HFS size=307200K FILE_LENGTH=LONG FRAGSIZE=8192 BLKSIZE=65536 bad_block_relocate=FALSE contiguous_allocation=TRUE } # end logical_volume ...
# export INST_CLIENT_DIR=./ # export PATH=$PATH:/opt/ignite/lbin # rescan_hw_host * Scanning system for IO devices... * Querying disk device: 0/0/1/1.15.0 ... * Querying disk device: 0/0/2/1.15.0 ... # ll total 4 -rw-r--r-1 root sys 214 Apr 27 15:31 host.info -rw-r--r-1 root sys 688 Apr 27 15:31 hw.info # cat host.info MEMORY=1310720K HARDWARE_MODEL="9000/800" MODEL="9000/800/A400-6X" can_run_32bit=TRUE can_run_64bit=TRUE is_numa=FALSE is_ia64=FALSE is_hppa=TRUE _hp_boot_dev_path="0/0/1/1.15.
manually change the io.info file, this file is considerably more complex than the hw.info file and manual changes are likely to leave the file unusable. Miscellaneous configuration tips In Ignite-UX configuration files, TRUE and FALSE should be stated only in upper- or lower-case and never in mixed case. Ignite-UX does not understand TRUE or FALSE when they are in mixed case. This applies to other keywords as well. Be careful when deciding to use the = or += operators.
"/opt/ignite/data/Rel_B.11.11/hw_patches_cfg" "/var/opt/ignite/config.local" } This section describes these configuration files and explains what is happening and why certain things have been done in certain ways. The release-specific configuration file The config file defines all of the file system and volume management configurations for the release (and a few other things).
HP-UX Release 18 PA-RISC Itanium®-based B.11.11 B.11.11 N/A B.11.23 B.11.23 B.11.23 B.11.31 B.11.31 B.11.31 Therefore, if you boot the B.11.11 installation kernel you can install HP-UX B.11.11 but you cannot install B.11.23. The reverse applies - if you boot the B.11.23 PA-RISC installation kernel, you cannot install B.11.11 with it. When you create custom configuration files and do not plan to include the default configuration files you must set this variable. release="B.11.
the Basic tab. The form used in the next example to initialize a list of possible values allows the Ignite-UX GUI to modify the list later. Further in the configuration file, when giving _hp_disk_layout a final value you only assign its value using init. When using the form "init _hp_disk_layout="…" the Ignite-UX GUI is still allowed to modify the value. If you instead define "_hp_disk_layout="…"" without the init, the Ignite-UX GUI cannot change this value.
The next section of the configuration file presents a critical concept that it is important to understand – the idea of the effects relationship. An effects relationship creates a relationship between two variables so that when one variable changes the other variable is re-evaluated – even if its final value is not based upon that variable.
{ _hp_min_swap = 512Mb } (_hp_min_swap > 192Mb & disk[_hp_root_disk].size < 1800Mb) { _hp_min_swap = 192Mb } (_hp_min_swap > 96Mb & disk[_hp_root_disk].size < 700Mb) { _hp_min_swap = 96Mb } (_hp_min_swap > 68Mb & disk[_hp_root_disk].size < 600Mb) { _hp_min_swap = 68Mb } Now _hp_sec_swap has been initialized with a set of values that can be chosen from; however, they are not a fixed set of values.
# # Define the defaults based on the system architecture 700 vs 800 # is_hppa { HARDWARE_MODEL ~ "9000/7.*" { init _hp_disk_layout = "Logical Volume Manager (LVM) with VxFS" } else { # For a certain class of S800's, non-LVM takes >30 minutes to boot due # to sequential access firmware. So make the default LVM on them no # matter what size of disk it is. disk[_hp_root_disk].size >= 600Mb | HARDWARE_MODEL ~ "9000/825.*" | HARDWARE_MODEL ~ "9000/834.*" | HARDWARE_MODEL ~ "9000/835.
The expression in the next example is defining a use model. Use models are not variables; they are true / false expressions that are used to control how things are done 22 . Like variables, use models can be viewed using the Additional button of the Basic tab in the Ignite-UX GUI. When you are in the Additional dialog box, use models look visibly different from variables. Later in the configuration file, is the impact statement that this use model would have when it is set to true.
Next is another use model defined called "Create separate volumes (/usr, /var, ...)". It is used later for _hp_disk_layouts other than "Whole disk (not LVM) with HFS" only. By default, this is TRUE (and the Ignite-UX GUI does show separate volumes for /usr, /var, … by default). INIT "Create separate volumes (/usr, /var, ...)" = TRUE The first disk configuration "Whole disk (not LVM) with HFS" is protected by a test of the variable _hp_disk_config to see if it is equal to "Whole disk (not LVM) with HFS".
Now size is set to the remaining, which takes whatever space is left over once "other" things (in this case swap at the end of the disk) have been allocated., The mount point naturally is "/" (since it is the root file system). Lastly, if this is a very small disk change minfree to be 5% (you are installing B.11.11 and there is no way you can fit B.11.11 onto a 300MB disk anyway).
The _hp_group_name does not actually do anything except hold the initial name of the volume group or disk group that this configuration is defining. If this variable could be changed using the Additional button, it would not do anything since it is only a temporary variable to hold the name 29 .
# In order to accommodate adding 9GB disks now or in the # future, set the default max_physical_extents large # enough to handle it (based on 4Mb extent size). # Note that this will be increased by IUX automatically # for disks larger than 9GB. max_physical_extents = 2500 Very large disks are the most common disks on new systems with ≥140GB disks considered large, 36/72GB disks average, and 18GB disks small.
If you are not expected to create separate logical volumes for file systems like /usr and /var then the sizes are the remaining space up to 1200MB if the size of the disk is less than 8192MB or the remaining space up to 1200MB plus the size of _hp_pri_swap 32 . The root file system cannot have bad block relocation on and must be contiguous; therefore contiguous_allocation is set to true, and bad_block_relocation is set to false.
You looked at _hp_sec_swap earlier in the configuration file to see how it was defined. The only place you can give it a value is by using the Additional button on the Basic tab in the Ignite-UX GUI. You can manually define secondary swap using the File system tab, but you must manually select the disk to avoid it being on the same disk as primary swap. The configuration enables you to have secondary swap/dump. You only have to care about its size, not placement.
} else { size = 112Mb } } else { size = 300Mb } contiguous_allocation = true bad_block_relocate = false } 300MB is the default for large disk configurations because additional Dynamically Loadable Kernel Modules (DLKMs) require more space in /stand. Now at this stage you might be wondering why you had to make sure that you set up those logical volumes with certain values for contiguous allocation and bad block relocation. Table 3 contains a brief summary of the reasons.
offset limit for dump since they all support block-based dump. In these cases the size is limited to the size of the disk itself. If the option to create separate volumes is true (the default), then the following very long block of definitions is examined: "Create separate volumes (/usr, /var, ...)" { Next is a definition for /usr.
If the configuration item _hp_root_grp_striped is set to "YES" then you set up striping. The "stripes = *" set the number of stripes equal to the number of disks in the volume group. The stripe size _hp_FS_stripe_size was set up earlier as 64KB. _ hp_root_grp_striped == "YES" { stripes = * stripe_size = _hp_FS_stripe_size } } The definition of /opt is very similar to the definition of /usr. For this volume and the others defined by setting "Create separate volumes (/usr, /var, ...
logical_volume { mount_point = "/var" largefiles = true _hp_disk_layout == "Logical Volume Manager (LVM) with HFS" { # /var needs lots of inodes due to SD's IPD nbpi = 2048 usage = HFS blksize = _hp_HFS_blksize fragsize = _hp_HFS_fragsize } else { usage = VxFS blksize = _hp_VxFS_blksize } disk[_hp_root_disk].
usage = HFS blksize = _hp_HFS_blksize fragsize = _hp_HFS_fragsize } else { usage = VxFS blksize = _hp_VxFS_blksize } size = remaining | 100Mb _hp_root_grp_striped == "YES" { stripes = * stripe_size = _hp_FS_stripe_size } } } The /home volume always gets defined and has a rather small size with no minimum, going up to 20MB.
_hp_disk_layout == "VERITAS Volume Manager (VxVM) with VxFS" | _hp_disk_layout == "Logical Volume Manager (LVM) with HFS" | _hp_disk_layout == "Logical Volume Manager (LVM) with VxFS" { "Create /export volume" visible_if true "Create separate volumes (/usr, /var, ...)" visible_if true _hp_sec_swap visible_if true _hp_root_grp_striped visible_if (_hp_root_grp_disks > 1) _hp_root_grp_disks visible_if true } else { "Create /export volume" visible_if false "Create separate volumes (/usr, /var, ...
support booting into any other mode than the default multi-user run level at this point. The installation or recovery session has not yet completed and some steps must still be performed by Ignite-UX. Booting into anything other than the default run level does not allow the installation or recovery to complete. This is the intended behavior of Ignite-UX and not a flaw.
2. Makes sure that _hp_os_bitness is set and set correctly (it should be set by the configuration file that defines the core operating system depot or archive sw_sel clause). 3. Makes sure that the system can run the bitness of HP-UX. 4. Sets the operating system Name attribute for the swinstall command line. ################################################################# # Ensure that the swinstall command line used contains the correct pose_as # attributes for the type of system being installed.
cfg "HP-UX B.11.31 Default" { description "This selection supplies the default system configuration that HP supplies for the B.11.31 release." "/opt/ignite/data/Rel_B.11.31/config" "/opt/ignite/data/Rel_B.11.31/hw_patches_cfg" "/var/opt/ignite/config.local" } Of course, by itself, this can’t be used to install a system as it doesn’t have a configuration file referencing any software to be installed. This section describes the per release configuration file /opt/ignite/data/Rel_B.11.
The release keyword is probably the single-most important keyword in an Ignite-UX configuration file. This keyword must be set or else any installation of HP-UX is likely to fail or not work properly. Ignite-UX has no idea what version of HP-UX it is installing unless it is set. As of Ignite-UX C.6.0.x, the release keyword is checked against the value of the _hp_ikernel_os_release variable (the client creates the value of this variable in the host.info file).
and much older systems that had smaller default block and fragment sizes. (For example, the file system attributes are different so the block and fragment sizes from older systems are probably smaller.) The use of visible_if false ensures that the variables do not appear in the Additional dialog box from the Basic tab. ####################################################################### init _hp_HFS_blksize = 65536 # HFS block size. init _hp_HFS_fragsize = 8192 # HFS frag size.
init _hp_service_partition_size = 400Mb _hp_service_partition_size help_text "HP Service Partition (KB)" } else { _hp_efi_partition_size visible_if false _hp_service_partition_size visible_if false } The following shows the start of a definition for the _hp_disk_layout variable, which is set to one of several possible values depending on if this is a HP9000 or HP Integrity system. Around the _hp_disk_layout is a test for is_ia64 and is_hppa (is HP Integrity or PARISC/HP9000 system).
"Logical Volume Manager (LVM) with HFS", "Logical Volume Manager (LVM) with VxFS", "VERITAS Volume Manager (VxVM) with VxFS" } } # convert strings for backwards compatibility (_hp_disk_layout == "Whole disk (not LVM) with VxFS") { _hp_disk_layout = "Whole disk with VxFS" } (_hp_disk_layout == "VxVM with VxFS") { _hp_disk_layout = "VERITAS Volume Manager (VxVM) with VxFS" } Here the variable _hp_disk_root is set to the value of _hp_primary_path, assuming that the device _hp_primary_path points to exists and
Although we cover effects relationships in other places, it is worthwhile revisiting it again. Normally, once a value is worked out for a variable it is not reevaluated again. Effects relationships set relationships between values, so when one changes the other is forced to be reevaluated. The effects relationships below cause _hp_pri_swap to be reevaluated whenever the size of the root disk changes, or when the disk layout is changed.
} } Here we set up an effects relationship between _hp_min_swap and _hp_pri_swap. That is followed by some final adjustments to the size of primary swap based on the size of the root disk and the amount of memory in the system. Depending on the size of the root disk and the amount of memory in then system, Ignite-UX will attempt to place a sensible lower bound (_hp_min_swap) on the size of primary swap.
_hp_sec_swap help_text "Secondary Swap space (KB)" From here we are going to be looking at the disk layouts. Some parts of the disk layout have changed significantly for HP-UX 11i v3. ####################################################################### # Determine disk layout for volumes and file systems. # You should have noticed by now that for HP-UX 11i v3, all of the tests related to legacy HP9000 systems have been removed.
Additional dialog box, use models look visibly different from variables. Later in the configuration file is the impact statement this use model would have when it is set to true. INIT "Create /export volume" = false Now you have another effects relationship, this time between a new variable _hp_root_grp_disks and _hp_root_disk. The variable _hp_root_grp_disks is meant to be an integer, so when doing the effects relationship you add zero (0) to disk[_hp_root_disk].
For the physical volume statement, you need only supply the name of the disk used as the root disk. (The disk[] keyword takes a hardware path or index number, and returns the name of the disk.) This discussion assumes you are defining the boot disk as a whole disk 46 . _hp_disk_layout == "Whole disk with VxFS" | _hp_disk_layout == "Whole disk (not LVM) with HFS" { partitioned_disk { The file system partition on a partitioned disk must be HFS for HP9000 systems.
swap_partition { usage = SWAP mount_point = "primary" size = _hp_min_swap | remaining | _hp_pri_swap } } } Here are the volume manager disk layouts. The definition of logical volumes and volumes are performed identically with Ignite-UX. The usage definition (LVM or VxVM), not the volume group definition, determines if LVM or VxVM will be used.
A volume group definition must have the following: volume group attributes one or more physical_volume definitions (including "group" 51 definitions that also include more physical volume definitions) one or more (usually more) logical_volume definitions. volume_group _hp_group_name { The physical_volume definition places the first disks (whose number is determined by _hp_root_grp_disks) returned by the disk[] construct into the root volume group 52 .
In a custom configuration, it might be better to scale both max_physical_extents and physical_extent_size based upon the disk size. # # As disk size increases the root group VGRA meta-data area # will outgrow it's bounds and trigger an IUX sanity check # error. So for root disks large enough, set the physical # extent size. Note that this only handles the root disk, but # any disk in the root VG could trigger the error... # For consistency with previous releases these disk sizes # are specified in MB.
Next, primary swap is defined. The usage has been set to swap and dump. The mount_point is set to "primary". The vgdisk[0] value enables you to specify that this logical volume be placed onto the first disk in the root volume group. Refer to instl_adm(4) for more information on the vgdisk keyword. Next are the usual settings for primary swap of contiguous allocation and disabled bad block relocation. The size must be at least _hp_min_swap and up to _hp_pri_swap depending on the size of the disk.
system won’t boot). The size defined here is fixed at 2000MB. Note that impacts exist later that prevent you from decreasing the size below approximately 1GB. The reason for the much larger size is that kernels are considerably larger on HP-UX 11i v3 than previous HP-UX releases.
blksize = _hp_HFS_blksize fragsize = _hp_HFS_fragsize } else { usage = VxFS blksize = _hp_VxFS_blksize } size = 512MB | remaining | 25% free _hp_root_grp_striped == "YES" { stripes = * stripe_size = _hp_FS_stripe_size } } The definition of /opt is identical to /usr. Please refer to the discussion of /usr for more information.
blksize = _hp_HFS_blksize fragsize = _hp_HFS_fragsize } else { usage = VxFS blksize = _hp_VxFS_blksize } size = 512Mb | remaining | 512Mb + _hp_pri_swap _hp_root_grp_striped == "YES" { stripes = * stripe_size = _hp_FS_stripe_size } } In previous releases of HP-UX, the /tmp file system size was based upon the size of the root disk (64MB if less than approximately 8GB, or 200MB if greater). The size of the file system has been increased to be simply 512MB.
size = remaining | 100Mb _hp_root_grp_striped == "YES" { stripes = * stripe_size = _hp_FS_stripe_size } } } The /home directory has also changed in size from previous releases of HP-UX, making it much more usable in a default state. The new size is up to 100MB (depending on free space) previously it was up to 20MB in size.
_hp_sec_swap visible_if true _hp_root_grp_striped visible_if (_hp_root_grp_disks > 1) _hp_root_grp_disks visible_if true } else { "Create /export volume" "Create separate volumes (/usr, _hp_sec_swap visible_if _hp_root_grp_striped visible_if _hp_root_grp_disks visible_if } visible_if false /var, ...)" visible_if false false false false The following impacts have changed from previous releases. Note the large impacts on /stand. This prevents you from decreasing the size of /stand below about 1GB in size.
Important: If you disable autoboot and then install a system, the system never executes a final reboot without manual intervention. HP does not support booting into any other mode than the default multi-user run level at this point. The installation or recovery session has not yet completed, and some steps must still be performed by Ignite-UX. Booting into anything other than the default run level does not allow the installation or recovery to complete.
# range provided if you click on the button is from 0-10, but a larger # value can be entered directly in the field if desired. # _hp_addnl_fs_free_pct = { 0,1,2,3,4,5,6,7,8,9,10 } init _hp_addnl_fs_free_pct = 10 _hp_addnl_fs_free_pct help_text "Additional free space %" The configuration that used to exist before this variable for previous releases is no longer present. It is no longer required with HP-UX 11i v3.
If _hp_locale is not set, it is set internally to the first value of the locale keyword for a selected sw_sel. If multiple selected sw_sels contain locale keywords, the _hp_locale variable is set to the first value of the locale of the first selected sw_sel. The geocustoms 54 application is used to manage the default locale on a system. If a locale is not important, do not set one.
For example, the line _hp_cfg_detail_level="ivsp" in a client configuration file would indicate that the file contains information about which cfg INDEX selection is to be used, as well as the variable settings, software selection settings, and system parameters. The user interface rewrites the config and config.full files in the per-client directories on the Ignite-UX server for network installation and recovery, or in the /var/opt/ignite/local directory for local media installation and recovery.
_hp_disk_layout The _hp_disk_layout string variable is set by the Ignite-UX GUI to indicate which disk layout (LVM, whole-disk, etc) that you have selected. As configurations are saved, the list of values that it can have is increased to contain any modified layouts. There are ways you should and should not define this variable. The following is the correct way to define the _hp_disk_layout variable; this assumes that _hp_root_disk has already been set.
(disk[_hp_root_disk].size<400000Mb) { _hp_disk_layout="N4000 with 36Gb disk" } else { _hp_disk_layout="N4000 with 72Gb disk" } } } } The difference between the two sets of configuration is that the init keyword is missing from the second set of configuration statements when _hp_disk_layout is set to be a specific value.
Important: Only perform this test with one of the standard unmodified layouts. Do not perform this test with a modified disk layout. Removing init prevents you from modifying anything to do with the file system. The values in _hp_disk_layout are only indirectly visible. The list of values in the _hp_disk_layout variable is shown on the Basic tab in the Ignite-UX GUI in the File System: list. The use of init indirectly affects how _hp_disk_layout works.
with the LAN device specified by this variable is used for the entry in the /etc/hosts file for the system's hostname. That means that if you have the following partial configuration: final ip_addr[]="15.30.129.47" final netmask[]="255.255.255.0" The IP address information is applied to the LAN interface defined by the variable _hp_default_final_lan_dev, and this IP address is the one associated with the name of the host in the /etc/hosts file.
–k option, enables you to specify an alternate file to read. Refer to keymap_ed(1) for more information. The standard configuration files use _hp_keyboard visible_if false to prevent this variable from being visible or changeable using the Additional button in the Ignite-UX GUI. It can be set for clients with required hardware from the Keyboard button on the Basic tab. If the hardware is not present, the only choice presented is "Not Applicable".
The bootsys command stores the original AUTO file line as a commented-out string in the AUTO file itself (using '#' as the comment char). Ignite-UX uses the value in _hp_boot_dev_path to reset the AUTO file in the LIF of that device if that disk is not used in the install. On Itanium®-based systems the AUTO file is stored in the Extensible Firmware Interface (EFI) partition. Ignite-UX treats that AUTO file exactly the same way as the PA-RISC AUTO file stored in a boot LIF.
This variable can affect new installations or reinstallations. If you have sized the boot disk of a system to a certain size and have not included the size of the EFI Partition (and Service Partition, see "_hp_service_partition_size") you may not have enough disk space to install the system in the way that you want. _hp_service_partition_size The _hp_service_parition_size integer variable is set by the Ignite-UX GUI and indicates the size of the HP Service Partition on Itanium®-based systems.
The itool wizard prompts you to specify whether the disks in the root volume/disk groups should be striped (as well as to specify the number of disks in the root volume/disk group on the same screen). However, in the Ignite-UX GUI you must use the Additional button on the Basic tab to display the item Stripe root VG disks?. Even though instl_adm(4) discusses LVM, striping also applies to VxVM (VxVM licensing may restrict its use).
$ print "f tmp/a 1024" | /opt/ignite/lbin/gen_impacts impacts = "tmp" 8Kb $ print "f tmp/a 10240" | /opt/ignite/lbin/gen_impacts impacts = "tmp" 16Kb The first command specifies a file size tmp/a of 1KB, but the impact is 8KB. The second command specifies a file size of tmp/a as 10KB, and the impact is 16KB. Most systems these days use VxFS instead of HFS for file systems. VxFS file systems are extentbased file systems and can usually allocate (space allowing) blocks as small as 1KB to a file.
impacts = "/sbin/init.d" 1256Kb … The size differences in the first four impacts are summarized in Table 4 (the percentage difference is between the 2KB and 8KB fragments compared to the 1KB fragment impacts): Table 4 Impacts Size (1KB) Size(2KB) % difference Size (8KB) %difference / 1138 1138 0.0% 1138 0.0% /usr/lib 599090 603124 0.7% 632140 5.5% /sbin/lib 561 578 3.0% 684 21.9% /usr/conf 107843 108359 0.5% 111703 3.6% /sbin/init.d 664 743 11.9% 1256 89.
_hp_lanadmin_args If your network requires that the default MTU or speed be set using the lanadmin command to operate correctly, you can specify the arguments to the lanadmin command using the _hp_lanadmin_args variable. This variable setting must be set in the INSTALLFS file using the instl_adm command. Any change made with this variable only affects the installation and is not permanently applied to the system.
Problems that can be solved with _hp_lanadmin_args". _hp_nfs_mount_opts The _hp_nfs_mount_opts string variable is set in the INSTALLFS file and is used to supply additional options to the NFS mounts that are performed during the installation. This is intended for use when the default options are not appropriate for your network. (Refer to mount_nfs(1M) for valid options).
10.0.0.1:/var/opt/ignite/clients /var/opt/ignite/clients" NOTE: Retrying: "/usr/sbin/mount -orw 10.0.0.1:/var/opt/ignite/clients /var/opt/ignite/clients" NOTE: Retrying: "/usr/sbin/mount -orw 10.0.0.1:/var/opt/ignite/clients /var/opt/ignite/clients" ... The messages continue until either the amount of retries given in _hp_nfs_mount_retries is exceeded or the NFS file system mounts successfully.
_hp_os_bitness The _hp_os_bitness string variable is used to package software for running on a 32-bit operating system, 64-bit operating system, or both. The _hp_os_bitness variable is set to either 32 or 64 when an operating system is chosen. This is normally done in a configuration file by keying off the sw_sel for a 32- or 64-bit operating system. The sw_sel statements for certain applications rely on the setting of this variable to tell which version of the application to install.
_hp_ikernel_os_release The _hp_ikernel_os_release variable is not defined in the Ignite-UX documentation and it should never be set explicitly by any custom written Ignite-UX configuration files. When a client boots, part of starting Ignite-UX for installation or recovery is to create a file called "host.info". As of Ignite-UX version C.6.0.x, this variable is added to the host.info file and gives the HP-UX revision that the installation kernel is running.
# If cloning to a different model of machine, _HP_CLONING will # be true (it can also be set via the Additional UI screen). In # this case remove the kernel which will allow IUX to rebuild it, # plus remove device files which will get rebuilt by insf or # might be inappropriate. if [[ "$_HP_CLONING" = "TRUE" ]] ; then remove_devs rm -f /stand/vmunix fi This variable does not control anything else.
_hp_patch_save_files help_text "Save patched files?" However, the description in the previous example is wrong because the patches are not committed. This variable construct only controls whether the swinstall option -x patch_save_files=true or false command is added to the swinstall command line. Later in the same file, the following construct is found: (_hp_patch_save_files == "NO") { sd_command_line += " -xpatch_save_files=false " } else { # This is actually the default...
init _hp_ht_enable="true" _hp_ht_enable help_text "Enable firmware hyperthreading" } else { _hp_ht_enable visible_if false } This allows you to set the state of Hyper-Threading during a cold install using SD depots. Note that setting this variable to “true” on systems that do not support Hyper-Threading has no effect. _hp_debug_level The _hp_debug_level variable allows you to set the debug level without having to interact with the boot loader.
# cat vpars_A.02.02.00.cfg ######################################################### ## Software Sources ######################################################### sw_source "/var/opt/ignite/depots/T1335AC_A.02.02.00" { source_type = "NET" sd_server = "10.0.0.1" sd_depot_dir = "/var/opt/ignite/depots/T1335AC_A.02.02.00" source_format = SD } Next is patch software.
visible_if = TRUE } else { visible_if = FALSE } } The configuration file is not yet 100% complete and requires a manual change that causes problems. Specifically, the patch defined by the sw_sel, b_PHSS_28764 needs to be installed at the same time as T1335AC. Therefore, you need to make a small change to the sw_sel clause for T1335AC: sw_sel "T1335AC" { (_hp_os_bitness == "64") { description = "HP-UX Virtual Partitions" sw_source = "/var/opt/ignite/depots/T1335AC_A.02.02.
sw_source "/var/opt/ignite/depots/T1335AC_A.02.03.02" { source_type = "NET" sd_server = "10.0.0.1" sd_depot_dir = "/var/opt/ignite/depots/T1335AC_A.02.03.02" source_format = SD } Now vPars version A.02.03.
} } sw_sel "KRMonitor" { description = "EMS Kernel Resource Monitor" sw_source = "/var/opt/ignite/depots/T1335AC_A.02.03.02" sw_category = "HPUXAdditions" sd_software_list = "KRMonitor,r=B.11.11.04,a=HP-UX_B.11.11_32/64,v=HP" ... Using both of these configuration files together (or the configuration file /var/opt/ignite/data/Rel_B.11.11/vpars_A.02.03.02.cfg with anything else) causes conflicts unless manual changes are made.
The exrequisite statements are added to make sure that you cannot select both products at the same time. In this case, to change from one revision of the vPars bundle to the other, simply select it. The originally selected version is automatically unselected because of the exrequisite statement. Warning: You should be careful when creating application depots containing software from different sources, such as the application media and other media.
The sw_source definition for the core operating system depot contains the information needed to define an SD depot. The load_order of 0 (zero) is important for a core operating system depot. The load order determines the order in which Ignite-UX loads the software. Other software products can be loaded at load order 0 except when the core operating system is an archive rather than a depot. When loading a core operating system archive, you can have one and only one sw_sel installed at load_order 0.
sw_category = "HPUXBaseOS" sd_software_list = "HPUXBase64,r=B.11.11,a=HP-UX_B.11.11_64,v=HP" ... exrequisite = sw_category } (sw_sel "HPUXBase64") { _hp_os_bitness = "64" } The following example is the definition of the 32-bit Base HP-UX bundle. It is very similar to the 64bit example. It also has the exrequisite = sw_category attribute that prevents the selection of the 32-bit and 64-bit Base HP-UX bundle at the same time.
The items of most interest here are the regular expressions shown since they need improvement. The next section discusses what the regular expressions do. The regular expression "9000/8.*" means match for the pattern 9000/8 followed by zero or more characters. The "." means any character, and the following "*" changes that to mean zero (0) or more of that character. The regular expression "9000/8" is more precise since it just matches any string containing "9000/8"; the ".*" is superfluous.
The following example shows the OE definitions for all of the OEs on the B.11.11 OE media. The definitions are similar to the other sw_sel definitions already discussed. The impacts statements have been removed, but the impacts are different for 32-bit and 64-bit installations. Subsequent OE definitions and the language clauses that follow them have been removed from this discussion of the core configuration file.
The following definition automatically selects Perl for installation from the OE media. The sw_sel configuration is initialized to TRUE. However, you can deselect the software from installation on the Software tab in the Ignite-UX GUI. init sw_sel "perl" { description = "Perl Programming Language" sw_source = "core" sw_category = "OrderedApps" sd_software_list = "perl,r=D.5.8.0.B,a=HP-UX_B.11.11_32/64,v=HP" impacts = "/opt" 92854Kb } = TRUE The following software is the Online Diagnostics bundle.
"PS2_DIN_Canada_TBITS-3", "PS2_DIN_Canadian_French", "PS2_DIN_Czech", "PS2_DIN_Czech_Euro", "PS2_DIN_Danish", "PS2_DIN_Danish_Euro", "PS2_DIN_Euro_Spanish", "PS2_DIN_Euro_Spanish_Euro", "PS2_DIN_French", "PS2_DIN_French_Euro", ...
What happens if you want to create the following extra file systems (for an application)? /opt/application /opt/application/static /var/opt/application /var/opt/application/data /var/opt/application/tmp Ignite-UX has no information about what data might be stored in these file systems because it has no impacts statements that affect them.
statements. When Ignite-UX processes a large amount of impacts statements it can slow down to a significant degree. Combining those large numbers of impacts statements down into a few that match planned mount points is a manual task (and, unfortunately, if the software ever changes you need to do it all again). Impact Hints Keep impact levels to the minimum required to minimize their affect Ignite-UX performance.
sw_category cat-tag-string { description = string } The sw_category definition provides a grouping mechanism for sw_sel's to reference. The user interface uses the sw_category to help the user browse the software more easily. There are six values of cat-tag-string that the user interface treats special. Software that are in these groups are represented in special locations and by special methods in the user interface.
Defining a custom software configuration The section of instl_adm(4) that defines software configuration is quite long but very useful only sections of it are discussed here. If you require more information, review the section titled "Software Source and Selections". Do not attempt to write configuration files for SD depots. Instead use the make_config command because it correctly defines all configuration data needed. You can then customize the configuration file produced by make_config.
for a core operating system archive if it is a recovery archive or a golden image; you can only have one archive at load order 0). The attribute change_media is set to FALSE because you do not want to be prompted to change the media. It does not make sense to change media when the source is over the network using NFS. You then test to see if the source_type is "NET" and if it defines the nfs_source to point to the archive.
archive_type = gzip tar # For NFS, the path to the archive is relative to the mount point # specified in the sw_source: (source_type == "NET") { nfs_source = "10.0.0.1:/var/opt/ignite/images" } ... visible_if } = TRUE = can_run_64bit (sw_sel "golden image1") { _hp_os_bitness = "64" } _hp_os_bitness visible_if false Next, a language is set up so there is a choice of no locale English, or C locale and English.
} init sw_sel "Run site commands" { description = "Run site commands after OS loaded" sw_source = "site commands" sw_category = "SiteSpecific" post_load_script="/var/opt/ignite/scripts/run_after_load" } = TRUE The difference between this method and placing a post_load_cmd into the core operating system load sw_sel is that you have the opportunity to prevent the commands from running the Ignite-UX GUI by deselecting the software (even though in this case there really is no "software").
signed 32-bit arithmetic for decimal values, and it has problems when values exceed this limit. If larger values are needed, convert them to hexadecimal since the shell does not evaluate them. Note that any allowable syntax supported by the config command can be used in mod_kernel keywords. This includes formulas. For example, it is possible to use: mod_kernel += "ninode (20+8*MAXUSERS+NPTY+" + ${"%d" _inc} + ")" assuming _inc has been initialized to some value in the configuration file.
description = "Kernel Configuration sets" } sw_source "Kernel Configuration" { source_format = cmd load_order = 11 } The first sw_sel defines a set of kernel parameters that can be applied to a system when Java is installed. The only new items here are the exrequisite statement and set_kernel. The set_kernel statements enable you to easily set the formula as the value to be assigned to a kernel tunable since Ignite-UX does not attempt to check the value being assigned to the kernel tunable.
automatically selected; otherwise, if this is a server selected, then "Kernel Config for Servers" will be selected. If neither of these are selected, the "Kernel Config for Workstations" will be selected. ( sw_sel "B9789AA,r=1.3.1.09.08" ) { init sw_sel "Kernel Config for Java" } else { ( HARDWARE_MODEL ~ "9000/8" | MODEL init sw_sel "Kernel Config for } else { init sw_sel "Kernel Config for } } = TRUE ~ "ia64.
} } } ... Forcing software (sw_sel) clauses to be installed Be careful when marking software automatically for installation using a configuration file.
sw_sel "Product XYZ" { description = "Product XYZ base runtime" sw_source = "Applications for 11i Version 1" sw_category = "SiteApps" sd_software_list = "ProductXYZ,r=4.0,v=XYZCorp" } sw_sel "Product XYZ – 4GL" { description = "4GL option for Product XYZ" sw_source = "Applications for 11i Version 1" sw_category = "SiteApps" corequisite = "Product XYZ" sd_software_list = "ProductXYZ4GL,r=4.0,v=XYZCorp" } See "Using a sw_sel to apply kernel parameters" for exrequisite examples.
Similar to above, except that when the ~ operator is used instead of =, then the sw_sel tags listed are treated as fnmatch(3C) regular expressions that can be used to match any selection fitting the given pattern. (Note that this operator uses fnmatch(3C) pattern matching expressions. Other uses of the ~ operator in the configuration file, uses extended regular expressions. This difference is for compatibility with some existing data.) The category string can be specified (with a ".
Overview The general format for Disk Group, Volume Group, and whole disk layout is as follows: partitioned_disk { physical_volume disk[hw_path|index] { physical_volume-attributes... } fs_partition { file-system-attributes... } swap_partition { swap-attributes... } } volume_group group_name { volume_group-attributes... physical_volume group "pvgname" { physical_volume disk[hw_path|index] { physical_volume-attributes... } ... } ... physical_volume disk[hw_path|index] { physical_volume-attributes... } ...
Configuration examples The following section presents several different disk configuration examples. They may prove useful when developing your own configurations. This section does not discuss the extra space that may be allocated to file systems because of impacts configuration statements or the effect that variables such as _hp_addnl_pct_free or _hp_efi_partition_size may have.
# # Add a new disk layout type # _hp_disk_layout += { "Custom configuration for Product XYZ" } The test on sw_sel Product XYZ to the variable set _hp_disk_layout to Custom configuration for Product XYZ is only evaluated once. If Product XYZ is not selected for installation by the time this configuration file is parsed, you must manually change the disk layout to Custom configuration for Product XYZ during installation.
} You can now start the definition of the volume group that has its name set by the variable _my_volume_group; the volume group is explicitly defined to be the LVM: volume_group _my_volume_name { # # Only allow LVM # usage = LVM You now define some volume group attributes, specifically the maximum number of physical extents (Ignite-UX changes this to suit the disks as required). In addition, you set up the PE size here as well. The default configuration file sets the variable up _hp_root_disk for you.
{ mount_point = "primary" usage=SWAP_DUMP contiguous_allocation = true bad_block_relocate = false size = _hp_min_swap | remaining | _hp_pri_swap } Currently, for PA-RISC systems, the boot file system must be HFS. For Itanium®-based systems, the boot file system can be either HFS or VxFS. So here, you define a fixed-size boot file system (/stand) to be HFS.
size = 50Mb | remaining | 200Mb } } The next file system is /usr. The minimum size is 500MB. Depending on available disk space, the volume may be expanded to require a minimum of 20 percent free space after the file system impacts statements associated with software being installed into /usr are taken into account.
The last volumes are defined as follows: # # Define /var/tmp # logical_volume { mount_point = "/var/tmp" usage=VxFS size = remaining | 1000Mb } # # Define /opt # logical_volume { mount_point = "/opt" usage=VxFS (sw_sel "Product XYZ - 4GL" ) { size = remaining | 1500Mb } else { size = remaining | 20% free } } # # Define /home # logical_volume { mount_point = "/home" usage=VxFS size = 500Mb } The default configuration files make setting up a disk configuration much more complex than for a relatively simple d
The following test makes sure that the root disk size is at least the minimum required size for installing an rp8400 system 65 . If the root disk is too small, an error message is presented to users to prevent them from being able eventually to select Go! in the Ignite-UX GUI and install the system. The only recourse is to change the disk layout or increase the size of the root disk by selecting a new one. (hardware_model == "9000/800/SD16K-A" & disk[_hp_root_disk].
You leave the custom configuration at that point since you are only looking for some other tests for automating selection and enforcing it with tests and the error keyword. Instead of using error, using warning might alert the user to choose the selection when the tests fail (for example, to use it on an rp7410 instead.) Example Three (be careful what you ask for, you just might get it) This example disk layout asks for something that just can’t be done.
ERROR: 1000Mb). For more information run "instl_dbg -D -d". The root volume (/) size plus the boot volume (/stand) size plus primary swap size plus dump volume(s) size (1024000Kb + 24576Kb + 17780736Kb + 0Kb) is larger than the root disk (0/0/2/1.15.0)capacity (17776640Kb) by 1052672Kb. These volumes must fit contiguously on the root disk. For more information run "instl_dbg -D -d". In this case there were two disks in the root volume group.
ip_addr[]="10.0.1.45" Doing this might not be very useful on multi-homed hosts because the LAN interface at the lowest hardware address is given the IP address. To give the IP address to a specific LAN interface you must do the following: ip_addr[0/0/0/0]="10.0.1.45" This is applied to an LIF (created with make_medialif –m) with the instl_adm command. The LIF can then be placed on media. Note: Unless you are using unallocated IP addresses, a boot tape or CD|DVD created in this way is specific to a system.
In the second method we will look at a way to define a variable that allows someone to pick from a list of values or allows them to enter any value. Part A (restricting the values that a variable can take using an enum) The following configuration is what we want to end up with.
} Since we can test on the initial value of _my_location_codes, we can show an error and prevent any installation from continuing if a location code has not been set. If one has been chosen we can print out information about the location code. Part B (looking at the same thing when we don’t have an enum) The following configuration is what we want to end up with in this case.
-c which needs to be able to take any specified value (a user name) Since -a is fixed we don't do anything about it. We only need to do something about the variable parts. For option -b we need to create it as an enum because it only takes one of a specific set of values. We don’t need to worry about special configurations to ensure that the user sets a specific value, as in this case we have chosen a suitable default of “5”.
This example is not a reference on how to write regular expressions (complex regular expression writing can be very difficult) but we will look at some common operators and how you might use them. The information provided here is only a very basic introduction to extended regular expressions. An important thing to remember is that ~ is the operator that controls regular expression matching within Ignite-UX configuration files.
( _my_command_c_option ! ~ “^user” ) { error+=”The user name must start with user” } else { note+=”The user name chosen was “ + ${_my_command_c_option} } Note the use of the “!” operator in the test: this reverses the comparison, so an error is given if the value in _my_command_c_option does not match the regular expression. The example is presented this way since you may not want to always print the note - the else and the note can be skipped.
You can test regular expressions against expected data outside of Ignite-UX using grep with the – E 70 option: # cat data u1 u12 u123 u1234 U1a U123456 # cat data | grep -E "^[[:alpha:]][[:digit:]]+[[:digit:]]$" u12 u123 u1234 U123456 This allows you to have some level of confidence that your regular expression will do what you want it to.
Although we’ve concentrated on using character classes for matching, there are cases where this may not be appropriate. In this example we will restrict the letter the user name starts with: “u”, “a”, or “s”.
( _my_command_c_option ! ~ "^(ab|cd|gh)[[:digit:]]+[[:digit:]]$") { error+=”The user must start with ab, cd, or gh followed by only digits” } else { note+=”The user chosen was “ + ${_my_command_c_option} } Try to restrict yourself to simple regular expressions. If complex regular expressions are needed, test them extensively against large amounts of potential values to ensure they behave the way you expect.
is_hppa { dhcp_class_id = "Ignite_PA_clients" } else { dhcp_class_id = "Ignite_IA_clients" } The else condition implicitly means Itanium®-based systems since Ignite-UX currently supports only PA-RISC and Itanium®-based systems. This also assumes that you would want to share the same installation file system configuration. This condition effectively limits what the client responds to 71 . dhcp_server—this keyword can be used to limit the responses that are accepted by a particular server.
Problems that can be solved with _hp_lanadmin_args When a kernel first boots (this is true even of a normal kernel that is not used for installation) all of the 100bt and Gigabit LAN interfaces attempt to autonegotiate the LAN speed and duplex settings. In this example, an rp8400 is connected to an HP Procurve 9315m routing switch. When the switch point to which port the system is connected is set to autonegotiate, the switch, and the system both autonegotiate the speed and duplex.
option to give explicit installation file system names. However, you should try to keep the various installation file systems consistent. This issue creates difficulties when you mix system types that are running at different duplexes and speeds, rather than setting the systems to autonegotiate both. To avoid this situation, you should develop and follow a consistent approach to speed and duplex settings.
Environment variables With the env_vars configuration item, you can place environment variables into the environment of the programs that are run by Ignite-UX. Setting an environment variable is done in the following way: env_vars += "TZ=JST-9" The preceding example sets the time zone for the installation to Japanese Standard Time. Although this time zone does not define daylight savings, if you set a time zone that does have daylight savings you should be very careful.
to one with the same model string 72 ). The following happens, depending on what value you set it to: 0 – A yes/no question is asked: Do you wish to cancel the non-interactive installation in order to respond to the warnings above?. There is no timeout associated with this question; Ignite-UX waits indefinitely for a response. 1 – This message appears: Continuing despite above warnings because INST_ALLOW_WARNINGS=1. The installation/recovery proceeds regardless.
server="10.0.0.2" netmask[]="255.255.255.0" route_gateway[0]="10.0.1.1" route_destination[0]="default" disable_dhcp=true ( lla[0/0/0/0] == "080009654321" ) { ip_addr[0/0/0/0]="10.0.1.45" } ( lla[2/0/2] == "080009654123" ) { ip_addr[2/0/2]="10.0.1.46" } ( lla[1/0/0/0] == "080009654213" ) { ip_addr[1/0/0/0]="10.0.1.47" } ... ( lla[0/0/0/0] == "08000A654321" ) { ip_addr[0/0/0/0]="10.0.2.45" } ( lla[2/0/2] == "08000A654123" ) { ip_addr[2/0/2]="10.0.2.
#ifdef LAN_SEGMENT_2 ( lla[0/0/0/0] == "08000A654321" ) { ip_addr[0/0/0/0]="10.0.2.45" } ( lla[2/0/2] == "08000A654123" ) { ip_addr[2/0/2]="10.0.2.46" } ( lla[1/0/0/0] == "08000A654213" ) { ip_addr[1/0/0/0]="10.0.2.47" } ... #endif You can now use unifdef to create a configuration file for LAN segment one: $ unifdef –t 73 -DLAN_SEGMENT_1 -ULAN_SEGMENT_2 lan.cfg server="10.0.0.2" netmask[]="255.255.255.0" route_gateway[0]="10.0.1.
/opt/ignite/boot/boot_lif). This new format is capable of showing you a menu-like selection and asking you to choose a kernel to boot. Of course, to provide for non-interactive installation and recovery, there is a time-out value for a response and a default response. With PA-RISC systems using Ignite-UX version C.6.0.x or later, an HP-UX B.11.11 kernel is used to install and recover HP-UX B.11.11 systems, and an HP-UX B.11.23 kernel is used to install and recover HP-UX B.11.23 systems.
# auto_adm -f /opt/ignite/boot/boot_lif timeout = 0 default = 1 message = Choose a boot action label = target OS is B.11.11 bootcmd = boot boot = (;0) image = /boot/Rel_B.11.11/INSTALL label = target OS is B.11.23 PA bootcmd = boot boot = (;0) image = /boot/Rel_B.11.23/WINSTALL label = target OS is B.11.31 PA bootcmd = boot boot = (;0) image = /boot/Rel_B.11.31/WINSTALL This reads the AUTO file from the LIF and prints it in the auto_conf (CONF) format.
The auto_adm command is intended for the management of the AUTO file in an LIF that is used by Ignite-UX. The bootcmd field only accepts one argument. ISL data The following example presents the same data as the CONF data although it is translated into ISL format: # auto_adm -f ./output -o ./isl -O ISL # cat isl hpux KernelPrompt "Choose a boot action" 0 2 reset "target OS is B.11.11" boot (;0)/boot/Rel_B.11.11/INSTALL "target OS is B.11.23 PA" boot (;0)/boot/Rel_B.11.23/WINSTALL "target OS is B.11.
bootcmd = boot boot = (;0) image = boot/Rel_B.11.11/INSTALL To create the same thing but on ISL format, you can use the following format of the command: # auto_adm -n -T 10 -M "Please select something to boot" \ > -l "HP-UX 11.11 32bit" -c boot -b "(;0)" \ > -i boot/Rel_B.11.11/INSTALL -o boot.isl -O ISL $ cat boot.isl hpux KernelPrompt "Please select something to boot" 10 1 reset "HP-UX 11.11 32bit" boot (;0)boot/Rel_B.11.
bootcmd = boot boot = (;0) image = boot/Rel_B.11.11/INSTALL Using an "append" file The auto_adm command also enables you to take records sitting in one file and append them to an input file, combining them into one output file. The following form does this: /opt/ignite/bin/auto_adm -A appendfile -f infile [-o outfile] [-O output_format] [-?] For example: # cat boot.append label = HP-UX 11.11 64bit bootcmd = boot boot = (;0) image = boot/Rel_B.11.11/WINSTALL label = HP-UX 11.
This enables you to update a boot menu entry. The following examples only look at CONF format files. First change the boot field for the label HP-UX 11.23 64bit: # auto_adm -L "HP-UX 11.23 64bit" -c "-i3" \ > -f boot.adm -o boot.adm2 -O CONF $ cat boot.adm2 timeout = 10 default = 1 message = Please select something to boot label = HP-UX 11.23 64bit bootcmd = boot boot = -i3 image = boot/Rel_B.11.23/WINSTALL label = HP-UX 11.11 64bit bootcmd = boot boot = (;0) image = boot/Rel_B.11.
image = boot/Rel_B.11.11/WINSTALL Changing the default menu choice Using auto_adm , you can also change the default menu choice with the following form of the command: /opt/ignite/bin/auto_adm -D -L label [-f infile] [-o outfile] [-O output_format] [-?] The following example shows the change in default menu choices from the first to the second option: $ cat boot.adm hpux KernelPrompt "Please select something to boot" 10 1 reset "HP-UX 11.23 64bit (PA-RISC)" -i3 (;0)boot/Rel_B.11.23/WINSTALL "HP-UX 11.
Updating the prompt message The prompt message is what the boot loader prompts you with when you are asked to make a selection from the available options. The form of the command that enables you to change the prompt message is as follows: /opt/ignite/bin/auto_adm -M message [-f infile] [-o outfile] [-O output_format] [-?] The following example uses this form to change the prompt message: # auto_adm -M "Please select an option" -f boot.combined -o boot.final -O ISL # cat boot.
How to configure instl_bootd or DHCP servers to allow clients to boot over the network is not discussed. For more information, refer to the Ignite-UX Administration Guide and instl_bootd(1M). How to setup depots up remote to the Ignite-UX server is not discussed; the simplest location for depots is on the Ignite-UX server. How to use this process with versions earlier than the C.6.0.x version of Ignite-UX is not discussed.
PHCO_25841 PHKL_26269 PHKL_28025 1.0 1.0 1.0 Add Rock Ridge extension to mount_cdfs(1M) Rock Ridge extension for ISO-9660 Rock Ridge extension for ISO-9660 There are no patches required for HP-UX B.11.23. The make_depots command above assumes that there was no previous depot created at /var/opt/ignite/depots/Rel_B.11.11/core. If such a depot exists, you should use the –d option of make_depots to have the new depot created in a new location.
100BaseT-01 ... HPUXBase32 HPUXBase64 HPUXBaseAux HWEnable11i v1, December 2003 ... hpuxwsWebmin hpuxwsXml perl scsiU320-00 B.11.11.01 HP-PB 100BaseT;Supptd HW=A3495A;SW=J2759BA B.11.11 B.11.11 B.11.11.0312 B.11.11.0312.4 HP-UX 32-bit Base OS HP-UX 64-bit Base OS HP-UX Base OS Auxiliary Hardware Enablement Patches for HP-UX 11i A.1.0.05.02 A.1.0.01.02 B.5.6.1.F B.11.11.
5. Run the following command: make_depots –r B.11.11 –s /dev/dsk/c0t1d0 –d \ /var/opt/ignite/depots/Rel_B.11.11/core_Sep2005_mc 6. Remove the second CD. 7. Insert the third CD from the September 2005 11.11 OE. 8. Run the following command: make_depots –r B.11.11 –s /dev/dsk/c0t1d0 –d \ /var/opt/ignite/depots/Rel_B.11.11/core_Sep2005_mc 9. Remove the third CD. 10. Insert the fourth CD from the September 2005 11.11 OE. 11. Run the following command: make_depots –r B.11.
2. Select Run Tutorial/Server Setup… from the Actions menu. 3. Click the Server Setup button.
4. The third step, Set up Software, allows you to create a core operating system depot. Click the Next button in this and the Next or OK buttons on the following dialog boxes until the following dialog box appears. 5. Select Copy CD/DVD using the adjacent radio button then click Next to copy the core operating system (OE) media into a depot. Note the Use CD/DVD option, which allows you use a directly mounted DVD rather than have it copied to another depot for usage.
6. Insert the media as requested and click OK. 7. Select the correct CD or DVD device from the drop-down button then click OK. 8. Enter the location and name of the depot that the core operating system (OE) to which the media will be copied then click OK. The size displayed in the dialog box may not be correct as it is a static message and the 3400Mb is not based upon the size of the depot on the CD or DVD. 9. Review the information you have entered to be sure it is correct and then click OK.
You should not click OK in the status dialog box until the process of copying the CD/DVD is complete as an error results. 10.
Once the process is completes successfully: the depot exists, a configuration file is created for it, and the configuration file is added to the appropriate default configuration clause /var/opt/ignite/INDEX. If you do not want the configuration file added to the cfg clauses in the INDEX file that it has been added to, you must remove it from each clause using manage_index.
13. Click Yes to setup more depots or No to finish the process. 14. Click Finish to complete the process. The pitfalls of using multiple media If you are creating a depot, you should be very careful if the OE media contains more than one CD or DVD. If the OE contains multiple CDs or DVDs, it will be indicated on each CD or DVD. For example, the 11i v2 March 2006 Mission Critical DVDs will have “1 of 2” printed on the first DVD, and “2 of 2” printed on the second DVD.
-c /var/opt/ignite/data/Rel_B.11.11/core_cfg Warning: HP does not support placing different versions of an OE in one depot. Instead, you must keep different OEs in different depots. This creates the configuration file that describes the depot in /var/opt/ignite/data/Rel_B.11.11 and it is named core_cfg 81 . However, it does not update /var/opt/ignite/INDEX so that you can create your own custom cfg clause later.
In addition to creating the configuration file, the /var/opt/ignite/INDEX file will be updated as in the following excerpt of the file: cfg "HP-UX B.11.11 Default" { description "This selection supplies the default system configuration that HP supplies for the B.11.11 release." "/opt/ignite/data/Rel_B.11.11/config" "/opt/ignite/data/Rel_B.11.11/hw_patches_cfg" "/var/opt/ignite/data/Rel_B.11.11/core_1203_mc_cfg" "/var/opt/ignite/data/Rel_B.11.11/core_cfg" "/var/opt/ignite/config.
Comments on the SD based cfg clause The clause created does nothing except install a generic core operating system (OE) from an SD depot (with the patches included with the operating system). The important thing is that it will install HP-UX. To enable this all you have had to do is create a core operating system (OE) depot, run make_config once, and then manage_index twice.
After you run the following command to add apps_1203_cfg to the cfg clause, you can install any applications that are in the depot: # manage_index -a -f /var/opt/ignite/data/Rel_B.11.11/apps_1203_cfg \ -c "Custom B.11.11 installation using SD" An example problem It is often helpful to examine a real life problem. The previous process created a problem by adding the applications configuration file to the same cfg clause as the core operating system (OE) depot.
There are four solutions to this problem: Edit the apps_1203_cfg file and change the name of the sw_sel clauses so that they are unique and descriptive of the clause's content. This allows you to address the two software selection clauses uniquely. It also ensures that the intended software is selected from the core operating system (OE) depot, and that software from the applications media is not selected inadvertently.
As in in the previous section, there are several ways to deal with this: Always place the applications depot into the core OE depot. This also assumes a different version of VxVM/VxFS is not available on the application media - you can’t cold install a different version of VxVM/VxFS to the version available from the core OE media. Use the load_order keyword to change the load order of the depots so that the applications depot is always loaded after the core OE depot and before any other depots.
Define an application in a non-SD format You either have the option of providing applications in non-SD format in tar or cpio format archives that have been gzipped or compressed. This section explains how to write a configuration file that describes an application in non-SD format 84 . The archive that you will be installing the application with is assumed to contain no system specific configuration. You should configure the application as necessary with the command and script hooks provided by Ignite-UX.
description = "My Application version 1.0" sw_source = "my application archive" sw_category = "SiteApps" archive_type = gzip tar archive_path = "myapps64-1.0.tar.gz" impacts = "/opt" 160154Kb impacts = "/tmp" 500Kb impacts = "/var" 450334Kb exrequisite="MyApp,v=1.0,32bit" post_load_cmd="/opt/myapp/bin/initialize" } You must ensure that only one version of the application is installed and that the user cannot change it. For example, allowing a user to install the 64-bit version with 32-bit HP-UX.
The selection of the 64-bit product is marked as Required because the 64-bit OE has been selected. If you placed the init before the sw_sel, the Ignite-UX GUI would allow you to change the software selection. The software would then be marked with Yes or No to indicate whether it will be installed.
Using noncore.cfg to define applications Ignite-UX provides a template that you can use to define non-SD (archive based) applications in the file /opt/ignite/data/examples/noncore.cfg. The following is an excerpt from this file: ########################################################### ## ## Filename: noncore.cfg ## ## @(#) noncore.cfg $Revision: 10.
## ## Note: ## This example shows the use of an NFS mounted directory ## from the Ignite-UX server to the client in order to obtain ## access to the archives. You could also use the ftp_source or ## remsh_source keywords instead. ## ## In order to use the nfs_source keyword as shown, you must first ## export the directory given in the nfs_source keyword. This is ## accomplished by editing the Ignite-UX server file /etc/exports ## and adding the export information.
## ## Note that the HARDWARE_MODEL clause is only needed if the sw_sels ## inside it can only be installed on a certain type of machine. ## HARDWARE_MODEL ~ "9000/*" { ###################################################### ## Software Selections ##################################################### The sw_sel clauses are self-explanatory. The important parts are: The src, which defines where the software is located.
sw_sel "EE pack" { description = "Software Apps for Electrical Engineering IPF clients" sw_source = "Per-Discipline Packs" archive_type = gzip tar archive_path = "ee_client_archive_IPF.gz" sw_category = "Disciplines" impacts = "/var" 18852Kb impacts = "/usr" 35202Kb impacts = "/" 3Kb } The next example sw_sel defines a different application, but shares all of the same attributes.
} This code allows SD to select common and 64-bit only filesets (and not include 32-bit only filesets) into the operating system. Because there is nothing similar for archives, you must do this manually. Adding the non-SD application configuration file to the INDEX file Now you can easily add the application configuration file to our cfg clause in the configuration file using the following command: # manage_index -a -f /var/opt/ignite/data/Rel_B.11.11/myapps_cfg \ -c "Custom B.11.
# make_bundles -b -i -n "ISO_patches" \ -t "Patches to enable Rock Ridge natively" -r 1.0 \ /var/opt/ignite/depots/Rel_B.11.11/patches_iso Generating list of unbundled filesets... ======= 10/11/04 23:37:34 EST BEGIN swpackage SESSION * Session started for user "root@test.rc.aus.hp.com". * Source: test:/var/tmp/psf.24606 * Target: test:/var/opt/ignite/depots/Rel_B.11.11/patches_iso * Software selections: * * Beginning Selection Phase. * Reading the Product Specification File (PSF) "/var/tmp/psf.24606".
######################################################### ## Software Sources ######################################################### sw_source "/var/opt/ignite/depots/Rel_B.11.11/patches_iso" { source_type = "NET" sd_server = "10.2.72.150" sd_depot_dir = "/var/opt/ignite/depots/Rel_B.11.
# touch /var/opt/ignite/data/Rel_B.11.11/custom_cfg # manage_index -a -f /var/opt/ignite/data/Rel_B.11.11/custom_cfg \ -c "Custom B.11.11 installation using SD" You have a file to which you can start adding configuration information to customize the existing configuration files. HP does not recommend that you customize configuration files generated by Ignite-UX commands. If the software in the depot changes, it is much easier to recreate them using Ignite-UX commands than it is to maintain them manually.
If you maintain the core operating system (OE) and the applications media in different depots, you may need to make customizations for the bundles you have created that define patches. If some products are installed from the applications depot instead of the core operating system (OE) depot and you have patches that depend on the filesets in the bundles that are taken from the applications depot, you may need to set the load_order on sw_sel clauses describing patches to be >10.
Tuning SD-UX for concurrent access Generally, SD will not be able to handle more than three installation sessions by remote systems without introducing either delays or timeouts. The following information also applies to swm on HPUX 11i v3, since it uses swagentd to access SD-UX depots. In a default setup, SD-UX is able to handle no more than six concurrent RPC connections.
2. nkthread – There will be a thread created in swagentd for each of the RPC connections that swagentd may need to handle. If you were to increase rpc_max_calls from the default of six to 28, there would be at least 22 more threads active in swagentd. 3. max_thread_proc – As more threads will be active in swagentd, you will need to ensure that max_thread_proc is set at a value that allows all of the additional threads to be created.
If you were planning for a maximum of 50 concurrent swagent processes, you might begin to run into problems since the system is likely to start to swap (800Mb of real memory and 1200Mb of virtual memory would be required). Do not add real and virtual memory together when trying to determine if you need more swap or physical memory in a system; the amount of virtual memory consumed by swagent includes the real memory used.
The result is the estimated number of hours to install a system. Please note that these calculations are only intended to illustrate that the time it takes to install a system is impacted by: 1) the size of the data to be installed by SD, 2) the number of systems running concurrently, and 3) the speed of the connection. The calculation is not intended to tell you exactly how long it takes to install an actual system.
## ## ## ## ## ## ## ## ## ## ## ## - remove any extra sw_sel clauses. - run /opt/ignite/lbin/archive_impact on each OS archive and replace the "impacts" statements with those given by the archive_impact tool. - Edit the /var/opt/ignite/INDEX file.
sw_source "core archive" { description = "HP-UX Core Operating System Archives" load_order = 0 source_format = archive source_type="NET" # # # # When using this configuration file with a tape or CD-ROM where the archive is on the same piece of media, then un-comment the next line to prevent a prompt to change media during install. change_media=FALSE The following instructions, the two scripts given as the post_load_script and the post_config_script are required and you should not remove them.
Note that there are no Operating Environment (OE) definitions. This is not possible because software packaged in SD format is required.
impacts = "/var" 5705Kb exrequisite += "golden image - 64 bit OS" visible_if = can_run_32bit } = (can_run_32bit) Following is the example for a 64-bit golden archive. All of the information previously presented regarding the 32-bit golden image are applicable to a 64-bit golden archive as you can see in the example. init sw_sel "golden image - 64 bit OS" { description = "English HP-UX 11.
## archives associated with it. ## ## The "no select" sw_source is a no-op source since it is "cmd" ## format, and does not have any scripts specified. Every sw_sel needs ## a sw_source.
######################################################################## has_ps2 { _hp_keyboard = { "Not_Applicable", "PS2_DIN_US_English", "PS2_DIN_US_English_Euro" } init _hp_keyboard = "PS2_DIN_US_English" } has_usb { _hp_keyboard = { "Not_Applicable", "USB_PS2_DIN_US_English", "USB_PS2_DIN_US_English_Euro" } init _hp_keyboard = "USB_PS2_DIN_US_English" } Instances that may require modifying os_arch_post_l There are circumstances in which you may want to modify os_arch_post_l.
In summary you can use: save_file to keep the version of the file from the Operating System archive preventing IgniteUX from making changes to the file; merge_file to keep the version of the file from the Operation System archive but allow IgniteUX to make customizations to it based upon the configuration for the installation session. Creating a golden image The creation of a golden image is not discussed in this document.
Understanding what is_net_info_temporary does Ignite-UX differentiates temporary and permanent network settings with the use of the final keyword. The final keyword is placed in front on networking attributes to indicate that they should apply to the final system. This behavior can change based upon the value of the is_net_info_temporary variable. Information picked up from a DHCP/bootp server is placed into the configuration without the final keyword.
nameserver 10.1.1.10 nameserver 10.1.1.30 This shows Ignite-UX using the networking configuration marked with the final keyword when is_net_info_temporary is set to true and using the networking configuration not marked with final when is_net_info_temporary set to false (in this case information picked up from a DHCP/bootp server).
layout version for VxFS 4.1 is 6. If your system wll be running VxFS 3.5 you should not choose layout version 6, as VxFS 3.5 cannot read VxFS version 6 file systems. With Ignite-UX version C.6.9 (released September 2006) on HP-UX 11.23 you have the choice of making a VxFS file system version 7. You must be careful when doing this as VxFS version 7 file systems require you to be running VxVM/VxFS 5.0.
# Stop the kernel linker warning from printing # when compiling a new kernel is_hppa { env_vars += "LD_OPTS=+vnocompatwarnings" } How do I recognize if a disk exists or not from within a configuration file? It is easy to see if a disk exists or not within an Ignite-UX configuration file. For example: ( disk[0/1/0/8/0.15.0].size == 0 ) { error += "Disk at 0/1/0/8/0.15.0 does not exist" } The previous example configuration excerpt adds an error message if the disk does not exist.
Outside the inner parenthesis the ! (logical not) changes the sense of the test so it becomes TRUE if no model string is reported for that hardware path. This test could be used to perform actions if the disk did not exist. For a more complete test, you could combine the previous examples as follows: ( (disk[0/1/0/8/0.15.0].model ~ ".") & (disk[0/1/0/8/0.15.0].size != 0) ) { init _my_var1=disk[0/1/0/8/0.15.0].model init _my_var2=disk[0/1/0/8/0.15.0].size note += "Disk at 0/1/0/8/0.15.
Important: HP-UX does not currently support writing to USB DVD writers. This currently affects the built-in DVD writers on the rx3600 and rx6600 systems and is expected to be resolved on both HP-UX 11i v2 and 11i v3 with OE updates during 2007. Although this question does not appear to be related to custom configuration, you can place custom configuration in the installation file systems contained on a custom installation CD that you create.
WINSTALLFS IINSTALL VINSTALL WINSTALL IINSTALLFS PAD -12290 -12290 -12290 -12290 -12290 BIN 69408 105248 302880 376688 460528 576752 35840 197630 73806 83837 116224 256 0 0 0 0 0 0 04/11/15 04/11/15 04/11/15 04/11/15 04/11/15 04/11/15 13:57:12 13:57:26 13:57:32 13:57:38 13:57:47 13:57:48 If you have customizations to apply to the installation file systems, you should apply them now using instl_adm. The instl_adm command , prior to Ignite-UX version C.6.0.
Size of boot image is 10240 sectors -> No emulation Size of boot image is 288504 sectors -> No emulation 6.69% done, estimate finish Mon Nov 15 18:05:23 2004 13.39% done, estimate finish Mon Nov 15 18:05:31 2004 20.07% done, estimate finish Mon Nov 15 18:05:28 2004 26.77% done, estimate finish Mon Nov 15 18:05:27 2004 33.45% done, estimate finish Mon Nov 15 18:05:26 2004 40.15% done, estimate finish Mon Nov 15 18:05:26 2004 46.83% done, estimate finish Mon Nov 15 18:05:26 2004 53.
How do I enable the X server and CDE during a golden image install? The information provided here is intended only for golden image installs and not for SD-UX based installations. You should not use these commands during an SD-UX based installation. It is also assumed that you are using a version of Ignite-UX recent enough to support the graphics card in question (for newer graphics cards), and that the golden image has the required products and patches loaded to support the graphics card and input device.
Summary A firm understanding of how to design, maintain, test and troubleshoot configuration files is essential in reducing business resources. With careful consideration and planning, you can create custom configuration files that improve mass deployments and system standardization. For more information The following relevant documents are available online at the HP Technical Documentation Web site at http://www.docs.hp.
© Copyright 2004-2007, 2009 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice.