ServiceGuard Admin

Ignite-UX Advanced
Troubleshooting
January 2009
HP Restricted
Student guide
Ignite-UX Advanced
Troubleshooting
January 2009
HP Restricted
Student guide
Use of this material to deliver training without prior written permission from HP is prohibited.
© Copyright 2008 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice. The only warranties for HP
products and services are set forth in the express warranty statements accompanying such products
and services. Nothing herein should be construed as constituting an additional warranty. HP shall
not be liable for technical or editorial errors or omissions contained herein.
This is an HP copyrighted work that may not be reproduced without the written permission of HP.
You may not use these materials to deliver training to any person outside of your organization
without the written permission of HP.
Printed in the US
Ignite-UX Advanced Troubleshooting
Student guide
January 2009
HP Restricted — Contact HP Education for customer training materials.
Ignite-UX
Troubleshooting
Ignite-UX Troubleshooting Student Guide
Contents
Introduction .................................................................................................................................................... 8
Other documentation ...................................................................................................................................... 8
Booting Systems............................................................................................................................................. 9
Tape formats – HP9000 bootable tape format ........................................................................................... 9
The format............................................................................................................................................. 9
Contents of the LIF ............................................................................................................................. 10
Extracting the archive ......................................................................................................................... 14
Copying a boot tape ............................................................................................................................ 15
Comparing the limitations of different archive types.......................................................................... 16
Tape formats – HP Integrity older formats .............................................................................................. 21
Tape formats – HP Integrity history ........................................................................................................ 21
Tape formats – HP Integrity native tape boot format .............................................................................. 22
About label files.................................................................................................................................. 23
The first ANSI label (file 1)................................................................................................................ 23
What is EFIBOOTHPUX? (file 2)...................................................................................................... 25
The second ANSI label (file 3) ........................................................................................................... 27
The third ANSI label (file 4)............................................................................................................... 28
The bootloader (file 5) ........................................................................................................................ 28
The fourth ANSI label (file 6)............................................................................................................. 29
The fifth ANSI label (file 7) ............................................................................................................... 29
FPSWA.EFI (file 8) ............................................................................................................................ 30
The sixth ANSI label (file 9)............................................................................................................... 30
The seventh ANSI label (file 10) ........................................................................................................ 31
AUTO (file 11) ................................................................................................................................... 31
The eighth ANSI label (file 12) .......................................................................................................... 32
The nineth ANSI label (file 13) .......................................................................................................... 32
IINSTALL (file 14)............................................................................................................................. 32
The tenth ANSI label (file 15) ............................................................................................................ 33
The eleventh ANSI label (file 16)....................................................................................................... 33
IINSTALLFS (file 17) ........................................................................................................................ 34
The twelfth ANSI label (file 18) ......................................................................................................... 34
The thirteenth ANSI label (file 19) ..................................................................................................... 35
HPUXIUXLIF (file20)........................................................................................................................ 35
The fourteenth ANSI label (file 21) .................................................................................................... 36
The fifthteenth ANSI label (file 22).................................................................................................... 36
Archive (file 23).................................................................................................................................. 37
Copying a boot tape ............................................................................................................................ 37
What errors do you see from tapes that aren’t valid?.......................................................................... 37
HP9000 tape boot example ............................................................................................................ 37
HP Integrity tape boot examples .................................................................................................... 40
A zero length EFIBOOTHPUX file .......................................................................................... 41
An empty AUTO file................................................................................................................. 43
A corrupt IINSTALLFS file...................................................................................................... 44
What to take away from these examples ................................................................................... 46
Converting a network recovery archive to a natively bootable tape for HP Integrity systems ........... 46
Upgrading the version of Ignite-UX on a natively bootable tape for HP Integrity systems................ 48
Setting up tape boot on HP Integrity servers ........................................................................................... 50
Working out the EFI device path for a tape drive ............................................................................... 50
Setting up a boot manager menu option.............................................................................................. 50
Booting manually from a tape drive.................................................................................................... 54
What is supported when booting from tape?....................................................................................... 57
Disk formats – HP9000 systems .............................................................................................................. 57
Just a LIF ............................................................................................................................................ 58
A LIF and a HFS filesystem ............................................................................................................... 58
HP Restricted Page 2
Testing media without burning it ........................................................................................................ 58

Disk formats –HP Integrity systems ........................................................................................................ 58
El Torito format media........................................................................................................................ 59
Using vMedia...................................................................................................................................... 60
SSL Certificates ............................................................................................................................. 60
The vMedia User Interface (local media)....................................................................................... 65
The vMedia User Interface (local image)....................................................................................... 68
Expected vMedia Speeds ............................................................................................................... 69
vMedia – what happens with a read failure.................................................................................... 69
Dual Media Recovery .............................................................................................................................. 70
Network booting – HP Integrity systems................................................................................................. 72
An Overview – the full PXE Boot ...................................................................................................... 72
Setting up the Ignite server ................................................................................................................. 74
Setting up Ignite-UX........................................................................................................................... 74
DHCP setup ........................................................................................................................................ 76
Installing tcpdump/libpcap.................................................................................................................. 77
Booting the system and capturing the initial PXE traffic (DHCP) ..................................................... 78
Booting the system and capturing the initial PXE traffic (bootp) ....................................................... 83
The files downloaded for booting (part 1) .......................................................................................... 86
The files downloaded for booting (part 2) .......................................................................................... 89
Booting the system and capturing the initial PXE traffic (full PXE) .................................................. 90
Booting the system and getting a response that firmware doesn’t like ............................................... 93
tftpd errors........................................................................................................................................... 96
Direct Boot Profiles (dbprofile)............................................................................................................... 98
What PXE-E errors can you see?........................................................................................................... 103
Network Booting – HP9000 systems..................................................................................................... 104
The format of a bootp packet ............................................................................................................ 104
Gaining an IP address ....................................................................................................................... 104
Loading the boot LIF – Part 1 (ISL) ................................................................................................. 107
Loading the boot LIF – Part 2 (secondary loader) ............................................................................ 110
Loading the install kernel and filesystem.......................................................................................... 111
Limitations, Restrictions, and other Information .............................................................................. 113
vPars systems and network booting....................................................................................................... 113
HP9000 vPars systems ...................................................................................................................... 114
HP Integrity vPars systems ............................................................................................................... 115
The AUTO files.......................................................................................................................................... 116
Where are the AUTO files? ................................................................................................................... 116
How long can an AUTO file be? ...................................................................................................... 116
On an Ignite server (network booting) .............................................................................................. 116
On media (CD/DVD)........................................................................................................................ 116
On tape.............................................................................................................................................. 117
On a running system ......................................................................................................................... 117
Extending the flexibility of boot helpers ............................................................................................... 118
A general example ............................................................................................................................ 118
Using it with a network boot helper.................................................................................................. 119
How the boot loaders locate the install kernels (network installs)......................................................... 121
Inventory blocking best practices .......................................................................................................... 122
Extending the flexibility of media ......................................................................................................... 125
The product structure of Ignite-UX ............................................................................................................ 126
Historical filesets and bundle wrapper................................................................................................... 126
The web and OE/AR versions ............................................................................................................... 128
Packaging differences ....................................................................................................................... 128
Version differences ........................................................................................................................... 129
The filesets............................................................................................................................................. 130
The recovery commands depot ......................................................................................................... 131
The contents of the recovery commands depot...................................................................................... 132
How the bin and lbin directories work................................................................................................... 132

File formats............................................................................................................................................ 133
flist .................................................................................................................................................... 133
archive_content ................................................................................................................................. 134
command archives ............................................................................................................................ 138
install kernels .................................................................................................................................... 139
install filesystems.............................................................................................................................. 140
How make_net_recovery works ................................................................................................................. 141
make_net_recovery from the start to lanscan ........................................................................................ 142
Looking at add_new_client to understand why lanscan is called .......................................................... 143
make_net_recovery from lanscan to the pax checks.............................................................................. 147
make_sys_image does some pax patch checks ...................................................................................... 147
make_net_recovery after the pax check................................................................................................. 148
make_net_recovery and the version check ............................................................................................ 149
A discussion of compatibility ........................................................................................................... 155
make_net_recovery and automatic updates ........................................................................................... 155
make_net_recovery after the version check........................................................................................... 160
A short break from make_net_recovery ................................................................................................ 162
make_net_recovery after generating the flist file .................................................................................. 163
After creating archive_cfg (creating the archive itself) ......................................................................... 165
Looking at make_arch_config ............................................................................................................... 166
Looking into gen_impacts ..................................................................................................................... 167
The impact of impacts and blocksize, fragsize and dirsize ............................................................... 167
Looking at how gen_impacts works from debug output................................................................... 169
Going back to list_expander to see how the blocks are calculated ................................................... 171
Looking into make_sys_image .............................................................................................................. 171
Working out the compression and archive part of the command line ............................................... 171
The archive size check ...................................................................................................................... 173
Creating the archive .......................................................................................................................... 177
Looking at find_files and $filter_dead_files ..................................................................................... 178
Troubleshooting NFS issues that can affect make_net_recovery .......................................................... 182
NFS configuration (11.23 and below)............................................................................................... 182
NFS configuration (11.31 onwards).................................................................................................. 183
Kernel tunables that can impact on NFS........................................................................................... 184
NFS versions that support large files ................................................................................................ 185
Wrong ownership/permissions.......................................................................................................... 186
A quick look at save_config ....................................................................................................................... 187
Looking at save_config - main .............................................................................................................. 187
Looking at save_config - disk_to_path.................................................................................................. 197
Looking at save_config - process_partitions ......................................................................................... 201
How make_tape_recovery works ............................................................................................................... 204
make_tape_recovery from the start to the version check....................................................................... 205
make_tape_recovery and the version check .......................................................................................... 207
A discussion of compatibility ........................................................................................................... 209
make_tape _recovery after the version check ........................................................................................ 209
Continuing on HP Integrity servers ....................................................................................................... 212
Continuing on HP9000 servers .............................................................................................................. 213
make_tape_recovery after writing some of the tape .............................................................................. 213
Looking at make_arch_config ............................................................................................................... 214
Looking at make_sys_image ................................................................................................................. 214
Looking at make_ipf_tape ..................................................................................................................... 217
Looking at make_medialif ..................................................................................................................... 227
The listener(s)............................................................................................................................................. 236
The files involved .................................................................................................................................. 236
The VxVM listener ................................................................................................................................ 236
The I/O listener...................................................................................................................................... 236
Indirect usage examples......................................................................................................................... 237

check_net_recovery and check_tape_recovery .......................................................................................... 241
Looking at check_net_recovery............................................................................................................. 241
Looking at check_tape_recovery ........................................................................................................... 241
The operation of chk_rec ....................................................................................................................... 242
Running recovery commands from an Ignite server................................................................................... 243
Adding a new client ............................................................................................................................... 243
Looking at add_new_client - main.................................................................................................... 244
Running make_net_recovery ................................................................................................................. 250
Running make_tape_recovery ............................................................................................................... 251
Using ssh or remsh and their requirements............................................................................................ 252
The process of a recovery or cold install .................................................................................................... 253
The install filesystem, init, and the contents of inittab .......................................................................... 253
The phases ............................................................................................................................................. 255
Phase 1................................................................................................................................................... 256
init starts............................................................................................................................................ 256
The real init starts.............................................................................................................................. 257
What does /sbin/ramfs do?................................................................................................................ 258
What does /sbin/launch do? .............................................................................................................. 261
Running net_cfg_prep....................................................................................................................... 263
The start of net_cfg_prep ............................................................................................................. 263
Coming to a decision about what source type to use.................................................................... 263
Back to net_cfg_prep (non-interactive)........................................................................................ 264
Back to net_cfg_prep (interactive) ............................................................................................... 268
Run an Expert Recovery Shell ..................................................................................................... 270
Install HP-UX .............................................................................................................................. 271
Start Networking .......................................................................................................................... 276
Network startup - Part 2 ............................................................................................................... 279
Back to /sbin/launch.......................................................................................................................... 280
Running itool .................................................................................................................................... 281
Running configure1 .......................................................................................................................... 284
Running configure1 – disk setup ...................................................................................................... 287
Running configure1 – download mini-system .................................................................................. 289
Running configure1 – final preparation before loading software ..................................................... 290
Running configure1 – loading software (OS Core archive).............................................................. 292
Archive extraction – monitor_bpr ................................................................................................ 297
Running os_arch_post_l.................................................................................................................... 298
Running configure1 – after the initial archive load........................................................................... 309
Running configure1 – the chroot (NFS client directory) .................................................................. 310
Running configure1 – the chroot (no NFS client directory) ............................................................. 311
Running configure 1 – post chroot.................................................................................................... 312
Phase 2................................................................................................................................................... 313
Continuing running configure1......................................................................................................... 313
Running configure1 – preparing the system file ............................................................................... 314
Running configure1 – after preparing the system file....................................................................... 315
Running configure1 – load the remaining software .......................................................................... 317
Running configure1 – building a kernel............................................................................................ 319
Running configure1 – setting up for the reboot into phase 3 ............................................................ 323
Phase 3................................................................................................................................................... 325
Running configure3 - startup ............................................................................................................ 325
Running configure3 – after networking has been started.................................................................. 327
Running configure3 – configuring software ..................................................................................... 328
Running configure3 – post-configure ............................................................................................... 332
Running os_arch_post_c................................................................................................................... 336
Running configure3 – winding down................................................................................................ 347
The new 11.31 I/O stack, HPVM, and vPars.............................................................................................. 351
The new 11.31 I/O stack........................................................................................................................ 351

HPVM and Ignite-UX............................................................................................................................ 351
vPars and Ignite-UX .............................................................................................................................. 351
Appendix A ................................................................................................................................................ 352
Combining two OE DVDs into one for use with HPVM....................................................................... 352
Appendix B – ndd parameters used by Ignite-UX...................................................................................... 355
Appendix C - Course lab exercises............................................................................................................. 356
Lab exercise preparation – installing a system and setting things up .................................................... 356
Lab exercise 1 – pulling a part a recovery tape...................................................................................... 356
Lab exercise 2 – comparing archive types ............................................................................................. 359
Lab exercise 3 – Looking at an install filesystem.................................................................................. 360
Lab exercise 4 – inventory blocking and the AUTO file ....................................................................... 361
Lab exercise 5 – File formats and product structure .............................................................................. 362
Lab exercise 6 – network booting a system ........................................................................................... 363
Lab exercise 7 – Network Booting – HP9000 systems.......................................................................... 364
Lab exercise 8 – How make_net_recovery works (part 1) .................................................................... 365
Lab exercise 9 – How make_net_recovery works (part 2) .................................................................... 365
Lab exercise 10 – How make_net_recovery works (part 3) .................................................................. 366
Lab exercise 11 – How make_net_recovery works (part 4) .................................................................. 367
Lab exercise 12 – A quick look at save_config ..................................................................................... 367
Lab exercise 13 – How make_tape_recovery works (part 1)................................................................. 368
Lab exercise 14 – How make_tape_recovery works (part 2)................................................................. 368
Lab exercise 15 – check_net_recovery and check_tape_recovery......................................................... 369
Lab exercise 16 – cold install and recovery (part 1) .............................................................................. 369
Lab exercise 22 – The big lab................................................................................................................ 372
Lab exercise 23 – An Extra lab.............................................................................................................. 378
Lab exercise 1 Answers – pulling a part a recovery tape....................................................................... 380
Lab exercise 2 Answers – comparing archive types .............................................................................. 382
Lab exercise 3 Answers – Looking at an install filesystem ................................................................... 385
Lab exercise 4 answers – inventory blocking and the AUTO file ......................................................... 391
Lab exercise 5 answers – File formats and product structure ................................................................ 408
Lab exercise 6 Answers – network booting a system ............................................................................ 412
Lab exercise 7 Answers – Network Booting – HP9000 systems........................................................... 414
Lab exercise 8 Answers – How make_net_recovery works (part 1)...................................................... 415
Lab exercise 9 Answers – How make_net_recovery works (part 2)...................................................... 417
Lab exercise 10 Answers – How make_net_recovery works (part 3).................................................... 420
Lab exercise 11 Answers – How make_net_recovery works (part 4).................................................... 423
Lab exercise 12 Answers – A quick look at save_config ...................................................................... 424
Lab exercise 13 Answers – How make_tape_recovery works (part 1).................................................. 424
Lab exercise 14 Answers – How make_tape_recovery works (part 2).................................................. 427
Lab exercise 15 Answers – check_net_recovery and check_tape_recovery.......................................... 427
Lab exercise 16 Answers – cold install and recovery (part 1) ............................................................... 430
Lab exercise 22 Answers –The big lab .................................................................................................. 439
Lab exercise 23 Answers – Extra lab One ............................................................................................. 467
Appendix D – A side by side comparison of make_net_recovery and make_tape_recovery..................... 475
Index of tables
Table 1 - File numbers on a PA-RISC bootable tape ..................................................................................... 9

Table 2 - Archive block sizes on tape............................................................................................................. 9
Table 3 - archive features and limitations..................................................................................................... 16
Table 4 - Tape format history (HP Integrity systems) .................................................................................. 21
Table 5 - Contents of natively bootable tape for HP Integrity systems ........................................................ 22
Table 6 - The contents of HPUXIUXLIF ..................................................................................................... 35
Table 7 - Ignite-UX Fileset Changes .......................................................................................................... 127
Table 8 - Ignite-UX Fileset Contents.......................................................................................................... 130
Table 9 - Recovery Commands Depot Bundles.......................................................................................... 132
Table 10 - flist Formats .............................................................................................................................. 133
Table 11 - flist Fields.................................................................................................................................. 134
Table 12 - Programs Called By make_net_recovery .................................................................................. 141
Table 13 - make_net_recovery actions for return codes from check_version ............................................ 150
Table 14 - make_arch_config commands called by make_net_recovery ................................................... 164
Table 15 - make_sys_image commands called by make_net_recovery ..................................................... 165
Table 16 - make_sys_image free space calculation.................................................................................... 176
Table 17 - Programs called by make_tape_recovery.................................................................................. 204
Table 18 - make_arch_config commands called by make_tape_recovery ................................................. 211
Table 19 - make_ipf_tape commands called by make_tape_recovery ....................................................... 212
Table 20 - make_sys_image commands called by make_tape_recovery.................................................... 213
Table 21 - Currently available listeners...................................................................................................... 236
Table 22 - Files involved with the listeners................................................................................................ 236
Table 23 - Inquiry message from ignite(1) ................................................................................................. 243
Table 24 - Unexpected NFS options messages........................................................................................... 250
Table 25 - Commands run by ignite(1) to run make_net_recovery on client ............................................. 251
Table 26 - Commands run by ignite(1) to run make_net_recovery on client ............................................. 252
Table 27 - Minimum and Minimal memory sizes ...................................................................................... 259
Table 28 - RAM filesystem sizes ............................................................................................................... 260
Table 29 - host.info definitions................................................................................................................... 262
Table 30 - net_cfg_prep exit values and actions......................................................................................... 280
Table 31 – itool exit values and actions...................................................................................................... 280
Table 32 - mkboot commands used to recover LIF files ............................................................................ 347
Introduction
This course was written to try and introduce you to the way things work with Ignite-UX. All of the students
attending this course do not have access to the HP-UX source code so the course content cannot discuss
what is happening at a very low level (i.e to line of source). Where possible alternatives have been found to
explain what is happening.
Wherever possible fully worked examples and commentary have been given to try and give you a better
understanding of what is being discussed.
Large parts of this course present information that is not officially documented. This course is NOT official
documentation of the functionality provided by Ignite-UX. HP reserves the right to change interfaces,
functionality, and the behavior of the internals of Ignite-UX at any time and without notice.
An example of a major change to the way that Ignite-UX worked is here: “The install filesystem, init, and
the contents of inittab”. Ignite-UX changed the way that it started up on the install filesystem. This change
was not communicated to anyone when it occurred as it was internal to Ignite-UX.
The only functionality you can rely on not changing is when it is officially documented in a manual page or
in the Ignite-UX Administrators Guide. HP is still able to replace or reimplement officially documented
functionality to the extent that it should appear functionality equivalent. That is it should still achieve the
same results but may do so in a completely different manner.
The course content (in most cases) does not distinguish between information that is officially documented
and information that is not.
Other documentation
All of the currently available documentation for Ignite-UX is available in one location:
http://www.docs.hp.com/en/IUX/infolib.html
Reading all of the available documentation will give you a very good understanding of Ignite-UX. Of
particular importance if you use systems with SAS devices is the following white paper “Ignite-UX and
SAS Devices”:
http://docs.hp.com/en/5992-3755/5992-3755.pdf
To understand how Ignite-UX uses SAS devices from Ignite-UX C.7.5 onwards when some of the
information in that white paper no longer applies to Ignite-UX see the section “Looking at save_config -
disk_to_path” where a section of the release notes from C.7.5 is quoted to give information about what
does and does not apply.
Booting Systems
This section covers how systems boot from various media. How HP-UX would normally boot from an
installed disk will not be discussed as this course covers only information related to Ignite-UX.
Tape formats – HP9000 bootable tape format

In this section we will define the tape format used by HP9000 systems.
The format
The HP9000 bootable tape format is a very simple format involving two files place sequentially on the tape.
If an archive exceeds one tape is it continued on a new tape after prompting the user to change tapes and
enter a response to continue.
Important: The pax command prompts interactively for a new tape when writing an archive and end of
tape is detected. Running the make_tape_recovery using a method where it cannot open a tty to ask for the
new tape will cause the creation of the recovery archive to be aborted. If you see this error you should
ensure that the recovery archive will fit onto one tape.
Table 1 - File numbers on a PA-RISC bootable tape

File Number Contents Block Size
1 LIF 2k
2 Archive Varies (See “Table 2 -

Archive block sizes on
tape”)
When reading the files from tape they have a fixed block size. The block sizes in use for various format
types are:
Table 2 - Archive block sizes on tape

Archive Type Block Size
cpio 5k
tar 10k
pax 1 5k
The block sizes above are the default block sizes for each archive format. Ignite-UX does not provide the
ability to change the block size when writing to tape.
1
This is not the pax command but the X/Open defined pax format archive that can be written by the pax
command on 11.31 (and now 11.23 with a patch and enhancement bundle).
Contents of the LIF
Note: The lif commands used in this section can only operate on HP-UX files or random access devices not
sequential access devices (such as a tape drive). If you need to run lifcp on a LIF on a sequential access
device you must first extract the LIF from the device.
Using the information provided above we can pull the LIF 2 from a recovery tape (created on a HP-UX
B.11.23 system using Ignite-UX version C.7.3) using the following command:
# dd if=/dev/rmt/0mn of=./lif bs=2k

146219+0 records in
146219+0 records out
# lifls -l ./lif
volume ISL10 data size 1953114 directory size 3 08/02/10 21:48:53
filename type start size implement created
===============================================================
ISL -12800 16 242 0 08/02/10 21:48:53
AUTO -12289 264 1 0 08/02/10 21:48:53
INDEX BIN 272 1 0 08/02/10 21:48:53
CONFIG BIN 280 90 0 08/02/10 21:48:53
HPUX -12928 376 1024 0 08/02/10 21:48:53
FWWKAR6 BIN 1400 1 0 08/02/10 21:48:53
FWWKAR7 BIN 1408 1 0 08/02/10 21:48:53
FWWKAR8 BIN 1416 1 0 08/02/10 21:48:53
WINSTALL -12290 1424 139206 0 08/02/10 21:48:58
WINSTALLFS -12290 140632 131056 0 08/02/10 21:49:01
IINSTALL -12290 271688 280915 0 08/02/10 21:49:04
IINSTALLFS -12290 552608 175616 0 08/02/10 21:49:04
INSTCMDS BIN 728224 55232 0 08/02/10 21:49:04
SYSCMDS BIN 783456 101539 0 08/02/10 21:49:04
INSTCMDSIA BIN 885000 104388 0 08/02/10 21:49:04
SYSCMDSIA BIN 989392 180041 0 08/02/10 21:49:09
SCRIPTS BIN 1169440 45 0 08/02/10 21:49:09
VERSION BIN 1169488 1 0 08/02/10 21:49:09
PAD BIN 1169496 256 0 08/02/10 21:49:09
The “type” information is important when dealing with LIF files. Files of an the incorrect type may not be
able to be processed by HP9000 firmware when booting. The Ignite-UX command make_medialif will
always create LIF entries with the correct type. If you ever need to manually create a LIF or copy files into
a LIF to replace an existing file you should review the make_medialif script for information on the correct
lifcp command to use.
The size and start information in a LIF directory are always given in multiples of 256 bytes. Files written to
a lif are always padded to a multiple of 256 bytes.
The contents of the LIF from the tape are:
1. ISL – The Initial System Loader. This is the first program loaded by firmware from tape. This
program is responsible for loading subsequent programs to continue the boot process (for
more information see the manual page isl(1m)). The ISL program reads the AUTO file from
the LIF to determine what the next action in the boot process is. This file is always taken from
/opt/ignite/boot/boot_lif when the LIF is created by make_medialif. This LIF entry is only
used during the boot process.
2
An abbreviation of Logical Interchange Format, see the manual page lif(4) for more information.
2. AUTO – The AUTO file (also known as the autoexecute file) is read by the ISL program to
determine what to do to continue the boot process. It’s easy to copy the AUTO file from the
lif to see what the next step in the boot process will be:
# lifcp lif:AUTO -
hpux (;0):INSTALL
Notice that the boot command says to load the secondary loader (called hpux) and ISL fills
out the rest of the information required. The colon in “:INSTALL” says to load the INSTALL
file from a LIF (we need to since you’d be booting from tape). The ISL program understands
when a system cannot run a 32bit kernel and automatically replaces the INSTALL with
WINSTALL.
This tape was created on a HP-UX 11.23 system. There are no systems that can run that
version of HP-UX and run 32bit HP-UX so the INSTALL is always changed to WINSTALL.
The contents of the AUTO file are always the same for HP9000 systems. The make_medialif
program always supplies a new AUTO file. The AUTO file from the /opt/ignite/boot/boot_lif
is not used for tape since it is setup for network booting HP9000 systems:
# lifls -l /opt/ignite/boot/boot_lif
===============================================================
ISL -12800 16 242 0 07/07/30 21:48:53
AUTO -12289 264 2 0 07/07/30 21:48:53
HPUX -12928 272 1024 0 07/07/30 21:48:53
VERSION BIN 1296 1 0 07/07/30 21:49:06
# lifcp /opt/ignite/boot/boot_lif:AUTO -
hpux KernelPrompt "Choose an operating system to install that your hardware
supp
orts:" 120 1
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
"Exit" reboot
3. INDEX – The INDEX file is used to locate the configuration on the media once Ignite-UX
has started. Its placement is close to the start of the LIF so when it is located on a tape it does
not take long to load.
# lifcp lif:INDEX -
cfg "Recovery Archive" {

description "This selection supplies the default system configuration given
to make_medialif for the B.11.23 release."
"CONFIG"
}
The format is exactly the same as the /var/opt/ignite/INDEX file on an Ignite server. On a tape
created by Ignite-UX there is only ever one cfg clause and the cfg clause only ever refers to
one other LIF file that the configuration is in. This LIF entry is only used after the install
kernel has started running.
4. CONFIG – This LIF entry always contains the configuration required to describe a recovery
archive 3. For a recovery tape the system_cfg, archive_cfg, and control_cfg files are
concatenated together to form the contents of this LIF entry. The configuration is not used
until after the boot process has been completed and Ignite-UX has started running on the
install kernel.
5. HPUX – This is the secondary system loader and is responsible for loading the install kernel
and setting it running. This file is always taken from /opt/ignite/boot/boot_lif when the LIF is
created by make_medialif. This LIF entry is only used during the boot process.
6. FWWKAR6 – This file name is short for “FirmWare WorKARound” followed by the LIF
entry number. Some older HP9000 700 series workstation (C36xx, C37xx, and J56xx)
firmware would not read a large file from this LIF position. For this reason the file contains
the following text:
# lifcp lif:FWWKAR6 -
Workaround for Forte/Allegro firmware bug; avoid reading large file from LIF
file slot 8.
firmware would not read a large file from this LIF position. The contents of this file are
identical to FWWKAR6.
firmware would not read a large file from this LIF position. The contents of this file are
identical to FWWKAR6.
9. WINSTALL – This is the name of the 64bit HP-UX install kernel. The name has special
meaning to the install kernel. When the name of a HP-UX kernel ends with INSTALL it
performs some startup actions differently (such as loading an install filesystem). Note that this
functionality requires the “install” driver to be compiled into the kernel. We do not discuss the
install driver in this course. This LIF entry is only used during the boot process.
10. WINSTALLFS – This is the install filesystem. It is actually a filesystem that is loaded by the
install kernel and used as the root filesystem during an installation or recovery session.
This file is sort of used both during and after the boot process. The install kernel is running by
the time it has been loaded. The install kernel makes calls back into the secondary loader to
actually load the file because the kernel has not initialized the I/O subsystem yet. Because of
this the install kernel is reliant on the secondary loader to load the install filesystem. This is
true regardless of where the install filesystem is – on tape, CD/DVD, or network.
11. IINSTALL – This is an Itanium install kernel, although it may be present on a PA-RISC
format recovery tape it serves no purpose as this tape was created on a HP9000 system it is
not natively bootable on an Itanium system and the recovery archive could not be loaded onto
an Itanium system regardless 4.
3
If you produced a custom install tape using a golden image the same LIF file would still contain the
configuration if the LIF was created by make_medialif.
4
Even for older format recovery tapes for HP Integrity servers this install kernel was never used because
you need to boot from CD/DVD then recover from tape. The install kernel came from the CD/DVD not the
tape.
12. IINSTALLFS – This is an Itanium install filesystem. Although it is present on a recovery tape
it serves no purpose (see the footnote for the IINSTALL file above).
13. INSTCMDS – This file is a gzipped tar archive. It contains most of the commands and files
used by the installation process up to the point where volume or disk groups are created, for
example the itool command (the configuration user interface during recovery or installation)
and most of the files required to run it are extracted from this file when it is needed. This LIF
entry is only used after the install kernel has started running.
14. SYSCMDS – This file is a gzipped tar archive. This file is mostly used after Ignite-UX has
configured disk/volume groups and created filesystems. The file is then extracted fully onto
the newly configured disks. Some files are loaded individually from this file to create the
disk/volume groups and filesystems.
The most common time the contents of this file are noticeable to anyone using Ignite-UX is
when Ignite-UX prints “Download the mini-system”. At that point the file is extracted in its
entirety and you can see this happening on the console and the install.log file.
15. INSTCMDSIA – This is the Itanium version of the INSTCMDS file. Although it is present on
a recovery tape it serves no purpose (see the footnote for the IINSTALL file above).
16. SYSCMDSIA – This is the Itanium version of the SYSCMDS file. Although it is present on a
recovery tape it serves no purpose (see the footnote for the IINSTALL file above).
17. SCRIPTS – This LIF entry contains the os_arch_post_l and os_arch_post_c scripts. When
Ignite-UX executes them as part of the recovery session they have been extracted from this
LIF entry and placed into an alternate location and executed from there. The os_arch_post_l
and os_arch_post_c scripts in the archive are not used.
# lifcp lif:SCRIPTS - | gzcat | pax

./opt/ignite/data/scripts/os_arch_post_l
./opt/ignite/data/scripts/os_arch_post_c
18. VERSION – This file contains the version of Ignite-UX used to create the tape, you can easily
extract this data using lifcp once you have extracted the LIF from a bootable tape:
# lifcp lif:VERSION -
C.7.3.145
19. PAD – This file is used to pad out the end of the LIF. Some very old CD-ROM drives on
HP9000 servers could not read the last block from CD-R or CD-RW media. When combining
a LIF with a HFS filesystem the LIF was added to the end of the filesystem image using
instl_combine. In these cases Ignite-UX would hang extracting SYSCMDS. For this reason
there is now a 64KB LIF entry called PAD added to the end of every LIF created by
make_medialif. There are comments about this lif entry in make_medialif:
# JAGae47732: Copy a dummy file to the end of the LIF volume file to resolve a
# hang problem while reading the last file in a LIF volume on some old CD-ROMs:
#
# This workaround is required until the problem no longer exists on any
# supported hardware or drivers, which is hard to determine.
This tape did not contain a RECCMDS file, if it did you would also be able to access a recovery shell when
booting from the tape.
Extracting the archive
You can easily extract the archive with the following commands:
# mt rew 5
# mt fsf 1
# dd if=/dev/rmt/0m of=./archive bs=10k
184854+0 records in
The above commands assume that the tape was created with the default block size (as Ignite-UX creates it).
If you’ve previously copied the tape and changed the block size you would need to adjust the block size
argument (bs) to the dd command. A rewind device was used with the above dd command so when the dd
is complete the tape will be rewound back to the start of the tape.
If you only need to view the contents of the archive on tape you can instead use the following command
(since there is no need to extract the archive from tape using dd):
# mt rew
# mt fsf 1
# pax –v –f /dev/rmt/0m
The archive always a path relative archive:
# pax -v -f archive
USTAR format archive
dr-xr-xr-x 0 bin bin Feb 10 21:18 stand/
drwxr-xr-x 0 root root Oct 30 23:09 stand/lost+found/
-rw-r--r-- 0 root sys 4532 Feb 10 21:18 stand/ioconfig
-rw-r--r-- 0 root sys 19 Oct 30 23:09 stand/bootconf
lrwxr-xr-x 0 root root Feb 10 21:18 stand/system ->
nextboot/system
drwxr-xr-x 0 root sys Feb 10 21:19 stand/krs/
...
This is important if for any reason you need to extract it and replace something in the archive as you will
need to ensure that you recreate the archive in the same format. If you attempt to use a recovery archive
with fully qualified paths it will always fail to recover a system – Ignite-UX depends on recovery archives
being path relative. The reason for this is discussed much later in the course.
When extracting an archive with a different block size and you know the block size use exactly that block
sizes, however if you’re not sure you can actually just use 10k as long as you aren’t using the ibs, obs, or
some conv= options to dd.
# mt rew
# mt fsf 1
# dd if=/dev/rmt/0m of=archive.cpio bs=10k
0+366129 records in
A cpio archive is written to tape by Ignite-UX with a block size of 5120, so why can we get away with
reading a block size of 10k. We can look at the output above along with the following from the dd manual
page:
5
Rewinding the tape is not actually required if the last file read was the LIF, in this case since it’s an
isolated example we rewind the tape and then skip forward one file to make sure that we are accessing the
archive.
Upon completion, dd reports the number of input and output records:
f+p records in Number of full and partial blocks read.

f+p records out Number of full and partial blocks
written.
So you can see that even with the larger block size than is required for dd we only read and wrote the
partial blocks. So the dd command will try to read in 10k at a time from the tape drive but only get 5k so it
writes out the 5k.
It just so happens with this command that with tar format archives you read one block from tape and write
one to disk, with pax and cpio format archives you read one partial block from tape and write a partial
block to disk.
After reading the cpio archive from the tape with the above command we can still access the complete
archive:
# pax -v -f archive.cpio
ASCII CPIO format archive
dr-xr-xr-x 1 bin bin Feb 10 21:18 stand
drwxr-xr-x 1 root root Oct 30 23:09 stand/lost+found
-rw-r--r-- 1 root sys 4532 Feb 10 21:18 stand/ioconfig
-rw-r--r-- 1 root sys 19 Oct 30 23:09 stand/bootconf
...
lrwxrwxrwt 1 root sys Oct 30 23:35 usr/bin/cue.etc/cue.dm ->
/etc/cue.dm
lrwxr-xr-t 1 root sys Oct 30 23:35 usr/bin/cc ->
/usr/ccs/bin/cc
lr-xr-xr-t 1 root sys Oct 30 23:35 usr/bin/ar ->
/usr/ccs/bin/ar
This also implies that any archive can be extracted from tape in this way (regardless of the block size used)
with the following command by using the largest possible block size that pax supports writing to tape:
# dd if=/dev/rmt/0m of=archive bs=32256
Copying a boot tape
The simplest way to copy a HP9000 boot tape is to use the copy_boot_tape command. Note that this
command only works on HP9000 boot tapes it has never been enhanced to be able to copy natively
bootable tapes for HP Integrity servers. Given that’s it is simple and does it all for you we’re not going to
look at how it works we’re going to just use the commands instead.
We’ve already seen from the previous section that to pull the lif and archive off the tape all you really need
is the following commands:
# mt –t /dev/rmt/0m rew
# dd if=/dev/rmt/0mn of=./lif bs=2k
# dd if=/dev/rmt/0m of=./archive bs=10k
Putting the archive back onto the tape is just as easy:
# mt –t /dev/rmt/0m rew
# dd if=./lif of=/dev/rmt/0mn bs=2k
It’s important when using the dd command that the sze of the file be a multiple of the the block size being
written to tape. This shouldn’t affect the lif since you shouldn’t be modifying it but if you change the
archive it could easily impact on how you dd the archive to tape. If the archive is a multiple of the block
size being written to tape you can just dd it onto tape (for tar formats):
# dd if=./archive of=/dev/rmt/0m bs=10k
For cpio and pax format archives the following command should be used:
# dd if=./archive of=/dev/rmt/0m bs=5k
Note that even though this course talks about how to change the block size of an archive Ignite-UX
currently expects archives to only have certain block sizes on tape. Changing the tape to give the archive a
different block size should work with no problems (since pax supports automatic detection of block sizes of
tape archives up to 32256 bytes) but HP does not test this and does not support doing it. Tools such as
copy_boot_tape do not currently support non-default block sizes (no more than 10k) and that may lead to
failures duplicating a tape with an archive that has a block size of more than 10k.
Although not supported if you were to change the block size to the largest block size supported by pax you
would use a command like the following to change the archive block size 6:
# dd if=./archive of=/dev/rmt/0m bs=32256 conv=sync
Important: HP does not test non-default archive block sizes on tape, should you elect to use this
information for performance reasons you should test the functionality to ensure that it works to your
satisfaction. HP may refuse to fix any defects related to non-default archive block sizes.
Important: This assumes that the archive on tape is not compressed (make_tape_recovery only creates
uncompressed archives on tape). If you have a compressed or gzipped archive on tape using a non-default
block size will cause a failure during archive extraction.
Comparing the limitations of different archive types
The following limitations are not imposed by Ignite-UX, they are imposed by limitations in the archive
formats and it is not possible to change them because they are controlled by standards e.g. (POSIX.2,
XPG4, UNIX95, UNIX98, and UNIX2003).
Important: Under all circumstances Ignite-UX uses the pax command to read and write archives although
names like cpio and tar are used for the format names the cpio or tar commands are never used by Ignite-
UX.
Table 3 - archive features and limitations

cpio tar pax
Standards format name 7 ASCII cpio interchange extended tar interchange pax interchange format
format format
File size Less than 8GiB Less than 8GiB Any file size supported
by HP-UX (a)
6
This assumes you have already written the LIF to the tape and it was currently positioned after the LIF.
7
This is the name of the format given by relevant standards, for example although Ignite-UX uses the term
“tar” the pax command actually writes “Extended tar Interchange Format archives” also known as ustar
format.
Maximum uid or gid 262144 (b) 2097152 (c) Any gid or uid supported
by HP-UX (h)
Maximum user or group Not Applicable (b) 31 bytes (c) Any user or group name
name length supported by HP-UX
Maximum file name Any file name supported Varies in length up to Any file name supported
length by HP-UX 256 bytes (d) by HP-UX
Maximum file name Any symlink target 100 bytes (e) Any symlink target
length (symlink target) supported by HP-UX supported by HP-UX
Supports ACLs (f) No No No
Default block size (g) 5k 10k 5k
Maximum block size 32256 32256 32256
(a) The fact that pax format archives can support any size file that HP-UX may create unintended
consequences if you decide to start using it. If you’ve always had some large files (greater than or equal to
8GB) in a volume group that is included into a recovery archive they would never have been made it into
the archive using tar or cpio formats previously.
If you switch to pax format archives those files will be included into a recovery archive. This may have a
significant impact on disk usage (for make_net_recovery) or tape usage (make_net_recovery might need
more tapes to create a recovery archive).
Although pax format archives remove all of the limitations of tar and cpio archives you should be aware
that there is still an issue to consider before switching to the new archive format.
HP-UX B.11.23 requires an enhancement bundle to enable the pax command to write pax format 8. You
will be able to write pax format archives on HP-UX B.11.23 once a version of Ignite-UX is delivered that
supports this archive format on HP-UX B.11.23.
You should always install a minimum of PHCO_38321 on HP-UX B.11.31 (or any superceding patch as
indicated by make_tape_recovery or make_net_recovery). The following defect listed in the patch text is
the reason why it should be installed:
The pax command with "-x pax" option archives pathnames longer than 100
characters wrongly. As a result, files having pathname longer than 100
characters are extracted to wrong directory.
With this defect it is possible that some files may be recovered to the wrong directory. This could possibly
cause a filesystem full event leading to a failed recovery. This defect is encountered when the archive is
written and it cannot be fixed during extraction of the archive. The defect is not present in the HP-UX
B.11.23 enhancement bundle version of the pax command.
(b) The format of cpio archives only allows the uid/gid values to be stored into an archive. Any file with a
uid/gid value larger than 262144 will be recovered owned by the user running the pax command (user root
and group sys in the case of a recovery archive). An example:
8
you must use version 1.1 or later as version 1.0 of the enhancement bundle breaks the pax checks in
make_tape_recovery and make_net_recovery
# id lgeuid
uid=300000(lgeuid) gid=20(users)
# id lgeruid
uid=3000000(lgeruid) gid=20(users)
# touch file1
# touch file2
# chown lgeuid file1
# chown lgeruid file2
# pax -w -x cpio -f pax.cpio file1 file2
# pax -v -f pax.cpio
-rw-r--r-- 1 -1 sys 0 Feb 11 12:47 file1
-rw-r--r-- 1 -1 sys 0 Feb 11 12:47 file2
# rm file1 file2
# pax -pe -r < pax.cpio
# ll file1 file2
-rw-r--r-- 1 root sys 0 Feb 11 12:47 file1
Both uids are too large to be stored into the cpio interchange format. This applies to gids as well but this
example has only used uids to keep the example simple.
(c) The uid support for extended tar interchange format is more complex than just looking at the uid as the
user name and group name is stored in the archive as well. Let’s look at the following example:
# id lgeuid
uid=300000(lgeuid) gid=20(users)
# id lgeruid
uid=3000000(lgeruid) gid=20(users)
# touch file1
# touch file2
# chown lgeuid file1
# chown lgeruid file2
# pax -w -x ustar -f pax.ustar file1 file2
# pax -v -f pax.ustar
-rw-r--r-- 0 lgeuid sys 0 Feb 11 12:47 file1
-rw-r--r-- 0 lgeruid sys 0 Feb 11 12:47 file2
# rm file1 file2
# pax -pe -r < pax.ustar
# ll file1 file2
-rw-r--r-- 1 lgeuid sys 0 Feb 11 12:47 file1
-rw-r--r-- 1 lgeruid sys 0 Feb 11 12:47 file2
The ownership of the files were recovered correctly even though the uid for the user lgeruid is larger than
supported by the extended tar interchange format.
The reason for this (as mentioned in “Table 3 - archive features and limitations”) is that up to 31 bytes (32
including the null terminator) of the user and group name are stored in the archive. Since we did the
extraction on a running system this allows pax to call getpwnam(3) with the user name and getgrpnam(3)
with the group name. These library calls will return the correct uid/gid value. The pax command always
does this for this for ustar and pax formats 9. If the user or group name is not found it falls back to the uid or
gid as applicable (this is what happens during a recovery or golden image install).
In this example we will see that happen as the users that were present in the previous example have been
removed from the system:
9
It can’t be done for cpio ASCII interchange format because that format does not store the user and group
names associated with the file into the archive.
# rm file1 file2
# pax -pe -r < pax.ustar
# ll file1 file2
-rw-r--r-- 1 300000 sys 0 Feb 11 12:47 file1
The first file has been recovered with the correct uid of the missing user but the second file is owned by
root because the uid (3000000) is too large to store as a uid in extended tar interchange format.
This has particular relevance to recovering a system from a recovery archive. The passwd file (or an
alternative if PAM is using a repository other than files) is not accessible when the archive is recovered any
uid/gid out of range of the format used for that recovery archive will be recovered as the user and group of
the process running the pax command. This should be root:sys.
(d) The extended tar interchange format has two fields used to store the name of the file in the archive. The
two fields are name (100 bytes in length) and prefix (155 bytes). The ways that the name of the file can be
formed using these two fields are:
1. The file name fits entirely within name and prefix starts with a NULL byte – in this case the
file name from name is used only.
2. The prefix field doesn’t start with a NULL byte in which case the file name is a concatenation
of prefix + ‘/’ + name.
This raises some limitations:
1. If the name of the file is more than 100 bytes long it will not be able to be stored into the
archive.
2. A path name more than 256 bytes long can never be stored into the archive . Because of the
limitation of generating the name using prefix + ‘/’ + name the limit may be significantly less.
Files that cannot have their path names expressed in a way that fits into an archive are dropped with an
error printed by the pax command. Below are some examples of files that can’t be stored into an extended
tar interchange format archive. The first has a filename that is too long to fit into the name field:
# pax -w -x ustar -f pax.ustar this*

pax: this_is_long_filename_1234567890_1234567890_1234567890_1234567890
_1234567890_1234567890_1234567890_1234567890_1234567890 : Path name el
ement too long - skipped
This next one has a path that cannot be split in a way that allows it to fit into the name and prefix fields:
# mkdir -p
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb/ccc
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
ccccccccccccccccccccccccccccccc
# touch /home/shane/paxtest/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbb/ccccccccccccccccccccccccccccccccccccccccccccc
ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc/testfile
# pax -w -x ustar -f pax.ustar aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/
pax: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
b/cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
cccccccccccccccccccccccccccccccccccc/ : Path name element too long – s
kipped
pax: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
b/cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
cccccccccccccccccccccccccccccccccccc/testfile : Path name element too
long - skipped
The directory with a lot of c's in it's name is placed so it can't be split to fit into the prefix (155 bytes) and
name (100 bytes). This is because ccc...ccc/testfile is too long to fit into the name field and
aaa...aaa/bbb...bbb/ccc...ccc/ is too long to fit into the prefix field. We can only split the filename at some
point in the path where there is a '/' because the name is rebuilt by cat'ing together prefix + '/' + path.
(e) The link target of a file with extended tar interchange format is only allowed to be 100 bytes long. Here
is an example showing that once the target of a symlink hits 100 bytes in length it will not be written to the
archive when extended tar interchange format is used:
# ln -s 01234567890123456789012345678901234567890123456789012345678901
2345678901234567890123456789012345678 test1
# ln -s 01234567890123456789012345678901234567890123456789012345678901
23456789012345678901234567890123456789 test2
# ln -s 01234567890123456789012345678901234567890123456789012345678901
234567890123456789012345678901234567890 test3
# pax -w -x ustar -f pax.ustar test*
pax: test3 : Link name is longer than 100 chars.
We can see that only two of the symbolic links were placed into the archive. The symbolic link with the
101 character file name as the target was not included (this was the expected result).
# pax -v < pax.ustar

lrwxr-xr-x 0 root sys Feb 11 15:15 test1 -> 0123456
7890123456789012345678901234567890123456789012345678901234567890123456
7890123456789012345678
7890123456789012345678901234567890123456789012345678901234567890123456
78901234567890123456789
Just for comparison since we said that this is not a problem for ASCII cpio interchange format – and it’s
not. All 3 symbolic links appear in the archive.
# pax -w -x cpio -f pax.cpio test*

# pax -v < pax.cpio
7890123456789012345678901234567890123456789012345678901234567890123456
7890123456789012345678
7890123456789012345678901234567890123456789012345678901234567890123456
78901234567890123456789
7890123456789012345678901234567890123456789012345678901234567890123456
789012345678901234567890
Each archive format has different strengths and weaknesses. The only archive format that does not have
inherent limitations is the pax format.
(f) No archive format supported by Ignite-UX supports ACLs if you wish to retain ACLs you will need to
either document what ACLs are in use so you can manually re-implement them or have an alternative
method for saving and restoring ACL information.
(g) This is not actually a limitation in the archive formats. This table was simply the most suitable place to
document this information. Currently Ignite-UX writes archives to tape using the default block sizes for
each format. It is not known if any future release of Ignite-UX will change (or permit the user to specify)
those block sizes so a larger value can be used to enable better streaming performance of high speed tape
drives.
(h) The supported uid/gid maxiumum value is 2^31-1 (2147483646). From /usr/include/limits.h we have
the definition of UID_MAX which is the smallest unattainable value for a user or group id. This means that
uids and gids must be less than this value.
# define UID_MAX MAXUID /* smallest unattainable value for a

user or group ID */
Then from /usr/include/sys/param.h we have:
#define MAXUID MAXINT /* smallest unattainable value for a user or

* group id */
From the same header file we have:
#ifndef MAXINT
#define MAXINT 0x7fffffff /* max value for integer */
Which is 2147483647 and since that is the smallest unattainable uid/gid value valid uid/gid values must be
less than this so they can be no more than 2147483646.
At this point perform lab exercise two (see “Lab exercise 2 – comparing archive types”).
Tape formats – HP Integrity older formats

There were three tape formats prior to the current natively bootable tape format for HP Integrity systems.
They will be detailed here in terms of their differences to the other formats. One of these tape formats was
never made available outside of HP (no details of this tape format will be provided in this course).
Neither of the two remaining formats is natively bootable. They rely on dual media recovery or two step
recovery 10. The first format is identical to the HP9000 bootable format, see the previous section (“Tape
formats – HP9000 bootable tape format”).
The second format is mostly the same as the natively bootable Itanium tape format except that the
EFIBOOTHPUX file contained different information. The contents of the file were based on a version of
UEFI specification before version 2.0. Because of this EFI firmware will not recognized the tape as
bootable and will refused to boot from the tape.
Tape formats – HP Integrity history

The versions of Ignite-UX that produce the different tape formats are:
Table 4 - Tape format history (HP Integrity systems)

Ignite Version Tape Format
C.6.4 and lower PA-RISC bootable format.
C.6.5 to C.6.7 Newer format following pre-UEFI 2.0 standard - not natively bootable.
10
Both names mean the same thing. They involved booting from CD or DVD and then continuing a
recovery from tape. When this course was written it was only possible to perform dual media recovery in
this way (i.e. you could not network boot and then recover from tape).
C.6.8 onwards Natively bootable format for Itanium systems.
For information on the firmware and platform requirements for native tape boot support please review the
Ignite-UX white paper “Ignite-UX Installation Booting” available from the following URL:
In the information about HP Integrity systems please see the section “Booting from a tape”
Tape formats – HP Integrity native tape boot format

Important: Tape formats are subject to change over time, the following information documents the HP
Integrity native tape boot format only as it currently is implemented. This documentation does not imply
that this is the way the tape format will always exist.
HP Integrity natively bootable tapes are formatted using ANSI tape labels as defined by ANSI Standard X
3.27. The best documentation online is the following URL (CERN):
http://it-div-ds.web.cern.ch/it-div-ds/HO/labels.html
The table below is taken from the HP White Paper “Ignite-UX Installation Booting”. This defines the files
contained on a natively bootable tape for HP Integrity systems. From here the new format tape will just be
referred to as a bootable tape.
Table 5 - Contents of natively bootable tape for HP Integrity systems

File Number Contents File Number Contents
1 ANSI Label containing 13 ANSI Label

VOL1 header
2 EFIBOOTHPUX 14 IINSTALL
3 ANSI Label 15 ANSI Label
5 BOOTLOADER 17 IINSTALLFS
8 FPWSAEFI 20 HPUXIUXLIF
10 ANSI Label 22 ANSI Label describing

archive
11 AUTO 23 Archive
12 ANSI Label
About label files
You should take special care when editing a file with an ANSI label in it. Editing the file will cause
problems unless you take special care to fix up the file after changing it. The ANSI labels you will see
below only appear to start on a new line. They appear to wrap to a new line in the output because each
record is 80 bytes long and the terminal they were displayed on was 80 characters wide.
If you edit these files with vi you will add a trailing linefeed to the end of the file. This will increase the
size of the file by 1 byte and make the file the wrong size. To fix this you need to use the dd command to
remove the trailing newline from the file.
If you had a one record label (this example is file 22) you need to dd the file to a new one with a block size
of 80 (bs=80) and a count equaling the number entries that should be in the label file. After editing the file
will be 81 bytes instead of 80. That means we need to dd the file with a count of 1 and a block size of 80.
This will drop the trailing newline from the file.
# ll uhl.header
-rw-rw-rw- 1 root sys 81 Jul 9 09:49 uhl.header
# dd if=uhl.header of=uhl.header1 bs=80 count=1
1+0 records in
1+0 records out
# mv uhl.header1 uhl.header
# ll uhl.header
The first ANSI label (file 1)
The first entry in the first file file 11 on the tape contains a VOL1 entry. This entry is always required at the
start of a tape with ANSI labels. The file looks like:
# dd if=/dev/rmt/0mn of=file1 bs=80

5+0 records in
5+0 records out
# cat file1
VOL1HP0912 ROOT 3
HDR1EFIBOOTHPUX HP091200010001000100006254006254 000000UNIXTAPEV2.0
HDR2F010240102400ROOT //OPT/IGN M B 00
HDR3
HDR4 00
We’ll expand on what the data in here actually means:
11
ANSI labels always have a block size of 80 bytes
So what does this tell us? The VOL1 line contains certain fixed information the Volume Serial Number. A
volume serial number (or VOLSER) is usually a human and machine readable label on the tape which
uniquely identifies a tape with in an environment. By default, unless overridden with the –D option to
make_tape_recovery, the value HPMMDD is used (where MM is the month of the year and DD the day of
the month).
The VOL1 line also contains the owner set to ROOT (this is always set by Ignite-UX) the last field is the
tape type. Some valid values are 1 for ANSI and 3 for HP OpenVMS. Ignite-UX sets this field to 3.
Next we have a HDR1 record:
The HDR starts a header record and this one is a level 1 header (i.e. HDR1). The file identifier gives the
name of the file contained after this ANSI label. The volume set number is always the same as the volume
serial number.
If the the volume set number was used it would identify a set of volumes that make up a multi-volume set.
Ignite-UX does not support writing multi-volume sets for recovery tapes. The make_tape_recovery
command can write multiple tapes but the second and any subsequent tapes will not be ANSI labeled.
The creation and expiration dates are in the format CYYDDD. For century a space identifies 1900-1999
and a 0 2000-2099. The year is the two digit year of the century; DDD is the current day of the year.
Ignite-UX does not currently use the following items in a HDR1 record 12:
1. File Section Number

2. File Sequence Number
12
they always have the same values
3. Generation Number
4. Version of Generation
5. Accessibility
6. Block Count
Note that “UNIXTAPEV2.0” may or may not appear in a HDR1 record depending on the version of Ignite-
UX used when creating a tape.
The next record is the HDR2 record. This record is important because it contains information about how
the next file on the tape is formatted.
The F in the Record Format indicates that the file has fixed length records. The next two fields are the
block length and the record length. Here they’re the same value so we know that the block size of the next
file is 1024 bytes 13.
Ignite-UX does not use the density or volume switch and they are always 0. The contents of job are
irrelevant to Ignite-UX and the carriage control and blocked records are not used by Ignite-UX. The block
offset tells anyone reading the tape to ignore that many bytes from the start of each block (again this is
never used by Ignite-UX).
The HDR3 record contains no useful data, so we won’t be reviewing the contents here, but it is always
written when Ignite-UX creates the tape.
There isn’t much data in a HDR4 record, if the filename didn’t fit in the 17 bytes allowed for in the HDR1
record it goes into the 63 bytes available in the HDR4 record (Ignite-UX does not use this feature).
What is EFIBOOTHPUX? (file 2)
13
All files present on a recovery tape created by Ignite-UX use fixed length records where the block size is
the same as the record size.
We know how to get the file from the tape given the ANSI label that described it. It is called
EFIBOOTHPUX (although we won’t call it that) and it has a block size of 1024 bytes (both from HDR2):
# mt rew
# mt fsf 1
1+0 records in
1+0 records out
# xd -xc < file2
0000000 4546 4920 424f 4f54 0000 0001 0000 0400
E F I B O O T \0 \0 \0 01 \0 \0 04 \0
0000010 75b8 81ca 9aa2 ef8b 1135 f74c a2eb 5fe3
u b8 81 ca 9a a2 ef 8b 11 5 f7 L a2 eb _ e3
0000020 7c3b f55b dc3f 8b69 c413 d911 adde 0010
| ; f5 [ dc ? 8b i c4 13 d9 11 ad de \0 10
0000030 83ff ca4d ca19 3ded 2c42 db11 bbca 000f
83 ff ca M ca 19 = ed , B db 11 bb ca \0 0f
0000040 203c 42e5 0300 0000 0080 0000 0000 0a00
< B e5 03 \0 \0 \0 \0 80 \0 \0 \0 \0 \n \0
0000050 4850 2d55 5820 422e 3131 2e32 3300 0000
H P - U X B . 1 1 . 2 3 \0 \0 \0
0000060 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000070 0000 0000 0000 0000 4028 2329 4967 6e69
\0 \0 \0 \0 \0 \0 \0 \0 @ ( # ) I g n i
0000080 7465 2d55 5820 5265 7669 7369 6f6e 2043
t e - U X R e v i s i o n C
0000090 2e37 2e30 2e36 3100 0000 0000 0000 0000
. 7 . 0 . 6 1 \0 \0 \0 \0 \0 \0 \0 \0 \0
00000a0 3230 3036 2d30 392d 3132 3037 3a30 343a
2 0 0 6 - 0 9 - 1 2 0 7 : 0 4 :
00000b0 3236 0000 6361 7363 6164 6500 0000 0000
2 6 \0 \0 c a s c a d e \0 \0 \0 \0 \0
00000c0 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000400
This is an EFI tape boot block descriptor. There is information in the file (in the binary data) to tell EFI that
this is a bootable tape and that is an Ignite-UX recovery tape. The exact format is defined in the UEFI 2.0
specification. The UEFI 2.0 specification is available for download from the UEFI web site:
http://www.uefi.org/
Please note that registration is required. Additional information about the contents of this file can be found
in US Patent 7117302.
Important! Ignite-UX version C.6.10 contains a defect in the command used to create this file. It will
create a zero length file. If you ever extract what should be this file and it is zero length the tape will not be
bootable (although you will still be able to use dual media recovery, covered later, to recover from the tape).
We can look at the contents of the file and pointing out what the various parts of the EFIBOOT file mean 14:
14
The structure defined in the UEFI specifications cannot be reproduced without permission and so cannot
be presented as part of the student notes.
Note that all of the values are stored in little endian not big endian format. The most useful information
stored in this file is the version of Ignite-UX used to create the tape, the date and time it was created and the
name of the system it was created on.
One very useful bit of information for EFI is the number of files relative to the current file that the boot
loader is stored in along with its block size and total size. This gives EFI enough information to be able to
locate and read in the boot loader.
The second ANSI label (file 3)
Now we can extract the second ANSI label file from the tape and see what’s in it (unfortunately this is from
a different tape to the previous two files as the tape was accidentally overwritten):

4+0 records in
4+0 records out
# cat file3
EOF1EFIBOOTHPUX HP091700010001000100007259007259 000001UNIXTAPEV2.0
EOF2F010240102400ROOT //OPT/IGN M B 00
EOF3
EOF4
Apart from the VOL1 header (which only appears in the very first ANSI label on a tape) the format of the
EOF labels is exactly the same as their HDR counterparts. In most cases there is no useful information in
the EOF labels compared to the HDR labels. However files labeled with ANSI labels are required to have a
trailing label so any application reading the labels can determine that this is the end of the file.
The one piece of useful information is the block count. It’s updated to contain the block count written (1 in
this case). This allows you to manually validate the contents of a tape when extracting parts of it as the
EOF labels will give information on the number of blocks that the dd command should have read from the
tape.
The third ANSI label (file 4)
Here’s the data from file 4:

4+0 records in
4+0 records out
# cat file4
HDR1BOOTLOADER 00000001000100007259007259 000000
HDR3
HDR4
It’s another set of ANSI labels, this time for a file called BOOTLOADER. HDR2 contains the most
important information since with it we can dd the next file from tape. It’s got a fixed block size and the
block and record length are 32768 bytes in size.
The bootloader (file 5)

20+0 records in
20+0 records out
The table earlier (“Table 5 - Contents of natively bootable tape for HP Integrity systems”) says that this
should be the boot loader; it is approximately the correct size:
# ll file5
-rw-r--r-- 1 root sys 655360 Apr 29 10:41 file5
# cd /opt/ignite/boot
# ll hpux.efi
-r--r--r-- 1 bin bin 654025 Jan 9 2007 hpux.efi
We can look at the start of the files and determine that they are the same file. The only difference is that the
file had to be made a multiple of the block size defined in the ANSI label surrounding the file:
# dd if=file5 bs=128 count=1 | xd -xc

1+0 records in
1+0 records out
0000000 4d5a 9000 0300 0000 0400 0000 ffff 0000
M Z 90 \0 03 \0 \0 \0 04 \0 \0 \0 ff ff \0 \0
0000010 b800 0000 0000 0000 4000 0000 0000 0000
b8 \0 \0 \0 \0 \0 \0 \0 @ \0 \0 \0 \0 \0 \0 \0
0000020 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000030 0000 0000 0000 0000 0000 0000 8000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 80 \0 \0 \0
0000040 0e1f ba0e 00b4 09cd 21b8 014c cd21 5468
0e 1f ba 0e \0 b4 \t cd ! b8 01 L cd ! T h
0000050 6973 2070 726f 6772 616d 2063 616e 6e6f
i s p r o g r a m c a n n o
0000060 7420 6265 2072 756e 2069 6e20 444f 5320
t b e r u n i n D O S
0000070 6d6f 6465 2e0d 0d0a 2400 0000 0000 0000
m o d e . \r \r \n $ \0 \0 \0 \0 \0 \0 \0
0000080
# dd if=/opt/ignite/boot/hpux.efi bs=128 count=1 | xd -xc
1+0 records in
1+0 records out
0000000 4d5a 9000 0300 0000 0400 0000 ffff 0000
M Z 90 \0 03 \0 \0 \0 04 \0 \0 \0 ff ff \0 \0
0000010 b800 0000 0000 0000 4000 0000 0000 0000
b8 \0 \0 \0 \0 \0 \0 \0 @ \0 \0 \0 \0 \0 \0 \0
0000020 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000030 0000 0000 0000 0000 0000 0000 8000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 80 \0 \0 \0
0000040 0e1f ba0e 00b4 09cd 21b8 014c cd21 5468
0e 1f ba 0e \0 b4 \t cd ! b8 01 L cd ! T h
0000050 6973 2070 726f 6772 616d 2063 616e 6e6f
i s p r o g r a m c a n n o
0000060 7420 6265 2072 756e 2069 6e20 444f 5320
t b e r u n i n D O S
0000070 6d6f 6465 2e0d 0d0a 2400 0000 0000 0000
m o d e . \r \r \n $ \0 \0 \0 \0 \0 \0 \0
0000080
The fourth ANSI label (file 6)
Here we have the trailing ANSI label for the boot loader. It shows all of the information we’ve seen before
in a trailing ANSI label.

4+0 records in
4+0 records out
# cat file6
EOF1BOOTLOADER 00000001000100007259007259 000020
EOF3
EOF4
The fifth ANSI label (file 7)
Using the information presented previously about how to read ANSI labels we can tell that this label
describes a file called FPSWA.EFI (Floating Point Software Assist 15) and it has a block size of 32768.

5+0 records in
5+0 records out
# cat file7
HDR1FPSWA.EFI 00000001000100007259007259 000000
HDR3
HDR4 00
UHL3EFIAUXF000000000000003604480000000000032768
There’s also something here that we’ve never seen previously. A UHL header is a user defined header
whose contents are not defined, the contents are only meaningful to the application that writes them. Ignite-
UX will only write level 3 UHL headers.
This header is mainly written to provide the total size and the block size of the file in one header since
standard ANSI labels do not provide a mechanism for providing the size of a file in the HDR records 16.
This makes it easier for the bootloader since it can allocate memory for the file it is about to load before
reading it into memory.
FPSWA.EFI (file 8)
We can now extract FPSWA.EFI from the tape using the block size from the ANSI label:

11+0 records in
11+0 records out
As we can see the file size extracted matches the UHL3 header. The size of the files also match as 328192
rounded up to the next multiple of 32768 is 360448:
# ll file8
# ll fpswa.efi
-r--r--r-- 1 bin bin 328192 Jan 9 2007 fpswa.efi
The sixth ANSI label (file 9)
Next we have the trailing record for the FPSWA.EFI file
15
For additional information on what the floating point software assist program does please refer to UEFI
documentation.
16
And remember the number of records in the file is given in the trailing ANSI label. This saves the boot
process from having to read the contents of the file to determine the size (or reading the trailing label for
the number of records) then repositioning the tape to read the contents again.

4+0 records in
4+0 records out
It contains the same information as the header ANSI label (except the trailer ANSI label does not contain a
user header record):
# cat file9
EOF1FPSWA.EFI 00000001000100007259007259 000011
EOF3
EOF4 00
The seventh ANSI label (file 10)
The next ANSI label describes the AUTO file. Unlike a PA-RISC bootable tape where the AUTO file is
located with a LIF the AUTO file is a separate file on a natively bootable Itanium tape.

5+0 records in
5+0 records out
The block size and the file size (from the UHL3 header) are both 512 so we should only expect one record
to be read from the tape.
# cat file10
HDR1AUTO 00000001000100007259007259 000000
HDR3
HDR4 00
UHL3EFIAUXF000000000000000005120000000000000512
Prior to Ignite-UX version C.7.2 the user header looked like:
UHL3EFIAUXF000000000000000005120000000000002048
This means although the size of the AUTO file could have been larger from Ignite-UX version C.7.2
onwards it is limited to 512 bytes.
AUTO (file 11)
Now we can extract the AUTO file from the tape, as expected the size of the file is 512 bytes long:

1+0 records in
1+0 records out
# ll file11
The AUTO file contains:
# cat file11
boot IINSTALL
This shows another difference to HP9000 systems. The kernel is not prefixed with a “:” indicating that the
kernel is located within a LIF. The normal bootloader argument (from ISL to the secondary loader) for
HP9000 systems would be “hpux (;0):INSTALL”. As we will see shortly although there is a LIF located in
a file on tape the install kernel and filesystem are not within that LIF.
The eighth ANSI label (file 12)
We can extract the trailing (EOF) label from the tape

4+0 records in
4+0 records out
And look at its contents:
# cat file12
EOF1AUTO 00000001000100007259007259 000001
EOF3
EOF4 00
It doesn’t make for interesting reading. There was one record and the block and record size is 512 bytes.
The nineth ANSI label (file 13)
The next ANSI label is the header label for the install kernel (IINSTALL):

5+0 records in
5+0 records out
It has a block size of 32768 and that information allows us to extract the install kernel from the tape. The
UHL3 header exists for this file so we know the size of the file in advance as well (again this is to allow the
bootloader to allocate memory for the install kernel 17).
# cat file13
HDR1IINSTALL 00000001000100007259007259 000000
HDR3
HDR4 00
UHL3EFIAUXF000000000000222167040000000000032768
IINSTALL (file 14)
This file (as the ANSI label suggests) is the Itanium install kernel.

678+0 records in
678+0 records out
We can have a look at the file and verify that it’s a kernel:
# ll file14
17
This is similar to PA-RISC systems where the LIF directory of a LIF contains information on the size of
the install kernel in the directory. This allows the bootloader to know in advance what the size of the install
kernel is (when read from a LIF).
# file file14
file14: gzip compressed
# cd /opt/ignite/boot/Rel_B.11.23
# ll IINSTALL
-r-xr-xr-x 1 bin bin 22186598 Feb 14 2007 IINSTALL
It reports however as being gzip compressed. As of Ignite-UX version C.6.9 the 11.23 onwards install
kernels have been gzip compressed.
- Support for 11.23 compressed install kernels
The Ignite-UX install kernels (/opt/ignite/boot/Rel_B.11.23/WINSTALL

and IINSTALL) are now shipped as gzip compressed files to save disk
space and transfer times when booting. The secondary boot loaders
shipped with Ignite-UX understand and support compressed kernels to
enable this when booting over the LAN. The bootsys command will
uncompress these kernels on the client side when that is used to
initiate an install. However, the kernels put on a PA-RISC tape via
make_medialif are uncompressed due to the needs of vPars.
There is a further undocumented reason for why the install kernels are gzip compressed. That reason is to
overcome firmware limitations on HP9000 systems that are being network booted which prevent any file
being transferred using tftp if its size is more than 32MiB minus 512 bytes (the 11.23 and 11.31
WINSTALL kernels are both more than this size). The space savings are also significant, using this 11.31
Itanium install kernel as an example (saving over 90MiB):
# pwd
/opt/ignite/boot/Rel_B.11.31
# gzcat IINSTALL |wc -c
139417032
# ll IINSTALL
-r-xr-xr-x 1 bin bin 46787623 Jan 11 2007 IINSTALL
Important: NEVER gzip /stand/vmunix or any other kernel on a normal running system. The boot loader
installed on HP-UX may or may not support it. Also none of the tools that deal with kernels on a running
HP-UX system understand compressed kernels.
The tenth ANSI label (file 15)
This is the trailer label for the install kernel. We can see that the block count for the file was 678 and that
was the number of records read from the tape using dd.

4+0 records in
4+0 records out
# cat file15
EOF1IINSTALL 00000001000100007259007259 000678
EOF3
EOF4 00
The eleventh ANSI label (file 16)
Next we have the install filesystem. Again we have the UHL3 header record that details the size of the file
along with the block size for the bootloader so it can easily load it.

5+0 records in
5+0 records out

# cat file16
HDR1IINSTALLFS 00000001000100007259007259 000000
HDR3
HDR4 00
UHL3EFIAUXF000000000000449576960000000000032768
IINSTALLFS (file 17)
This is the install filesystem being extracted from tape:

1372+0 records in
1372+0 records out
You might be wondering why we call it an install filesystem, that’s because it really is an image of a
filesystem 18. When downloaded the install filesystem contains enough programs and data to start a network,
tape, or media install or recovery. The install filesystem also contains the some configuration data in the
first 8KiB of the filesystem 19:
# instl_adm -F ./file17
# instl_adm defaults:
# NOTE: Manual additions between the lines containing "instl_adm defaults"
# and "end instl_adm defaults" will not be preserved.
server="10.145.55.213"
netmask[]="255.255.254.0"
route_gateway[0]="10.145.55.1"
route_destination[0]="default"
env_vars+="TZ=EST-10EDT"
# end instl_adm defaults.
_hp_locale = "SET_NULL_LOCALE"
use_expert_ui=TRUE
env_vars +="INST_ALLOW_WARNINGS=10"
run_ui=FALSE
sysadm_message = "Recovery tape created from system: xxxx on Mon April Sep 21
17:52:03 2008"
The twelfth ANSI label (file 18)
Next we have our end of file ANSI label for the install filesystem, again the block count in EOF1 matches
the block count reported by dd.

4+0 records in
4+0 records out
# cat file18
EOF1IINSTALLFS 00000001000100007259007259 001372
EOF3
EOF4 00
18
If you create a logical volume large enough to hold it you can dd the install filesystem into it and then
mount the filesystem. HP does not support modification of the install filesystem except for the
configuration stored in the first 8KiB of the filesystem and it is maintained by instl_adm(1m).
19
The first 8KiB of ISO9660, VxFS, and HFS filesystems are unused.
The thirteenth ANSI label (file 19)
Now we have what is going to be the last file on the tape before the archive, we can see from the header
ANSI label that it’s called HPUXIUXLIF:

5+0 records in
5+0 records out
# cat file19
HDR1HPUXIUXLIF 00000001000100007259007259 000000
HDR3
HDR4 00
UHL3EFIAUXF000000000000717516800000000000002048
HPUXIUXLIF (file20)
With LIF in the name of the file in the header it’s a pretty good guess that it’s going to be a LIF file we can
use lifls on the file to see if that is true or not:

35035+0 records in
35035+0 records out
# lifls -l file20
===============================================================
INDEX BIN 16 1 0 07/09/17 17:52:03
CONFIG BIN 24 61 0 07/09/17 17:52:03
INSTCMDSIA BIN 88 104071 0 07/09/17 17:52:07
SYSCMDSIA BIN 104160 173999 0 07/09/17 17:52:10
RECCMDSIA BIN 278160 1803 0 07/09/17 17:52:11
SCRIPTS BIN 279968 45 0 07/09/17 17:52:11
VERSION BIN 280016 1 0 07/09/17 17:52:11
PAD BIN 280024 256 0 07/09/17 17:52:11
The files located in the LIF are:
Table 6 - The contents of HPUXIUXLIF

INDEX A file containing a cfg clause that points to the LIF file containing the configuration.
Note that a recovery tape always contains an INDEX file and this file always points to
the configuration located in CONFIG.
CONFIG A file containing the configuration to be used (in conjunction with the configuration
from the install filesystem) to recover a system.
INSTCMDSIA A gzipped tar portable interchange format archive containing files used while installing
the system.
SYSCMDSIA A gzipped tar portable interchange format archive containing files used while installing
the system. Most commonly see as a list of files extracted into the disk based
filesystems once they have been created.
RECCMDSIA A gzipped tar portable interchange format archive containing files used running the
recovery shell.
SCRIPTS The scripts that will be executed as part of the recovery (they referenced by the
configuration).
VERSION The version of Ignite-UX used to create this recovery archive.
PAD An unused file.
This example of the INDEX file is shown here because it’s a file that not many people ever see:
# lifcp file20:INDEX -
cfg "Recovery Archive" {
description "This selection supplies the default system configuration given
to make_medialif for the B.11.23 release."
"CONFIG"
}
The fourteenth ANSI label (file 21)
This is the trailer (end of file) record for the LIF. The number of records reported by dd when extracting the
file match the number of records reported in the in EOF1 (35035) record.

4+0 records in
4+0 records out
# cat file21
EOF1HPUXIUXLIF 00000001000100007259007259 035035
EOF3
EOF4 00
The fifthteenth ANSI label (file 22)
This is our last ANSI label. Notice that it’s also very different to previous labels, this label does not contain
any HDR records only a user header record.

1+0 records in
1+0 records out
# cat file22
UHL3EFIAUXA000000000000032024700000000000010240
In this case the file size is not exact, it’s actually wildly different to the actual archive size. The actual
archive is really about 3.2GiB in size. Unlike all of the previous UHL3 labels this size is in KiB not bytes
(that is 3202470KiB). The block size is accurate and for ustar format archives it should always be 10240
and for cpio interchance format and pax format archives it should be 5120.
There was a defect in versions of Ignite-UX before version C.6.9.141 (when it was fixed). The ANSI label
describing the archive may not be correct. In the example below note that after the block size the 80 bytes
is padded with 0x0 it should have been padded with spaces instead.
# xd -xc < file22.fromanothertape

0000000 5548 4c33 4546 4941 5558 4130 3030 3030
U H L 3 E F I A U X A 0 0 0 0 0
0000010 3030 3030 3030 3031 3334 3032 3437 3030
0 0 0 0 0 0 0 1 3 4 0 2 4 7 0 0
0000020 3030 3030 3030 3030 3030 3130 3234 3000
0 0 0 0 0 0 0 0 0 0 1 0 2 4 0 \0
0000030 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000050
This problem was reported in JAGag03107. Note that this defect did not impact on the recoverability of a
tape. Any tape showing this issue should still be recoverable.
H6487S_n02_doc.zip
Archive (file 23)
The archive is the last file on the tape and it contains the recovery archive that is extracted to recover a
system. The block size of the archive is given in the previous ANSI label.
You should not rely on the size information in the UHL3 ANSI label describing the archive. The size
information is only an estimate of the size of the archive on the tape and is based upon a calculation by
list_expander.
It’s important to note that there are no more ANSI labels on the tape. There is no ANSI label after the
archive and if the archive goes onto more than one tape there is no ANSI label at the start of each new tape.
Copying a boot tape
There is no simple way to copy a natively bootable Itanium tape. The copy_boot_tape command has never
been enhanced to be able to copy Itanium natively bootable tapes. However given that we’re previously
discussed the layout of a bootable tape and how to determine the block sizes of each of the files (from the
ANSI labels) it is possible to copy a tape.
To copy the tape follow the steps listed above used to show the contents of the tape to extract the files from
the tape. When complete use the same steps to dd the extracted files to the new tape. For large files you can
dd directly from one tape to the other – always using the correct block size. If you accidentally get any of
the block sizes wrong the resulting tape is unlikely to be usable.
What errors do you see from tapes that aren’t valid?
This section presents some examples of the sorts of errors you might see from system firmware or
bootloaders when there is something wrong with a tape.
Please note that the examples in this section are contrived 20 examples and not examples of tapes incorrectly
created by Ignite-UX.
HP9000 tape boot example

In this example we’re running make_tape_recovery. Since we don’t intend to ever use the tape to perform a
recovery we won’t actually use an option like –A:
# make_tape_recovery
* Creating local directories for configuration files and archive.
======= 05/01/08 19:17:23 MDT Started make_tape_recovery. (Thu May 01

19:17:23 MDT 2008)
@(#)Ignite-UX Revision C.7.4.157
@(#)ignite/net_recovery (opt) Revision:
/branches/IUX_RA0712/ignite/src@72068 Last Modified: 2007-11-01
14:16:06 -0600 (Thu, 01 Nov 2007)
* Testing for necessary pax patch.

* Checking Versions of Ignite-UX filesets
* Creating System Configuration.
20
The tapes were modified so they would produce errors when attempting to use them.
WARNING: The volume group /dev/vg00 will be only partially included in the
System Recovery Archive. This means that not all files and
directories on this volume group will be restored when the archive is
installed. This message can be suppressed using the "-P s" option for
make_tape_recovery. See make_tape_recovery(1M) for more details.
...
======= 05/01/08 19:38:31 MDT make_tape_recovery completed with warnings
Now we can extract the LIF. If we were modifying this tape manually to replace something we would then
also need to extract the archive as well and put it back onto the tape afterwards.
# dd if=/dev/rmt/0m of=./original_lif bs=2k

51246+0 records in
51246+0 records out
Now we can look at the LIF we extracted from the tape. Pay careful attention to the type field in the liflis
output:
# lifls -l original_lif
===============================================================
ISL -12800 16 242 0 08/05/01 19:18:05
AUTO -12289 264 1 0 08/05/01 19:18:05
INDEX BIN 272 1 0 08/05/01 19:18:05
CONFIG BIN 280 57 0 08/05/01 19:18:05
HPUX -12928 344 1024 0 08/05/01 19:18:05
FWWKAR6 BIN 1368 1 0 08/05/01 19:18:05
FWWKAR7 BIN 1376 1 0 08/05/01 19:18:05
FWWKAR8 BIN 1384 1 0 08/05/01 19:18:05
INSTALL -12290 1392 62442 0 08/05/01 19:18:08
INSTALLFS -12290 63840 61440 0 08/05/01 19:18:09
VINSTALLFS -12290 63840 61440 0 08/05/01 19:18:09
WINSTALLFS -12290 63840 61440 0 08/05/01 19:18:09
VINSTALL -12290 125280 75819 0 08/05/01 19:18:11
WINSTALL -12290 201104 88347 0 08/05/01 19:18:14
INSTCMDS BIN 289456 39036 0 08/05/01 19:18:16
SYSCMDS BIN 328496 81157 0 08/05/01 19:18:19
SCRIPTS BIN 409656 45 0 08/05/01 19:18:19
VERSION BIN 409704 1 0 08/05/01 19:18:19
PAD BIN 409712 256 0 08/05/01 19:18:19
We’re going to replace the secondary loader. Assume for the moment that we are doing this because we
needed to replace the secondary loader to fix a defect:
# cp -p original_lif modified_lif
# lifrm modified_lif:HPUX
# lifcp original_lif:HPUX ./HPUX
# lifcp ./HPUX modified_lif:HPUX
Notice that the type field for the secondary loader change from -12928 to ASCII:
# lifls -l modified_lif
===============================================================
ISL -12800 16 242 0 08/05/01 19:18:05
AUTO -12289 264 1 0 08/05/01 19:18:05
INDEX BIN 272 1 0 08/05/01 19:18:05
CONFIG BIN 280 57 0 08/05/01 19:18:05
HPUX ASCII 337 1042 0 08/05/01 22:04:06
FWWKAR6 BIN 1368 1 0 08/05/01 19:18:05

FWWKAR7 BIN 1376 1 0 08/05/01 19:18:05
FWWKAR8 BIN 1384 1 0 08/05/01 19:18:05
INSTALL -12290 1392 62442 0 08/05/01 19:18:08
INSTALLFS -12290 63840 61440 0 08/05/01 19:18:09
VINSTALLFS -12290 63840 61440 0 08/05/01 19:18:09
WINSTALLFS -12290 63840 61440 0 08/05/01 19:18:09
VINSTALL -12290 125280 75819 0 08/05/01 19:18:11
WINSTALL -12290 201104 88347 0 08/05/01 19:18:14
INSTCMDS BIN 289456 39036 0 08/05/01 19:18:16
SYSCMDS BIN 328496 81157 0 08/05/01 19:18:19
SCRIPTS BIN 409656 45 0 08/05/01 19:18:19
VERSION BIN 409704 1 0 08/05/01 19:18:19
PAD BIN 409712 256 0 08/05/01 19:18:19
This causes the boot to fail as the initial loader (ISL) can now no longer find the secondary loader (HPUX)
as there is no file of the correct type in the LIF any more:
Main Menu: Enter command or menu > sea
Searching for potential boot device(s) on the core cell

This may take several minutes.
To discontinue search, press any key (termination may not be immediate).
IODC
Path# Device Path (dec) Device Type Rev
----- ----------------- ----------- ----
P0 1/0/0/2/0.6 Random access media 4
P1 1/0/0/2/1.3 Sequential access media 4
1/0/8/1/0.0 Fibre Channel Protocol 13
1/0/8/1/1.0 Fibre Channel Protocol 13
...
Main Menu: Enter command or menu > bo p1
BCH Directed Boot Path: 1/0/0/2/1.3
Do you wish to stop at the ISL prompt prior to booting? (y/n) >> n
Initializing boot Device.
Boot IO Dependent Code (IODC) Revision 4
Boot Path Initialized.
HARD Booted.
ISL Revision A.00.44 Mar 12, 2003
ISL booting hpux (;0):INSTALL
Bad utility file type.
Auto-execute file is inconsistent. Autoboot aborted.
ISL>
The only time that you would see this issue is if you had taken this action manually, the first error “Bad
utility file type.” is the clue to the problem. The HPUX utility is the wrong type in the LIF. The
make_medialif command has the following code to copy the secondary loader into the LIF:
# Copy the HPUX (secondary loader) file:

#
# Note: This goes after INDEX and CONFIG for historical reasons, although it
# might cause a slight backup of serial (tape) media to retrieve the two prior
# (small) files later.
Lifcp $BootLIF:HPUX "$LIF_File:HPUX" -K2
Lifcp is a function in the script it’s not actually the lifcp command (although it does call it). The reason
why make_medialif doesn’t need to give the option –T -12928 is that when lifcp ends up being used to
copy between LIF files it preserves the type information making it unnecessary. The function Lifcp is
provided the –K2 option which tells the lifcp command when used to pad the LIF file being copied to a
multiple of 2KiB.
===============================================================
ISL -12800 16 242 0 07/02/14 01:39:26
AUTO -12289 264 2 0 07/02/14 01:39:26
HPUX -12928 272 1024 0 07/02/14 01:39:26
VERSION BIN 1296 1 0 07/02/14 01:41:53
The reason for –K2 is that the LIF on the tape is written with a 2KiB block size so it’s important that files
start on a multiple of the block size.
It is strongly recommended that you never attempt to manually modify a LIF unless directed to do so by HP
and been given instructions on how to perform any changes.
HP Integrity tape boot examples

In this section we’re going to look at multiple examples of problems with a boot tape. All of them are going
to be simulated. We’ll inject the errors into the tape intentionally after successfully creating the tape.
Before putting the tape back together to illustrate some problems we need to first take the tape apart into
the files that make it up using this script:
# cat extract
#!/usr/bin/sh
mt -f /dev/rmt/0m rew
dd if=/dev/rmt/0mn of=file1 bs=80

As discussed previously you need to validate the block size of the data you are extracting before extracting
it. The block size of the archive (file23) can change the recovery tape was creating in tar interchange format
so the block size is 10240 (cpio and pax format archives have a block size of 10240). The block sizes on
this tape were determined by reviewing the ANSI labels assocated with the files, the working involved in
doing this is not discussed here 21.
Once extracted the list of files looks like:
# ll
total 17285696
-rwxr-xr-x 1 root sys 854 May 5 11:58 extract
-rw-rw-rw- 1 root sys 400 May 5 12:00 file1
A zero length EFIBOOTHPUX file
In this first example we’re going to write the tape back but it’s not going to complete, the EFIBOOTHPUX
file is going to be a zero length file. This is an example of the issue in Ignite-UX version C.6.10 (mentioned
previously in the section titled “What is EFIBOOTHPUX? (file 2)”). That was a defect in Ignite-UX that
caused a zero length EFIBOOTHPUX file to be written to tape so it was no longer bootable.
This is the script that will write the file, note that in this example we are not writing the archive back to the
tape as we’re not going to be using the tape to perform an recovery.
# cat write_example_one
21
In practice the block sizes are unlikely to change often however when performing these actions yourself
you should always determine the block sizes to ensure that you extract the tape correctly. Note that in the
longer term it is possible that the number of files on the tape could change. Ensure you review the
documentation for current versions of Ignite-UX for information about potential changes.
#!/usr/bin/sh
dd if=file1 of=/dev/rmt/0mn bs=80
mv file2 file2.orig
touch file2
mv file2.orig file2
#
# Won't write back the archive because it takes a while
# and in this example we're not going to recover from
# the tape anyway.
#
# dd if=file23 of=/dev/rmt/0mn bs=10240
After running the script to recreate the (faulty) tape this is what happens. The first screen shows the boot
menu option to boot from the HP SureStore DDS tape drive connected to the system:
This fails with the not very useful error (it doesn’t report what was not found only that booting from the
tape failed because something was not found – EFIBOOTHPUX in this case):
In this case dual media recovery will work. Compare that to the output from the original tape:
The failing boot from tape attempt doesn’t show the information about searching for devices up to
“Loading: …” because the device search was performed by EFI when the option “Boot from DDS tape
drive” was added to the boot manager menu.
An empty AUTO file
The following script was written to create the tape with an empty AUTO file.
# cat write_example_two
#!/usr/bin/sh

mv file11 file11.orig
touch file11
mv file11.orig file11
#
# the tape anyway.
#
In this case the boot from tape stops at the bootloader prompt with no errors printed:
If you wanted to contiunue the boot you could manually type “boot IINSTALL” at the HPUX> prompt.
A corrupt IINSTALLFS file
In this case we’re going to corrupt the IINSTALLFS install filesystem on the tape. The script that copies
the files back onto the tape looks like:
# cat ./write_example_three
#!/usr/bin/sh

mv file17 file17.orig
dd if=/stand/vmunix of=file17 bs=32768 conv=sync
mv file17.orig file17
#
# the tape anyway.
#
The install filesystem is not a filesystem but a kernel in this case this causes the following errors to be seen:
You can see from this that there was an error loading the install filesystem from tape.
The most likely reason for this particular error is that the “corrupt” install filesystem on the tape was larger
than the UHL3 header in the ANSI label describing the file was smaller than the file that was written to
tape. This isn’t something that would normally happen when Ignite-UX was creating a tape. It is possible
that if someone is manually modifying a tape that they may not recreate the tape correctly. In this case just
replacing an install filesystem with another one won’t work. You would need to make sure that it was the
correct size and that the ANSI labels assocated with it were modified to correct show the size of the new
file..
What to take away from these examples
Sometimes it is necessary to pull a tape apart to find out what is wrong. This section on Itanium natively
bootable tapes should have given you a feel for how to pull a tape apart and look for inconsistences in the
files that make up the tape.
All of the examples here (contrived or not) can be worked around using dual media recovery. When dual
media recovery is used the only components used from the tape are some of the contents in the LIF file
HPUXIUXLIF and the archive. If the LIF is corrupted you may have issues recovering from the tape even
using dual media recovery. In most cases however any issue with a tape format issue on a HP Integrity
system can be worked around using dual media recovery.
Converting a network recovery archive to a natively bootable tape for

HP Integrity systems
Before reading this you should be aware that the make_ipf_tape command contains a defect (to be
fixed in C.7.9 – which should be released with the 0903 11.31 OE) that may significantly impact your
ability to use this information.
The make_ipf_tape command will include files that match the HP-UX the system is running not the HP-
UX release you specify with the –r option. This means if you are creating a tape for an 11.31 system on an
11.23 system you will end up with the install kernel and other files related to 11.23 not 11.31.
Until you are using a version of Ignite-UX that addresses this problem you should only ever create
custom recovery tapes using this method on the same HP-UX release that should be on the tape.
Please note that the following has not been extensively tested and this is not official documentation or
supported. You should test that the follow procedure works and that you hare happy with its results.
1. You need to make sure that you have available the configuration files describing an archive
(archive_cfg, system_cfg, and control_cfg) and the matching archive. The configuration files will
be available on the Ignite server the location of the archive will be described in the configuration
files. The following instructions assume that you have copied all of the files to the one directory
and that the archive is gzipped and called image.gz. If you wish to access the files in place you
will need to change the instructions accordingly.
2. The archive_cfg file needs to be modified to change 22:
} else {
archive_path = "1"
}
to:
} else {
archive_path = "22"
22
Make a copy of the files do not modify the configuration files for the network recovery archive
referenced by the cfg clause in the CINDEX file for the client.
And also to change 23:
archive_type = gzip tar
to:
archive_type = tar
Important: If you write a compressed or gzipped archive to tape you must only ever use the
default block size when writing the archive to tape. If you choose to try and attempt to create a
tape with a non-standard block size for a compressed or gzipped archive the tape will not be able
to be used for recovery (it will fail).
3. Now we need to create an archive header label, if the archive is less than 2TiB in size 24 we can do
that directly (the size here is in KiB). For pax and cpio format archives the block size used (the
second number in the header) should be 5120 and for ustar format archives the block size should
be 10240.
# printf "UHL3EFIAUXA%020d%016d" 2098456 5120 | dd of=./uhl.header \

bs=80 cbs=80 conv=block conv=sync
0+1 records in
1+0 records out
# ll uhl.header
# xd -xc < uhl.header
0000000 5548 4c33 4546 4941 5558 4130 3030 3030
U H L 3 E F I A U X A 0 0 0 0 0
0000010 3030 3030 3030 3030 3230 3938 3435 3630
0 0 0 0 0 0 0 0 2 0 9 8 4 5 6 0
0000020 3030 3030 3030 3030 3030 3035 3132 3020
0 0 0 0 0 0 0 0 0 0 0 5 1 2 0
0000030 2020 2020 2020 2020 2020 2020 2020 2020
*
0000050
If the size of the archive is 2TiB or larger use 2147483647 for the size in the above command. The
reason for this is that the printf command does not support numbers larger than this. When you
have created the file edit it and change the number to be the correct one.
When using vi to edit the file a line feed will be added to the end of the file (it will now be 81
bytes in size). To remove the extra line feed run the following commands:
# ll uhl.header
# dd if=uhl.header of=uhl.header1 bs=80 count=1
1+0 records in
1+0 records out
# mv uhl.header1 uhl.header
# ll uhl.header
Alternatively you can print the size directly making sure that the size field occupies 20 bytes and
is padded with zeros, for example:
23
This assumes the archive was compressed with gzip.
24
It would be extremely unusual to have an archive 2TiB or more in size.
# printf " UHL3EFIAUXA00000000000002098456%016d" 5120 | dd of=./uhl.header \

> bs=80 cbs=80 conv=block conv=sync
0+1 records in
1+0 records out
# cat uhl.header
UHL3EFIAUXA000000000000020984560000000000005120
4. Make sure that the tape is rewound and then use make_ipf_tape as follows:
# mt -t /dev/rmt/0mn rew
# make_ipf_tape -f ./system_cfg -f ./archive_cfg -f ./control_cfg -r B.11.23 25 \
> -d /dev/rmt/0mn
5. Write the archive label to the tape:
# dd if=uhl.header bs=80 of=/dev/rmt/0mn
6. Since the archive as stored on the ignite server will have been compressed with gzip (in most
cases). You will need to uncompress it. If the archive was compressed with compress then use
uncompress(1m) to uncompress the archive. Note that if you have used no compression when
creating the archive you do not need to do anything,
# gunzip image.gz
7. Write the archive to the tape:
# dd if=image of=/dev/rmt/0mn bs=10k
This example used an archive in tar format hence the bs=10k. If the archive is in cpio or pax
format you should use bs=5k instead.
This example assumed that you do not wish to explicitly set a volume serial number (volser) if you wish to
do so you can do it with the –n option to make_ipf_tape.
Please note that for HP Integrity systems if you are using a tape drive for recovery that is either not
supported for native tape boot or it is connected to an interface that is not supported for native tape boot
you can create tapes in either HP9000 bootable format or this format – both will work with dual media
recovery.
Upgrading the version of Ignite-UX on a natively bootable tape for HP

Integrity systems
The steps covered in the previous section (“Converting a network recovery archive to a natively bootable
tape for HP Integrity systems”) also explain how to upgrade the version of Ignite-UX used on a recovery
tape 26 (or modify the configuration if there is something in it causing issues). To do this you need to:
1. Extract the following files from the original tape:

a. HPUXIUXLIF (file 20)
25
This is the release of HP-UX that the tape is being written for. Obviously for a HP-UX B.11.23 archive
you would use B.11.23 and for HP-UX B.11.31 you would use B.11.31 as the argument to the –r option.
26
An example of why you might do this would be a system that has been upgraded and the version of
Ignite-UX on an old recovery tape no longer supports the new system. Please note that the archive would
still need to support the target system in this case otherwise the system being cloned to may panic on first
boot.
b. The archive label (file 22)

c. The archive (file 23).
2. From the HPUXIUXLIF file copy the CONFIG file from the LIF into another file, for example:
# lifcp HPUXIUXLIF:CONFIG ./CONFIG
3. Follow the previous instructions with the following exceptions:

a. Instead of using “-f ./system_cfg -f ./archive_cfg -f ./control_cfg” with make_ipf_tape
use –f ./CONFIG. You should not need to make any changes the CONFIG file as it
should already accurately describe the archive on the tape.
b. Instead of creating a new archive label file use the file extracted from tape.
c. You can choose to dd the archive directly between tape drives or dd the archive from tape
and then dd it onto the destination tape drive.
At this point please perform lab exercise 1 (see “Lab exercise 1 – pulling a part a recovery tape”).
Setting up tape boot on HP Integrity servers

In this section we’re going to look at how to manually boot from a tape drive and how to configure a boot
manager menu option to boot from tape. This is covered in the Ignite-UX Adminstrators Guide but not to
the same level of detail.
Working out the EFI device path for a tape drive
The first issue we need to over come with booting from a tape drive is that ioscan will not show the ACPI
device path for tape drives. The –e option to ioscan will only print an ACPI device path for disk devices:
# ioscan -efkCtape
Class I H/W Path Driver S/W State H/W Type Description
=====================================================================
tape 2 0/5/1/0.3.0 stape CLAIMED DEVICE HP C7438A
# ioscan -efkCdisk
===============================================================================
disk 19 0/0/2/1.0.16 UsbScsiAdaptor CLAIMED DEVICE USB SCSI
Stack Adaptor
disk 26 0/4/1/0.0.0.0.0 sdisk CLAIMED DEVICE
HPDG146ABAB4
Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr5000C50006106081,
Lun0)/HD(Part1,Sig9B048C22-926E-11DC-8000-D6217B60E588)/\EFI\HPUX\HPUX.EFI
disk 24 0/4/1/0.0.0.1.0 sdisk CLAIMED DEVICE
HPDG146ABAB4
Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr5000C50006105531, Lun0)
...
It is relatively easy to locate the correct EFI device path for the device with only a little bit of detective
work. The following image is from the Ignite-UX Adminstrators Guide it shows how to map part of the
HP-UX hardware path to the EFI device path:
In our case with the tape drive in the ioscan output for this tape drive:
# ioscan -efkCtape
=====================================================================
tape 2 0/5/1/0.3.0 stape CLAIMED DEVICE HP C7438A
We need to look for a device that contains “Pci(1|0)/Scsi(Pun3,Lun0)”, we can locate that easily.
Setting up a boot manager menu option
Now that we know some of the ACPI device path that what we’re looking for we can bring the system
down at a convienient time 27. Once down and at the EFI boot manager menu we go to boot configuration.
Then add a boot manager menu entry:
Before seeing this screen EFI will first search for devices. If devices have been search for previously they
will not be search for again.
If you have had a tape drive turned off and only just turned it on or connected a new tape drive to the
system at this point EFI will not know about it. You will need to go to the EFI shell and run the command
“reconnect –r” to get EFI to search for devices again.
We can locate the device we’re looking for that contains “Pci(1|0)/Scsi(Pun3,Lun0)”, note that tape drives
will always be referenced by the “Load File” in front.
27
HP-UX does not provide any way to manage the boot manager menu from HP-UX apart from setting the
primary, alternate, and HAA boot paths (along with the autoboot and autosearch options). You cannot
manage other boot menu items from HP-UX only from the boot manager menu at EFI.
Now we can enter a description. This appears on the boot manager menu so you need to make sure it
adequately describes the tape drive so anyone else who chooses the option knows which tape drive it is if
you have multiple tape drives. Press enter when you have entered the description.
The next thing prompted for are load options, you should not need to enter anything here simply press enter
again:
Next you will be asked if you wish to save the changes to NVRAM, press “Y” to save the changes or “N” if
you do not wish to save the changes.
The next screen to appear will be the boot configuration menu:
Pressing x/X or escape will take you back to the boot menu and the new option will appear.
Choosing the option just added will now allow you to boot from the tape drive.
Remember:
• Some platforms may have EFI interfaces that appear slightly different to this.
• Not all platforms support boot from tape and some platforms do not have any parallel SCSI
interfaces – they don’t support native tape boot.
Booting manually from a tape drive
There is another way to boot from a tape drive without adding a boot manager menu item. Although adding
a boot manager menu item is significantly easier and you don’t have to understand ACPI device paths.
In this first case we will boot from a file using the following menu option:
The option “Boot From File” doesn’t really have anything to do with the boot configuration of the boot
manager menu it is simply the place to find this option.
Next you need to select the EFI device path associated with the tape drive. That means that it is still
important to understand something about the APCI hardware path that we determined earlier.
EFI knows how to load the boot loader from the tape and sets it running.
This in turn starts loading the install kernel and filesystem from the tape:
When complete the install kernel starts running and the recovery session starts.
What is supported when booting from tape?
For HP Integrity systems this is an easy question to answer. The list of supported systems, HBAs, and tape
drives is listed in the white paper “Ignite-UX Installation Booting” available from this URL:
See the section “Booting from a tape” in the information about HP Integrity systems. This section contains
the following information:
• A list of systems and if they support native tape boot (if they do what EFI firmware requirements
there are, if any).
• A list of supported HBAs (built-in parallel SCSI interfaces on the systems that support native tape
boot are always supported for native tape boot on HP Integrity systems 28).
• A list of current HP StorageWorks tape drives and if they support native tape boot on HP Integrity
systems 29.
For HP9000 systems there is no similar list of systems, HBAs, and tape drives. Such a list is unlikely to
ever be created because the age and breadth of such a list. If there is a problem booting from tape on an
interface for a system it would need to be investigated to determine if it is meant to work or not.
In general builtin parallel SCSI interfaces on HP9000 systems should support boot from tape, although it is
nearly impossible to determine what tape drives have been tested on specific systems.
Disk formats – HP9000 systems

This section only discusses booting from optical media not from any other kind of media. When discussing
media the term DVD will only be used. In all circumstances however if the image will fit onto a CD then
CD can be used interchangeably with DVD. This section will not deal with creating custom media for the
install or recovery of systems or with how to burn media using cdrecord or growisofs.
HP9000 systems support several different formats of optical media. The important thing for all these
different formats is that a LIF appears to be at the very start of the media. The supported formats are:
28
Be mindful that not all systems have built-in parallel SCSI interfaces.
29
Other tape drives may work but they have not been tested hence they are not supported.
1. A LIF burnt directly to a DVD

2. A LIF combined with a HFS filesystem using instl_combine.
3. An ISO9660 filesystem containing a LIF as an alternate boot file in El Torito 30 format.
The last item will be discussed in the section on HP Integrity systems rather than here since the steps
required are (usually) identical.
An alternative to perform these manual steps is to use the make_media_install script to create some media
types. An important use for creating media in this way is for dual media recovery.
Just a LIF
For HP9000 systems it is possible to simply create a LIF and burn it directly to a DVD. If you create a LIF
as follows (changing B.XX.YY for the appropriate HP-UX release):
# make_medialif –m –r B.XX.YY –l ./my_lif
And burn the LIF directly to a DVD you should be able to boot directly from the media. If you add the –R
option to the make_medialif command the resulting image will also be able to run a recovery shell. Media
created this way is perfect for dual media recovery purposes.
A LIF and a HFS filesystem
The following way of creating media is probably not that commonly used anymore. It has a limitation that
the final size of the media cannot be 2GiB or larger. The reason for this is firmware limitations on older
HP9000 systems where firmware may not be capable of reading past the 2GiB point on a disk. In this
format the LIF is actually stored at the end of the filesystem since firmware needs to read the LIF contents
it’s limited to a size of less than 2GiB.
If you have an archive in a HFS filesystem (the Ignite-UX Adminstrators Guide has details on how to do
this) you can combine the HFS filesystem and the LIF together using the instl_combine command. The
instl_combine(1m) manual page also has more information on the limitations and the choices available.
Testing media without burning it
This method works for both HP 9000 and HP Integrity systems. If you have an image already created you
can dd it into a disk and boot directly from that disk (that assumes that the disk is not used for anything
else). This allows you to test an image without the need to burn it onto media.
If the disk that you dd the image to is on a Fibre Channel device connected to a SAN that allows multiple
systems access to the device multiple systems will be able to access it.
Disk formats –HP Integrity systems

HP Integrity systems support only one optical media format for boot – El Torito format. Because of the
commonality of the tools used by Ignite-UX in installing both architectures El Torito format media ends up
working just as well for both architectures.
30
El Torito format DVD media is required to boot Itanium systems not HP9000 systems but because of the
way a LIF must be placed on this media even for Itanium systems it allows HP9000 systems to boot from
this media as well.
If that wasn’t the case you would not be able to use the HP-UX B.11.23 and B.11.31 OE media to install
both HP9000 and HP Integrity servers.
El Torito format media
The following instructions are based on the instructions from the section titled “How do I create the CD
equivalent of a tape created by make_boot_tape?” from the manual “Ignite-UX Custom Configuration
Files” available from this URL:
Assuming that the LIF created in the section “Just a LIF” was for a HP-UX release that supports both
HP9000 and HP Integrity systems you can do the following steps to create a CD/DVD in El Torito format.
1. You must create a pseudo-root for the CD image; this is necessary to add support for Itanium®-based
systems. Enter the following commands:
# mkdir top
# mv my_lif top
# cp /opt/ignite/boot/Rel_B.XX.YY/EFI_CD_image top/EFI_CD_image
# cd top
2. Create an ISO image that can be written to a DVD. The mkisofs command is supplied with Ignite-UX.
# /opt/ignite/lbin/mkisofs -no-emul-boot -b EFI_CD_image \

-eltorito-alt-boot -no-emul-boot -b my_lif -o ../cdfs.out $(pwd)
Messages similar to the following appear:
Size of boot image is 10240 sectors -> No emulation

6.69% done, estimate finish Mon Nov 15 18:05:23 2004
Total translation table size: 2048
Total rock ridge attributes bytes: 0
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 9000
74736 extents written (145 Mb)
Ensure that there are no mkisofs command errors. Older versions of mkisofs 31 do not accept:
1. the -no-emul-boot option given twice
31
These limitations existed in very old versions of mkisofs not in the versions shipped with Ignite-UX that
supported both HP9000 and HP Integrity systems running the same release of HP-UX (i.e. September 2004
and later).
2. the use of multiple –b options

3. the -eltorito-alt-boot option
Place a LIF directory at the start of the ISO image with the instl_combine command so that the media will
boot:
# /opt/ignite/lbin/instl_combine -C cdfs.out
HP Integrity systems do not require a LIF to be present to boot (PA-RISC systems do). However the kernel
loader used to install HP Integrity systems reads the installation kernel and file system from the LIF. Later
in the installation process, other files will also be read from the LIF. For more information regarding how
to create custom installation media, refer to the Ignite-UX Administration Guide.
The above instl_combine command modifies the ISO9660 filesystem to use the unused first 8KiB of the
filesystem to contain a LIF directory. The LIF directory points to the LIF entries in the LIF file in the
ISO9660 filesystem. Files in an ISO9660 filesystem are contiguous so any utility reading the LIF directory
does not need to understand an ISO9660 filesystem and can read the file based upon the starting offset and
size determined from the LIF directory.
The ISO image can be written onto a DVD. This method is an ideal way to create media suitable for use
with dual media recovery.
Using vMedia
vMedia is a licensed product 32 available on iLO2 management processors (MP). vMedia allows the system
to prevent a virtual USB DVD drive to a system. Only iLO2 MPs support vMedia, older MPs do not.
Note that although the MP on the rx3600 system that was used for the following examples says “The
Virtual Media applet requires that Java Plug-in 1.4.2-10 be installed on the client system.” the Java 1.5.0
runtime that was used ran the vMedia Java application with no problems.
SSL Certificates
The SSL certificates created by the iLO2 MP are self-generated. When accessing the MP you will see the
following dialog box (this is from Internet Explorer version 6 (IE6)):
32
An Advance Pack License must be purchased and installed on the iLO2 MP before vMedia is active. For
non-admistrator users the use of vMedia must also be authorized on the MP by an administrative user.
The reason for this as you can see when viewing the certificate is that the certificate is self signed:
The following are dialogs generated when attempting to run the iLO2 vMedia Java programs downloading
to a PC from the MP. You are like to always see these dialogs when running the vMedia Java application
unless you install the certificates from the MP and choose to trust the MP as the publisher. In these dialogs
the MP name is different because it was changed part way through writing this example.
If you ever need to recreate the SSL certificate on the MP (for example after changing the IP address or
hostname of the MP) follow these instructions:
[greenmp] MP:CM> so
SO
This command allows you to modify the security options.

For User Configuration see the UC command.
For SNMP Configuration see the ID command.
For SSH enable/disable see the SA command.
Current Security Options:

O - Login Options
L - SSL Certificate
H - SSH Key Pairs
Enter menu item or [Q] to Quit: L

L
Current SSL Certificate parameters:

SSL Certificate : Generated
Certificate Expiration : Jul 11 2017
Current SSL Certificate status:

N - Common Name : mp0014c29c330f
O - Organization : organization
U - Organizational Unit : unit
C - Country : country
R - Region/State : region
L - Locality/City : locality
E - Email Address : email
Enter parameter(s) to change, A to modify All, or [Q] to Quit: n

n
For each parameter, enter:

New value, or
<CR> to retain the current value, or
DEFAULT to set the default value, or
Q to Quit
Current Common Name: mp0014c29c330f
Enter new value, or Q to Quit: greenmp

greenmp
-> Common Name will be updated
New SSL Certificate parameters (* modified values):

SSL Certificate : Generated
Certificate Expiration : Jul 11 2017
New SSL Certificate status (* modified values):

* N - Common Name : greenmp
O - Organization : organization
U - Organizational Unit : unit
C - Country : country
R - Region/State : region
L - Locality/City : locality
E - Email Address : email
Enter Parameter(s) to revise, Y to confirm, or [Q] to Quit: y

y
Please wait ...
-> Restart MP and browser for new security settings to take effect.
-> Security Options have been updated.
Current Security Options:

O - Login Options
L - SSL Certificate
H - SSH Key Pairs
Enter menu item or [Q] to Quit: q

q
As noted above the MP must be reset after recreating the SSL certificate:
[greenmp] MP:CM> xd
XD
Diagnostics Menu:
Non destructive tests:
P - Parameter checksum
I - I2C access (get BMC Device ID record)
L - LAN access (PING)
H - History
Destructive tests:
R - Restart MP
Enter menu item or [Q] to Quit: r

r
Confirm? (Y/[N]): y
y
MP is now being reset...
After doing this you will need to accept new certificates from the MP and retrust the MP as the publisher of
the vMedia application.
The vMedia User Interface (local media)

When first started the vMedia interface looks like:
In this case the 11.31 0803 Mission Critical OE media is located in drive D:. If we change the local media
pull down from “None” to “D:\” and then click on the connect button the screen changes to become:
The disk is now accessable from the iLO2 MP and can be used for an installation session.
From the EFI shell if the vMedia device is already connected the following will happen:
Searching for devices

HP Fibre Channel Adapter (driver 1.05, firmware 4.00.070)
HP 2Port 4Gb Fibre Channel Adapter (driver 1.05, firmware 4.00.070)
Scsi(Pun3,Lun0) HP C7438A ZP6B (160 MBytes/sec)
Loading.: EFI Shell [Built-in]
EFI Shell version 1.10 [14.62]
Device mapping table
fs0 : Acpi(HWP0002,PNP0A03,0)/Pci(2|0)/Usb(0, 0)/CDROM(Entry0)
fs1 : Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr5000C50006106081,Lun0)
/HD(Part1,Sig9B048C22-926E-11DC-8000-D6217B60E588)
fs3 : Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr5000C50005E147ED,Lun0)
/HD(Part1,Sig8980E690-9BAA-11DC-8000-D6217B60E588)
blk0 : Acpi(HWP0002,PNP0A03,0)/Pci(2|0)/Usb(0, 0)
blk1 : Acpi(HWP0002,PNP0A03,0)/Pci(2|0)/Usb(0, 0)/CDROM(Entry0)
blk2 : Acpi(HWP0002,PNP0A03,0)/Pci(2|0)/Usb(0, 0)/CDROM(Entry1)
blk4 : Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr5000C50006101899,Lun0)
blk5 : Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr5000C5000610541D,Lun0)
/HD(Part2,Sig9B048C5E-926E-11DC-8000-D6217B60E588)
blkA : Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr5000C50006106081,Lun0)
blkB : Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr5000C50005E12E05,Lun0)
blkC : Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr5000C50005E14589,Lun0)
blkD : Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr5000C500053FAD09,Lun0)
blkE : Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr5000C50005E147ED,Lun0)
blkF : Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr5000C50005E147ED,Lun0)
blk10 : Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr5000C50005E147ED,Lun0)
/HD(Part2,Sig8980E6AE-9BAA-11DC-8000-D6217B60E588)
blk11 : Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr5000C50005E147ED,Lun0)
/HD(Part3,Sig8980E6C2-9BAA-11DC-8000-D6217B60E588)
startup.nsh> echo -off
Welcome to HP-UX Install Media
(C) Copyright 1999-2006 Hewlett-Packard Development Company, L.P.

All rights reserved
HP-UX Boot Loader for IPF -- Revision 2.035
Press Any Key to interrupt Autoboot

AUTO ==> boot :IINSTALL
Seconds left till autoboot - 0
AUTOBOOTING...> System Memory = 16351 MB
loading section 0
...........................................................................
...................... (complete)
loading section 1
................. (complete)
loading symbol table
loading ram disk file (:IINSTALLFS).
...........................................................................
..........................................
(complete)
Launching :IINSTALL
SIZE: Text:49429K + Data:8267K + BSS:22598K = Total:80294K
...
Console is on Serial Device - via PCDP
Booting kernel...
0.30.60.7krs_read_mfs: Error 5 opening MFS.

Loaded ACPI revision 2.0 tables.
krs_read_mfs: Error 5 opening MFS.
Memory Class Setup

-------------------------------------------------------------------------
Class Physmem Lockmem Swapmem
-------------------------------------------------------------------------
System : 15551 MB 15551 MB 15551 MB
Kernel : 15551 MB 15551 MB 15551 MB
User : 14601 MB 12944 MB 12995 MB
-------------------------------------------------------------------------
...
If you connect the vMedia device after getting to the EFI shell you will need to run map –r and manually
change to the filesystem belonging to the vMedia virtual DVD/CD drive:
Searching for devices

...
Shell> map -r
fs2 : Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr5000C50005E147ED,Lun0)
fs3 : Acpi(HWP0002,PNP0A03,0)/Pci(2|0)/Usb(0, 0)/CDROM(Entry0)
...
Welcome to HP-UX Install Media

All rights reserved

AUTO ==> boot :IINSTALL
...
The vMedia User Interface (local image)

Now we’re going to do the same thing but use a local image (you can copy any DVD to a local image by
pressing the “Create Disk Image” button 33). The interface for creating a disk image looks like (press “Disk
>> Image” to create the image – once created press cancel to close):
Now we can connect to the disk image:
33
Remember OE media usually has 2 DVDs you will need to create disk images of both or use one disk
image and use one DVD directly.
Booting from this image will work the same as booting from the physical DVD drive.
Expected vMedia Speeds

vMedia runs at a maximum of USB 1.1 speeds, this is part of the design of the iLO2 MP. Using vMedia
will be significantly slower than using a local USB 34 or SCSI DVD drive and the slower the network
connection the slower the speed of reading the image.
Over a local network assuming no time elapsed for changing DVDs you expect roughly 4 hours to install
via vMedia and less than 2 hours for a locally attached DVD (assuming that the install kernel on the media
has USB 2.0 drivers installed if the locally attached DVD drive is a USB drive).
vMedia – what happens with a read failure

Since vMedia is connecting a device over the network via a connection from a PC to the MP of a system
you will find that network errors, outages or delays may cause problems. These problems may be
manifested in different ways in this section we will present two possible outcomes for network problems
that can be seen when using vMedia.
The closer you are to a system (in terms of network hops) or the higher the speed between you and the
system and the lower the occurrence of network problems the less likely you are to see any problems.
This first problem shows the boot loader unable to open the volume for the filesystem. In this case you can
type “exit” and try again or “boot :IINSTALL” to continue.
Shell> fs3:
fs3:\> install
34
This assumes a version of Ignite-UX is being used that supports USB 2.0 so the USB DVD drive can
operate at more than USB 1.1 speeds.

All rights reserved
Cannot open the volume for the file system

Type 'help' for help
HPUX>
In this case a network issue caused the response to a read request to take too long. After series of errors the
bootloader gave up and panic’ed:
fs3:\> install

All rights reserved

\AUTO ==> boot :IINSTALL
Seconds left till autoboot - 0
AUTOBOOTING...Error - efi_disk_read returned (Device Error)
offset:0x46da000, ma:0xfdea0010, len: 8192
pausing temporarily... 0
Error - efi_disk_read returned (Device Error)

offset:0x471a000, ma:0xfde20010, len: 8192

offset:0x4a9a000, ma:0xfdf20010, len: 8192

offset:0x4aba000, ma:0xfdee0010, len: 8192

offset:0x4bba000, ma:0xfdce0010, len: 8192

offset:0x4c1a000, ma:0xfdc20010, len: 8192
assertion failed: zs->ftype == FTYPE_GZIP_EOF, file:

/ux/core/kern/tools/bootloader/common/gzip/zfs.c, line: 443
PANIC: assertion error

Press Any Key To Continue ...
Important: a bootloader panic will cause the system to reboot go through selftest again and then go back
to the EFI boot manager menu.
Dual Media Recovery

Dual media recovery (also known as Two Step recovery) is designed for booting from a CD/DVD image
and then switching to a tape recovery. The original intent of doing this was to allow HP Integrity systems to
perform a tape recovery using a HP9000 bootable format tape (since this format obviously is not bootable
on HP Integrity systems).
This does have other uses however. For both architectures this allows a recovery tape to be written to a tape
drive that is not supported for boot to be used for a recovery (regardless of the format). For HP Integrity
systems this allows systems that do not support native tape boot to continue to use tape recovery.
Using dual media recovery comes with one extremely important restriction. The version of Ignite-UX
used to create the CD/DVD (or OE) media must be the same version of Ignite-UX that was used to create
the tape. HP does not support using “mixed media”. The term “mixed media” means that the version of
Ignite-UX on the CD/DVD (or OE) media that was used to boot the system does not match the version of
Ignite-UX used to create the recovery tape.
There are good reasons for this. The most important reason comes about because of how Ignite-UX is built.
When a new OE is released the install kernel, install filesystem, INSTCMDS[IA], SYSCMDS[IA], and
RECCMDS[IA] files are all built together. There are dependencies between the install kernel, the install
filesystems, and the commands archives.
The important thing to consider with dual media recovery is that once you have booted the install kernel
and filesystem (and some initial commands) are from the CD/DVD (or OE) media. After you switch to tape
Ignite-UX will load subsequent commands from tape not the CD/DVD (or OE) media. Doing this is what
usually causes the mismatches that create problems – this is why it’s not supported.
Here are some examples of such dependencies:
• When the version of VxVM/VxFS rolls in the install kernel the commands are automatically
updated to reflect the new version of VxVM/VxFS. If you boot from media that contains a
different VxVM/VxFS version it is likely that when Ignite-UX comes to create filesystems that
this will fail.
• Missing libraries, for example when Ignite-UX changed to use aCC for development the aCC
runtime was not in the install filesystem. With the switch to using aCC the aCC runtime libraries
were included into the install filesystem. Booting from any previous version of Ignite-UX and
switching to a tape recovery caused dynamic loader errors when programs were loaded from the
tape and run because of the missing libraries.
Important: Don’t use mismatched media as it is not supported. No problem found with dual media
recovery using mismatched media will be investigated unless it can be shown to happen with matched
media.
Note: Currently to perform dual media recovery you MUST boot from CD/DVD (or OE) media then switch
to tape. The option to switch to tape is not available via any other booting method, for example you cannot
boot from the network then switch to tape.
For situations where there is no readily available media to perform dual media recovery with (e.g. no OE
media for the version of Ignite-UX being used) it is easy to create minimal bootable CD/DVD images. For
HP-UX 11.11 see “Just a LIF” and HP-UX 11.23 onwards see “El Torito format media”.
The Ignite-UX Adminstrators guide contains information on how to perform dual media recovery (referred
to as two-step recovery by that manual) including information on what the screens look like and the options
to choose.
Note: for a system with vMedia support (requires an iLO2 MP and Advance Pack License for the MP) the
minmal image can be located on a PC. Using the vMedia software you can access the image from the PC. If
you have a high speed connection between the PC and the iLO2 MP this can better cater for unattended
operation of systems since you do not need someone to put in the CD for dual media recovery.
Network booting – HP Integrity systems

HP Integrity systems, like all other Itanium-based systems, use the Industry standard PXE protocol to
perform network booting. Detailed information about the PXE protocol can be found on the Intel web site
(www.intel.com and search for PXE).
An Overview – the full PXE Boot
When booting there are two initial steps involved before the client attempts to download anything. First an
IP address must be gained by DHCP (remember bootp is a subset of DHCP) and the second is to talk to a
PXE Proxy server.
DHCP Request
DHCP Reply
Booting Network
System
PXE Proxy
PXE Proxy
Reply
The reason why the boot process is structured like this is so the booting system can use a standard DHCP
server with no extra configuration and then communicate with the PXE proxy for information that it needs
to start a network boot.
HP-UX doesn’t have a PXE Proxy server at this time. A full PXE boot doesn’t use HP-UX to reply to PXE
boot requests. This is why when configuring the DHCP server on HP-UX the ncid option is used. The ncid
option says not to reply with the DHCP class id in the response.
The presence of a DHCP class id in the DHCP response is what tells the booting system if it should
perform a full PXE boot (i.e. attempt to talk to a PXE Proxy server or not). If the Itanium PXE class id
(PXEClient:Arch:00002:UNDI:xxxyyy 35) is present a full PXE boot is performed. If the DHCP class id is
not present EFI assumes that the response is a bootp response and the information required to perform a
network boot is present in the responses so a PXE proxy server is not contacted.
Note: Industry standard servers and desktop PCs also use a similar class id the difference is that the number
00002 is replaced with 00000. It’s important when configuring a system to respond to Itanium systems that
35
where xxxyyy are major and minor numbers for the Universal Network Device Interface revision.
Although it’s rare for it to change it is possible that this number can change over time.
you do not configure them to respond to the class id PXEClient:Arch:00000:UNDI:* (as this may interfere
with other systems).
During a PXE boot however the client will listen for multiple responses to its PXE boot request. A response
containing the Itanium PXE class id will always take precedence over a non-PXE (i.e. a bootp response or
DHCP response that does not have a class id in it). The Ignite-UX documentation explains how this can
lead to problems when you have multiple systems responding to the boot request making it difficult to
troubleshoot network booting issues.
HP Integrity systems do not support a directed listen for responses. With HP9000 systems you are able to
start a network boot of the form “bo lan.10.0.0.50 install” so the system will only accept a response from
the server 10.0.0.50. That means that you have no control over who you will accept responses from.
From this point on however we will assume that there are no DHCP servers on the network that will
respond to PXE boot requests leaving only the DHCP server we have configured to respond to PXE boot
requests.
In this section we’re going to go through an example of installing a HPVM guest over the network. Note
that this example uses a virtual private network switch that is not connected to a physical network, only the
Ignite server and client are connected.
The HPVM guests were created using the following commands:
# hpvmnet -c -S private
# hpvmcreate -P vm010 -l "Guest for Ignite testing" -B auto -O HPUX -c 4 -e 10
-r 4G -a disk:scsi::lv:/dev/vg01/rlvol101 -a dvd:scsi::null:/var/dvd -a
network:lan::vswitch:private
# hpvmcreate -P vm011 -l "Guest for Ignite testing" -B auto -O HPUX -c 4 -e 10
-r 4G -a disk:scsi::lv:/dev/vg01/rlvol111 -a dvd:scsi::null:/var/dvd -a
network:lan::vswitch:private
And then started:
# hpvmnet -b -S private
# hpvmstart -P vm010
# hpvmstart -P vm011
The two systems are connected as follows:
Ignite Client
Server
vswitch
vm010 vm011
Additional information about PXE is available here (it contains a reasonable amount of information about
PXE and has links to the Intel specifications):
http://en.wikipedia.org/wiki/Preboot_Execution_Environment
Setting up the Ignite server
In this example the Ignite server vm010 was installed with a version of the 0709 11i v3 OE media where
the two DVDs were combined into one media image (See “Combining two OE DVDs into one for use with
HPVM” for more information). Since Ignite-UX is not installed by default with an OE the bundle Ignite-
UX-11-31 was installed after the system was cold installed.
Setting up Ignite-UX
The following steps were performed to setup the Ignite server so it was ready to install HP-UX 11i v3 onto
the client:
1. After install Ignite-UX logout and log back into the system 36.
2. The OE DVD (the one combined DVD image) was copied into a depot on the local system:
# make_depots -s /cdrom -d /var/opt/ignite/depots/Rel_B.11.31/0709_MC_OE
3. Then a configuration file was created to describe the depot that was just created:
# make_config -s /var/opt/ignite/depots/Rel_B.11.31/0709_MC_OE -c
/var/opt/ignite/data/Rel_B.11.31/0709_MC_OE.cfg
You should see the following output from this command:
36
Installing a product for the first time adds the product directories into the PATH (updates /etc/PATH) and
this is not reflected in the PATH environment variable of any user currently logged in. In this case you
need to update the PATH environment variable manually or logout and log back in again.
NOTE: make_config can sometimes take a long time to complete. Please be

patient!
4. Now we need to create a new configuration clause in /var/opt/ignite/INDEX to describe the new
depot so it can be installed. The first command creates a new cfg clause in the INDEX file called
“11i v3 0709 MC OE” that is a copy of the clause “HP-UX B.11.31 Default”. The second
command sets the cfg clause “11i v3 0709 MC OE” to be the default cfg clause. The last
command adds the configuration file 0709_MC_OE.cfg into the cfg clause “11i v3 0709 MC OE”
# manage_index -n "HP-UX B.11.31 Default" -c "11i v3 0709 MC OE"

# manage_index -e -c "11i v3 0709 MC OE"
# manage_index -a -f /var/opt/ignite/data/Rel_B.11.31/0709_MC_OE.cfg -c "11i v3
0709 MC OE"
From Ignite-UX C.7.4 onwards you might also use the following command to change the
description of the cfg clause. Before Ignite-UX version C.7.4 it is not possible to change the
description using the manage_index command.
# manage_index -y "Install the 11i v3 0709 MC OE" -c "11i v3 0709 MC OE"
After the changes (assuming that we haven’t changed the description the INDEX file should now look
like 37:
# cat /var/opt/ignite/INDEX
# /var/opt/ignite/INDEX
# 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.
#
# NOTE: The manage_index command is used to maintain this file.
# Comments, logic expressions and formatting changes are not
# preserved by manage_index.
#
# WARNING: User comments (lines beginning with '#' ), and any user
# formatting in the body of this file are _not_ preserved
# when the version of Ignite-UX is updated.
#
cfg "HP-UX B.11.31 Default" {
description "This selection supplies the default system configuration
th
at 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"
}
cfg "11i v3 0709 MC OE" {
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/data/Rel_B.11.31/0709_MC_OE.cfg"
"/var/opt/ignite/config.local"
}=TRUE
If you choose to make the changes to the INDEX file manually please always run the following command
to ensure that you have not introduced any syntax errors into the file:
37
Remember we only installed the bundle Ignite-UX-11-31 because of that we would only have cfg clauses
for 11i v3 in the INDEX file.
# instl_adm -T -f /var/opt/ignite/INDEX
If there are no problems from the syntax check no output will be printed.
To complete the Ignite-UX setup run the ignite command. In the screens that are shown answer ok to any
dialogs and do not choose to run server setup. Exit from the program when you can. On HP-UX 11i v3 this
will have added the following into /etc/dfs/dfstab:
# cat /etc/dfs/dfstab
# place share(1M) commands here for automatic execution
# on entering init state 3.
#
# share [-F fstype] [ -o options] [-d "<text>"] <pathname>
# .e.g,
# share -F nfs -o rw=engineering -d "home dirs" /home
share -F nfs -o anon=2 /var/opt/ignite/clients
On HP-UX releases prior to 11i v3 the file /etc/exports will have been changed to be:
# cat /etc/exports
/var/opt/ignite/clients -anon=2
These entries are added only if the entries do not already exist. Note that there may be other entries in these
files. As an alternative you can also run the following commands (the share command is for 11i v3 and
exportfs is for 11i v2 and earlier releases of HP-UX.
# exportfs
# share
- /var/opt/ignite/clients anon=2 ""
If the contents of exportfs and /etc/exports or share and /etc/dfs/dfstab do not match you have to manually
export the filesystem (see the manual pages for exportfs or share on the applicable release of HP-UX). You
should also configure the filesystems to be exported/shared permanently so you do not need to run the same
commands after every reboot.
DHCP setup
The Ignite-UX Administrators guide discusses how to setup a system for DHCP or bootp in much greater
detail than we’re going to. For this example that will look at booting an HP Integrity system (actually a
HPVM guest) we’re going to use a DHCP configuration.
The entry that we will add into /etc/dhcptab will look like:
dhcp_device_group:\
re:\
ncid:\
class-id="PXEClient:Arch:00002":\
lease-time=300:\
subnet-mask=255.0.0.0:\
addr-pool-start-address=10.1.1.200:\
addr-pool-last-address=10.1.1.210:\
bf=/opt/ignite/boot/nbp.efi
This entry tells the bootpd (the DHCP/bootp server on HP-UX) to only reply using this DHCP device group
if the incoming request has a DHCP class id that matches the regular expression (the re tag says that the
class-id tag is a regular expression) that matches “PXEClient:Arch:00002” and when replying not to send
back a class-id.
Important: In the device group added into /etc/dhcptab it is critical that no white space or any other
characters exist after the line continuation character “\”. If it is not the last character on the line bootpd will
report syntax errors when it reads /etc/dhcptab.
This class id is different to the one in the Ignite-UX Administrators Guide examples. The class-id in that
document looks like “PXEClient:Arch:00002:.*”, however .* means zero or more characters of any kind
which renders it superfluous. As a class-id “PXEClient:Arch:00002” is sufficient to match only Itanium
PXE boot requests without the need for wildcards in regular expressions. We can show that the regular
expression “PXEClient:Arch:00002” is sufficient to match an Itanium PXE class- id using the grep 38
command:
# print "PXEClient:Arch:00002:UNDI:000000" | grep "PXEClient:Arch:00002"

PXEClient:Arch:00002:UNDI:000000
# print "PXEClient:Arch:00002:UNDI:000000" | grep "PXEClient:Arch:00002:.*"
PXEClient:Arch:00002:UNDI:000000
The regular expression provided by the Ignite-UX Administrators Guide is not wrong it is just not the most
minimal Basic Regular Expression (BRE) possible.
The other entries in the DHCP device group are standard. We have:
1. A start and ending address pool range for the device group
2. A subnet mask
3. The lease time
4. The name of the boot file that the client should download to start the network boot
(/opt/ignite/boot/nbp.efi – where nbp stands for network bootstrap protocol).
Important: Make sure that the following line is not commented out in /etc/inetd.conf (if it’s commented out
you won’t supply DHCP/bootp services from the system you’re setting it up on):
bootps dgram udp wait root /usr/lbin/bootpd bootpd
At this point if we wanted to we could boot the client but we have one more step to do. We need to install
tcpdump onto the Ignite server.
Important: If you provide an entry for a system in /etc/bootptab and there is a DHCP device group that
could also satisfy the request the bootpd daemon will always respond with the bootp information. If you
expect that a client should be getting information from a DHCP device group but is getting different
information check to ensure that the client does not have an entry defined for it in /etc/bootptab.
Installing tcpdump/libpcap
We’re using tcpdump/libpcap because it’s easier to use than netll for network tracing. Similarly to the OE
media in this case we’ve copied the tcpdump and libptap products from the Internet Express software
bundle (available for download from www.hp.com/go/softwaredepot). Once we have the two products that
we’re after we can package them into an ISO image (in this HPVM example we don’t have a network
interface that connects to a “real” network):
# cd /var/tmp/build
# mkdir dvd
38
When the re tag is used the class-id is used as a Basic Regular Expression (BRE), these are the default
regular expression used by grep so no options are required to change the regular expression types used. The
regular expression type used is documented on the bootpd(1m) manual page.
(copy the software we want using swcopy)

# /opt/ignite/lbin/mkisofs -R -D -U -v -max-iso9660-filename -o tcpdump dvd
Once we’ve created the ISO image we can move it into the file backing store for the virtual DVD and
mount it in the Ignite server 39 and install it.
# ll
total 6576
drwxrwxrwx 7 root sys 8192 Feb 5 15:45 dvd
-rw-rw-rw- 1 root sys 3356672 Feb 5 15:47 tcpdump
# chmod 644 tcpdump 40
# mv tcpdump /var/dvd
Booting the system and capturing the initial PXE traffic (DHCP)
Before we attempt to capture what is happening let’s make sure that we can boot the system. The system
booted first time:
Shell> lanboot
Select Desired LAN: 1
Selected Acpi(PNP0A03,0)/Pci(1|0)/Mac(3AE253DAC61A)
Running LoadFile()
CLIENT MAC ADDR: 3A E2 53 DA C6 1A

CLIENT IP: 10.1.1.204 MASK: 255.0.0.0 DHCP IP: 10.1.1.1
Running LoadFile()
TFTP.
@(#) HP-UX IA64 Network Bootstrap Program Revision 1.0
Downloading HPUX bootloader
Starting HPUX bootloader
Obtaining size of fpswa.efi (328192 bytes)
Downloading file fpswa.efi (328192 bytes)

All rights reserved
Booting from Lan

Obtaining size of AUTO (172 bytes)
Downloading file AUTO (172 bytes)

1. target OS is B.11.31 IA
2. Exit Boot Loader
Choose an operating system to install that your hardware supports:
39
The HPVM guest that we created earlier uses a virtual DVD drive with a directory as a backing store. To
change the DVD you need to use in IN command from the virtual MP (accessed via the hpvmconsole
command). To eject the DVD you need to use the EJ command from the virtual MP.
40
HPVM will not allow you to mount world writable files in a virtual DVD.
This shows us one very important bit of information just in case the wrong system answered the PXE boot
request, the DHCP IP in this information:

Is the IP address of the DHCP/PXE/bootp server that answered the PXE boot request. If it contains an
unexpected IP address you have another DHCP/PXE/bootp server answering the boot request than the one
that you have setup.
Choosing option 2 exits from the bootloader and puts us back at the EFI shell so we can start the network
boot again and trace the network traffic with tcpdump.
The tcpdump 41 command that we will use is:
# /usr/sbin/tcpdump -i 1 -nXXvv -s 1024 portrange 67-68
The options used mean:

• -i 1 – Listen on interface 1, a list of interfaces can be retrieved using the tcpdump command with
the –D option. On this system there was only one choice available:
# /usr/sbin/tcpdump -D
1.lan0
• -n – do not translate IP addresses or port numbers into names.

• -XX - dump all packets captured in both hex and ascii.
• -vv - Print verbose information.
• -s 1024 – capture at least 1024 bytes per packet – in the case of bootp it’s larger than required.
• “portrange 67-68” the last part of the command is an expression that tells tcpdump what kind of
data to capture (the default is to capture everything). The manual page for tcpdump contains more
information about expressions.
In this case because we’re only capturing a few packets of data we won’t send the output to a file, if you
send the captured packets to stdout when capturing large numbers of packets some packets may be dropped
by tcpdump.
The captured traffic looks like:

tcpdump: listening on lan0, link-type EN10MB (Ethernet), capture size 1024
bytes
13:48:40.591769 IP (tos 0x0, ttl 16, id 24223, offset 0, flags [none], proto:
UDP (17), length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP,
Request from 3a:e2:53:da:c6:1a, length 548, xid 0xf1c40000, secs 38, Flags
[ Broadcast ] (0x8000)
Client-Ethernet-Address 3a:e2:53:da:c6:1a
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
MSZ Option 57, length 2: 1472
Parameter-Request Option 55, length 35:
Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
IEN-Name-Server, Domain-Name-Server, Hostname, BS
41
We are running this command on the Ignite server or boot helper that is replying to the booting client, if
we were to run it on another system we might see the client broadcast message but we would not see the
reply in a switched environment.
Domain-Name, RP, EP, RSZ

TTL, BR, YD, YS
NTP, Vendor-Option, Requested-IP, Lease-Time
Server-ID, RN, RB, Vendor-Class
TFTP, BF, GUID, Option 128
Option 129, Option 130, Option 131, Option 132
Option 133, Option 134, Option 135
GUID Option 97, length 17:
0.86.61.25.201.105.211.220.17.184.0.0.21.96.4.53.170
NDI Option 94, length 3: 1.3.16
ARCH Option 93, length 2: 2
Vendor-Class Option 60, length 32:
"PXEClient:Arch:00002:UNDI:003016"
0x0000: ffff ffff ffff 3ae2 53da c61a 0800 4500 ......:.S.....E.
0x0010: 0240 5e9f 0000 1011 4a0f 0000 0000 ffff .@^.....J.......
0x0020: ffff 0044 0043 022c 7dc7 0101 0600 f1c4 ...D.C.,}.......
0x0030: 0000 0026 8000 0000 0000 0000 0000 0000 ...&............
0x0040: 0000 0000 0000 3ae2 53da c61a 0000 0000 ......:.S.......
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0110: 0000 0000 0000 6382 5363 3501 0139 0205 ......c.Sc5..9..
0x0120: c037 2301 0203 0405 060c 0d0f 1112 1617 .7#.............
0x0130: 1c28 292a 2b32 3336 3a3b 3c42 4361 8081 .()*+236:;<BCa..
0x0140: 8283 8485 8687 6111 0056 3d19 c969 d3dc ......a..V=..i..
0x0150: 11b8 0000 1560 0435 aa5e 0301 0310 5d02 .....`.5.^....].
0x0160: 0002 3c20 5058 4543 6c69 656e 743a 4172 ..<.PXEClient:Ar
0x0170: 6368 3a30 3030 3032 3a55 4e44 493a 3030 ch:00002:UNDI:00
0x0180: 3330 3136 ff00 0000 0000 0000 0000 0000 3016............
…
13:48:40.959883 IP (tos 0x0, ttl 1, id 4, offset 0, flags [DF], proto: UDP
(17), length: 576) 10.1.1.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP,
Reply, length 548, xid 0xf1c40000, Flags [ Broadcast ] (0x8000)
Your-IP 10.1.1.204
Server-IP 10.1.1.1
sname "vm010"
file "/opt/ignite/boot/nbp.efi"
DHCP-Message Option 53, length 1: Offer
Lease-Time Option 51, length 4: 300
Server-ID Option 54, length 4: 10.1.1.1
Subnet-Mask Option 1, length 4: 255.0.0.0
RN Option 58, length 4: 3
RB Option 59, length 4: 3
0x0000: ffff ffff ffff 72c4 0ccf 7426 0800 4500 ......r...t&..E.
0x0010: 0240 0004 4000 0111 6ca8 0a01 0101 ffff .@..@...l.......
0x0020: ffff 0043 0044 022c fd41 0201 0600 f1c4 ...C.D.,.A......
0x0030: 0000 0000 8000 0000 0000 0a01 01cc 0a01 ................
0x0040: 0101 0000 0000 3ae2 53da c61a 0000 0000 ......:.S.......
0x0050: 0000 0000 0000 766d 3031 3000 0000 0000 ......vm010.....
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 2f6f 7074 2f69 676e 6974 ....../opt/ignit
0x00a0: 652f 626f 6f74 2f6e 6270 2e65 6669 0000 e/boot/nbp.efi..
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0110: 0000 0000 0000 6382 5363 3501 0233 0400 ......c.Sc5..3..
0x0120: 0001 2c36 040a 0101 0101 04ff 0000 003a ..,6...........:
0x0130: 0400 0000 033b 0400 0000 03ff ffff ffff .....;..........
…
DHCP-Message Option 53, length 1: Request
TTL, BR, YD, YS
0.86.61.25.201.105.211.220.17.184.0.0.21.96.4.53.170
Requested-IP Option 50, length 4: 10.1.1.204
0x0010: 0240 3df3 0000 1011 6abb 0000 0000 ffff .@=.....j.......
0x0020: ffff 0044 0043 022c fcef 0101 0600 f1c4 ...D.C.,........
0x0030: 0000 0026 8000 0000 0000 0000 0000 0000 ...&............
0x0040: 0000 0000 0000 3ae2 53da c61a 0000 0000 ......:.S.......
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0110: 0000 0000 0000 6382 5363 3501 0339 0205 ......c.Sc5..9..
0x0120: c037 2301 0203 0405 060c 0d0f 1112 1617 .7#.............
0x0130: 1c28 292a 2b32 3336 3a3b 3c42 4361 8081 .()*+236:;<BCa..
0x0140: 8283 8485 8687 6111 0056 3d19 c969 d3dc ......a..V=..i..
0x0150: 11b8 0000 1560 0435 aa5e 0301 0310 5d02 .....`.5.^....].
0x0170: 6368 3a30 3030 3032 3a55 4e44 493a 3030 ch:00002:UNDI:00
0x0180: 3330 3136 3204 0a01 01cc 3604 0a01 0101 30162.....6.....
...
Your-IP 10.1.1.204
Server-IP 10.1.1.1
sname "vm010"
DHCP-Message Option 53, length 1: ACK
0x0010: 0240 0005 4000 0111 6ca7 0a01 0101 ffff .@..@...l.......
0x0020: ffff 0043 0044 022c fa41 0201 0600 f1c4 ...C.D.,.A......
0x0030: 0000 0000 8000 0000 0000 0a01 01cc 0a01 ................
0x0040: 0101 0000 0000 3ae2 53da c61a 0000 0000 ......:.S.......
0x0050: 0000 0000 0000 766d 3031 3000 0000 0000 ......vm010.....
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 2f6f 7074 2f69 676e 6974 ....../opt/ignit
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0110: 0000 0000 0000 6382 5363 3501 0533 0400 ......c.Sc5..3..
0x0120: 0001 2c36 040a 0101 0101 04ff 0000 003a ..,6...........:
0x0130: 0400 0000 033b 0400 0000 03ff ffff ffff .....;..........
…
We can immediately draw conclusions about the traffic, we can see that it’s a full DHCP conversation from
the DHCP message options in the packets:

Note that in all of the replies from the server no DHCP class-id is ever returned to the booting client
because of the ncid option in the DHCP device group (this was discussed earlier – since HP-UX does not
have a PXE proxy server the class-id cannot be sent back, if it is the PXE client will attempt to talk to the
PXE proxy – that will fail and the network boot will end in error) (an example of this is presented here
“Booting the system and capturing the initial PXE traffic (full PXE)”).
Everything else the system needs to boot is supplied in that packet. Next we’ll look at what happens when
bootp is used instead of DHCP (we’ll keep using the entry in /etc/bootptab for the rest of this section).
Important: If you respond to anonymous Itanium PXE boot requests using a DHCP device group you
should ensure “is_net_info_temporary” is not set to FALSE in the install filesystem (see instl_adm(1m)).
Setting “is_net_info_temporary” to FALSE will cause Ignite-UX to use the temporary information gained
via DHCP permanently on this system unless you change the information in itool. By default Ignite-UX
will not attempt to use the information gained via DHCP permanently (the default is TRUE).
Booting the system and capturing the initial PXE traffic (bootp)
For this example of booting using bootp the following was configured into /etc/bootptab:
ignite-defaults:\
ht=ethernet:\
hn:\
bf=/opt/ignite/boot/nbp.efi:\
bs=48
vm011:\
tc=ignite-defaults:\
ha=3ae253dac61a:\
ip=10.1.1.240:\
sm=255.0.0.0
The ignite-defaults settings were present already and the vm011 entry was added. Now we will capture the
initial network boot when the client system gets its IP address.

bytes
TTL, BR, YD, YS
0.86.61.25.201.105.211.220.17.184.0.0.21.96.4.53.170
0x0010: 0240 5e9f 0000 1011 4a0f 0000 0000 ffff .@^.....J.......
0x0020: ffff 0044 0043 022c 7de9 0101 0600 f1c4 ...D.C.,}.......
0x0030: 0000 0004 8000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 0000 3ae2 53da c61a 0000 0000 ......:.S.......
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0110: 0000 0000 0000 6382 5363 3501 0139 0205 ......c.Sc5..9..
0x0120: c037 2301 0203 0405 060c 0d0f 1112 1617 .7#.............
0x0130: 1c28 292a 2b32 3336 3a3b 3c42 4361 8081 .()*+236:;<BCa..
0x0140: 8283 8485 8687 6111 0056 3d19 c969 d3dc ......a..V=..i..
0x0150: 11b8 0000 1560 0435 aa5e 0301 0310 5d02 .....`.5.^....].
0x0170: 6368 3a30 3030 3032 3a55 4e44 493a 3030 ch:00002:UNDI:00
0x0180: 3330 3136 ff00 0000 0000 0000 0000 0000 3016............
...
Your-IP 10.1.1.240
Server-IP 10.1.1.1
sname "vm010"
Hostname Option 12, length 5: "vm011"
BS Option 13, length 2: 24576
0x0010: 0240 0006 4000 0111 6ca6 0a01 0101 ffff .@..@...l.......
0x0020: ffff 0043 0044 022c 27ad 0201 0600 f1c4 ...C.D.,'.......
0x0030: 0000 0000 8000 0000 0000 0a01 01f0 0a01 ................
0x0040: 0101 0000 0000 3ae2 53da c61a 0000 0000 ......:.S.......
0x0050: 0000 0000 0000 766d 3031 3000 0000 0000 ......vm010.....
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 2f6f 7074 2f69 676e 6974 ....../opt/ignit
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0110: 0000 0000 0000 6382 5363 3501 0233 04ff ......c.Sc5..3..
0x0120: ffff ff36 040a 0101 0101 04ff 0000 000c ...6............
0x0130: 0576 6d30 3131 0d02 6000 ffff ffff ffff .vm011..`.......
...

TTL, BR, YD, YS
0.86.61.25.201.105.211.220.17.184.0.0.21.96.4.53.170
0x0010: 0240 3df3 0000 1011 6abb 0000 0000 ffff .@=.....j.......
0x0020: ffff 0044 0043 022c fced 0101 0600 f1c4 ...D.C.,........
0x0030: 0000 0004 8000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 0000 3ae2 53da c61a 0000 0000 ......:.S.......
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0110: 0000 0000 0000 6382 5363 3501 0339 0205 ......c.Sc5..9..
0x0120: c037 2301 0203 0405 060c 0d0f 1112 1617 .7#.............
0x0130: 1c28 292a 2b32 3336 3a3b 3c42 4361 8081 .()*+236:;<BCa..
0x0140: 8283 8485 8687 6111 0056 3d19 c969 d3dc ......a..V=..i..
0x0150: 11b8 0000 1560 0435 aa5e 0301 0310 5d02 .....`.5.^....].
0x0170: 6368 3a30 3030 3032 3a55 4e44 493a 3030 ch:00002:UNDI:00
0x0180: 3330 3136 3204 0a01 01f0 3604 0a01 0101 30162.....6.....
0x0190: ff00 0000 0000 0000 0000 0000 0000 0000 ................
...
Your-IP 10.1.1.240
Server-IP 10.1.1.1
sname "vm010"
Hostname Option 12, length 5: "vm011"
BS Option 13, length 2: 24576
0x0010: 0240 0007 4000 0111 6ca5 0a01 0101 ffff .@..@...l.......
0x0020: ffff 0043 0044 022c 24ad 0201 0600 f1c4 ...C.D.,$.......
0x0030: 0000 0000 8000 0000 0000 0a01 01f0 0a01 ................
0x0040: 0101 0000 0000 3ae2 53da c61a 0000 0000 ......:.S.......
0x0050: 0000 0000 0000 766d 3031 3000 0000 0000 ......vm010.....
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 2f6f 7074 2f69 676e 6974 ....../opt/ignit
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0110: 0000 0000 0000 6382 5363 3501 0533 04ff ......c.Sc5..3..
0x0120: ffff ff36 040a 0101 0101 04ff 0000 000c ...6............
0x0130: 0576 6d30 3131 0d02 6000 ffff ffff ffff .vm011..`.......
...
It is still a DHCP conversation even though we configured the entry in /etc/bootptab. The main differences
are:
1. The lease time is 4294967295 42 seconds instead of 300. The DHCP device group we created
previously gave a specific lease time of 300 seconds with bootp you cannot give a lease time since
the IP address is tied to a MAC address and the IP address is permanent.
2. No DHCP class-id is returned because the entry satisfying the request is from /etc/bootptab.
In the section on network booting HP9000 systems (“Gaining an IP address”) you will see that a bootp
response only takes one packet since HP9000 systems only use bootp when network booting not DHCP.
The files downloaded for booting (part 1)
At this point we’re only going to look at the files that are downloaded to get to the loader menu:
2. Exit Boot Loader
Because we want to capture a lot of traffic on port 69 (the port that tftp uses) we’re going to sent the output
into a file to try to make sure that we capture as much of the network traffic as possible. The command
we’re going to use is:
# /usr/sbin/tcpdump -i 1 -nXX -s 128 -vv host 10.1.1.240 > /var/tmp/output.full

2>&1

1.lan0

• -vv – very verbose output (some packet contents decoded)
42
4294967295 is 2^32-1 which is the largest unsigned value that can fit into a 32bit unsigned integer.
• -s 128 – capture at least 128 bytes per packet – since we’re capturing tftp traffic we’re only
interested in the header information not in the actual data being tftp’ed.
• “host 10.1.1.240” the last part of the command is an expression that tells tcpdump what kind of
data to capture (the default is to capture everything). The manual page for tcpdump contains more
information about expressions. In this case we need to capture everything going to and from the
host as the tftp data send back from the Ignite server does not use any well known port 43.
We can immediately determine the files accessed via tftp by grep’ing the output for file “RRQ”:
# grep RRQ /var/tmp/output.full

UDP (17), length: 74) 10.1.1.240.2117 > 10.1.1.1.69: [udp sum ok] 46 RRQ
"/opt/ignite/boot/nbp.efi" octet blksize 8192
"/opt/ignite/boot/hpux.efi" octet blksize 512 tsize 0
"/opt/ignite/boot/hpux.efi" octet blksize 8192
"/opt/ignite/boot/fpswa.efi" octet blksize 512 tsize 0
"/opt/ignite/boot/fpswa.efi" octet blksize 8192
"/opt/ignite/boot/AUTO" octet blksize 512 tsize 0
"/opt/ignite/boot/AUTO" octet blksize 512
So the files being downloaded are /opt/ignite/boot/nbp.efi (which initiates the network boot),
/opt/ignite/boot/hpux.efi (the boot loader), /opt/ignite/boot/fpswa.efi (floating point software assist), and
/opt/ignite/boot/AUTO (which contains the instructions on what the boot loader needs to do).
Apart from nbp.efi you’ll notice that every file access is actually a combination of two:
43
An alternative would have been to continue using the DHCP device group in /etc/dhcptab and use the
condition "(ether src 3a:e2:53:da:c6:1a) or (ether src 72:C4:0C:CF:74:26)" to capture all packets sent from
our client or server MAC addresses to filter on (Note that on a busy system this might capture a lot of
traffic from the server).
"/opt/ignite/boot/hpux.efi" octet blksize 8192
The first file access is actually very short:
0x0000: 72c4 0ccf 7426 3ae2 53da c61a 0800 4500 r...t&:.S.....E.
0x0010: 0052 ae47 0000 1011 e561 0a01 01f0 0a01 .R.G.....a......
0x0020: 0101 0846 0045 003e 53fa 0001 2f6f 7074 ...F.E.>S.../opt
0x0030: 2f69 676e 6974 652f 626f 6f74 2f68 7075 /ignite/boot/hpu
0x0040: 782e 6566 6900 6f63 7465 7400 626c 6b73 x.efi.octet.blks
0x0050: 697a 6500 3531 3200 7473 697a 6500 3000 ize.512.tsize.0.
15:06:39.835191 IP (tos 0x0, ttl 64, id 43018, offset 0, flags [DF], proto:
UDP (17), length: 55) 10.1.1.1.57479 > 10.1.1.240.2118: [udp sum ok] UDP,
length 27
0x0000: 3ae2 53da c61a 72c4 0ccf 7426 0800 4500 :.S...r...t&..E.
0x0010: 0037 a80a 4000 4011 7bb9 0a01 0101 0a01 .7..@.@.{.......
0x0020: 01f0 e087 0846 0023 1ccd 0006 626c 6b73 .....F.#....blks
0x0030: 697a 6500 3531 3200 7473 697a 6500 3635 ize.512.tsize.65
0x0040: 3430 3235 00 4025.
length 5
0x0010: 0021 ad29 0000 1011 e6b0 0a01 01f0 0a01 .!.)............
0x0020: 0101 0846 e087 000d 0007 0005 0008 0000 ...F............
0x0030: 0000 0000 0000 0000 0000 0000 ............
We don’t decode the tftp packets directly but notice in the second packet you will see that after the “tsize.”
the size of the file is returned:
# ll hpux.efi
-r--r--r-- 1 bin bin 654025 Feb 16 2007 hpux.efi
All of the tftp RRQ requests that you see going from the client to the server that have tsize in them are
asking for the size of the file. Note that if the tftpd daemon on the system does not support this option (it’s
supported from 11.11 with patches and from first release on 11.23 and 11.31) the full file will be
downloaded twice 44 – the first time to get the size of the file and the second time to actually download the
file.
So get to the loader menu:
2. Exit Boot Loader
The EFI lanboot command downloaded nbp.efi and set it running, it then downloaded hpux.efi (the kernel
loader) and fpswa.efi (to handle floating point traps in software since EFI does not handle them) and sets
hpux.efi running. The AUTO file (/opt/ignite/boot/AUTO) is read multiple times and the loader menu (see
44
It is possible to disable tsize support in tftpd but it’s not recommend as some of the files (e.g. the install
kernel and filesystem) are quite large disabling tsize support will mean those large files will be downloaded
twice instead of once leading to increased network boot times. Some versions of HPVM also contain an
EFI defect where downloading the file to calculate the size does not determine the correct file size causing
a network boot attempt to fail.
above is shown) the output on the screen shows that the AUTO file has been downloaded 3 times as
indicated by the network trace:

...
The files downloaded for booting (part 2)
From this step we’re going to look at what happens after we choose to boot the 11.31 install kernel via the
loader menu:
2. Exit Boot Loader
To do that we’re going to use the same command as before:
# /usr/sbin/tcpdump -i 1 -nXX -s 128 -vv host 10.1.1.240 > /var/tmp/output.full

2>&1
When running the network boot the output after selecting the target kernel was:

Obtaining size of Rel_B.11.31/IINSTALL (42902098 bytes)
Downloading file Rel_B.11.31/IINSTALL (42902098 bytes)
> System Memory = 4087 MB
loading section 0
................................................................................
............ (complete)
loading section 1
............... (complete)
Obtaining size of Rel_B.11.31/IINSTALLFS (61341696 bytes)
Downloading file Rel_B.11.31/IINSTALLFS (61341696 bytes)
loading ram disk file (Rel_B.11.31/IINSTALLFS).
................................................................................
.....................................
(complete)
Launching Rel_B.11.31/IINSTALL
This is the result (just the RRQ lines) from tcpdump showing the files downloaded by the loader:
"/opt/ignite/boot/Rel_B.11.31/IINSTALL" octet blksize 512 tsize 0
"/opt/ignite/boot/Rel_B.11.31/IINSTALL" octet blksize 8192
"/opt/ignite/boot/Rel_B.11.31/IINSTALLFS" octet blksize 512 tsize 0
"/opt/ignite/boot/Rel_B.11.31/IINSTALLFS" octet blksize 8192
So we can see the AUTO file being downloaded again followed by the 11.31 install kernel and filesystem.
After that is complete the kernel is set running.
Note in the decoded packets that the block size option to tftpd is different.
"/opt/ignite/boot/Rel_B.11.31/IINSTALL" octet blksize 8192
The implementation of tftp has the tftp server sending the block number and the tftp client acknowledging
that blocks have been received. The block number is a 16 bit number allowing for a maximum of 65535
blocks. With a 512 byte block size this limits the size of a file to just under 32MiB for the maximum file
size. With larger files you can see that the block size used is larger to enable the transfer of larger files
using tftp.
Booting the system and capturing the initial PXE traffic (full PXE)
In this last example we’re going to look at an incorrect DHCP device group that sends the Itanium PXE
DHCP class-id back to the client to see what happens (the entry in /etc/boottab has been commented out for
this example). The DHCP device group we will be using looks like:
dhcp_device_group:\
re:\
# ncid:\
class-id="PXEClient:Arch:00002":\
lease-time=300:\
subnet-mask=255.0.0.0:\
addr-pool-start-address=10.1.1.200:\
addr-pool-last-address=10.1.1.210:\
bf=/opt/ignite/boot/nbp.efi
In this example we’re going to use the following tcpdump command:
# /usr/sbin/tcpdump -i 1 -nXXvv -s 1024 "(ether src 3a:e2:53:da:c6:1a) or

(ether src 72:C4:0C:CF:74:26)" > /var/tmp/output.full 2>&1
In this case we capture all traffic on the interface so we need to use the expression "(ether src
3a:e2:53:da:c6:1a) or (ether src 72:C4:0C:CF:74:26)" since we want to capture all of the packets sent by
either system 45. When booting the following is seen on the console output:
Shell> lanboot
45
Because we know what is going to happen in advance the client will be sending traffic on ports other
than 67 and 68 as it’s going to attempt a full PXE conversation with the server. It will also be receiving
ICMP packets and we want to see those packets.
Running LoadFile()

DHCP.................
PXE-E16: Valid PXE offer not received.
Exit status code: Invalid Parameter
We’ll only show the information decoded by tcpdump not the actual data from the packets. The first packet
sent out by the booting client is one we’ve seen before it’s a DHCP discover packet:
TTL, BR, YD, YS
0.86.61.25.201.105.211.220.17.184.0.0.21.96.4.53.170
Then we have a response (a DHCP offer) from the Ignite server to the booting client, note that because we
commented out the ncid option the DHCP device group this response contains the same DHCP class-id that
was sent out in the DHCP discover.
Your-IP 10.1.1.210
Server-IP 10.1.1.1
sname "vm010"
The next packets are the DHCP request and ack packets. The ack response from the server contains the
DHCP class-id set by the client.
TTL, BR, YD, YS
0.86.61.25.201.105.211.220.17.184.0.0.21.96.4.53.170
Your-IP 10.1.1.210
Server-IP 10.1.1.1
sname "vm010"
The next packet sent by the client however is not one that we’ve seen before:
length 548
ICMP (1), length: 112) 10.1.1.1 > 10.1.1.210: ICMP 10.1.1.1 udp port 4011
unreachable, length 92
What is happening? Because the DHCP replies from the server returned the Itanium PXE class id the server
is assumed to be running a PXE proxy server on UDP port 4011. The PXE proxy server can be used to
return additional information that the client requires to boot. Since HP-UX does not come with a PXE
proxy server attempts to send UDP packets to port 4011 on the server get an ICMP message indicating that
the port is unreachable, in this specific case there is nothing listening on the port.
The client attempts to send a UDP packet to the same port twice more before giving up:
length 548
length 548
In the test that produced this output the client started over 4 more times before giving up. That is it started
the DHCP conversation from scratch (discover, offer, accept, and ack) and then attempts to contact UDP
port 4011 to talk to a PXE proxy server.
Until HP-UX gets a PXE proxy server attempting a full PXE boot to a HP-UX system (running HP
supported software) will always fail.
Booting the system and getting a response that firmware doesn’t like
In this example we’re going to look at an issue that EFI really does not like. To do this however we need to
have the HPVM guest containing the Ignite server have a second LAN interface 46. The guest needs to be
rebooted to add the second interface.
# hpvmmodify -P vm010 -a network:lan::vswitch:private
The Ignite server is using the entry in /etc/bootptab created earlier in this example. An IP address has been
configured on the new LAN interface so we have two different interfaces both connected to the same
network:
# ifconfig lan0
lan0: flags=1843<UP,BROADCAST,RUNNING,MULTICAST,CKO>
inet 10.1.1.1 netmask ffff0000 broadcast 10.1.255.255
# ifconfig lan1
lan1: flags=1843<UP,BROADCAST,RUNNING,MULTICAST,CKO>
inet 10.1.1.2 netmask ffff0000 broadcast 10.1.255.255
Now we can boot the other HPVM guest from this Ignite server:
Shell> lanboot
Running LoadFile()

Running LoadFile()
TFTP...|
PXE-E18: Timeout. Server did not respond.
46
This isn’t strictly required the same issue can happen when using stacked IP addresses on a LAN
interface (e.g. using lan0:1).
When we do this it fails to boot, we can see that the DHCP part of the process worked – we did gain an IP
address however the tftp failed (it’s attempting to download the boot file from the DHCP/bootp response).
To work out why we’re going to need to do it again and capture all of the traffic between the two systems
using the following (this would attempt to capture all traffic that appeared coming into this system):
# /usr/sbin/tcpdump -i 1 -nXX -s 128 –vv > /var/tmp/output.full 2>&1
With this tcpdump command we can see the incoming tftp requests from the client but there was no
response captured:
0x0010: 004a e257 0000 1011 b159 0a01 01f0 0a01 .J.W.....Y......
0x0020: 0101 6ba5 0045 0036 f74e 0001 2f6f 7074 ..k..E.6.N../opt
0x0030: 2f69 676e 6974 652f 626f 6f74 2f6e 6270 /ignite/boot/nbp
0x0040: 2e65 6669 006f 6374 6574 0062 6c6b 7369 .efi.octet.blksi
0x0050: 7a65 0038 3139 3200 ze.8192.
0x0010: 004a a938 0000 1011 ea78 0a01 01f0 0a01 .J.8.....x......
0x0020: 0101 6ba6 0045 0036 f74d 0001 2f6f 7074 ..k..E.6.M../opt
0x0050: 7a65 0038 3139 3200 ze.8192.
0x0010: 004a c69c 0000 1011 cd14 0a01 01f0 0a01 .J..............
0x0020: 0101 6ba7 0045 0036 f74c 0001 2f6f 7074 ..k..E.6.L../opt
0x0050: 7a65 0038 3139 3200 ze.8192.
Of course this system has another interface now so we’d better have a look at the traffic on it as well (note
the –i 2 to trace the network on the second interface):
# /usr/sbin/tcpdump -i 2 -nXX -s 128 -vv > /var/tmp/output.full 2>&1
Now we can see the responses 47:
length 15
0x0000: 3ae2 53da c61a 4256 4ef1 e4c3 0800 4500 :.S...BVN.....E.
0x0010: 002b 817f 4000 4011 a24f 0a01 0102 0a01 .+..@.@..O......
0x0020: 01f0 c3a2 33f1 0017 e374 0006 626c 6b73 ....3....t..blks
0x0030: 697a 6500 3831 3932 00 ize.8192.
47
These packets have a different timestamp since the command was run a second time while another
network boot was attempted.
length 15
0x0000: 3ae2 53da c61a 4256 4ef1 e4c3 0800 4500 :.S...BVN.....E.
0x0010: 002b 8180 4000 4011 a24e 0a01 0102 0a01 .+..@.@..N......
0x0020: 01f0 c3a2 33f1 0017 e374 0006 626c 6b73 ....3....t..blks
0x0030: 697a 6500 3831 3932 00 ize.8192.
So what’s happening? The traffic is coming in one interface and going out the other! The tftp protocol uses
UDP as its transport. Unless you specifically set an IP address that the packet needs to be sent from the
kernel will automatically set the source IP address based on the current routing information in the kernel. In
this particular case it means that although the tftp packets come in one interface because we have two
interfaces on the same network responses can go back out a different interface.
This issue affects systems that have more than one lan interface on the one network segment and systems
that use stacked IP addresses, for example an interface lan0:1, this includes Serviceguard clusters as
package IP addresses are implemented this way. This issue does not impact systems that are multi-homed
and have different lan interfaces on different networks.
The good news is that this has an easy method to resolve it, you need only change the following entry in
/etc/inetd.conf from 48:
tftp dgram udp wait root /usr/lbin/tftpd tftpd\

/opt/ignite\
/var/opt/ignite
To:
tftp dgram udp wait root /usr/lbin/tftpd tftpd -s\

/opt/ignite\
/var/opt/ignite
The –s option tells tftpd to send any tftp responses back using the IP address that they were sent to. Don’t
forget to run “inetd –c” to get inetd to re-read the configuration file.
Important: If you change /etc/inetd.conf even though inetd will have re-read /etc/inetd.conf tftpd will
continue to run from previous invocations. Until the old one times out and dies inetd will not start a new
one with the new options (e.g. like after adding –s above). If you change the options to tftpd check to see if
any tftpd daemons are running and if there are kill them.
Note that as the following console output from lanboot shows when booting the client over the network
either interface on the LAN can respond. It just depends which LAN interface receives the packet first and
how quickly it makes it through the kernel to bootpd.
Shell> lanboot
Running LoadFile()

Running LoadFile()
...
48
These are example default tftp entries after Ignite-UX has been installed, it is possible another system
may have other entries but you only should add the –s option do not modify the tftp directories without
understanding the reason for doing so.
Shell> lanboot
Running LoadFile()

Running LoadFile()
...
tftpd errors
In this case it’s pretty easy to determine the cause of the problem so there’s no need to troubleshoot the
issue in great depth (so no network trace):
Shell> lanboot
Running LoadFile()

Running LoadFile()
TFTP.
PXE-E22: Client received ICMP error from server.
PXE-E98: Type: 3h Code: 3h Port unreachable
The Ignite server will have sent back an ICMP message indicating that the port unreachable in response to
the tftp traffic directed to the port that tftpd would normally be configured on. Although inetd actually
listens on the port when it’s been enabled in /etc/inetd.conf and starts tftpd as required.
If we set tftpd back running again we can simulate some other errors, we’ll be looking at two of them to see
how the different errors appear on the console. The first is a permissions issue with the
/opt/ignite/boot/AUTO file:
Shell> lanboot
Running LoadFile()

Running LoadFile()
TFTP..

All rights reserved
Booting from Lan

Obtaining size of AUTO (failed)
Downloading file AUTO
TFTP session failed. (reason:TFTP Error)
Error Code: 2, Error Str: Access violation
Note that in this case you will be left at the boot loader prompt not the EFI shell prompt
HPUX> exit
Exiting bootloader.
Shell>
We can see that there was a tftp error and Access Violation is what you’d get as an error message from the
HP-UX tftp program as well. Obtaining the size of the AUTO file is what failed so it would be the first
thing you checked if you saw the above messages.
The next problem we’ll look at is one of the files required for the network booting (hpux.efi) is missing:
Shell> lanboot
Running LoadFile()

Running LoadFile()
TFTP..
TFTP failed due to - 0x8000000000000017
Error Code - 1
Error Str - File not found
From the message it should be obvious that a file appears to be missing. We already know what files are
involved in network booting a HP Integrity server and it’s not going to be nbp.efi (as that was running) and
there are only a few other files to check.
The following error can only be seen when network booting HPVM guest systems from Ignite servers that
do not support the tftpd tsize option (or servers that have disabled the option). This defect does not exist in
physical HP Integrity servers. From older versions of HPVM you may see something like:
Shell> lanboot
Running LoadFile()
TFTP..
PXE-E05: Download buffer is smaller than requested file.
Or, from newer versions of firmware:
Shell> lanboot

Running LoadFile()

Running LoadFile()
TFTP..
TFTP failed due to - 0x8000000000000004
Note that the errors here are only here to illustrate issues that you might see. A real problem could look
completely different.
With the information presented in this section you understand the files that are accessed and download as as
part of a network boot of a HP Integrity server. You should be capable of looking for any obvious problems
to do with accessing those files from the booting client. You should also feel confident enough to look at a
network trace and see if you can determine what the problem is via the network trace.
If you ever need to manually decode the contents of TCP/IP packets for different protocols the following
book is an excellent reference “TCP/IP Illustrated, Volume 1”, W Richard Stevens, ISBN 0-201-63346-9.
Note that the book was first printed in 1994 and only addresses IPv4 and does not discuss IPv6.
Alternatively you can look at the contents of RFC 1350 (http://www.ietf.org/rfc/rfc1350.txt) for more
information about the format of tftp packets.
Direct Boot Profiles (dbprofile)

Direct boot profiles allow some HP Integrity systems to boot over the network without any need for
DHCP/PXE/bootp support. All HP Integrity servers that support dbprofiles 49 should be able to show the
following help message for dbprofiles:
Shell> help dbprofile

Set up, remove or copy direct boot profiles
DBPROFILE [-dn name [-dhcp] [-sip server_ip] [-cip client_ip]

[-gip gateway_ip] [-m subnet_mask] [-b "boot_file"]
[-od "optional_data"]] | [rm name] | [cp src_name dst_name] | [-h]
-dn : Display/Create/Modify a db-profile

name : The db-profile name to access
-dhcp : A DHCP server will be used to get the client information
-sip : Set the static IP address for the boot server
server_ip : The static IP address for the boot server
-cip : Set the static IP address for the client
client_ip : The static IP address for the client
-gip : Set the static IP address for the gateway
gateway_ip : The static IP address for the gateway
-m : Set the subnet mask for the local network
subnet_mask : The subnet mask for the local network
-b : Load boot file from the boot server
"boot_file" : Full path to the boot file on the boot server
49
Direct boot profiles are not standard EFI functionality. Direct boot profiles are a HP extension to EFI
functionality. Direct boot profiles are not available on all HP Integrity servers.
-od : Pass optional command line arguments to the boot file

"optional_data" : Optional command line arguments to pass to the boot file
rm : Remove a db-profile
name : The db-profile to remove
cp : Copy a db-profile
src_name : Name of the source db-profile name
dst_name : Name of the destination db-profile name
Note:
1. A db-profile name can be at most 12 characters long, and spaces are
not allowed. If the db-profile name already exists, it will be
updated with the new values passed as arguments to this command.
2. If client IP information is missing in the db-profile, DHCP will be
used by default.
3. Only IPv4 is supported.
4. Use "" around the boot_file and optional_data fields.
Examples:
* To display settings in the db-profile(s):
Shell> dbprofile
OR
Shell> dbprofile -dn test
* To create and modify settings in a db-profile:

Shell> dbprofile -dn test -dhcp -sip 192.168.0.1 -m 255.255.255.0
Shell> dbprofile -dn test -b "/foo/bar/loader.efi" -od "-foo -bar"
* To copy a db-profile:
Shell> dbprofile cp test profile1
* To remove a db-profile:
Shell> dbprofile rm test
Direct boot profiles work in conjunction with the lanboot command where the –dn option is used to specify
a direct boot profile to use in conjunction with selecting a lan interface:
Shell> help lanboot

Perform boot over LAN using a default server or a directed boot profile
LANBOOT [select] [-od "optional_data"] | [-dn name]
select : Select from a list of available LAN devices

-od : Pass optional command line arguments to the boot file
"optional_data" : Optional command line arguments to pass to the boot file
-dn : Specify the db-profile name to use for the LAN boot
name : The db-profile name to access
Note:
1. Use 'select' when no default LAN device is provided, so a list
of available LAN devices will be provided for user selection.
2. Use '-od' to specify optional data to be passed to the boot file.
3. Use '-dn' to specify a Direct Boot Profile (db-profile) to be used
to handle the LAN boot. Use the 'dbprofile' command to create and
manage db-profiles.
Examples:
* To LAN boot from a boot server that has been previously setup:
Shell> lanboot
* To select MAC address to perform lan boot

Shell> lanboot select
01 Acpi(HWP0002,0)/Pci(3|0)/Mac(00306E1E1E2F)
02 Acpi(HWP0002,100)/Pci(2|0)/Mac(00306E1E1E18)

Selected Acpi(HWP0002,0)/Pci(3|0)/Mac(00306E1E1E2F)
* To specify optional data to be passed to the boot file that will

be loaded from the boot server:
Shell> lanboot -od "-foo -bar"
OR
Shell> lanboot select -od "-foo -bar"
* To perform a direct LAN boot using a previously created db-profile:

Shell> lanboot -dn profile1
OR
Shell> lanboot select -dn profile1
Some important things to note about dbprofiles:
1. If you do not have the client IP address defined in a direct boot profile, EFI will use DHCP instead
of the direct boot profile to start the boot process. Although if the direct boot profile uses the –b
option it will be used for the boot file in preference to anything received via DHCP.
2. If you supply the client IP address and the Ignite server is not on the same LAN segment you will
need to supply enough information (e.g. netmask, gateway, etc) for the client to talk to the Ignite
server.
3. If you have multiple LAN interfaces, you must choose the LAN interface that the direct boot
profile is applicable to. If you choose a LAN interface on a network that does not match your
dbprofile information, the client will fail to contact the Ignite-UX server.
4. The dbprofile command might exist on some platforms but not be supported to use. This applies to
HPVM A.03.50, the dbprofile command exists and you can create direct boot profiles however
they do not currently work. Direct boot profiles are expected to work in a future release of HPVM.
5. Some platforms may require firmware upgrades to fix issues to do with dbprofiles. For example
the following platforms all had dbprofile issues with Intel Gigabit Ethernet interfaces and
dbprofiles and these HP-UX B.11.23 patches 50 address the issues:
PHSS_37047 rx2620 System, BMC & iLO MP Firmware Patch

PHSS_37118 rx4640 System, BMC and MP Firmware Patch
PHSS_37144 rx16x0 System, BMC & MP Firmware Patch
Other systems may have other firmware fixes for direct boot profiles, please consult the release
notes for the latest revision of firmware for a platform to determine if there are any fixes available.
Now we’re going to look at some examples of using direct boot profiles. The first one is on a HPVM
system to show that it doesn’t work with HPVM A.03.50:
Shell> dbprofile -dn igtest -sip 10.1.1.1 -cip 10.1.1.250 -b

"/opt/ignite/boot/nbp.efi"
Creating profile igtest
Shell> lanboot -dn igtest
Running LoadFile()

DHCP..............
50
When you read this these patches may have been superceded. Check the latest patch to determine if there
are any dbprofile fixes for the platform you are using if you encounter issues with direct boot profiles.

This should have worked because the client IP address was given there should have been no need to use
DHCP to get any more information (any DHCP support for this system on the network was disabled before
running the lanboot command). This has been addressed in HPVM 4.0.
The following two tests were performed on an rx3600 system.
This first test supplies enough information to be able to directly contact the Ignite server (if it was not on
the same subnet we would need to give a gateway, the subnet mask given here (-m) is not actually needed).
This is the dbprofile command that was used:
Shell> dbprofile -dn igtest1 -sip 16.144.207.33 -cip 16.144.207.152 -m

255.255.255.0 -b "/opt/ignite/boot/nbp.efi"
Creating profile igtest
When we first attempt to do a lanboot EFI chooses which interface it will attempt to use. In this case that
network interface is not actually connected to a network, Because the network interface is not connected to
anything that returns a PXE error E12 because no network could be detected:
Shell> lanboot -dn igtest1

BC was not started.BC was not started.
Client MAC Address: 00 1A 4B 06 DF 7A BC was not started.
PXE-E12: Could not detect network connection. Check cable.
Note that this is different behavior to HPVM 51 where it always makes you select a lan interface even if
there is only one on the system. To select an interface outside of HPVM use the select option 52 to the
lanboot command.
Shell> lanboot select -dn igtest1

01 Acpi(HWP0002,PNP0A03,100)/Pci(1|0)/Pci(6|0)/Mac(001A4B0A828E)
02 Acpi(HWP0002,PNP0A03,100)/Pci(1|0)/Pci(6|1)/Mac(001A4B0A828F)
03 Acpi(HWP0002,PNP0A03,200)/Pci(1|0)/Pci(6|0)/Mac(0019BBEB9EFC)
04 Acpi(HWP0002,PNP0A03,200)/Pci(1|0)/Pci(6|1)/Mac(0019BBEB9EFD)
05 Acpi(HWP0002,PNP0A03,400)/Pci(2|0)/Mac(001A4B06DF7A)
06 Acpi(HWP0002,PNP0A03,400)/Pci(2|1)/Mac(001A4B06DF7B)
Selected Acpi(HWP0002,PNP0A03,100)/Pci(1|0)/Pci(6|0)/Mac(001A4B0A828E)
Client MAC Address: 00 1A 4B 0A 82 8E

Client IP Address: 16.144.207.152
Subnet Mask: 255.255.255.0
BOOTP Server IP Address: 16.144.207.33
DHCP Server IP Address: 0.0.0.0 53
Boot file name: /opt/ignite/boot/nbp.efi
Retrieving File Size.

Retrieving File (TFTP).
51
More accurately the behavior of HPVM is different to physical platforms. Don’t rely on the behaviour of
HPVM being different it may change to the same as physical platforms in the future.
52
The select option does work in HPVM but outside of HPVM lanboot may not prompt you to select a lan
interface without giving the select option (i.e. one will be choosen for you).
53
Note the DHCP server IP Address in the output displayed, it is 0.0.0.0 confirming that we never used a
DHCP server to gain networking information.


All rights reserved
Booting from Lan


3. Exit Boot Loader
In this next example we’re going to rely on there being a regular DHCP server on the network that doesn’t
provide PXE boot services. The direct boot profile here only provides the server IP address, says that
DHCP should be used to get IP address information and that the boot file will be "/opt/ignite/boot/nbp.efi".
Shell> dbprofile -dn igtest2 -sip 16.144.207.33 -dhcp -b

"/opt/ignite/boot/nbp.efi"
Creating profile igtest2
If we use lanboot to run with this direct boot profile you can see in the output below that we did use DHCP
but since we provided an explicit server IP address and boot file name that we’re using those instead.
Shell> lanboot select -dn igtest2

01 Acpi(HWP0002,PNP0A03,100)/Pci(1|0)/Pci(6|0)/Mac(001A4B0A828E)
02 Acpi(HWP0002,PNP0A03,100)/Pci(1|0)/Pci(6|1)/Mac(001A4B0A828F)
03 Acpi(HWP0002,PNP0A03,200)/Pci(1|0)/Pci(6|0)/Mac(0019BBEB9EFC)
04 Acpi(HWP0002,PNP0A03,200)/Pci(1|0)/Pci(6|1)/Mac(0019BBEB9EFD)
05 Acpi(HWP0002,PNP0A03,400)/Pci(2|0)/Mac(001A4B06DF7A)
06 Acpi(HWP0002,PNP0A03,400)/Pci(2|1)/Mac(001A4B06DF7B)
Selected Acpi(HWP0002,PNP0A03,100)/Pci(1|0)/Pci(6|0)/Mac(001A4B0A828E)
Client MAC Address: 00 1A 4B 0A 82 8E

Client IP Address: 16.144.207.152
Subnet Mask: 255.255.254.0
BOOTP Server IP Address: 16.144.207.33
DHCP Server IP Address: 16.238.57.250
Boot file name: /opt/ignite/boot/nbp.efi
Retrieving File Size.

Retrieving File (TFTP).

All rights reserved

Booting from Lan


3. Exit Boot Loader
Direct boot profiles can be significantly easier to use than setting up, configuring, and troubleshooting
DHCP/PXE/bootp issues although not all HP Integrity servers support them. 54
What PXE-E errors can you see?

Unfortunately there is no comprehensive list of PXE errors that can be seen on HP Integrity systems. A list
of potential errors and what they mean is not available.
The following list of PXE-E errors comes from a HPVM guest 55:
The following list contains some common errors from EFI in a HP VM guest:
The cause of this is usually a tftp timeout, or for some reason the server did not respond, or did not respond
in an expected manner, when EFI is attempting to load the boot file form the server in the bootp/DHCP
response. There are multiple reasons for this error, one example is presented here “Booting the system and
getting a response that firmware doesn’t like”.
The cause of this error can vary quite a lot. It also has a different meaning depending on how quickly it is
printed. If the message is printed after about 15-30 seconds the system did not receive any valid responses
to its PXE boot request. If message is printed more or less immediately a response was received but it could
not be used to continue to boot.
An example of an immediate failure is here “Booting the system and capturing the initial PXE traffic (full
PXE)”. When you see this error there is a problem in the setup of the DHCP/bootp support for booting
Itanium clients. It is possible that there may be an issue in the network environment.
PXE-E05: Download buffer is smaller than requested file.
This is most often caused by a firmware defect in HPVM guests. The code to download files using tftp in
earlier version of HPVM EFI firmware had a defect where it would calculate the size of the file wrong
when the tsize option was not available (since the tftpd would provide the file size working around the
firmware defect).
54
All partitionable systems, all zx2 based platforms, most Integrity blades, and future HP Integrity servers
should support dbprofiles (there may be some other HP Integrity systems that support dbprofiles that do not
fit into these categories). It is expected that HPVM will support them in a future release.
55
And it is possible that PXE errors may vary between systems.

Complete lab 6 (see “Lab exercise 6 – network booting a system”).
Network Booting – HP9000 systems

The format of a bootp packet
Before we can start to look at how the system gains an IP address we need to understand that for HP9000
systems the bootp protocol is used for this purpose. For your reference the bootp protocol uses the
following fixed format:
0 7 8 15 16 23 24 31
Opcode (1=Request, Hardware Type Hardware Address Hop Count
2=Response) (1=ethernet) Length (6 for ethernet)
Transaction ID
Number of Seconds (Unused)
Client IP Address
Your IP Address
Server IP Address
Gateway IP Address
Client Hardware Address (16 bytes)
Server Hostname (64 bytes)
Boot Filename (128 bytes)
Vendor Specific Information (64 bytes)
Gaining an IP address
The following section deals with the initial flow of traffic between a HP9000 system and its Ignite server or
boot helper. This step involves the firmware attempting to gain an IP address.
To see what happens we’re going to be looking at an environment with a rp8420 partition booting from an
Ignite server on the same network segment. We’re going to use tcpdump to capture the flow of network
traffic during the very first stages of boot when the firmware will attempt to get an IP address.
Note that tcpdump is not a standard HP-UX tool. It is an open-source program. Be careful when directing
the output of tcpdump to the screen, unless there is only a small amount of data to be printed tcpdump will
not be able to capture all of the traffic. When capturing large amounts of traffic the output should be sent to
a file instead.
The command used to boot will be:
Main Menu: Enter command or menu > boot lan 56 install
The tcpdump 57 command that we will use is:
56
HP9000 systems allow an optional IP address to the lan part of this command to allow you to select what
system you are willing to accept a reply to the boot request from.
57
We are running this command on the Ignite server or boot helper that is replying to the booting client, if
we were to run it on another system we might see the client broadcast message but we would not see the
reply in a switched environment.

1.lan0

• -vv - Print verbose information.
• -s 1024 – capture at least 1024 bytes per packet – in the case of bootp it’s larger than required.
• “portrange 1067-1068” the last part of the command is an expression that tells tcpdump what kind
of data to capture (the default is to capture everything). The manual page for tcpdump contains
more information about expressions.
Now we can have a look at the data we captured:

bytes
length 300
0x0000: ffff ffff ffff 0012 7995 5572 0800 4500 ........y.Ur..E.
0x0010: 0148 42c6 0000 2011 56e0 0000 0000 ffff .HB.....V.......
0x0020: ffff 042c 042b 0134 cff9 0101 0600 5bc0 ...,.+.4......[.
0x0030: 3c72 0003 0000 0000 0000 0000 0000 0000 <r..............
0x0040: 0000 0000 0000 0012 7995 5572 0000 0000 ........y.Ur....
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0110: 0000 0000 0000 6382 5363 0000 0000 0000 ......c.Sc......
0x0120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0150: 0000 0000 0000 ......
UDP (17), length: 328) 16.144.170.12.1067 > 16.144.170.14.1068: [udp sum ok]
UDP, length 300
0x0000: 0012 7995 5572 0012 7995 5589 0800 4500 ..y.Ur..y.U...E.
0x0010: 0148 7041 4000 4011 5429 1090 aa0c 1090 .HpA@.@.T)......
0x0020: aa0e 042b 042c 0134 17c3 0201 0600 5bc0 ...+.,.4......[.
0x0030: 3c72 0003 0000 0000 0000 1090 aa0e 1090 <r..............
0x0040: aa0c 1090 aa0c 0012 7995 5572 0000 0000 ........y.Ur....
0x0050: 0000 0000 0000 7361 6e69 7479 0000 0000 ......sanity....
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 2f6f 7074 2f69 676e 6974 ....../opt/ignit
0x00a0: 652f 626f 6f74 2f62 6f6f 745f 6c69 6600 e/boot/boot_lif.
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................

0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0110: 0000 0000 0000 6382 5363 ff00 0000 0000 ......c.Sc......
0x0120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0150: 0000 0000 0000 ......
2 packets captured
425 packets received by filter 58
0 packets dropped by kernel
Let’s look at the first packet. We’re not interested in the first part of the packet as it contains the ethernet
information, IP header, and UDP header.
0x0000: ffff ffff ffff 0012 7995 5572 0800 4500 ........y.Ur..E.
0x0010: 0148 42c6 0000 2011 56e0 0000 0000 ffff .HB.....V.......
0x0020: ffff 042c 042b 0134 cff9 ...,.+.4..
Now we can start to look at the contents. The first byte listed below, 01, is the opcode of the bootp request.
In this case 01 means this is a request not a reply, the 01 following that means that the hardware type for
the bootp request is ethernet. The next byte contains an 06 and it is the hardware address length for this
request (which has to be 6 for an ethernet request as that’s how many bytes long an ethernet MAC is).
That’s followed by the hop count (for a local network that will always be 0).
Following that is a 32bit transaction id (0x5bc03c72). After the transaction id is the number of seconds
since the system first started to attempt to boot (it is effectively unused in this situation). The only other
information supplied is the MAC address for the system (0x001279955572) and the vendor specific
information magic number (0x63825363).
0101 0600 5bc0 ....[.

0x0030: 3c72 0003 0000 0000 0000 0000 0000 0000 <r..............
0x0040: 0000 0000 0000 0012 7995 5572 0000 0000 ........y.Ur....
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0110: 0000 0000 0000 6382 5363 0000 0000 0000 ......c.Sc......
0x0120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0150: 0000 0000 0000 ......
The vendor specific information contains only the vendor specific information magic cookie and no vendor
specific information (see RFC1497 at http://tools.ietf.org/html/rfc1497 for more information).
The reply sent by the Ignite server contains more interesting information (like before we’re not going to be
looking at the ethernet information, IP header, or UDP header in the packet):
58
The expression used with the tcpdump acts as a filter, only two packets passed the expression so only two
packets were printed.

0x0000: 0012 7995 5572 0012 7995 5589 0800 4500 ..y.Ur..y.U...E.
0x0010: 0148 7041 4000 4011 5429 1090 aa0c 1090 .HpA@.@.T)......
0x0020: aa0e 042b 042c 0134 17c3 ...+.,.4..
In this bootp packet we can see that the first byte is 0x02 so we know that this is a bootp reply. The next 3
bytes are the same as what was in the client request. The transaction id is the same in the reply (and the two
bytes after it are unused.
0201 0600 5bc0 ....[.
0x0030: 3c72 0003 0000 <r....
The setting of client IP address is 0.0.0.0 and that is followed by your IP address (which is the IP address
the system that this response is being sent to should use for an IP address). Your IP address (0x1090aa0e) is
16.144.170.14. The server IP address (0x1090aa0c) is 16.144.170.12 (this is the Ignite server). The
gateway IP address being sent back is the same is the server IP. That is followed by the MAC address of
the client.
0000 0000 1090 aa0e 1090 ..........

0x0040: aa0c 1090 aa0c 0012 7995 5572 0000 0000 ........y.Ur....
0x0050: 0000 0000 0000 ......
Next we have the hostname of the server that responded to the request (64 bytes of data).
7361 6e69 7479 0000 0000 sanity....

0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 ......
That is followed by the name of the file that the system needs to start to download to perform the next stage
of the network boot.
2f6f 7074 2f69 676e 6974 /opt/ignit

0x00a0: 652f 626f 6f74 2f62 6f6f 745f 6c69 6600 e/boot/boot_lif.
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0110: 0000 0000 0000 ......
Lastly we have the vendor specific options. We still have the vendor specific options magic number and
that is followed by 0xff. The 0xff is an end field to indicate the end of data in this area of the reply. That
means that the reply had no vendor specific options set.
6382 5363 ff00 0000 0000 c.Sc......

0x0120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0150: 0000 0000 0000 ......
At this point the booting HP9000 system has an IP address and the name of the file that it needs to
download to continue the boot process.
Loading the boot LIF – Part 1 (ISL)

As the name of the title suggests the next thing that the system needs to do is something with the file that it
was told it should use to continue the boot process (/opt/ignite/boot/boot_lif). We can see from these
commands:
===============================================================
ISL -12800 16 242 0 07/07/30 21:48:53
AUTO -12289 264 2 0 07/07/30 21:48:53
HPUX -12928 272 1024 0 07/07/30 21:48:53
VERSION BIN 1296 1 0 07/07/30 21:49:06
# ll /opt/ignite/boot/boot_lif
-r--r--r-- 1 bin bin 332800 Aug 27 19:07 /opt/ignite/boot/boot_lif
That the size of the file is 332800 59 bytes long and it contains other files (for more information on the
format of a LIF file please review the manual page lif(4)).
The unit of size is 256 bytes, this can be determined by the following commands:
# lifcp /opt/ignite/boot/boot_lif:ISL - |wc -c

61952
The result of 61952/242 is 256. We can now see what happens when the system first attempts to use the file
to load the initial boot loader from the LIF. Again we use tcpdump to capture the packets exchanged
between the two systems (since we know the IP address we can limit the data we see to data from that IP
address):
# /usr/sbin/tcpdump -i 1 -n -s 2048 host 16.144.170.14

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lan0, link-type EN10MB (Ethernet), capture size 2048 bytes
16:25:24.621370 IP 16.144.170.14.8306 > 16.144.170.12.69: 516 RRQ
"/opt/ignite/boot/boot_lif"
16:25:24.622430 IP 16.144.170.12.49207 > 16.144.170.14.8306: UDP, length 516
16:25:24.622634 IP 16.144.170.14.8306 > 16.144.170.12.49207: UDP, length 4
16:25:24.622680 IP 16.144.170.12.49207 > 16.144.170.14.8306: UDP, length 516
16:25:24.622902 IP 16.144.170.14.8306 > 16.144.170.12.49207: UDP, length 4
…
Most of them have been removed but there were 132 packets transmitted from the Ignite server to the client.
In the UDP packets used by tftp there are 4 bytes that are part of the protocol at the beginning of the packet.
The actual data read with each reply from the server is 512 bytes.
The data for the LIF directory and the ISL program occupy the first 264 blocks of the LIF. That means we
can be sure that after reading the LIF directory the firmware continued and continued to read in all of the
ISL program from the LIF.
…
16:25:24.677788 IP 16.144.170.12.49208 > 16.144.170.14.9549: UDP, length 516
16:25:24.678008 IP 16.144.170.14.9549 > 16.144.170.12.49208: UDP, length 4
16:25:24.678057 IP 16.144.170.12.49208 > 16.144.170.14.9549: UDP, length 516
16:25:24.678274 IP 16.144.170.14.9549 > 16.144.170.12.49208: UDP, length 4
16:25:24.678322 IP 16.144.170.12.49208 > 16.144.170.14.9549: UDP, length 516
16:25:24.678975 IP 16.144.170.14.9549 > 16.144.170.12.49208: UDP, length 5
59
The size of this file may change from Ignite release to Ignite release depending on if any fixes are
incorporated into any of the files (HPUX and ISL).

Here we can’t actually tell what is happening because we never captured enough lower level information
about the packets. All we can tell is that we’re re-reading the boot file (there is another request for the
boot_lif again after this request which is not shown).
16:25:24.679098 IP 16.144.170.14.7771 > 16.144.170.12.69: 516 RRQ

16:25:24.680089 IP 16.144.170.12.49209 > 16.144.170.14.7771: UDP, length 516
16:25:24.680293 IP 16.144.170.14.7771 > 16.144.170.12.49209: UDP, length 4
16:25:24.680318 IP 16.144.170.12.49209 > 16.144.170.14.7771: UDP, length 516
16:25:24.680543 IP 16.144.170.14.7771 > 16.144.170.12.49209: UDP, length 4
16:25:24.680567 IP 16.144.170.12.49209 > 16.144.170.14.7771: UDP, length 516
16:25:24.680786 IP 16.144.170.14.7771 > 16.144.170.12.49209: UDP, length 4
16:25:24.680810 IP 16.144.170.12.49209 > 16.144.170.14.7771: UDP, length 516
…
We can however go back and get the data again in a more verbose form to find out what is happening here.
In the following output the –vv option was not used and the data collected limit to 128 bytes as we’re not
interested in the rest of the data:
17:41:14.526786 IP 16.144.170.14.63880 > 16.144.170.12.69: 516 RRQ

"/opt/ignite/boot/boot_lif""
0x0000: 0012 7995 5589 0012 7995 88a7 0800 4510 ..y.U...y.....E.
0x0010: 0220 83b9 0000 2011 9fc9 1090 aa0e 1090 ................
0x0020: aa0c f988 0045 020c 0dd7 0001 2f6f 7074 .....E....../opt
0x0030: 2f69 676e 6974 652f 626f 6f74 2f62 6f6f /ignite/boot/boo
0x0040: 745f 6c69 6600 6f63 7465 7400 fad0 0000 t_lif.octet.....
0x0050: 0000 0000 0000 3485 0002 6825 0338 0c9a ......4...h%.8..
0x0060: 1200 4823 0338 0eff 1019 3464 0002 6824 ..H#.8....4d..h$
0x0070: 0338 0c79 1200 4822 0338 0ee8 1038 3443 .8.y..H".8...84C
17:41:14.527004 IP 16.144.170.12.49230 > 16.144.170.14.63880: UDP, length 516
0x0000: 0012 7995 5572 0012 7995 5589 0800 4500 ..y.Ur..y.U...E.
0x0010: 0220 c6c6 4000 4011 fccb 1090 aa0c 1090 ....@.@.........
0x0020: aa0e c04e f988 020c 7758 0003 0001 8000 ...N....wX......
0x0030: 4953 4c31 3020 0000 0008 1000 0000 0000 ISL10...........
0x0040: 0003 0001 0000 0000 0001 0000 0001 001d ................
0x0050: cd65 0707 3021 2844 0000 0000 0000 0000 .e..0!(D........
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
17:41:14.527139 IP 16.144.170.14.63880 > 16.144.170.12.49230: UDP, length 4
0x0000: 0012 7995 5589 0012 7995 8aa7 0800 4510 ..y.U...y.....E.
0x0010: 0020 58ae 0000 2011 ccd4 1090 aa0e 1090 ..X.............
0x0020: aa0c f988 c04e 000c d0be 0004 0001 0000 .....N..........
0x0030: 0000 0000 0000 0000 0000 0000 ............
17:41:14.527221 IP 16.144.170.12.49230 > 16.144.170.14.63880: UDP, length 516
0x0000: 0012 7995 5572 0012 7995 5589 0800 4500 ..y.Ur..y.U...E.
0x0010: 0220 c6c7 4000 4011 fcca 1090 aa0c 1090 ....@.@.........
0x0020: aa0e c04e f988 020c 7758 0003 0002 0000 ...N....wX......
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
17:41:14.527355 IP 16.144.170.14.63880 > 16.144.170.12.49230: UDP, length 4
0x0000: 0012 7995 5589 0012 7995 8aa7 0800 4510 ..y.U...y.....E.
0x0010: 0020 f9ec 0000 2011 2b96 1090 aa0e 1090 ........+.......
0x0020: aa0c f988 c04e 000c d0bd 0004 0002 0000 .....N..........
0x0030: 0000 0000 0000 0000 0000 0000 ............
17:41:14.527432 IP 16.144.170.12.49230 > 16.144.170.14.63880: UDP, length 516
0x0000: 0012 7995 5572 0012 7995 5589 0800 4500 ..y.Ur..y.U...E.
0x0010: 0220 c6c8 4000 4011 fcc9 1090 aa0c 1090 ....@.@.........
0x0020: aa0e c04e f988 020c 7758 0003 0003 0000 ...N....wX......
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................

0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
17:41:14.527566 IP 16.144.170.14.63880 > 16.144.170.12.49230: UDP, length 4
0x0000: 0012 7995 5589 0012 7995 8aa7 0800 4510 ..y.U...y.....E.
0x0010: 0020 7a83 0000 2011 aaff 1090 aa0e 1090 ..z.............
0x0020: aa0c f988 c04e 000c d0bc 0004 0003 0000 .....N..........
0x0030: 0000 0000 0000 0000 0000 0000 ............
17:41:14.527643 IP 16.144.170.12.49230 > 16.144.170.14.63880: UDP, length 516
0x0000: 0012 7995 5572 0012 7995 5589 0800 4500 ..y.Ur..y.U...E.
0x0010: 0220 c6c9 4000 4011 fcc8 1090 aa0c 1090 ....@.@.........
0x0020: aa0e c04e f988 020c 7758 0003 0004 0000 ...N....wX......
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
17:41:14.527778 IP 16.144.170.14.63880 > 16.144.170.12.49230: UDP, length 5
0x0000: 0012 7995 5589 0012 7995 8aa6 0800 4510 ..y.U...y.....E.
0x0010: 0021 f5bf 0000 2011 2fc2 1090 aa0e 1090 .!....../.......
0x0020: aa0c f988 c04e 000d d0bc 0005 0000 0000 .....N..........
0x0030: 0000 0000 0000 0000 0000 0000 ............
In this case only 2KB was read on purpose from the LIF. We can tell this because of the opcode in the last
packet above was 0x0005, when it is followed by 0x0000 that means that it is the end of the data that will
be requested.
17:41:14.527778 IP 16.144.170.14.63880 > 16.144.170.12.49230: UDP, length 5

0x0000: 0012 7995 5589 0012 7995 8aa6 0800 4510 ..y.U...y.....E.
0x0010: 0021 f5bf 0000 2011 2fc2 1090 aa0e 1090 .!....../.......
0x0020: aa0c f988 c04e 000d d0bc 0005 0000 0000 .....N..........
0x0030: 0000 0000 0000 0000 0000 0000 ............
The most likely reason for this happening is ISL reading the LIF directory. There is a second read of the
start of the LIF again after this one. The most likely reason is so ISL knows what is in the contents of the
LIF directory as running the following ISL command does not cause network traffic:
ISL> ls
Utilities on this system are:
filename type start size created

=====================================================
HPUX -12928 272 1024 07/07/30 21:48:53
Loading the boot LIF – Part 2 (secondary loader)
In this section we will look at the network traffic involved in the initial loader (ISL) loading the secondary
loader (HPUX 60). Just looking at the file requests (the first 3 are not shown here since we showed they were
required to get ISL to start) we can see that there are additional file requests for the boot_lif file:
14:16:58.264635 IP 16.144.170.14.26690 > 16.144.170.12.69: 516 RRQ

14:16:58.312862 IP 16.144.170.14.63270 > 16.144.170.12.69: 516 RRQ
60
HPUX is the name of the secondary loader – it is not HP-UX just a program that loads the kernel and sets
it running.

14:16:58.362384 IP 16.144.170.14.2538 > 16.144.170.12.69: 516 RRQ

14:16:58.680332 IP 16.144.170.14.34247 > 16.144.170.12.69: 516 RRQ
14:17:05.260772 IP 16.144.170.14.51713 > 16.144.170.12.69: 516 RRQ
Note that some of these requests to read the boot_lif file will still belong to the initial loader, since however
this course is not able to investigate source code (unfortunately) we’re not able to investigate how the initial
and secondary loaders (sometimes known as “Mongoose”) work and why they need to read the boot_lif file
multiple times.
To find out what is happening though we’re going to need to capture the complete output (printing the first
128 bytes of the packets) using the following command:
# /usr/sbin/tcpdump -i 1 -nXX -s 128 host 16.144.170.14 >

/tmp/tcpdump/output.full 2>&1
Note: Care should be taken with the tcpdump command because of the potential size of the data collected.
The above command created a file >120MiB in size.
We can see that one of the times that the boot_lif file is read we read enough data to read the secondary
loader into memory:
14:26:31.385108 IP 16.144.170.12.49349 > 16.144.170.14.60870: UDP, length 516

0x0000: 0012 7995 5572 0012 7995 5589 0800 4500 ..y.Ur..y.U...E.
0x0010: 0220 fa49 4000 4011 c948 1090 aa0c 1090 ...I@.@..H......
0x0020: aa0e c0c5 edc6 020c 7758 0003 0288 0000 ........wX......
^^^^ ^^^^
Above you can see that in one of the data packets sent from the Ignite server to the client we are up to block
0x288. The end of block 0x288 is 331776 bytes into the file. Which is 1024 bytes from the end and that is
the location of the start of the VERSION file according to the LIF directory:
===============================================================
ISL -12800 16 242 0 07/07/30 21:48:53
AUTO -12289 264 2 0 07/07/30 21:48:53
HPUX -12928 272 1024 0 07/07/30 21:48:53
VERSION BIN 1296 1 0 07/07/30 21:49:06
# ll /opt/ignite/boot/boot_lif
-r--r--r-- 1 bin bin 332800 Aug 27 19:07 /opt/ignite/boot/boot_lif
That means we have shown that the secondary loader has been read from the boot_lif file. After being read
it would be set executing. The next packet from the client to the server tells it to stop sending the boot_lif
file (command 0x0005 with an error number of 0x0000 as discussed earlier means to finish).
...
14:26:31.531769 IP 16.144.170.14.60870 > 16.144.170.12.49349: UDP, length 5
0x0000: 0012 7995 5589 0012 7995 8aa6 0800 4510 ..y.U...y.....E.
0x0010: 0021 50b5 0000 2011 d4cc 1090 aa0e 1090 .!P.............
0x0020: aa0c edc6 c0c5 000d dc07 0005 0000 0000 ................
^^^^ ^^^^
0x0030: 0000 0000 0000 0000 0000 0000 ............
Loading the install kernel and filesystem

Now that the secondary loader has started running it’s time for it to load the kernel. These are the tftp traces
(showing only the files being requested) after the secondary loader has started and no more reads of the
boot_lif have been done:
14:26:40.590303 IP 16.144.170.14.62001 > 16.144.170.12.69: 516 RRQ

"/opt/ignite/boot/Rel_B.11.23/WINSTALL" octet
14:26:52.854342 IP 16.144.170.14.10177 > 16.144.170.12.69: 516 RRQ
14:27:04.765619 IP 16.144.170.14.56094 > 16.144.170.12.69: 516 RRQ
14:27:16.867429 IP 16.144.170.14.64093 > 16.144.170.12.69: 516 RRQ
"/opt/ignite/boot/Rel_B.11.23/WINSTALLFS" octet
14:27:46.316855 IP 16.144.170.14.45545 > 16.144.170.12.69: 516 RRQ
"/opt/ignite/stand/rootconf"
The first thing you may wonder is what is /opt/ignite/stand/rootconf? The kernel always attempts to read a
rootconf file – it should not exist on an Ignite server and for a network install or recovery boot it is of no
importance at all – it is safe to ignore that the kernel attempted to read it.
The following network packets printed by tcpdump are the last packets in each session that retrieves the
kernel file. We can see in the first session that the last block received is 0x4800 (around 9MB into the file).
The secondary loader is attempting to determine something about the kernel (most likely to ensure that it is
a valid kernel).
14:26:47.792504 IP 16.144.170.12.49352 > 16.144.170.14.62001: UDP, length 516

0x0000: 0012 7995 5572 0012 7995 5589 0800 4500 ..y.Ur..y.U...E.
0x0010: 0220 4349 4000 4011 8049 1090 aa0c 1090 ..CI@.@..I......
0x0020: aa0e c0c8 f231 020c 7758 0003 4800 409c .....1..wX..H.@.
^^^^ ^^^^
0x0030: 9b00 f249 8458 1e7c 52a1 3c88 1664 0442 ...I.X.|R.<..d.B
0x0040: b502 4180 54b8 a585 c034 104a b631 15d7 ..A.T....4.J.1..
0x0050: 87cf e5e4 410c 8d62 937c 5d02 ed95 2969 ....A..b.|]...)i
0x0060: df25 7ffe f461 f4a7 35fe 7c80 76e5 9c10 .%...a..5.|.v...
0x0070: 2ec4 4801 ed66 812d e72e 28d1 9f1f 4143 ..H..f.-..(...AC
14:26:47.986875 IP 16.144.170.14.62001 > 16.144.170.12.49352: UDP, length 5
0x0000: 0012 7995 5589 0012 7995 8aa6 0800 4510 ..y.U...y.....E.
0x0010: 0021 cd4c 0000 2011 5835 1090 aa0e 1090 .!.L....X5......
0x0020: aa0c f231 c0c8 000d d799 0005 0000 0000 ...1............
0x0030: 0000 0000 0000 0000 0000 0000 ............
In the next two tftp sessions the same amount of data is read, the reason for this is that the secondary loader
firmware reads the entire file twice. The first time is to see how long the file is 61. Then knowing how long
the file is the secondary loader firmware reads the complete kernel file into memory and sets it running.
14:27:01.116366 IP 16.144.170.12.49353 > 16.144.170.14.10177: UDP, length 445

0x0000: 0012 7995 5572 0012 7995 5589 0800 4500 ..y.Ur..y.U...E.
0x0010: 01d9 9f95 4000 4011 2444 1090 aa0c 1090 ....@.@.$D......
0x0020: aa0e c0c9 27c1 01c5 7711 0003 5c4c 23f2 ....'...w...\L#.
^^^^ ^^^^
0x0030: b38f a4ff 79b5 f77f 30fe e9f2 b3f6 b7d1 ....y...0.......
0x0040: cf92 e7c6 ceb0 97f4 239e 1deb 807e de75 ........#....~.u
0x0050: fa3c e813 34b1 0e7c 0692 7e61 2fe9 97f7 .<..4..|..~a/...
0x0060: 80de ab7b fee7 b4d6 9ede c54b a557 e3a5 ...{.......K.W..
0x0070: b747 39a0 df6c 47ff 754a 9242 3f4c f1df .G9..lG.uJ.B?L..
14:27:01.121637 IP 16.144.170.14.10177 > 16.144.170.12.49353: UDP, length 5
0x0000: 0012 7995 5589 0012 7995 8aa6 0800 4510 ..y.U...y.....E.
0x0010: 0021 53a6 0000 2011 d1db 1090 aa0e 1090 .!S.............
61
HP9000 firmware works from a much older base than HP Integrity firmware, it does not know about the
tsize tftp option to get a file size and does not support block sizes other than the default 512 bytes.

0x0020: aa0c 27c1 c0c9 000d a209 0005 0000 0000 ..'.............
0x0030: 0000 0000 0000 0000 0000 0000 ............
14:27:12.995456 IP 16.144.170.12.49354 > 16.144.170.14.56094: UDP, length 445

0x0000: 0012 7995 5572 0012 7995 5589 0800 4500 ..y.Ur..y.U...E.
0x0010: 01d9 fbe1 4000 4011 c7f7 1090 aa0c 1090 ....@.@.........
0x0020: aa0e c0ca db1e 01c5 7711 0003 5c4c 23f2 ........w...\L#.
^^^^ ^^^^
0x0030: b38f a4ff 79b5 f77f 30fe e9f2 b3f6 b7d1 ....y...0.......
0x0040: cf92 e7c6 ceb0 97f4 239e 1deb 807e de75 ........#....~.u
0x0050: fa3c e813 34b1 0e7c 0692 7e61 2fe9 97f7 .<..4..|..~a/...
0x0060: 80de ab7b fee7 b4d6 9ede c54b a557 e3a5 ...{.......K.W..
0x0070: b747 39a0 df6c 47ff 754a 9242 3f4c f1df .G9..lG.uJ.B?L..
14:27:13.119861 IP 16.144.170.14.56094 > 16.144.170.12.49354: UDP, length 5
0x0000: 0012 7995 5589 0012 7995 8aa6 0800 4510 ..y.U...y.....E.
0x0010: 0021 dceb 0000 2011 4896 1090 aa0e 1090 .!......H.......
0x0020: aa0c db1e c0ca 000d eeaa 0005 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 ............
Lastly the install filesystem is downloaded:
14:27:16.867429 IP 16.144.170.14.64093 > 16.144.170.12.69: 516 RRQ

"/opt/ignite/boot/Rel_B.11.23/WINSTALLFS"
Note that the kernel is running when the WINSTALLFS file is downloaded even though the kernel does not
have any of its networking subsystem working. A down call is made into the secondary loader which
downloads the WINSTALLFS file on behalf of the kernel. This is completely different to the way that HP
Integrity systems work (the IINSTALL kernel and IINSTALL install filesystem a copied down together
before the install kernel is set running).
From this point once the install filesystem has been downloaded init starts running and then Ignite-UX is
started.
Limitations, Restrictions, and other Information
The following is general information that while interesting did not fit within the discussion of how HP9000
systems network boot:
• Files that are downloaded must be less than 32MiB in size (the install filesystem is the closest in
size to this restriction). You are unlikely to see this issue in any released version of Ignite-UX as
HP has never shipped an install filesystem or kernel for HP9000 systems that is 32MiB or larger.
• A HP-UX install kernel has a special driver called “install” compiled into it. While this driver is
shipped with HP-UX 11.11 onwards. HP does not provide any information on how to create an
install kernel. HP does not provide support for install kernels created outside of HP.
vPars systems and network booting

The two different flavors of vPars have different characteristics when it comes to the way they work with
Ignite-UX. Both run vPars monitor programs however they have different features when it comes to
interacting with firmware and network booting. The following is from the vparboot(1m) manual page (from
version A.04.02):
PA-RISC platforms only

vparboot -p vp_name -I ignite_kernel
Itanium(R)-based platforms only

vparboot -p vp_name –I

Note that the –I option only accepts arguments on HP9000 systems. We will illustrate why this can cause
significant issues with a common misunderstanding about vPars.
HP9000 vPars systems
In this section we’re going to look at what happens with a HP9000 vPars system attempts to load an Ignite-
UX install kernel. So we can see what is happening we’re going tusc the vparboot command:
# /usr/local/bin/tusc -o /tmp/output -fkp vparboot -p hpchs24 -I \

> /opt/ignite/boot/Rel_B.11.23/WINSTALL
vparboot: Booting hpchs24. Please wait...
...
In the output from tusc below you can see the /dev/vpmon is opened and file descriptor 5 is returned. The
WINSTALL kernel ends up being opened on file descriptor 6. The WINSTALL file is read 4048 bytes at a
time and then there’s an ioctl call done on /dev/vpmon.
What is happening here is that the data read is being passed into the vPars monitor 62 (the install filesystem
is also handled this way):
...
[12916] open("/dev/vpmon", O_RDWR|O_LARGEFILE, 0) ........ = 5
[12916] ioctl(5, 0xffffffffc1004400, 0x800003ffefff10e0) . = 0
[12916] close(5) ......................................... = 0
[12916] open("/dev/vpmon", O_RDWR|O_LARGEFILE, 017) ...... = 5
[12916] ioctl(5, 0xffffffff90005000, 0x203ff) ............ ERR#14 EFAULT
[12916] brk(0x800000010000f000) .......................... = 0
[12916] stat("/opt/ignite/boot/Rel_B.11.23/WINSTALL", 0x800003ffefff1218) = 0
[12916] stat("/opt/ignite/boot/Rel_B.11.23/WINSTALLFS", 0x800003ffefff12b8) = 0
[12916] open("/opt/ignite/boot/Rel_B.11.23/WINSTALL", O_RDONLY|O_LARGEFILE,
0102460) = 6
[12916] brk(0x8000000100010000) .......................... = 0
[12916] read(6, "7fE L F 0202010101\0\0\0\0\0\0\0".., 4048) = 4048
[12916] ioctl(5, 0xffffffff90005000, 0x800000010000e038) . = 0
[12916] read(6, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0".., 4048) = 4048
[12916] read(6, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0".., 4048) = 4048
[12916] read(6, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0".., 4048) = 4048
...
On HP9000 systems vPars can not network boot. A running instance of HP-UX in another vPar must read
the install kernel and filesystem, pass it to the monitor, and the monitor puts into the memory for the vPar
and sets the kernel running. The firmware and bootloaders are never involved in the boot process once the
vPars monitor (vpmon) is running.
This can cause all sorts of interesting issues with networking. Most people assume that because they could
load the install kernel and filesystem into a vPar that there must be networking connectivity from the vPar
to the Ignite server. This does not have to be true.
Take the following rp7420 system, this system has been split into two vPars:
62
The –I option to vparboot can also take a leading IP address or hostname, when given this causes the
vparboot command to tftp the install kernel and filesystem from the remote Ignite server before passing it
to the vPars monitor.

In this case there is no way to route traffic from the network that vPar 1 is connected to and the other
network that vPar 2 is connected to. If vPar 1 is up and running and you issue the vparboot command to
load the install kernel in vPar 2 it will boot but the Ignite server defined in the install filesystem won’t be
contactable causing installation issues.
This issue can cause a lot of questions to be asked about networking when networking (or at least
networking from a firmware perspective) was not involved in loading the install kernel and filesystem.
HP Integrity vPars systems
On HP Integrity systems before running vPars the firmware must first be places into fpars mode. After that
EFI is still used for network booting so in the case of HP Integrity vPars a full PXE boot is performed. The
vparboot command does not pass the install kernel and filesystem to the vPars monitor.
Even if the system supports it the vPars monitor does not currently provide access to direct boot profiles –
you must perform a full PXE boot.
Complete lab7 (see “Lab exercise 7 – Network Booting – HP9000 systems”).

The AUTO files

This section provides additional information about AUTO files and how they can be used.
When using the examples in this section that explain how to pass additional arguments to Ignite-UX via the
boot loader it is important to test what you are implementing. The quoting is parsed multiple times and can
be difficult to get correct.
Where are the AUTO files?

There are two AUTO files used by Ignite-UX. The AUTO files are different for the two different hardware
architectures that HP-UX runs on. The AUTO file for HP9000 servers always exists in a LIF and for HP
Integrity servers the AUTO file can exist in different places (although never in a LIF).
How long can an AUTO file be?
Note that the following information is not officially documented.
An AUTO file cannot be more than 4KB long on HP Integrity systems (when presenting a list of choices
for selection). When using the traditional AUTO file format (no selectable options) only the first 1KB of
the AUTO file is used. On HP Integrity systems the make_ipf_tape command only supports writing an
AUTO file that is at most 512 bytes long. HP9000 systems support AUTO files 4KB or less at all times.
This discussion of the maximum AUTO file size only applies to boot loaders that have been modified to
support selectable boot options. The bootloaders supplied with Ignite-UX support selectable boot options,
the bootloaders supplied with HP-UX may or may not. This discussion of boot loaders should only be
applied in the context of Ignite-UX and not more generally to HP-UX.
On an Ignite server (network booting)
During a network boot the AUTO file used by a HP Integrity server is always this following file from an
Ignite server (See “The files downloaded for booting (part 1)” for an example of a booting HP Integrity
system downloading the AUTO file).
$ ll /opt/ignite/boot/AUTO
-r--r--r-- 1 bin bin 224 Oct 4 2007 /opt/ignite/boot/AUTO
On HP9000 system the AUTO file is never a file by itself it’s always contained within a LIF. During a
network install or recovery session when the initial loader requires the AUTO file it must read the boot_lif
file. The file is downloaded and the the LIF directory at the start read to get the offset for the start of the
AUTO file. Then the boot_lif file is read until it retrieves the AUTO file from the LIF:
$ lifls -l /opt/ignite/boot/boot_lif
===============================================================
ISL -12800 16 242 0 07/08/29 23:54:28
AUTO -12289 264 2 0 07/08/29 23:54:28
HPUX -12928 272 1024 0 07/08/29 23:54:28
VERSION BIN 1296 1 0 07/08/29 23:54:39
On media (CD/DVD)

Media intended for use with HP Integrity systems uses the EFI_CD_image file supplied with Ignite-UX as
part of creating an El Torito format CD or DVD. This is done as HP Integrity systems require El Torito
format CD/DVD media to boot from them. The AUTO file is located within the EFI_CD_image:
# pwd
/opt/ignite/boot/Rel_B.11.23
# efi_ls -d EFI_CD_image
FileName Last Modified Size
EFI/ 8/29/2007 0
INSTALL.EFI 8/29/2007 645215
AUTO 8/29/2007 16
STARTUP.NSH 8/29/2007 243
You can use commands like efi_ls(1m) and efi_cp(1m) to inspect the contents of the file and/or change the
contents.
On HP9000 systems a LIF is still used on CD/DVD media 63, although this LIF is from a tape not a
CD/DVD it would look identical on a HP-UX installation DVD 64.

===============================================================
ISL -12800 16 242 0 08/02/10 21:48:53
AUTO -12289 264 1 0 08/02/10 21:48:53
INDEX BIN 272 1 0 08/02/10 21:48:53
CONFIG BIN 280 90 0 08/02/10 21:48:53
HPUX -12928 376 1024 0 08/02/10 21:48:53
FWWKAR6 BIN 1400 1 0 08/02/10 21:48:53
FWWKAR7 BIN 1408 1 0 08/02/10 21:48:53
FWWKAR8 BIN 1416 1 0 08/02/10 21:48:53
WINSTALL -12290 1424 139206 0 08/02/10 21:48:58
WINSTALLFS -12290 140632 131056 0 08/02/10 21:49:01
IINSTALL -12290 271688 280915 0 08/02/10 21:49:04
IINSTALLFS -12290 552608 175616 0 08/02/10 21:49:04
INSTCMDS BIN 728224 55232 0 08/02/10 21:49:04
SYSCMDS BIN 783456 101539 0 08/02/10 21:49:04
INSTCMDSIA BIN 885000 104388 0 08/02/10 21:49:04
SYSCMDSIA BIN 989392 180041 0 08/02/10 21:49:09
SCRIPTS BIN 1169440 45 0 08/02/10 21:49:09
VERSION BIN 1169488 1 0 08/02/10 21:49:09
PAD BIN 1169496 256 0 08/02/10 21:49:09
On tape
Please refer to the section of this course on the format of bootable tapes for information on the location of
the AUTO file on HP9000 and HP Integrity natively bootable format tapes.
On a running system
This information is irrelevant to Ignite-UX but is presented here for completeness. On a HP Integrity server
the AUTO file is kept in HPUX/EFI 65:
63
A LIF exists on El Torito format media even if the media is intended for a HP Integrity system only. The
reason for this is commonality of tools, if an AUTO file exists in the LIF it would only ever be used by a
HP9000 system and never a HP Integrity server.
64
The start offsets would however be different since the LIF file would be present inside the ISO9660
filesystem it would not be at the start of the media.

# efi_ls -d /dev/rdisk/disk4_p1 66
EFI/ 4/ 3/2007 0
startup.nsh 4/ 3/2007 296
total space 523218944 bytes, free space 520216576 bytes
# efi_ls -d /dev/rdisk/disk4_p1 EFI

. 4/ 3/2007 0
.. 4/ 3/2007 0
HPUX/ 4/ 3/2007 0
Intel_Firmware/ 4/ 3/2007 0
diag/ 4/ 3/2007 0
hp/ 4/ 3/2007 0
tools/ 4/ 3/2007 0
# efi_ls -d /dev/rdisk/disk4_p1 EFI/HPUX

. 4/ 3/2007 0
.. 4/ 3/2007 0
hpux.efi 4/ 3/2007 654025
nbp.efi 4/ 3/2007 24576
AUTO 4/ 3/2007 12
With HP9000 systems of course everthing is stored in a LIF:
# lifls -l /dev/rdsk/c1t15d0
===============================================================
HPUX -12928 584 848 0 02/05/10 16:25:44
ISL -12800 1432 306 0 00/11/08 20:49:59
AUTO -12289 1744 1 0 00/11/08 20:49:59
PAD -12290 1752 1580 0 00/11/08 20:50:00
LABEL BIN 3336 8 0 06/09/02 22:49:02
Extending the flexibility of boot helpers

There is a boot loader feature for both HP9000 and HP Integrity servers that under some circumstances can
prove very useful. When you have multiple Ignite servers you can use this feature from a boot helper or
custom boot media to give extra configuration to the boot loader.
The following information has been tested with Ignite-UX version C.7.0 so it may or may not work with
versions of Ignite-UX prior to this.
A general example
As an example on a HP9000 system at the ISL prompt you can give the following option:
65
This is not true on CD/DVD media when Ignite-UX is used as the AUTO file is the root directory of the
EFI filesystem.
66
Note the agile device files so we can tell this was from an 11.31 system.

ISL> hpux –i'server=\"10.92.172.54\"' (;0):INSTALL
This will add the line:
server="10.92.172.54"
to the end of the configuration parsed from the install filesystem. This feature allows you to override the
Ignite-UX server defined in the install filesystem downloaded from a boot helper (when network booting)
and from the install filesystem from media (when booting from media).
This removes the need for multiple boot helpers when network booting when you have multiple Ignite
servers (since you could only define one server line in an install filesystem).
Using it with a network boot helper
Let’s look at network booting first by creating a boot menu that allows the selection of multiple Ignite
servers to install HP-UX B.11.23:
# auto_adm -f /opt/ignite/boot/boot_lif -o /var/tmp/auto -O ISL

# cat /var/tmp/auto
hpux KernelPrompt "Choose Operating System to Install :" 120 1
reset
"Exit" reboot
Now we can add some extra entries into the file 67:
# auto_adm -a -l "Install HP-UX B.11.23 from 10.92.172.54" -c \

-i\'server=\\\"10.92.172.54\\\"\' -b "(;0)" \
-i boot/Rel_B.11.23/WINSTALL -f /var/tmp/auto \
-o /var/tmp/auto1 -O ISL
# auto_adm -a -l "Install HP-UX B.11.23 from 10.92.174.54" -c \
-i\'server=\\\"10.92.174.54\\\"\' -b "(;0)" \
-i boot/Rel_B.11.23/WINSTALL -f /var/tmp/auto1 \
-o /var/tmp/auto2 -O ISL
Note that the second line starting with –i\’server= is an option to the –c argument not an argument to the
auto_adm command. Also if you use these commands note the quoting required to correctly getting the
information into the file so the boot loader will understand it.
Now we can place the changed data back into the AUTO file in the boot_lif and then see what the changes
look like 68:
# auto_adm -f /var/tmp/auto2 -o /opt/ignite/boot/boot_lif -O ISL

# auto_adm -f /opt/ignite/boot/boot_lif -O ISL
hpux KernelPrompt "Choose Operating System to Install :" 120 1
reset
67
It may be significantly easier to directly edit the AUTO files and place the required entries into them
instead of using auto_adm because of the complex shell quoting issues.
68
The output here shows the last two lines wrapping in the boot_lif the lines in the AUTO file do not wrap.

"Install HP-UX B.11.23 from 10.92.172.54" -i'server=\"10.92.172.54\"'

(;0)boot/Rel_B.11.23/WINSTALL
"Install HP-UX B.11.23 from 10.92.174.54" -i'server=\"10.92.174.54\"'
(;0)boot/Rel_B.11.23/WINSTALL
"Exit" reboot
When booting from the system the changes were made to you will see a menu that now looks like:
1. target OS is B.11.00
2. target OS is B.11.11
3. target OS is B.11.23 PA
4. target OS is B.11.31 PA
5. Install HP-UX B.11.23 from 10.92.172.54
7. Exit
Choose Operating System to Install :
This will allow you to use the one boot helper to install from multiple Ignite servers. If you have DHCP
available on the network that the system is on the client will automatically get an IP address (if you have
not disabled DHCP support). Once Ignite-UX has started it will contact the specific Ignite server you have
directed it to.
Starting with Ignite-UX version C.7.0 (which adds support for HP-UX B.11.31) the default AUTO file for
HP Integrity systems (/opt/ignite/boot/AUTO) looks like:
KernelPrompt "Choose Operating System to Install :" 120 1

reset
"target OS is B.11.23 IA" boot Rel_B.11.23/IINSTALL
"Exit" reboot
To add lines into the file you should run commands like:
# auto_adm -p IA -a -l "Install HP-UX B.11.23 from 10.92.172.54" -c boot -i \

\ -i\'server=\\\"10.92.172.54\\\"\' -b boot/Rel_B.11.23/IINSTALL \
-f /opt/ignite/boot/AUTO -o /var/tmp/auto3 -O ISL
Note the second line of the command starts with a \ followed by a space character. This forces the space to
be pre-pended to the option to the –i argument to correctly format the entry. The command itself however is
fairly different to auto_adm command used for HP9000 systems.
Now we can run the second command:
# auto_adm -p IA -a -l "Install HP-UX B.11.23 from 10.92.174.54" -c boot -i \

\ -i\'server=\\\"10.92.174.54\\\"\' -b boot/Rel_B.11.23/IINSTALL \
-f /var/tmp/auto3 -o /var/tmp/auto4 -O ISL
And the resulting file looks like 69:

reset
"Install HP-UX B.11.23 from 10.92.172.54" boot boot/Rel_B.11.23/IINSTALL -
i'server=\"10.92.172.54\"'
"Install HP-UX B.11.23 from 10.92.174.54" boot boot/Rel_B.11.23/IINSTALL -
i'server=\"10.92.174.54\"'
69
Note again the line wrapping, in the real file each of these entries occupies one line.

"Exit Boot Loader" exit
This file can be copied over /opt/ignite/boot/AUTO or you can have that file as the output file in the second
auto_adm command.
How the boot loaders locate the install kernels (network installs)
This discussion will be isolated to a few particular aspects of how this works.
The first point we will discuss deals with PA-RISC systems and why for HP-UX B.11.11 you always see
AUTO files lines such as:
There’s only a reference to the 32bit install kernel. The initial loader on HP9000 systems knows if the
system can only support 64bit version of HP-UX or not. If it’s a 64bit only the system the INSTALL is
automatically replaced with WINSTALL when it runs the secondary loader to boot the install kernel. The
automatic translation of INSTALL to WINSTALL happens regardless of the method the systems uses to
boot.
The next thing we need to look carefully at is how the loaders (on HP9000 and HP Integrity systems) know
where to get the correct install kernel from when network booting. The only initial information that is
available to systems booting over the network is the name of the boot file.
For HP9000 systems the response always tells the system to boot from /opt/ignite/boot/boot_lif and for HP
Integrity systems the response should always be to use /opt/ignite/boot/nbp.efi. So how does this relate to
the following example entries from (different) AUTO files:
The boot process takes the name of the boot file and keeps the first two directories on HP9000 systems then
adds the boot path from the auto file (this happens this way because of the way that NFS diskless systems
worked). For example:
/opt/ignite/boot/boot_lif + /boot/Rel_B.11.11/INSTALL =
/opt/ignite/boot/Rel_B.11.11/INSTALL
For HP Integrity servers the dirname is kept from the boot file (i.e. drop the basename) and then the path
from the AUTO file is added to give the name of the kernel. For example:
/opt/ignite/boot/nbp.efi + Rel_B.11.31/IINSTALL =
/opt/ignite/boot/Rel_B.11.31/IINSTALL
For Itanium systems the boot loader locates the install filesystem by attempting to load exactly the same
path with “FS” added to the end. The HP9000 install kernel does a similar thing but the kernel loads the
install filesystem not the boot loader.
There is a good reason for this difference.
On HP Integrity systems once the install kernel has been launched it no longer has access to EFI (firmware)
to assist it with any I/O operations. The kernel can’t perform any I/O until it has initialized the I/O
subsystem. Because of that the boot loader loads the kernel and the install filesystem at the same time.

On HP9000 systems the kernel still has access to firmware to perform I/O operations so it can make a
downcall into the system firmware once it starts to load the install filesystem.
Inventory blocking best practices

The following information was written by the Ignite lab about inventory blocking. Some changes have been
made to aid clarity or provide additional explaination.
Ignite-UX inventory blocking functionality is used to restrict the set of adapters and devices that are
included in the inventory process. It’s important to note that blocked devices may not be used for Ignite-
UX installation of file system content during install or recovery, blocking devices that are not required
during an recovery or installation session will decrease the amount of time spend inventorying devices
attached to the system. Blocked devices may include file system content that is imported during recovery.
The Ignite-UX config keywords that control blocking are:
inventory_block_path = hw_path
inventory_block_path += hw_path
This keyword is used to control Ignite-UX inventory functionality. The hardware paths must refer
to an I/O adapter or a device. Ignite-UX will not collect inventory information for devices listed or
for devices connected to adapters listed. All adapters used for devices must be listed when devices
are connected using multiple paths. Ignite-UX will inventory devices connected to any adapters
not listed. Restricting the Ignite-UX inventory process reduces the time required to collect I/O
configuration information but will result in some I/O information not being available for install
and recovery processing. Blocking inventory at the device level may not provide a significant
perfomance benefit. Because Ignite-UX does not control kernel boot inventory, some inventory
information for blocked devices may be collected. All blocked devices will be hidden and not
available for selection during install.
inventory_block_protocols = { “protocol”, “protocol”, ... }
This keyword is used to control Ignite-UX inventory functionality. Ignite-UX will not collect
inventory information for devices connected to I/O adapters of listed I/O protocol types.
Restricting the Ignite-UX inventory process reduces the time required to collect I/O configuration
information but will result in some I/O information not being available for install and recovery
processing. Because Ignite-UX does not control kernel boot inventory, some inventory
information for blocked devices may be collected. All blocked devices will be hidden and not
available for selection during install.
Please refer to the instl_adm(4) manual page for a list of valid protocols, Ignite-UX version C.7.3 listed the
supported protocols as:
fibre_channel
I/O protocol type Fibre Channel (FC). The priority
order of FC devices connected via the same I/O adapter
is based on hardware path (lunpath hardware path for
HP-UX 11.31 and later).
parallel_scsi
I/O protocol type Parallel Small Computer System
Interface (SCSI). The priority order of Parallel SCSI
devices connected via the same I/O adapter is based on
SCSI bus priority order (e.g. SCSI address 7 to 0
followed by 15 to 8).
sas I/O protocol type Serial Attached SCSI (SAS). The

order of SAS devices connected via the same I/O adapter

is based on physical location. Note that hardware path

values should not be used for device selection or
recovery device matching since these values are not
consistent for the same device from install to install.
usb I/O protocol type Universal Serial Bus (USB). The

order of USB devices is not yet defined. There is
currently no support for USB devices as a target for
install or recovery.
Since the inventory process is done very early during startup of the Ignite-UX install environment the
inventory control keywords will only be effective if they are included in the install file system config
content or in a HP-UX bootloader argument.
The simplest way to control inventory is to include keyword values in the install file system config content.
The instl_adm command may be used to accomplish this. To extract the current install file system config
contents you may use the following command on the Ignite-UX server:
# instl_adm > /tmp/myconfig

# cat /tmp/myconfig
The file might contain:
server="10.1.2.3"
netmask[]="255.255.248.0"
You might add the following content to this config file to control inventory functionality:
inventory_block_protocols = { “fibre_channel”, “sas” }

inventory_block_path = 0/4/1/0
inventory_block_path += 0/4/1/1
To update the install file system config contents the following command could be used:
# instl_adm –f /tmp/myconfig
Once this is done, install or recovery of clients using this server will be done with inventory blocking of
Fibre Channel and SAS devices as well as any devices connected only via the adapter paths listed.
It’s important to note that this inventory blocking will be done for all clients doing install or recovery from
the server. If you have a policy of only using internal SCSI devices for HP-UX operating system content
this might be very convenient since Fibre Channel inventory could be easily blocked for all systems 70.
However, if different configuration policies are used for different client systems which install and recovery
using the same Ignite-UX server this approach may not be acceptable.
70
Although it is unlikely, as in the example, that you would block SAS devices in this case.

The simplest way to provide client-specific inventory control is via an HP-UX bootloader command line
argument. Many people know that a “runlevel” such as ‘-i4’ may be given to the HP-UX bootloader to
enable Ignite-UX debugging.
However, it’s not widely known that any config content may also be given using that same argument. The
install boot sequence can be interrupted and special config content can be given to the bootloader which
will in turn pass that config content to Ignite-UX. The following is an example of how that may be done:
IPL> hpux -i'inventory_block_protocols={\"fibre_channel\"}' :WINSTALL
To reduce the need for typing, an AUTO file entry can be added to /opt/ignite/boot/AUTO to allow
simplified selection of the correct bootloader argument content. An example single line entry could be:
"target OS is B.11.23 PA (no FC use)" boot Rel_B.11.23/WINSTALL

-i'inventory_block_protocols={\\"fibre_channel\\"}'
During the boot sequence this AUTO file entry will allow the inventory control to be done simply by
choosing the boot selection.
Normally one of the methods described above will be sufficient. However, it is possible that there may be a
need for client-specific blocking which requires many distinct paths to be blocked and is too complex to be
given as a bootloader command argument. If that is the case, it may be useful to make use of an Ignite-UX
conditional config expression. For example, the following could be included in the install file system config
content:
(_mysys == 1)
{
}
(_yoursys == 1)
{
}
In this example, two different sets of paths have been specified. Since these are specified within a
conditional, normally neither would be used. To select one of these path sets for blocking, the variable in
the conditional expression must be set. This would normally be done via a bootloader argument, for
example:
IPL> hpux -i'_mysys=1' :WINSTALL
This approach can of course also be used in an AUTO file entry if required. These approaches should help
you make practical use of inventory blocking.
Finally, it’s very important to note that a MAC address conditional will not work for inventory blocking
control. For example, the following approach will not work:
LLA[] == "001234 678abc" {

inventory_block_...
}

Determining a system’s MAC address is part of the inventory process. The inventory blocking keywords
must be specified before inventory is done to be effective. As a result, the LLA data needed to evaluate the
conditional is not available in time to determine the blocking keyword values and control inventory.
Extending the flexibility of media

You can take the concepts presented here and use them with media as well. Typically the AUTO file on
media only has one boot option telling the boot loader to load the install kernel and filesystem. You can
change the AUTO file to add multiple boot loader choices to allow anyone using the media to pass different
options to Ignite-UX.
However with media only one HP-UX revision can be supported since you can only have one set of install
kernels and filesystems all belonging to the one HP-UX release present.
Important: Remember that the AUTO files for HP9000 and HP Integrity systems are different. You will
need to modify both files if you wish changed boot loader options to be present for both architectures.
Complete lab exercise four (see “Lab exercise 4 – inventory blocking and the AUTO file”).

The product structure of Ignite-UX

This section covers the current product structure of Ignite-UX some information is given about filesets
and/or product bundles that are no longer shipped.
Although this section does cover some information about the way that Ignite-UX is packaged and shipped
it does not contain information about updating and installing Ignite-UX. For information about installing
and updating Ignite-UX please see the white paper “Installing and Updating Ignite-UX” located at this
URL:
Historical filesets and bundle wrapper

Older versions of Ignite-UX had many different filesets compared to the most current versions. This is the
swlist –l fileset for the old Ignite-UX bundle wrapper:
# swlist -l fileset -a revision Ignite-UX

# Initializing...
# Contacting target "systema"...
#
# Target: systema:/
#
# Ignite-UX B.5.4.50
Ignite-UX.BOOT-KERNEL-IA B.5.4.50
Ignite-UX.BOOT-KERNEL-PA B.5.4.50
Ignite-UX.BOOT-SERVICES B.5.4.50
Ignite-UX.CFG-FILE-11-22 B.5.4.50
Ignite-UX.CFG-FILE-11-23 B.5.4.50
Ignite-UX.FILE-SRV-10-20 B.5.4.50
Ignite-UX.FILESRV-1122IA B.5.4.50
Ignite-UX.FILESRV-1123IA B.5.4.50
Ignite-UX.IGNITE B.5.4.50
Ignite-UX.IGNT-ENG-A-MAN B.5.4.50
Ignite-UX.MGMT-TOOLS B.5.4.50
Ignite-UX.OBAM-RUN B.5.4.50
Ignite-UX.RECOVERY B.5.4.50
A lot of the filesets in this older version of Ignite-UX no longer exist in the product:
# swlist -l fileset -a revision Ignite-UX

# Initializing...
# Contacting target "green"...
#
# Target: green:/
#
# Ignite-UX C.7.4.157
Ignite-UX.BOOT-COMMON-IA C.7.4.157
Ignite-UX.BOOT-COMMON-PA C.7.4.157
Ignite-UX.BOOT-KRN-11-11 C.7.4.157
Ignite-UX.BOOT-SERVICES C.7.4.157
Ignite-UX.CD-TOOLS C.7.4.157

Ignite-UX.CD-TOOLS-DOC C.7.4.157
Ignite-UX.CD-TOOLS-SRC C.7.4.157
Ignite-UX.DVD-TOOLS C.7.4.157
Ignite-UX.DVD-TOOLS-DOC C.7.4.157
Ignite-UX.DVD-TOOLS-SRC C.7.4.157
Ignite-UX.FILE-SRV-11-11 C.7.4.157
Ignite-UX.IGNITE C.7.4.157
Ignite-UX.IGNT-ENG-A-MAN C.7.4.157
Ignite-UX.IGNT-JPN-E-MAN C.7.4.157
Ignite-UX.IGNT-JPN-S-MAN C.7.4.157
Ignite-UX.IGNT-OBAM-RUN C.7.4.157
Ignite-UX.MGMT-TOOLS C.7.4.157
Ignite-UX.RECOVERY C.7.4.157
The changes can be summaries into this table comparing the two versions of Ignite-UX. Not all of these
changes happened at once. Some examples of this would be:
1. When support for PA-RISC systems was released for HP-UX B.11.23 Ignite-UX had to be
reorganized at version C.6.0 to take into deliver multiple PA-RISC install kernels (this is the point
when the install kernels moved from /opt/ignite/boot/ to /opt/ignite/boot/Rel_B.xx.yy).
2. In December 2005 HP-UX B.11.22 support was removed from Ignite-UX C.6.5.x. In September
2004 HP-UX B.10.20 was removed from Ignite-UX C.6.0.x. In September 2007 HP-UX B.11.00
was removed from Ignite-UX C.7.3.x. The filesets and/or files that provided support for these
versions of HP-UX were removed from the product.
3. The filesets for the DVD/CD writing tools were added into the product when they started to be
shipped with Ignite-UX.
4. The filesets containing ja_JP.SJIS and ja_JP.eucJP manual pages were added into the product.
5. The HP-UX release specific filesets for B.11.31 were added at C.7.0.
Table 7 - Ignite-UX Fileset Changes

New Old (and no longer exists) Unchanged 71
BOOT-COMMON-IA BOOT-KERNEL-IA BOOT-SERVICES
BOOT-COMMON-PA BOOT-KERNEL-PA FILE-SRV-11-11
BOOT-KRN-11-11 CFG-FILE-11-22 IGNITE
BOOT-KRN-11-23 CFG-FILE-11-23 IGNT-ENG-A-MAN
BOOT-KRN-11-31 FILE-SRV-10-20 MGMT-TOOLS
CD-TOOLS FILE-SRV-11-00 OBAM-RUN
CD-TOOLS-DOC FILESRV-1122IA RECOVERY
CD-TOOLS-SRC FILESRV-1123IA
DVD-TOOLS
DVD-TOOLS-DOC
DVD-TOOLS-SRC
FILE-SRV-11-23
FILE-SRV-11-31
IGNT-JPN-E-MAN
IGNT-JPN-S-MAN
The bundle wrapper for Ignite-UX also changed at Ignite-UX version C.7.0. The previous bundle wrapper
for the complete Ignite-UX product was B5725AA it is now IGNITE. If you swinstall the IGNITE bundle
it will automatically remove the B5725AA bundle. Although release specific bundles do exist we’re not
going to discuss them here.
Installing a newer version of Ignite-UX also automatically remove any of the older filesets that are no
longer part of Ignite-UX.
71
Indicates that the fileset still exists, the contents of the fileset have changed over time.

The web and OE/AR versions

This section deals with some of the differences between the two different methods of delivering Ignite-UX.
Packaging differences
There are some important differences between the web and OE (Operating Environment) AR (Application
Release) versions of Ignite-UX. One important thing to note about the contents of the web and OE/AR
versions – they are identical. The only difference between the two versions is the packaging.
Why is there a difference? Unfortunately it comes to down to reasons internal to HP. There are standards
for packaging software products on the OE and AR media. Those standards dictate that packaging on OE
and AR media must be tied to that specific HP-UX revision. Contrasting this Ignite-UX is one product that
is not tied to a specific version of HP-UX since it must be able to be installed on any supported release and
be capable of installing any other supported release of HP-UX.
Looking at the version of Ignite-UX in this OE depot you can see that the IGNITE bundle wrapper only
allows itself to be installed onto HP-UX 11.31:
# swlist -v -d IGNITE @ /var/opt/ignite/depots/Rel_B.11.31/0709_MCOE

# Initializing...
# Contacting target "vhost"...
#
# swlist Depot Table of Contents
#
# For depot: vhost:/var/opt/ignite/depots/Rel_B.11.31/0709_MCOE
#
# Date: Tue Mar 18 08:27:09 2008
#
# IGNITE
vendor
tag HP
uuid
title "Hewlett-Packard Company"
description "Hewlett-Packard
"
end
bundle
tag IGNITE
software_spec IGNITE,r=C.7.3.144,a=HP-UX_B.11.31_IA/PA,v=HP
data_model_revision 2.40
...
instance_id 1
control_directory IGNITE
size 700202107
revision C.7.3.144
title HP-UX Installation Utilities (Ignite-UX)
description "
Vendor Name Hewlett-Packard Company
Product Name HP-UX System Installation Services
This software bundle contains the complete Ignite-UX product

used for installing HP-UX systems.
This bundle contains filesets for installing all versions of HP-UX

that Ignite-UX supports. If you will only be installing one or two
releases of HP-UX then you should load one or more of the bundles

named "Ignite-UX-XX-YY" (where "XX-YY" is the HP-UX release you desire).

"
mod_date Thu Nov 15 19:01:12 EDT 2007
mod_time 1195113672
create_date Thu Nov 15 19:01:12 EDT 2007
create_time 1195113672
architecture HP-UX_B.11.31_IA/PA
machine_type *
os_name HP-UX
os_release ?.11.3*
os_version *
...
The setting of the os_release SD tag will only match B.11.31 (the underlying product doesn’t have this
restriction only the bundle). The web version of Ignite-UX does not contain these restrictions and can be
installed onto any currently supported release of HP-UX.
Important: HP recommends against installing a version of Ignite-UX that is packaged for a specific
revision of HP-UX onto any other version of HP-UX. You should use the web download version of Ignite-
UX instead.
Important: As each new version of Ignite-UX comes along the previous web version of Ignite-UX is
replaced by the new version. If you only require support for a subset of HP-UX releases but will require
support for more in the future and wish to use the same version of Ignite-UX download either the full
version of Ignite-UX or the release specific bundles that you require support for. If you plan to use the one
Ignite server to support multiple releases of HP-UX download and install the full version of Ignite-UX
containing support for all releases of HP-UX.
Version differences
Sometimes you can get differences in the version of Ignite-UX that appears on the web and on the OE/AR
media. This usually happens when a serious or critical defect is found that can impact a lot of customers.
The format for the Ignite-UX version is letter.major.minor.ticker (The letter is currently C). You can end up
with two things happening when the version number changes in a web release. The first is that the minor
number changes and the second is that the ticker changes. The minor number only tends to change when
there are a large number of fixes.
An example of the minor number changing for a web release is: C.7.0 and C.7.1, C.7.0 was the Ignite-UX
version on the initial OE and AR media for 11.31. Ignite-UX version C.7.0 had some problems, some of
them were not detected until after it was too late to resubmit Ignite-UX into the OE so a new version of
Ignite-UX was created and released on the web instead of releasing C.7.0.
Examples of web versions with different ticker numbers are:
• C.7.6.98 and C.7.6.100

• C.7.3.144 and C.7.3.148
• C.6.9.141 and C.6.9.150
The release notes for C.7.3.148 indicate that only the following fixes were made:
- Fixes for the following Change Requests:
* JAGag43543 fix. MAKE_BOOT errors when Igniting 11.23 clients with

VxVM & VxFS 4.1 have been fixed. These errors occurred on clients
with VxFS disk layout version 6 for the root file system.

x ./etc/nsswitch.conf, 382 bytes, 1 tape blocks

x ./monitor_bpr, 36864 bytes, 72 tape blocks
* Download_mini-system: Complete
* Loading_software: Begin
* Installing boot area on disk.

ERROR: MAKE_BOOT: Volume rootvol does not contain a file system.
The configuration process has incurred an error, would you like
to push a shell for debugging purposes? (y/[n]):
* JAGag43578. An issue with modifying system parameters when running

certain commands was resolved in response to HPSBUX02249.
* JAGag46613 fix. save_config, make_net_recovery, and

make_tape_recovery would fail on systems that have inactive volume
groups (which is typical on ServiceGuard clusters). This issue was
introduced with the C.7.3.144 Ignite-UX release.
In this case the most important fix was probably for the security bulletin HPSBUX02249.
The filesets
This section contains a short description of what is contained within each Ignite-UX fileset:
Table 8 - Ignite-UX Fileset Contents

Fileset Name Description
BOOT-COMMON-IA Contains files common to all HP Integrity servers that are required to boot this
include the AUTO file, fpswa.efi, hpux.efi, and nbp.efi.
BOOT-COMMON-PA The most important file in this fileset is /opt/ignite/boot/boot_lif file that is used by
all booting PA-RISC clients.
BOOT-KRN-11-11 Contains all of the install kernels and filesystems required for HP-UX 11.11 as well
as the RECMCMDS and INSTCMDS files.
as the RECMCMDS[IA] and INSTCMDS[IA] files.
as the RECMCMDS[IA] and INSTCMDS[IA] files.
BOOT-SERVICES Contains all of the files required for instl_bootd as well as files supplied to enable
the system that Ignite-UX is installed on to change hostname or IP address via
set_parms (set_parms calls the scripts).
CD-TOOLS Contains the compiled binaries from the cd-record open source distribution.
CD-TOOLS-DOC Contains one file (/opt/ignite/share/doc/cdrecord_licenses.txt) which provides the
licenses assocated with the Internet Express product (includes the GPL license
which covers cd-record.
CD-TOOLS-SRC Contains two files one of which is the source code associated with the version of
cd-record shipped with Ignite-UX.
DVD-TOOLS Contains the compiled binaries for the open source DVD+RW tools
DVD-TOOLS-DOC Contains the copyright, license, and readme files associated with the open source
DVD+RW tools.
DVD-TOOLS-SRC Contains the source code for the open source DVD+RW tools
FILE-SRV-11-11 Contains the SYSCMDS file for 11.11 as well as the per-release config file and
hw_patches_cfg.
FILE-SRV-11-23 Contains the SYSCMDS[IA] file for 11.23 as well as the per-release config file and
hw_patches_cfg.
FILE-SRV-11-31 Contains the SYSCMDS[IA] file for 11.31 as well as the per-release config file and
hw_patches_cfg.

IGNITE Contains most of the files required to run itool and ignite (the command not the
product)
IGNT-ENG-A-MAN Contains the C locale manual pages
IGNT-JPN-E-MAN Contains the Japanese ja_JP.eucJP manual pages
IGNT-JPN-S-MAN Contains the Japanese ja_JP.SJIS manual pages
IGNT-OBAM-RUN 72 Contains the ObAM runtime environment
MGMT-TOOLS Contains most of the binaries and scripts associated with Ignite-UX (including the
I/O listener)
RECOVERY The commands required for make_net_recovery and make_tape_recovery.
The recovery commands depot
The recover commands depot isn’t strictly related to the either the web or OE/AR version of Ignite-UX.
This is a good point however to discuss the way that the depot is packaged. The things that are important
about this depot are:
• The contents of the depot are always packaged in a way that they are release independent
irrespective of where Ignite-UX was installed from.
• Ignite-UX never creates this depot during product installation (this may not have been true in very
very old releases of Ignite-UX)
• Ignite-UX always updates this depot to reflect the current version of Ignite-UX when it is being
installed (as noted in the previous point only if the depot already exists).
• The bundles in the depot are intended to provide support for clients of an Ignite server for creating
recovery archives.
To create the recovery commands depot if it doesn’t exist run the pkg_rec_depot command:
# swlist -l depot
# Initializing...
# Target "vhost" has the following depot(s):
/var/opt/mx/depot11
/var/opt/ignite/depots/HPVM
/var/opt/ignite/depots/Rel_B.11.31/0709_MCOE
/var/tmp/build/dvd
/var/tmp/build/dvd2
/var/opt/ignite/depots/C.7.4.155
/var/opt/ignite/depots/pax.enh
# /opt/ignite/lbin/pkg_rec_depot
* Generating the product specification file.
* Creating depot: /var/opt/ignite/depots/recovery_cmds
...
In the swlist output above the recovery commands depot (/var/opt/ignite/depots/recovery_cmds) does not
exist so running /opt/ignite/lbin/pkg_rec_depot will create it. If you ever have a problem with the recovery
commands depot you can use the –f option to force it to be recreated.
There is only one known defect in the pkg_rec_depot command. From Ignite-UX version C.6.0 to C.6.10,
the command contained a defect that caused all the BOOT-KRN-11-XX filesets to be included in every
Ignite-UX-11-XX bundle in the recovery commands depot. For information about this issue please see the
section titled “Mismatched filesets after updating to version C.7.0 or later” in the white paper “Installing
and Updating Ignite-UX” located at this URL:
72
This fileset will eventually disappear from Ignite-UX. The ObAM infrastructure has been declared
obsolete on HP-UX 11.31 and will not appear in subsequent releases. Ignite-UX components currently
using ObAM (i.e. looks like SAM) will eventually present a different interface.

The contents of the recovery commands depot

The contents of the recovery commands depot normally look like this:
# swlist -d @ /var/opt/ignite/depots/recovery_cmds
# Initializing...
# Contacting target "vhost"...
#
# Target: vhost:/var/opt/ignite/depots/recovery_cmds
#
#
# Bundle(s):
#
IUX-Recovery C.7.3.148 Ignite-UX network recovery tool subset

Ignite-UX-11-11 C.7.3.148 HP-UX Installation Utilities for
installing 11.11 Systems
Installing 11.23 Systems
Installing 11.31 Systems
The bundles contain the following software:
Table 9 - Recovery Commands Depot Bundles

Bundle Name Contents
IUX-Recovery The filesets are that are required for a system to run make_net_recovery. Since
this bundle does not contain any install kernels or other related files the size
impact caused by this bundle on a system is not large.
Ignite-UX-11-11 The full version of Ignite-UX required to support HP-UX B.11.11 systems.
Typically this bundle is installed on a HP-UX B.11.11 system to enable support
for make_tape_recovery but with this installed a system should be capable of
installing HP-UX B.11.11 systems as well.
Important: The recovery commands depot is created “packaged in place”. This means that rather than
copy the files being refered to into the depot they are left where they are on the system and when required
they are accessed “in place”. This means that the actual files on the system are distributed to anyone
installing software from this depot. Care should be taken if you ever need to replace (or customize) any
files that are part of Ignite-UX on a server with a recovery commands depot – the changed files will be
distributed out to anyone who installs the software from the recovery commands depot.
How the bin and lbin directories work

The /opt/ignite/bin and /opt/ignite/lbin directories are really symlinks pointing to directories containing the
binaries required for a particular architecture:
$ cd /opt/ignite
$ ll -d *bin*
lrwxr-xr-x 1 root sys 17 Feb 18 12:59 bin ->
/opt/ignite/binpa
dr-xr-xr-x 2 bin bin 1024 Feb 18 12:59 binia
dr-xr-xr-x 2 bin bin 1024 Feb 18 12:59 binpa
lrwxr-xr-x 1 root sys 18 Feb 18 12:59 lbin ->
/opt/ignite/lbinpa
dr-xr-xr-x 2 bin bin 1024 Feb 18 13:00 lbinia
dr-xr-xr-x 2 bin bin 1024 Feb 18 13:00 lbinpa
On a HP9000 server the symlinks will look as they do above pointing to the binpa/lbinpa directories, on a
HP Integrity server they will instead point to the binia/lbinia directories.
There is a reason for doing this it this way. Normally when you have software that can install onto HP9000
and HP Integrity servers in the one depot you would normally expect to see the software packaged with
duplicate fileset names with different architecture settings so you can install the correct fileset for the
correct architecture.
Ignite-UX, however, when you create the recovery commands depot still needs to supply software that can
install install onto either architecture. Since the contents of the recovery commands depot are packaged in
place that means that the binaries for either architecture must be installed.
If this was not the case Ignite-UX on a HP9000 system would only be able to provide a recovery
commands depot for other HP9000 systems. It would not be able to supply the recovery commands depot
for HP Integrity systems. The reverse situation would be true, HP Integrity servers would not be able to
support HP9000 systems.
During installation the SD scripts assocated with Ignite-UX create the symlinks for /opt/ignite/lbin and
/opt/ignite/bin.
File formats
This section defines the file formats for files commonly used by Ignite-UX. Please note that the file formats
here are not publicly documented and like most of the content of this course are subject to change without
notice.
flist
There are three forms of the flist file (really two since the second is an optional form of the first), those
forms are:
Table 10 - flist Formats

Number Description
of fields
6 Valid up to C.6.4, this form is the same as the 7 field form of the flist file but the 7th
field is optional.
7 Valid up to C.6.4, this form is the same as the 6 field form of the flist file except
that it has the optional field. This form was only ever used by make_recovery73.
10 As of C.6.4 this is the only form of flist file. In all cases when called by
73
Which is no longer shipped or supported by Ignite-UX.

make_net_recovery or make_tape_recovery the 7th field is aways “NA”.
The following table shows what all of the fields are:
Table 11 - flist Fields

Field Description
Number
1 Number of bytes in the file name
2 File name – does not contain a leading / as the contents of an archive (recovery or
golden image) are always saved with relative (never absolute) paths.
3 File mode in octal (includes all bits from mode including parts that indicate if it a
directory, symlink, etc)
4 File mtime (used by check_tape_recovery and check_net_recovery)
5 File size (bytes)
6 File blocks (number of 1024 byte blocks the file occupies – includes filesystem
overheads)
7 File cksum. If not generated it is set to NA. It was only previously used by the
make_recovery and check_recovery commands. This field is not generated by the
make_tape_recovery or make_net_recovery commands.
8 Number of hard links
9 File system inode number (st_ino from a struct stat), note that some versions of
Ignite-UX may not provide a leading 0x but this number is always in hex.
10 File system id (st_fsid from a struct stat), note that some versions of Ignite-UX may
not provide a leading 0x but this number is always in hex.
The last 3 fields were added into the flist file so Ignite-UX could determine more accurate disk impacts for
hard linked files.
The following first line from a flist file is from Ignite-UX version B.2.6.358, note that there are only 6
fields as the 7th field is optional in this format:
5 stand 40555 1020038315 1024 1
The following first line from a flist file is from Ignite-UX version C.6.10.97:
5 stand 40555 1201455584 8192 8 NA 9 2 40000001
As noted above the last two fields are in hex, if you write a program that reads a flist file you will need to
make sure that the fields get converted from base16 since they do not have a leading 0x to identify them
has hex numbers. This line from an flist file clearly shows the 9th field in hex without a leading 0x:
25 stand/crashconfig/mod/ipf 100544 1061588391 415368 408 NA 1 3d 40000001
Later versions of Ignite-UX (C.7.1 onwards) do provide a leading 0x to correctly indicate that the last two
fields are in hex.
5 stand 40555 1209044741 1024 8 NA 10 0x2 0x40000001
archive_content
The archive content file accepts the following keywords 74:
include filename | directory

Includes the specified filename or directory and all
74
This data is from the make_net_recovery manual page

subdirectories and associated files. Mount points are not

crossed and symbolic links are not followed. Note, file
names may NOT end with a space.
inc_cross filename | directory

Include the specified filename or directory and all
subdirectories and files contained underneath
subdirectories. Local mount points are crossed but symbolic
links are not followed. Note, file names may NOT end with a
space.
inc_entire volume group | disk

Include the entire specified volume group (e.g., "vg00") or
disk (block device - e.g., "/dev/dsk/c0t5d0"). Do not
specify a disk if it is part of a volume group.
inc_all_affected
Is equivalent to using -A option. Based on the files that
are specified for inclusion, this option determines which
disk(s) and/or volume group(s) contain those specified
files, and includes all files from those disk(s) and/or
volume group(s) in the archive.
exclude filename | directory

Exclude the specified filename or directory and all
subdirectories and files contained under the subdirectories.
Note, file names may NOT end with a space.
There are some important things to note when using these keywords.
1. The inc_entire is the only keyword that accepts a disk device as an argument, however the disk
must be a “whole disk” that is it must contain a filesystem spanning the whole disk. Ignite-UX
will not save the contents of raw devices and recover them.
2. Pay careful attention to the difference between inc_cross and include, include will not cross mount
points but inc_cross will.
3. When using inc_all_affected (or using the –A option to make_net_recovery or
make_tape_recovery) understand that of a disk or volume/disk group is partially included (even if
it’s just one file) all of the affected disk or volume/disk group will be fully included into an
archive.
It’s possible to test what will happen on a with different archive content files on a running system without
impacting it.
The following are examples of showing what a recovery archive would do with different archive content
files (performing these tests are very quick it usually takes no more than a few seconds). In the output the
numbers have the following meaning:
0 Not included into archive

1 Partially included into archive
2 Fully included into archive
The first exampe shows the equivalent of using -A with the make_net_recovery or make_tape_recovery
commands. As expected the contents of the root volume group are fully included into the archive.
# cat archive_content_one
inc_all_affected
# /opt/ignite/lbin/list_expander -dv -f archive_content_one
In? dsk/vg name minor# Associated disks/mountpoints

2 v /dev/vg00 0x00 /dev/dsk/c2t1d0s2

/dev/vg00/lvol1 /stand 2
/dev/vg00/lvol2
/dev/vg00/lvol3 / 2
/dev/vg00/lvol4 /tmp 2
/dev/vg00/lvol5 /home 2
/dev/vg00/lvol6 /opt 2
/dev/vg00/lvol7 /usr 2
/dev/vg00/lvol8 /var 2
/dev/vg00/lvol9 /var/opt/ignite/depots
2
/dev/vg00/lvol10
0 v /dev/vg01 0x01 /dev/dsk/c3t0d0
/dev/vg01/lvvm0011
/dev/vg01/lvvm0012
...
The logical volume /dev/vg00/lvol10 are not given because it is not currently mounted (in this example it
was an unused currently empty logical volume). The second volume group is not included at all because it
contains logical volumes used by HPVM guests, it does not contain any filesystems mounted on this system.
The following archive_content file includes everything that is affected but excludes /tmp and it also
excludes /var/opt/ignite/depots (which would need to be recovered from regular system backups).
If this system had a /var/opt/ignite/depots/recovery_cmds depot it would need to be recovered from regular
backup tapes the matched when this recovery archive was created. If it is recovered from regular backups
and the depot was created using a different version the version of Ignite-UX to what was recovered using
the depot will lead to lots of errors being output by SD-UX. Also if the depots recovered from regular
backups don’t match what the recovered system had registered you may need to use the swreg command to
unregister/unregister depots to get SD back into sync and create new configurations referring to the depots
(assuming the system is an Ignite server).
# cat archive_content_two
inc_all_affected
exclude /var/opt/ignite/depots
exclude /tmp
# /opt/ignite/lbin/list_expander -dv -f archive_content_two

/dev/vg00/lvol2
/dev/vg00/lvol3 / 2
0
/dev/vg01/lvvm0011
/dev/vg01/lvvm0012
...
In this next example we’ll try to exclude a directory that would be critical during any recovery.
# cat archive_content_three
exclude /etc
# /opt/ignite/lbin/list_expander -dv -f archive_content_three
NOTE: Command 'exclude /etc' has no effect because essential files override
this command.


/dev/vg00/lvol2
/dev/vg00/lvol3 / 1
0
/dev/vg01/lvvm0011
/dev/vg01/lvvm0012
...
As you can see it didn’t work since without an /etc directory the system wouldn’t be able to boot. Note that
the archive content file as provided doesn’t produce a very useful recovery as it contains only a minimal
system and you would need to recover the rest of the system from backup tapes.
The reason why you can’t exclude /etc from the archive is that it is listed in the essentials file:
# cat /opt/ignite/recovery/mnr_essentials
# @(#) $Revision: 10.12 $
#
# /opt/ignite/recovery/mnr_essentials
#
# WARNING: This file should not be modified, for the following reasons:
# - Changes to this file will be overwritten with the next revision.
# - It can lead to including more than you really need without
# the ablity to remove what you add via make_net_recovery(1M).
#
# If you must modify the list of essential files, copy this file
# to the following location, then make the necessary modifications:
# /var/opt/ignite/recovery/mnr_essentials
#
# /var/opt/ignite/recovery/mnr_essentials is checked before
# /opt/ignite/recovery/mnr_essentials when looking for essential files.
#
#
# For information about this file, see make_net_recovery(1M).
# IGNITE_UX_COPYRIGHT 1999 2004 #

# "(C) Copyright 1999-2004 Hewlett-Packard Development Company, L.P." #
# IGNITE_UX_COPYRIGHT #
/sbin
/dev
/stand
/stand/vmunix
/usr/bin
/usr/ccs
/usr/conf
/usr/lbin
/usr/lib
/usr/newconfig
/usr/sbin
/usr/sam
/usr/share
/usr/obam

/usr/include
/bin
/lib
/etc
As the comments in the file note you should NEVER change this file. If you copy the file to
/var/opt/ignite/recovery/mnr_essentials it will be used instead of /opt/ignite/recovery/mnr_essentials. Never
remove any of the current entries in the file. You can add additional directories to include other content by
default. After upgrading to a new version of Ignite-UX you should verify that the contents of the
mnr_essentials file has not changed. If they have you will need to manually merge any changes between the
two files.
command archives
The commands archives are a series of gzipped tar archives that are used by Ignite-UX at various points to
perform certain tasks. They are mainly used when running on an install kernel but there are some cases
where they can be referenced by Ignite-UX on a running system:
# find /opt/ignite -name \*CMDS\*

/opt/ignite/data/Rel_B.11.11/INSTCMDS
/opt/ignite/data/Rel_B.11.11/RECCMDS
/opt/ignite/data/Rel_B.11.11/SYSCMDS
/opt/ignite/data/Rel_B.11.23/INSTCMDSIA
/opt/ignite/data/Rel_B.11.23/RECCMDSIA
/opt/ignite/data/Rel_B.11.23/SYSCMDSIA
/opt/ignite/data/Rel_B.11.31/INSTCMDSIA
/opt/ignite/data/Rel_B.11.31/RECCMDSIA
/opt/ignite/data/Rel_B.11.31/SYSCMDSIA
This shows all of the command archives shipped in the full version of Ignite-UX (the IGNITE bundle). You
can see that there are 3 files assocated with a release of HP-UX and architecture of the system:
INSTCMDS Mainly used during the initial installation stage

SYSCMDS Mainly used after itool has completed and the disk filesystems have been created
(where it is fully extracted onto the system 75).
RECCMDS Used only for the expert recovery shell/menu 76
For HP Integrity servers the naming convention includes "IA" on the end of the command archive. When
discussing command archives we will not usually mention the “IA” at the end. It is assumed that when
talking about HP Integrity systems any reference to, for example, SYSCMDS would really be a reference
to SYSCMDSIA.
The format of the file is a gzipped tar archive (portable tar interchange format as defined by POSIX). We
can easily get a listing of the contents of the file:
# gzcat < /opt/ignite/data/Rel_B.11.11/INSTCMDS | pax -v
75
This is the file that is extracted onto the newly created root disk or volume group during any cold install
or recovery session after you see “* Download_mini-system: Begin”.
76
The recovery shell and/or menu may however load commands and files from the other two command
archive files.


drwxr-xr-x 0 root users Aug 30 2007 ./
dr-xr-xr-x 0 bin bin Aug 30 2007 ./usr/
dr-xr-xr-x 0 bin bin Aug 30 2007 ./usr/ccs/
dr-xr-xr-x 0 bin bin Aug 30 2007 ./usr/ccs/lbin/
-r-xr-xr-x 0 bin bin 290816 Nov 14 2000 ./usr/ccs/lbin/cpp
dr-xr-xr-x 0 bin bin Aug 30 2007 ./usr/lib/
dr-xr-xr-x 0 bin bin Aug 30 2007 ./usr/lib/nls/
dr-xr-xr-x 0 bin bin Aug 30 2007 ./usr/lib/nls/msg/
dr-xr-xr-x 0 bin bin Aug 30 2007 ./usr/lib/nls/msg/C/
-r--r--r-- 0 bin bin 10542 Nov 14
2000 ./usr/lib/nls/msg/C/cpp.cat
-r-xr-xr-x 0 bin bin 987136 Aug 30 2007 ./usr/lib/libcl.2
-r-xr-xr-x 0 bin bin 106496 Aug 30 2007 ./usr/lib/libpthread.1
-r-xr-xr-x 0 bin bin 315392 Nov 14 2000 ./usr/lib/libxcurses.1
...
The contents of command archives are stored path relative not with absolute paths, this allows them to be
used in:
1. The ram root filesystem in a recovery or installation session
2. The on disk filesystems being created by Ignite-UX in a recovery or installation session (before or
after the chroot)
3. On a live system (this usage is very rare).
Warning: NEVER modify the command archives unless directed to do so by HP. Modifying these files
unless directed to by HP is not supported. The install kernel (discussed next) and the commands archives
are built so any dependencies between them are satisfied, indiscriminant changes may lead to unexpected
failures in install or recovery sessions.
install kernels
The Ignite-UX install kernels are regular kernels with a few exceptions, they're not hard to locate in the
filesystem:
# find /opt/ignite -name \*INSTALL

/opt/ignite/boot/Rel_B.11.11/INSTALL
/opt/ignite/boot/Rel_B.11.11/VINSTALL
/opt/ignite/boot/Rel_B.11.11/WINSTALL
The main differences between install kernels and regular kernels are:
1. For HP-UX 11.23 and above they are gzipped (the 11.11 kernels are not), this saves a considerable
amount of disk space (especially for the IINSTALL kernels for HP Integrity systems).
2. They contain the install driver. The install driver (when the kernel ends with INSTALL) changes
how the kernel works during startup (this will be discussed later).
The names of the kernel are:
INSTALL 32bit HP9000 install kernel

VINSTALL 64bit HP9000 install kernel (for V series systems only)
WINSTALL 64bit HP9000 install kernel (for 64bit systems other than V series)
IINSTALL 64bit HP Integrity install kernel
Complete lab five (see “Lab exercise 5 – File formats and product structure”).

install filesystems
The install filesystems really are filesystems, their name is descriptive of their purpose. These are all of the
install filesystems currently shipped with Ignite-UX:
# find /opt/ignite -name \*INSTALLFS

/opt/ignite/boot/Rel_B.11.11/INSTALLFS
/opt/ignite/boot/Rel_B.11.11/VINSTALLFS
/opt/ignite/boot/Rel_B.11.11/WINSTALLFS
/opt/ignite/boot/Rel_B.11.23/IINSTALLFS
/opt/ignite/boot/Rel_B.11.31/IINSTALLFS
We can show that it's a filesystem. First we'll find out the size of the install filesystem, create a logical
volume that can hold it, and then dd the filesystem into the logical volume:
# ll IINSTALLFS
-r--r--r-- 1 bin bin 61341696 Feb 28 16:08 IINSTALLFS
# lvcreate -L 64 /dev/vg00
Logical volume "/dev/vg00/lvol9" has been successfully created with
character device "/dev/vg00/rlvol9".
Logical volume "/dev/vg00/lvol9" has been successfully extended.
Volume Group configuration for /dev/vg00 has been saved in
/etc/lvmconf/vg00.conf
# dd if=/opt/ignite/boot/Rel_B.11.31/IINSTALLFS of=/dev/vg00/rlvol9 bs=64k
936+0 records in
936+0 records out
We can then create a mount point, mount the filesystem, and then have a look at it:
# mkdir /test
# mount /dev/vg00/lvol9 /test
# cd /test
# ll
total 30
dr-xr-xr-x 2 bin bin 24 Nov 2 2007 cdev
d--------- 2 bin bin 24 Nov 2 2007 core
dr-xr-xr-x 5 bin bin 292 Nov 2 2007 dev
drwxr-xr-x 2 bin bin 24 Nov 2 2007 disc
dr-xr-xr-x 4 bin bin 272 Nov 2 2007 etc
drwxr-xr-x 2 root root 4096 Nov 2 2007 lost+found
drwxr-xr-x 3 bin bin 40 Nov 2 2007 opt
drwxr-xr-x 3 bin bin 536 Nov 2 2007 sbin
drwxr-xr-x 2 bin bin 44 Nov 2 2007 stand
drwxrwxrwx 2 bin bin 24 Nov 2 2007 tmp
drwxr-xr-x 7 bin bin 96 Nov 2 2007 usr
drwxr-xr-x 5 bin bin 60 Nov 2 2007 var
# fstyp /dev/vg00/rlvol9
hfs
Warning: Never modify an install filesystem without explicit instructions from HP, modifying an install
filesystem may cause installation and recovery failures.
At this point complete lab exercise three (see “Lab exercise 3 – Looking at an install filesystem”).

How make_net_recovery works

Some of the programs that make_net_recovery calls will be explained separately from how
make_net_recovery works. This discussion also assumes that neither of the options –i or –p have been used
with make_net_recovery. The make_tape_recovery program will also be explained later (see “How
make_tape_recovery”).
The make_tape_recovery and make_net_recovery programs are in fact the same binary. You can see that
each binary has two hard links:
$ cd /opt/ignite/bin
$ ll make*recovery
-r-xr-xr-x 2 bin bin 479232 Feb 14 2007 make_net_recovery
-r-xr-xr-x 2 bin bin 479232 Feb 14 2007 make_tape_recovery
If we change the ll command slightly to see the inode number we will see that they are in fact hard links to
each other:
$ ll -i make*recovery
5963 -r-xr-xr-x 2 bin bin 479232 Feb 14 2007 make_net_recovery
5963 -r-xr-xr-x 2 bin bin 479232 Feb 14 2007 make_tape_recovery
Although they are the same program a complete discussion of make_tape_recovery will be done in another
section of this course. They may be the same binary but the functionality provided does differ.
The following is a high level overview of what programs make_net_recovery calls (and the order in which
they are called). The options and arguments passed to these commands are not discussed here. This list
assumes that none of the options –i, or -p have been used.
Table 12 - Programs Called By make_net_recovery

Program Brief Description
mount Mount /var/opt/ignite/clients from Ignite server.

lanscan Used to locate client directory on Ignite server.
make_sys_image Check for pax patches (ensures that minimum required pax patches are present on the
system).
list_expander Display what devices, volume and/or disk groups are fully, partially, or not included
into the archive.
check_version check to see if versions on client and Ignite server are compatible
update_tools Update Ignite-UX if required (requires –u option to be passed to command and for
check_version, above, to determine that Ignite-UX needs updating from the Ignite
server).
make_sys_image Backup LIF (saves a copy of the non-default LIF contents to /usr/lib/ignite_bootlif).
list_expander Create the list of devices, volume/disk groups to be included into the archive.
I/O Listener 77 Perform system inventory.
save_config Create the system_cfg configuration file.
instl_adm Validate the syntax of the system_cfg file.
model Used to get the hardware model of the system for certain configuration syntax written
to control_cfg (controls cloning).
instl_adm Validate the syntax of the control_cfg file.
list_expander Create the flist file (a list of all of the files and directories that will be placed into the
archive) and the archive size.
77
The program name is not given here as the I/O listener is a complex topic and will be discussed
separately. That discussion will not be in great detail.

list_expander Provides the raw data for generating impacts for the archive.
make_arch_cfg Create archive_cfg
vgcfgbackup Run on all on all volume groups defined on this system
vgexport Creates map files for each volume group that vgcfgbackup was successfully run on
(does include –s option to enable easy import in the event of recovery issues).
mount Mount NFS archive directory from archive server
make_sys_image Create archive
print_manifest Run the print_manifest command (there is no way to disable this command from
being run).
manage_index Creates the CINDEX file, if required, and adds an entry for this recovery archive.
manage_index Purge information about older recovery archives (depends on the value of the –n
option or the default number of archives to keep).
umount Umount all NFS filesystems mounted previously.
A small but significant number of the programs called by make_net_recovery are scripts. Some are quite
simple and others complex. Because they are scripts it is possible for anyone to troubleshoot them and
attempt to determine what went wrong when a problems is encountered. The following programs from the
list above are all scripts supplied by Ignite-UX and can be read by anyone:
• make_sys_image
• check_version
• update_tools
• save_config
It should be noted that because this course does not include a review of the source code only a high level
discussion of make_net_recovery is performed by explaining general actions at different points in the
program.
This is done by explaining major functional steps in the program and describing the arguments to external
programs. This allows you to gain an understanding of how the program works.
make_net_recovery from the start to lanscan

The make_net_recovery command starts by performing the following actions:
• Clear the environment variable “ENV” – this ensures that unexpected commands are not run when
Ignite-UX runs any shell scripts. Sourcing a .kshrc (ENV is usually set to ~/.kshrc when it is set)
has been known to cause Ignite-UX problems in the past.
• The umask for the process is set (in conjunction with the current umask) to be at least 022
(preventing at least write access group and other). The effective uid is also checked to ensure that
it is 0 (if not an error is logged and the program exits).
• Internal support for debug mode output is setup. The environment variable INST_DEBUG
controls debug level logging. Note that the log file (recovery.log) has not been opened yet.
• The name of the archive is determined is determined. This is the same name that is used in
recovery directory under the per-client directory on the Ignite server to store the configuration and
other files associated with a recovery. The archive name always takes the following form:
# date +"%Y-%m-%d,%H:%M"
2008-05-12,19:24
When referred to later in this course any reference to this value will be <date/time>.

• Variables are setup at this point to determine if this is make_net_recovery or make_tape_recovery

that is running. Note that past this point we will not discuss those variables again or if code is
being conditionally run based on the variables as it will be assumed that it is make_net_recovery
that is running.
• The lock file (/var/opt/ignite/recovery/mnr_lockfile) is created and Ignite-UX attempts to lock it.
Failing to lock the file with errno values indicating that someone else already has the lock causes a
message about another instance of make_net_recovery already running to be printed. Other errno
values cause a more general error message to be printed.
If the lock file exists but is not locked this causes no problems for Ignite-UX. It will simply lock
the existing file.
Important: If Ignite-UX reports that there is another instance of make_net_recovery running

when there should not be - do not remove the lock file. First investigate by running fuser on the
lock file to determine who has it locked. With this information you can determine if there really is
another instance of make_net_recovery running.
• The hostname is retrieved. Normally we won’t be discussing actions such as. It is mentioned here
because if the hostname of a system is a fully qualified domain name Ignite-UX will remove the
domain part of the hostname and use just the hostname.
This is discussed here because it can cause problems if you have the same hostname and use it in
multiple domains. When make_net_recovery is attempting to purge older recovery archives
(according to the setting of –n) it uses the hostname symlink to determine how many archives
exist. It is possible because it doesn’t use the MAC address to go directly to the per-client
directory that it may end up purging the wrong number of older archives.
• The configuration directory from the Ignite server is mounted (/var/opt/ignite/clients is mounted
on /var/opt/ignite/recovery/client_mnt). The next step is to determine the MAC address to be used
for this client. See the next section titled “Looking at add_new_client to understand why lanscan is
called” for more information about how this is done (this processing of the history to determine if
an old clients directory can be reclaimed is also performed in make_net_recovery).
After this some initial files and a directory are created in the per-client directory to enable support
for recovery. Lastly the configuration directory is created in under the recovery directory (in
<date/time> format) and then the latest link is removed (if it exists) and is changed to point to the
newly created directory.
Looking at add_new_client to understand why lanscan is called

In this section we’re going to take a detour away from make_net_recovery for a short time to look at an
almost unrelated script called add_new_client. This script is called as part of adding a new client to an
Ignite server. It’s not called at all from make_net_recovery.
The important thing about this script is that it implements the functionality of making sure that the per-
client directory exists on the Ignite-UX server and creating it if it doesn’t. That allows us to see and
understand what is happening in make_net_recovery without having to see the source code.
This is the function from add_new_client that sets up the client directory if it does not exist:
# ++
# Function: SetupClientDirectory()
# Description: Uses lanscan(1M) to generate a list of potential
# network adapters and then validates or constructs the corresponding

# client directory in /var/opt/ignite/clients

# Arguments: None
# Returns: 0: Success
# 1: Failure
# --
function SetupClientDirectory {
typeset status=1
typeset intrfc=""
typeset curdir=""
#
# Locate lan devices which has a MAC type of "ETHER" || "FDDI" ||
# "802.5" (token ring). At this point we don't care whether or not
# the interface is up or down, we simply want to attempt to re-use
# an existing client directory if it exists
#
#
lanscan | awk '{
if ($2 ~ /^0x*/) {
for (i = 3; i <= NF; i++) {
if ($i ~ /ETHER/ || $i ~ /FDDI/ || $i ~ /802.5/) {
print $2
break
}
}
}
}' > $LANSCAN_RESULTS
Here is some example output so we can see what is happening here:
# lanscan
Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPI
Path Address In# State NamePPA ID Type Support Mjr#
0/1/1/0/6/0 0x001A4B0A828E 0 UP lan0 snap0 1 ETHER Yes 119
0/1/1/0/6/1 0x001A4B0A828F 1 UP lan1 snap1 2 ETHER Yes 119
0/2/1/0/6/0 0x0019BBEB9EFC 2 UP lan2 snap2 3 ETHER Yes 119
0/2/1/0/6/1 0x0019BBEB9EFD 3 UP lan3 snap3 4 ETHER Yes 119
0/4/2/0 0x001A4B06DF7A 4 UP lan4 snap4 5 ETHER Yes 119
0/4/2/1 0x001A4B06DF7B 5 UP lan5 snap5 6 ETHER Yes 119
0/6/0/0/0/0/0/0/0/0 0x00074305406B 6 UP lan6 snap6 9 ETHER Yes 119
Excluding the headings we can see that the second field of the data shows the MAC (Media Access Control)
address and it always starts with 0x. The first if statement in the awk command tests for the second field
always matching the regular expression “^0x*”, this literally means starts with 0 (the ^ anchors the
expression to the start of the field) followed by 0 or more x’s. This probably isn’t the best regular
expression “^0x” would seem to be a better fit since it guarantees that the second field starts with “0x”.
In the for loop we go through each field in the input to see if it contains “ETHER”, “FDDI”, or “802.5” if it
does the second field (the MAC address) is printed. The redirection at the end causes the MAC addresses to
be written (one per line) to the output file contained in the variable LANSCAN_RESULTS. The file with
the above data would look like (this awk command is different because we know that all of the data lines
would match here as they all contain ETHER):
# lanscan | awk ' $2 ~ "^0x" { print $2 } '

0x001A4B0A828E
0x001A4B0A828F
0x0019BBEB9EFC
0x0019BBEB9EFD
0x001A4B06DF7A
0x001A4B06DF7B
0x00074305406B

Now we have some code that processes the file in a loop with each MAC address from the file being stored
into the variable “intrfc” and processed one MAC address at a time. When this code is run the client
directory are already mounted (CLIENT_MNT_DIR is set to client.mnt 78):
#
# If an lan interface was found, ensure that a client
# directory either exists or is constructed
#
if [[ -a $LANSCAN_RESULTS && -s $LANSCAN_RESULTS ]]; then
for intrfc in $(cat $LANSCAN_RESULTS)

do
_LocalDebug "Processing: $intrfc"
if [[ -d /var/opt/ignite/$CLIENT_MNT_DIR/$intrfc ]]; then

_LocalDebug "/var/opt/ignite/$CLIENT_MNT_DIR/$intrfc exists"
status=0
break
elif [[ -d /var/opt/ignite/$CLIENT_MNT_DIR/history/$intrfc ]]; then
mv /var/opt/ignite/$CLIENT_MNT_DIR/history/$intrfc
/var/opt/ignite/$CLIENT_MNT_DIR/$intrfc
_LocalDebug "/var/opt/ignite/$CLIENT_MNT_DIR/$intrfc moved from
history"
# JAGad90684 fix. Remove this client from history.log
rm -f /var/tmp/history$$
grep -v $intrfc
/var/opt/ignite/$CLIENT_MNT_DIR/history/history.log > /var/tmp/history$$
cp /var/tmp/history$$
/var/opt/ignite/$CLIENT_MNT_DIR/history/history.log
rm -f /var/tmp/history$$
_LocalDebug "$intrfc removed from
/var/opt/ignite/$CLIENT_MNT_DIR/history/history.log"
status=0
break
fi
done
If there is a client directory for the client with a matching MAC address (remembering that the clients
directory from the Ignite server is tested to see if the MAC address exists. The one that exists doesn’t have
to be the first one just one that exists on the system as a MAC address. If it doesn’t exist Ignite-UX will
make sure that the client directory hasn’t been moved to history and if it has it will move it back.
Important: HP-UX provides you with the functionality to reprogram the MAC address on most interface
cards (instead of using the burnt in address – also known as a BIA). If you reprogram the MAC address of
an interface so lanscan shows a different MAC address to the burnt in MAC addresses during a recovery or
cold install Ignite-UX will not know about the reprogramed MAC address. In all likelihood Ignite-UX will
use the BIA. If the Ignite server knows the client by the reprogramed MAC address the client will not be
able to find its per-client directory when running the install kernel and will create a new one. This can
prevent a recovery 79.
78
This is different to make_net_recovery since it NFS mounts /var/opt/ignite/clients from the Ignite server
at /var/opt/ignite/recovery/client_mnt not /var/opt/ignite/recovery/client.mnt.
79
Although some customers do use this functionality it is relatively uncommon to change the MAC address
of an interface card away from its BIA.

The next step if the directory can’t be found is to create the per-client directory. As you can see from the
code the first MAC address returned by lanscan 80 is used to create the per-client directory
(make_net_recovery follows this method as well):
#
# If the client directory did not already exist, construct it
# In this case we look for an interface with a supported MAC type
# *and* one that is currently marked as up
#
if [[ $status -eq 1 ]]; then
intrfc=$(head -l -n 1 $LANSCAN_RESULTS)
if [[ ! -z "$intrfc" ]]; then
mkdir -p /var/opt/ignite/$CLIENT_MNT_DIR/$intrfc
_LocalDebug "/var/opt/ignite/$CLIENT_MNT_DIR/$intrfc
constructed"
status=$?
else
status=1
fi
fi
Next the symlink of the hostname pointing to the per-client directory is created here if the per-client
directory was created (or existed) above if the symlink doesn’t already exist (and anything currently
pointing to the per-client directory is removed).
#
# If the client directory exist, export the associated
# environment variable and validate the symbolic link
# to the client hostname (either the short name or fully qualified)
#
export INST_CLIENT_DIR=/var/opt/ignite/$CLIENT_MNT_DIR/$intrfc
if [[ ! -L /var/opt/ignite/$CLIENT_MNT_DIR/$LOCAL_HOSTNAME ]]; then

curdir=$(pwd)
cd /var/opt/ignite/$CLIENT_MNT_DIR
ls -l * | grep $intrfc | awk '{if ($1 ~ /^l/) {system("/sbin/rm
-f " $9)}}'
cd $curdir
ln -s $intrfc /var/opt/ignite/$CLIENT_MNT_DIR/$LOCAL_HOSTNAME
status=$?
print "ERROR: Failed to install symbolic link to
/var/opt/ignite/$CLIENT_MNT_DIR/$LOCAL_HOSTNAME" >&2
fi
fi
fi
else
print "ERROR: Failed to detect an available interface of type: ETHER,
FDDI, or 802.5"
status=1
fi
return $status
}
80
Where the output contains “ETHER”, “FDDI”, or “802.5”..

You can see from the last message that Ignite-UX requires an interface to exist on a system that has a type
of ETHER, FDDI, or 802.5 (the last two are getting more and more rare however).
So as you can see from the above shell script when a per-client directory gets created (assuming it doesn’t
exist in the history) the following actions are performed:
1. Creating a directory under /var/opt/ignite/clients/ on the Ignite server (when mounted on the client)
using the MAC address of the first lan interface returned by lanscan that is of type ETHER, FDDI,
or 802.5.
2. The hostname symlink is created pointing to the per-client directory if it does not exist and all
other symlinks that may be pointing to it are removed (the last action of removing any other
symlinks pointing to the per-client directory is not done if the hostname symlink already exists).
If the per-client directory already exists the script still performs step two above.
make_net_recovery from lanscan to the pax checks

From here we will see what happens after the correct client directory has been selected and it’s been setup
(if required).
• Next the recovery.log file is opened, this file is located in the

/var/opt/ignite/recovery/client_mnt/<MAC>/recovery/<date/time> directory. Where <MAC> is
the LLA (Link Level Address) or MAC address discovered in the previous section. The
make_net_recovery command also places the name of the log file (including directory) into the
environment with the environment variable INST_LOG_FILE. This allows scripts and subsequent
programs to open and write messages into the log file.
• After that there is a check to ensure (since we are creating a network recovery archive) to ensure
that the system can perform a network boot. If the check fails a warning is printed that says:
"<hostname> is not network bootable. See man page for make_boot_tape for information on
using the system recovery archive created by make_net_recovery". All HP Integrity servers can
network boot so this message will never be seen on that kind of system.
The extended regular expression (ERE) that is used to check if the system is capable of a network
boot or not is "/[TVHGIE]|9000/8.7S". This means that the ERE would match a model string if
one of the following is true:
1. It contained a / followed one of the uppercase letters T, V, H, G, I, or E.

2. It contained “9000/8” followed by any character followed by “7S”.
For the first kind of system all of them are past the end of hardware support. For the second case
these systems have been out of hardware support for a very long time.
• If the UI for make_net_recovery was going to be discussed it would be at this point that it is run.
However we will not be discussing it or how information is passed back from it to
make_net_recovery.
• Now we need to run make_sys_image using the command line

“/opt/ignite/data/scripts/make_sys_image -s local –tp” to determine of the system needs pax
patches.
make_sys_image does some pax patch checks

We’re not going to look at the shell script that does the pax patch checks. To be honest it’s not very
interesting to look at. Instead we’re going to discuss the tests including one yet to be added (it hopefully be
present in the 0809 version of Ignite-UX).
The current tests that make_sys_image does for the pax tests are (from the comments within the script):
# The following pax tests are run:

# 1) pax doesn't handle 100 char dir-name (ORIGINAL PAX TEST)
# 2) pax doesn't handle hard/soft links exactly 100 chars.
# 3) pax doesn't give ERROR when hard links >100chars.
# 4) pax doesn't handle zero size hard linked files properly.
# 5) pax doesn't handle files with suid properly.
# 6) pax doesn't handle basename greater than 100 characters OR
# dirname that are greater than 155 characters.
These specific conditions are tested for in the function run_pax_tests() which is called by the function
pax_test_func() which controls the tests and interaction with the user if it is determined that the system
needs a newer pax patch.
Note the return codes that are documented in make_sys_image, you can see that there are two for the pax
checks. A return code of 3 means that the pax patch is not on the system and the user chose not to continue,
and 4 means that the patch is not on the system but the user chose to continue with the archive creation
regardless (when returned in other circumstances it means that it’s a just an indication that a warning
occurred).
# RETURN VALUES
# 0 = success
# 1 = ERROR - ERROR_RET
# 2 = NETWORK_ERROR (Unable to contact server) - NETWORK_ERROR_RET
# 3 = pax patch not on system, user canceled - PAX_PATCH_RET
# 4 = WARNING (including pax patch warning, when user doesn't cancel)
# - WARNING_RET
There’s one pax check that at time of writing this course hadn’t been added into make_sys_image or a
patch released to address it yet (it should be addressed in PHCO_38321 when it is released), it may have
made it in between when this was written and now however. On HP-UX 11.31 when using pax format
archives there is a defect where extended headers 81 for the file name are written with the file name
incorrectly formatted (part of the leading directory is missing from the extended header). You may
encounter this defect if the length of any file name is more than 100 characters long.
make_net_recovery after the pax check

Now we continue with creating the recovery archive.
• After calling make_sys_image we process the exit value. If it is 3 (indicating an error as discussed
previously since the user chose to cancel the archive creation) we exit with error 82. Note an exit
value of 4 (indicating a warning) is ignored, so chosing to ignore the missing pax patch won’t
directly cause make_net_recovery to exit with warnings when it’s complete.
• Next the archive_content file is created. The information placed into this file is created based up
the usage of the –A and –x options (if provided) otherwise the archive_content file given to the
81
This course does not explain the pax interchange format (not to be confused with the pax command that
produces this format archive) however you can read about it in the UNIX 2003 standard available for
viewing on the OpenGroup web site (www.opengroup.org).
82
“exit with error” when discussing make_net_recovery we actually mean we call a routine to do some
cleanup indicating that we want to exit with an error after the cleanup has been done.

command with the –f option is used. If there were no –A, -x, or –f options provided and the –i
option was used (to run the user interface) the archive contents file written by the user interface is
used, finally if none of the above were performed a default archive_content file is written that only
allows for a minimal system to be included into the archive.
The section of the make_net_recovery manual page titled “Including and Excluding From
Archive” explains the format of the archive_content file 83 (all of the values defined there can also
be given with a combination of the –x and –A options).
• The defaults file is read. This file is /var/opt/ignite/clients/<LLA>/recovery/defaults on the Ignite

server. The values from the defaults file are only used if there are no arguments that override them
given on the command line. If there are no values in the defaults file for any item the builtin
defaults used by make_net_recovery will be used instead. The defaults file is automatically created
by the make_net_recovery GUI to communicate back information to make_net_recovery but it can
be created manually.
The valid information for the defaults file is:
RECOVERY_LOCATION=<NFS source>
RECOVERY_DESCRIPTION=”string”
SAVE_NUM_ARCHIVES=<number>
TAPE_DESTINATION=<device>
ARCHIVE_TYPE=tar|cpio|pax
They can be defined as:

1. RECOVERY_LOCATION is the remote NFS filesystem where the archive needs to be
stored, for example 10.10.20.1:/var/opt/ignite/recovery/archives/mysystem.
2. RECOVERY_DESCRIPTION is a quoted string describing the archive.
3. SAVE_NUM_ARCHIVES must be a number, it is the number recovery archives
(including the one being created) that make_net_recovery should leave after it completes.
4. TAPE_DESTINATION can be set this to a device you want to use with
make_tape_recovery (ignored by make_net_recovery).
5. ARCHIVE_TYPE can be set to the archive type required for your recovery archive, the
pax option is not available on systems that do not support it 84.
• If not set (by command line options or the defaults file) the following default values are assigned:
1. The recovery description becomes "Recovery Archive"

2. The number of archives to save becomes 2
3. The archive type is tar (i.e. POSIX tar or ustar interchange format)
RECOVERY_LOCATION and TAPE_DESTINATION do not have default values.
• Next we need to complete the version checks to check the version of Ignite-UX on the client
against the server to ensure that they are compatible.
make_net_recovery and the version check
83
In the past some customers have true to use –x include=<devicefile> to attempt to include a raw device
into a recovery archive, this will not include the contents of the device file into the archive it will only
include the device file (and /dev is always included into a recovery archive regardless).
84
Supported on B.11.31 and should be supported on B.11.23 eventually– it will also require a patch and
enhancement bundle to be installed on HP-UX B.11.23.

The command run by make_net_recovery to perform the version check is “/opt/ignite/lbin/check_version -r

-g -s <ignite_server>”. Similarly to make_sys_image check_version also defines it’s return codes:
# Returns
# 0 - if the versions are the same
# 1 - if they are not the same. (See also -g, and exit 5)
# 2 - if there was an error determining the versions on the server.
# 3 - if the server's IUX version does not support this client's release.(-r)
# 4 - if there was an error determining the versions on this client.
# 5 - if -g option given, and server's version is greater than client.
# This version check ignores A/B/C differences, and includes the ticker
# 6 - if -g option given, and server's major version is greater than client.
# The major version number is the first numeric element of the version.
The make_net_recovery command performs the following actions depending on the return code:
Table 13 - make_net_recovery actions for return codes from check_version

Return Value Action
0 No action take since the versions are the same the command can continue
1 An error is printed indicating that the version of Ignite-UX on this system is newer than on
the server, the make_net_recovery command cannot continue and you must manually
downdate Ignite-UX to match the server.
2 An error is printed indicating that the version of Ignite-UX count not be retrieved from the
server. The make_net_recovery command cannot continue.
3 A message is printed by check_version indicating that the server does not support the
version of Ignite-UX installed on this system. The make_net_recovery command cannot
continue.
4 The file /opt/ignite/Version does not exist on the Ignite server. The make_net_recovery
command cannot continue.
5 without the A warning is given that the version of Ignite-UX on this system is older than the server,
–u option but the command will continue.
6 without the A error is given that the version of Ignite-UX on this system is too much older than the
–u option version of Ignite-UX on the server. The make_net_recovery command cannot continue.
5 or 6 with If this return value is seen and the –u option is given make_net_recovery will attempt to
the –u option update itself from the recovery commands depot on the Ignite server. If the update is
successful make_net_recovery will exec itself again to run the new version of
make_net_recovery 85.
Important: This script implements version checks that prevent invalid Ignite server and client version
combinations. The information supplied here should never be used to change check_version to circumvent
these checks as doing so may lead to recovery archives that cannot be recovered. The purpose of sharing
this information is to allow you to run the check_version command yourself when it prevents you from
running make_net_recovery to an Ignite server so you can determine what the problem is and then
investigate to determine if this how you should expect it to work or not.
The actions taken by the –u option (which causes /opt/ignite/lbin/update_tools to be run) is discussed in the
next section “make_net_recovery and automatic updates”.
Now we’re going to look at the script to see how it works. Code not related to the processing of the options
passed to check_version has been removed as it is not relevant to the discussion. This discussion will
follow the main part of the script and then look at some of the functions called.
85
At this point make_net_recovery probably should have also unmounted the NFS filesystem it mounted
and removed the configuration directory that was created and move the latest link back to the previous last
successful recovery archive also but it doesn’t perform these actions.

As you can see at the start here we get the Ignite-UX version from the file /opt/ignite/Version on the local
system 86. After that we verify that the server passed in with the –s option is not a zero length string.
my_vers="$(cat /opt/ignite/Version)"
if [ -z "$server" ] ; then
echo "$usage" >&2
exit_val=2
exit 2
fi
Next we translate the hostname provided into an IP address. This is done because if the hostname cannot be
resolved by tftp later it does not give a very useful error message (not one that indicates that the name can’t
be turned into an IP address anyway). We’re not going to discuss how getip function works as it is not
directly related to the version check.
# JAGag47172 fix. Check to see if server name is not resolvable. Display a

# unique ERROR message if so.
getip $server >/dev/null
if [[ $? -ne 0 ]] ; then
echo "ERROR: Cannot resolve server \"$server\" name." >&2
exit_val=2
exit $exit_val
fi
Next up we attempt to get the /opt/ignite/Version file from the Ignite server into a local file (VERS_FILE is
/var/tmp/ckvrs.$$ 87). If we manage to get the file from the server we put the contents into the variable
server_vers and call the function compare_vers (discussed below).
if [ $verbose = "true" ]
then
echo "get /opt/ignite/Version $VERS_FILE" | tftp $server
echo ""
else
echo "get /opt/ignite/Version $VERS_FILE" | tftp $server >/dev/null 2>&1
fi
if [ -s $VERS_FILE ] ; then
server_vers="$(cat $VERS_FILE)"
compare_vers
else
If the tftp attempt failed we end up in this code. The tftp attempt could have failed for a valid reason, for
example tftpd has been disabled. Instead we’re going to try to get the revision of two filesets from the
Ignite server (see the fs variable below).
# tftp failed may be due to the disabled tftp daemon on server

# we will try swlist to get the Ignite-UX verion of server
fs='Ignite-UX.RECOVERY Ignite-UX.MGMT-TOOLS'
# 11.00 swlist can produce copious WARNING messages when remotely swlisting
# newer systems, producing too much output. Send stderr to /dev/null.
86
This file is a really helpful file, if you ever need to know the version of Ignite-UX on a system without
running swlist you can cat /opt/ignite/Version to see the version information.
87
$$ in a shell script is automatically translated by the Korn and posix shell to be the pid of the current
process.

set -A v $(swlist -l fileset -a revision $fs @ $server 2> /dev/null | awk

'$1 !~ /^\#|^$/ {print $2}')
If we didn’t get two revisions from the above command (${#v[*]} returns the number of array entries) we
set the variables containing the revisions to be emptry strings otherwise we assign the array elements to the
variables.
if [[ ${#v[*]} != 2 ]]; then

server_rec_vers=""
server_mgt_vers=""
else
server_rec_vers=${v[0]}
server_mgt_vers=${v[1]}
fi
# If we did not get values for server_*_vers, let the user know
# that we could not determine the versions. This could be because
# Ignite-UX is not installed or because swlist failed for other
# reasons.
if [[ -z $server_rec_vers || -z $server_mgt_vers ]]; then

echo "ERROR: Cannot retrieve Ignite-UX version from server
\"$server\"." >&2
exit_val=2
exit $exit_val
fi
Now if they’re not equal we can complain about it since the Ignite server should have all filesets in the
Ignite-UX product with the same revision. If they do match server_vers is set and the function
compare_vers is called.
if [ $server_rec_vers != $server_mgt_vers ] ; then

echo "ERROR: The Ignite-UX filesets RECOVERY and MGMT-TOOLS on server
\"$server\" do not match." >&2
exit_val=2
exit $exit_val
else # server fileset version strings were equal
server_vers="${server_rec_vers}"
compare_vers
fi
fi
# Only get here in error case

exit_val=2
We can see from the above code that (assuming we can get the Ignite-UX version from the server) the
variable server_vers is always primed and the function compare_vers is always called to compare the
versions. There are two paths to get to this function, the first if we can get the Ignite server version from the
/opt/ignite/Version file via tftp and the second from the output of two different filesets (part of the Ignite-
UX product) via swlist.
Now let’s look at how the versions are compared in the function compare_vers.
#
# Compare versions from both server and client
#
compare_vers()
{

The following code removes the leading letters from the Ignite version number and the second lot of code
leaves only the leading letter, for example:
# my_vers=$(cat /opt/ignite/Version)
# print ${my_vers#[A-Z].}
7.4.157
# print ${my_vers%%.[0-9]*}
C
This makes the job of comparing the versions easier since the version numbers rather than the letters are the
important thing. There is also a historical check to do with the letters that is discussed later.
my_vers_num=${my_vers#[A-Z].}
server_vers_num=${server_vers#[A-Z].}
my_vers_ltr=${my_vers%%.[0-9]*}
server_vers_ltr=${server_vers%%.[0-9]*}
In verbose mode we print the versions from the local system and the Ignite server. If you ever get a
problem with the versions and you don’t understand what the problem is you should run check_version
with the –v option (not forgetting the other options: -r -g -s <ignite_server>).
then
echo "Version on this system: $my_vers"
echo "Version on server: $server_vers"
fi
This check isn’t required any more since Ignite-UX no longer supports HP-UX versions less than B.11.11.
The script only needs to actively prevent HP-UX versions less than HP-UX B.11.11 from being added as
clients of an Ignite server.
# Check if the server can support this client.

#
if [[ ${server_vers_ltr} > "B" && ${clientOS} < "B.11.00" ]]
then
echo "\
ERROR: Ignite-UX server versions greater than \"B\" do not support
HP-UX ${clientOS} clients." >&2
exit_val=3
fi
This check although required doesn’t actually need to ignore the initial letter in the version as there are no
supported versions of Ignite-UX that will have a matching number and a differing letter (the last time that
this happened was for versions B.3.7 and A.3.7 which were released in April 2002 and are no longer
supported).
# Compare the versions without regard to the A/B/C'ness of the

# strings. This is to allow 11.00 IUX servers with the B/C version
# to support 10.20 IUX clients with the A version. The recovery
# commands are the same in both, so it is a don't care and solves
# the problem of 10.20 clients not being able to load the full B/C
# version.
If they’re not equal then we need to start comparing them to see which is higher or lower to make a
decision about the exit code. Both revisions are passed into the function normalize_revs, this function isn’t
going to be covered here but it modifies the revisions. The end result given a pair of revisions is to take
each of the numbers (separated by .’s) and add leading 0’s to them so they end up the same length so for

example 7.4.157 and 6.10.87 would become 7.04.157 and 6.10.087. This allows the script to compare the
two strings using operators like less than 88.
if [ "${my_vers_num}" != "${server_vers_num}" ]
then
# Allow the server's rev to be greater than the client
# if -g option is given. Use normalize_revs to account for
# revs of different lengths and different length elements.
normalize_revs "${my_vers_num}" "${server_vers_num}"
The make_net_recovery command does provide the –g option (and this sets g_opt during the startup of the
script when arguments are processed) we go through and check the different combinations of version
possibilities and this causes the exit values we expect to see set in the variable exit_val.
if [[ $g_opt = true && "$normrev1" < "$normrev2" ]]

then
# Now check the major revision letter
if [ "${my_vers_ltr}" = "${server_vers_ltr}" ] ; then
exit_val=5
else
# Major revision letter does not match
exit_val=6
fi
else
# Ignite-UX versions do not match and no '-g' option
if (( exit_val != 3 ))
then
exit_val=1
fi
fi
fi
The next bit of code effectively does nothing because although we do provide the –r option to
check_version (which sets the variable recovery to “true” the code only does something if the letter in the
server version of ignite-UX is an “A”. This can’t be true when modern versions of Ignite-UX are being
used.
if [ "$recovery" = "true" ] ; then

# If things have been successful until now, or if we have only
# generated a warning condition (exit_val = 5) then promote that
# to the error condition of exit_val = 3 if server does not support
# the client.
if [ "$exit_val" = 0 -o "$exit_val" = 5 ] ; then
# TBD: This is probably obsolete, no more "A" servers?
if [[ "${server_vers_ltr}" = "A" ]]
then
# Server is running the "A" version, and this system is 11.X.
echo "\
ERROR: The Ignite-UX server is running the \"${server_vers_ltr}\" version of
Ignite-UX
which does not support HP-UX ${clientOS} systems. You must use
a server running the \"B\" or \"C\" version of Ignite-UX which
requires the server to be an HP-UX 11 system." >&2
exit_val=3
fi
fi
88
As another example, when comparing versions like 6.9 with 6.10 in a string comparison 6.10 is less than
6.9 but when modified in this way and compared 6.10 is higher than 6.09.

fi
Lastly we exit with the exit value we set earlier, when we return make_net_recovery will process the exit
value and decide what action to take.
exit $exit_val
} # end compare_vers()
Complete lab exercise 8 (see “Lab exercise 8 – How make_net_recovery works (part 1)“).
A discussion of compatibility
This is a good time to launch into a side discussion of exit value 1 from the check_version script. It has to
be said up front that using a newer version on a client system than on an Ignite server is not supported
(Anyone doing this will be told that their issue will not be investigated and their calls open with HP will be
closed). We do need to look at why by looking at a slightly different issue that was reported by a customer.
Obviously check_version prevents you from doing this directly but there are ways you can make this
happen by performing some manual tasks.
Let’s say that you’re running Ignite-UX version C.7.6 on a client and an Ignite server and you create a
network recovery archive. You wish to use the recovery archive to clone a new system but that system is on
another Ignite server. When you attempt the cloning session you encounter errors such as:
ERROR: "/var/opt/ignite/clients/mysystem/recovery/latest/system_cfg",
line 62: Illegal character: "v"
ERROR: "/var/opt/ignite/clients/mysystem/recovery/latest/system_cfg",
line 62: syntax error
ERROR: Problems were encountered while parsing config file:
"/var/opt/ignite/clients/mysystem/recovery/latest/system_cfg".
In all likelihood the version of Ignite-UX running on the new Ignite server that the recovery archive was
copied to is much lower than the original Ignite server. The illegal character “v” being complained about is
more than like the “version=” keyword in the disk layout defined in system_cfg.
It’s important to remember that HP does not provide any guarantee about compatibility for recovery
archives created by newer versions of Ignite-UX recovered with an older version of Ignite-UX. HP does not
support doing this.
You can also run into this issue if you update Ignite-UX create recovery archives and then for some reason
find that you need to remove and reinstall a previous version of Ignite-UX. The recovery archives created
with the newer version of Ignite-UX may or may not work during a recovery 89.
make_net_recovery and automatic updates

If check_version exited with an exit value of 5 or 6 and the –u option was supplied to make_net_recovery 90
the script that we’re discussing here (/opt/ignite/lbin/update_tools) is run with the arguments “-s
89
It really depends on of the configuration syntax has changed between the two versions, but in general HP
will not help you any further in these circumstances once it has been determined that the problem is caused
by attempting to use something created with a newer version of Ignite-UX with an older version of Ignite-
UX.
90
In preview mode update_tools is not run however a message is printed saying that it wasn’t and gives the
command line that needs to be run to update the system. The message is from make_net_recovery.

<igniteserver> -d /var/opt/ignite/depots/recovery_cmds”. When reviewing this script we’re only going to be

looking at part of it and some of the functions that it calls.
The first thing that update_tools does is make sure that it can ping the server passed as an argument. This
provides some level assurance that the remote system is up and responsive. Note that a lot of Ignite-UX
code wants to ping to ensure that a system is contactable, if you have a router between the client and Ignite
server that drops ping packets you are likely to see Ignite failures related to this.
#
# Ping the server and make sure that it can be contacted
# via the network
#
PingSystem $SERVER_NAME
if [[ $? -ne 0 ]]; then
print "\
ERROR: Client could not ping Ignite-UX Server: \"$SERVER_NAME\"" >&2
CleanupAndExit 1
fi
The function ValidateCommandsExist only ensures that swinstall can be located on the system (via the
PATH environment variable).
#
# Verify that the commands we are about to use exist
#
ValidateCommandsExist
if [[ $? -eq 1 ]]; then
CleanupAndExit 1
else
The following code locates the fully qualified path for check_version (if possible). If it doesn’t find it or it
finds it and check_version is not executable the function SwinstallRecoveryBundle is called. If an error is
retrned an error is printed out and the routine that cleans up and then calls exit (CleanupAndExit) is called.
As you can tell for the test it is unlikely that it won’t find it (/opt/ignite/lbin is added to the PATH
environment variable earlier in the script) and the only way it should be not executable would be if
someone manually change check_version so it could not be executed.
check_version_path=$(whence check_version)
if [[ -z $check_version_path || ! -x $check_version_path ]]; then
SwinstallRecoveryBundle
err=$?
if [[ $err -ne 0 ]]; then
print "\
ERROR: swinstall failed to install recovery tools from:\n\
\"$SERVER_NAME:$DEPOT_NAME\"." >&2
CleanupAndExit $err
fi
else
Now we’re going to be called check_version with the name of the server. In the previous section we look at
the return values that check_version could return. We know that we can’t get exit values 5 and 6 from
check_version in this case because the –g option needs to be given (exit values 5 and 6 are returned as 1
when there is no –g).
check_version -s $SERVER_NAME
exitCode=$?
case $exitCode in

An exit value of 0 from check_version means that the versions match. This part of the code is only strictly
relevant to make_tape_recovery however as although some part of Ignite-UX may be installed (enough to
supply the /opt/ignite/Version file) it does not mean that the required filesets to create a recovery archive on
tape are present. That’s why there is a check made to see if the install kernels and the SYSCMDS (or
SYSCMDSIA depending on architecture) file are present.
If they’re not present and this script was called from make_tape_recovery instead of make_net_recovery an
attempt will be made to install the filesets to support the make_tape_recovery command.
0 )
# tools may be up to date, but all filesets
# for tape recovery may not be installed
# check for a kernel that matches this machine and the syscmds
#
bootkern=$(ls /opt/ignite/boot/Rel_${RELEASE}/*INSTALL
2>/dev/null |head -1 )
cmdarch=$(ls /opt/ignite/data/Rel_${RELEASE}/SYSCMDS${ARCH}
2>/dev/null)
if [[ $RECOVERY = "make_tape_recovery" &&

(! -s ${bootkern} || ! -s ${cmdarch}) ]]; then
print "\
NOTE: The some of the required Ignite-UX filesets on the client are\n\
missing. They will be updated from the\n\
server: \"$SERVER_NAME:$DEPOT_NAME\"."
err=$?
print "\
CleanupAndExit $err
fi
else
print "\
* Ignite-UX recovery tools are up-to-date, no action required."
fi
;;
As discussed above this is the return code that 5 and 6 map to when –g is not provided to check_version. In
this case we can be sure that Ignite-UX needs updating and the SwinstallRecoveryBundle function is called
to do just that.
1 )
print "\
NOTE: The version of Ignite-UX software on the client is lower\n\
than that on the server. OR some of Ignite-UX filesets on the\n\
client are missing. Ignite-UX will be updated now \n\
from: \"$SERVER_NAME:$DEPOT_NAME\"."
err=$?
print "\
CleanupAndExit $err
fi
;;
For the other exit values an appropriate error message is printed:

2 )
print "\
ERROR: Unable to determine the version of recovery tools on\n\
server: \"$SERVER_NAME\"."
CleanupAndExit 1
;;
3 )
print "\
ERROR: The server: \"$SERVER_NAME\" does not support the client's \n\
operating system release."
CleanupAndExit 1
;;
4 )
print "\
ERROR: Unable to determine the version of recovery tools on client."
CleanupAndExit 1
;;
* )
print "\
ERROR: Unknown return code received during recovery tool version check."
CleanupAndExit 1
;;
esac
fi
fi
There is code after this that can execute make_net_recovery or make_tape_recovery (interactively mode
only) after this. Since make_net_recovery never makes it execute we will not be discussing it.
This function installs the correct recovery bundle needed for the client (always IUX-Recovery for
make_net_recovery).
# ++
# Function: SwinstallRecoveryBundle()
# Description: Performs the swinstall of the IUX-Recovery (net recovery)
# or Ignite-UX-XX-YY bundle (tape recovery). Also updates
# other Ignite-UX bundles and filesets that are installed
# on the client.
# Arguments:
# Returns: return value of swinstall
# --
function SwinstallRecoveryBundle {
So the first thing to do is to make sure that the recovery commands depot exists (make_net_recovery passed
/var/opt/ignite/depots/recovery_cmds via the –d option, however that depot is also the default depot used by
the command). Given the error messages that can be printed below (asking the user to run pkg_rec_depot
you should not use any other depot with this command other than /var/opt/ignite/depots/recovery_cmds).
The swlist command is used to ensure that the depot exists. This does nothing to ensure that the bundle we
want to install later is present in the depot.
# First check that the depot exists, and give a message on how
# to create it if it does not
swlist $SD_OPTS -l depot -s $SERVER_NAME:$DEPOT_NAME 2>&1 | \
grep -q "No depot was found"
if [[ $? = 0 ]] ; then
print "\
ERROR: Cannot access the depot: \"$SERVER_NAME:$DEPOT_NAME\".\n\
You may need to create the depot by running the command:\n\
\"/opt/ignite/lbin/pkg_rec_depot\" on \"$SERVER_NAME\".
return 1;

fi
For later we get a list of current bundles and filesets installed on the local system.
cur_bundles=$(swlist $SD_OPTS -l bundle | \

awk '$1 ~ /Ignite-UX-/ { print $1"."}')
cur_filesets=$(swlist $SD_OPTS -l fileset Ignite-UX 2>/dev/null | \
awk '$1 ~ /Ignite-UX.*/ { print $1}')
So if we were called by make_net_recovery we just the bundle we want to install to the IUX-Recovery
bundle as that’s all that is required.
if [[ $RECOVERY = "make_net_recovery" ]]; then

# the net recovery bundle is IUX-RECOVERY
recovery_bundle=IUX-Recovery
else
Otherwise we need to install the release specific bundle. The two set commands turn a release identifier
like B.11.31 into 11-31. The first transforms B.11.31 into B-11-31 and the second drops the B- to leave 11-
31. With that we can form together the bundle name.
os=$(echo ${RELEASE} | sed 's/\./\-/g' | sed 's/[AB]\-//')

# the tape recovery bundle is Ignite-XX-YY where
# XX-YY is the HP-UX release
recovery_bundle=Ignite-UX-$os
fi
Next we swinstall the bundle that we’ve decided on from the recovery commands depot on the Ignite server
and store the exit value. Note that we also attempt to install the current bundles and filesets that are on the
system as well. This may not work too well if the full Ignite-UX bundle is installed on the client (IGNITE
is the new bundle name since C.7.0 and before that it was B5725AA) as the full Ignite bundle is never
located in the recovery commands depot.
swinstall $SD_OPTS -x mount_all_filesystems=false \

-s $SERVER_NAME:$DEPOT_NAME \
$cur_bundles $cur_filesets $recovery_bundle 2>/dev/null
ret=$?
If the swinstall failed (perhaps not actually failed but swinstall returned a non-zero exit value) then we
execute the following code. It shouldn’t run in normal circumstances. We get the revision of the client
bundle that we just attempted to install.
# If swinstall fails, check to see if the recovery bundle

# was installed. If the recovery bundle was installed,
# ignore the failure to update the other filesets
# on the client and return success.
if [[ $ret -ne 0 ]]; then
client_bundle=$(swlist $SD_OPTS -l bundle -a revision $recovery_bundle
2>/dev/null)
ret=$?
# if return is non-zero than the recovery bundle wasn't installed,
# so return failure
We get the revision of the same bundle from the server and separate out the revision from both sets of
swlist output.
if [[ $ret -eq 0 ]]; then

# compare the revision of the client's recovery bundle with

# the revision of the server's recovery bundle

server_rev=$(swlist $SD_OPTS -s $SERVER_NAME:$DEPOT_NAME -l bundle\
-a revision $recovery_bundle | \
awk '{if ($1 != "#") print $2}')
client_rev=$(echo "$client_bundle" | \
awk '{if ($1 != "#") print $2}')
And compare them if they’re actually the same the bundle that we care most about got installed and it’s
likely that there was some issue updating something else so we can return 0 since we successfully updated
the bundle, if they don’t match we return 1 to indicate that the bundle didn’t get updated.
if [[ $client_rev = $server_rev ]]; then

# client and server have the same revision of the recovery
# bundle, so return success.
return 0
else
# client and server do not have the same revision of the
# recovery bundle, so return failure.
return 1
fi
fi
fi
return $ret
}
If you are going to use the –u option to make_net_recovery try to only have the bundle required to support
make_net_recovery on the system – IUX-Recovery – it will make the job of updating it automatically a lot
easier for the update_tools script.
make_net_recovery after the version check

Now we can continue on with what make_net_recovery does to create the recovery archive.
• The command “/opt/ignite/data/scripts/make_sys_image -s local –L” is run to backup the non-

default contents of the LIF on the boot disk. The lif contents are written to /usr/lib/ignite_bootlif.
We’re not going to look at how this is done in make_sys_image, if you wish to review the code
remember that make_sys_image is a script that anyone can read.
This is done on both HP Integrity and HP9000 systems. Even HP Integrity servers have a LIF on
the boot disk:
# lifls -l /dev/dsk/c2t1d0s2
===============================================================
ISL -12800 584 242 0 06/10/27 14:23:07
AUTO -12289 832 1 0 06/10/27 14:23:07
HPUX -12928 840 1024 0 06/10/27 14:23:07
PAD -12290 1864 1468 0 06/10/27 14:23:07
LABEL BIN 3336 8 0 07/11/13 23:19:01
# model
ia64 hp server rx4640
# uname -a
HP-UX vhost B.11.23 U ia64 4051507349 unlimited-user license
# lifls -l /dev/disk/disk4_p2

===============================================================
ISL -12800 584 242 0 07/01/10 17:13:32
AUTO -12289 832 1 0 07/01/10 17:13:32
HPUX -12928 840 1024 0 07/01/10 17:13:32
PAD -12290 1864 1468 0 07/01/10 17:13:33
LABEL BIN 3336 8 0 07/11/19 00:54:27
# model
ia64 hp server Integrity Virtual Machine
# uname -a
HP-UX vm001 B.11.31 U ia64 1223587842 unlimited-user license
The following LIF entries are not copied to the backup file: LABEL, FS, SWAP, ISL, AUTO 91,
HPUX, and PAD. HP Integrity systems only contain LIF files in this list so none of them are ever
backed up.
• The list_expander command is run to determine the list of devices that are going to be associated
with the recovery archive. The command run to do this is “/opt/ignite/lbin/list_expander -d -f
<archive_content> (we’ve previously discussed the archive content file and where it is written to).
The information is gathered by the command is saved away inside make_net_recovery.
• The io.info file is created by starting the I/O listener and asking it to perform an inventory of the
system (we will be briefly discussing the listeners in a separate section).
• The system_cfg file is created by calling “/opt/ignite/bin/save_config –f

/var/opt/ignite/client_mnt/<MAC>/recovery/<date/time>/system_cfg …” the volume groups, disk
groups, or whole disks that will be included into the archive (fully or partially) are provided to the
save_config command so it can generate the disk layout for the archive. Information about which
volume groups, disk groups, or whole disks need to be included is gathered from the output of
list_expander.
Most of the functionality of the save_config script will not be covered in this course (parts as they
relate to the I/O listener and a brief general overview will be). When complete the command use to
check the syntax of a configuration file is run over system_cfg (the command is
/opt/ignite/bin/instl_adm –T –f <configfile>).
For more information about save_config see the section “A quick look at save_config“.
• The next step is to backup all of the volume group information. The vgcfgbackup command is run
for all volume groups (any error causes the program to stop doing this and exit in error). After
each vgcfgbackup command the following command is run “vgexport –p –s –m
/etc/lvmconf/<vg>.mapfile”. A map file for each volume group is created. The –s option is used to
include information into the map file to make it easier to vgimport volume groups manually later
if required.
• The configuration file /var/opt/ignite/client_mnt/<MAC>/recovery/<date/time>/control_cfg is

created. It is created directly by make_net_recovery not by a separate program. This control file
contains configuration used to control aspects of the recovery, these include:
1. Shell scripting to run vgimports, vgchange, and vgcfgbackup commands and sets up the
variable _IMPORT_VG so the user can stop volume groups from being imported via the
additional button in the advanced user interface on the basic tab in itool.
2. If the system is using VxVM disk groups a series of VxVM commands will also be
included into the configuration file to allow VxVM to re-start successfully after a
91
If the AUTO file contains something other than “hpux” it is included into the LIF backup.

recovery. If these commands are run or not is also controlled by the setting of the
_IMPORT_VG variable.
3. Setting up the _HP_CLONING variable based on the model string of the system this can
also be changed via the additional button in the advanced user interface on the basic tab
in case a cloning session is being performed to an identical model of system.
4. The configuration variable _hp_hide_other_disks to allow disks that are used by the
system (i.e. they're the disks that will be imported rather than recreated and recovered) to
be hidden so they cannot be accidentally ovewritten. This is controlled by the
_hp_allow_use_of_imports variable which appears as "Allow use of other disks" on the
additional button in the advanced user interface on the basic tab in itool. The value "NO"
means you cannot use them and it is the default, "YES" means that they can be used
during the recovery.
5. Set the internal variable RECOVERY_MODE to TRUE so Ignite-UX knows that this is a
recovery session.
After the configuration file has been written the syntax of the file is validated using the instl_adm
command.
• Now we can generate the flist file. This has to be done before we can generate the archive_cfg file
(in the next step) because the information about what files will be included into the archive is used
to generate the impacts information. The command run to generate the flist file is
“/opt/ignite/lbin/list_expander -s -S -f
/var/opt/ignite/client_mnt/<MAC>/recovery/<date/time>/archive_content -l
/var/opt/ignite/client_mnt/<MAC>/recovery/<date/time>/flist 2> /dev/null”.
A short break from make_net_recovery

You may be wondering why we are presenting make_net_recovery as a list of actions and giving the names
and arguments of the commands being run.
The answer is simple. If you know the steps taken to create a recovery archive you are in a better position
to be able to investigate an issue when a certain action fails.
We can use the creation of the flist file as an example. If there is a problem creating it you know what the
command used to create it is and it’s possible for you to run it independently to determine the cause of the
problem. An example of such a problem might be that you’re not sure why a file isn’t included into the
archive.
The debug level output of make_net_recovery can generate a very large log file, isolating what you believe
to be the failing component and running it independently allows you to create a manageable set of data to
investigate.
Issues with list_expander are also the easiest to investigate as list_expander only uses information from the
system and does not directly rely on information in the per-client directory. That is, it is possible to run
list_expander completely outside of a client configuration to investigate issues with what you believe may
be a list_expander problem. Here’s an example of this:
# cat archive_content
inc_entire vg00
# /opt/ignite/lbin/list_expander -s -S -f ./archive_content -l ./flist
18946770
# pwd
/var/tmp/test
# ll
total 68098

-rw-r--r-- 1 root sys 16 May 16 10:01 archive_content

-rw-r--r-- 1 root sys 34856888 May 16 10:04 flist
The list_expander command does not have a manual page. Since it’s located in the lbin directory it’s not
meant to be called directly only indirectly via other Ignite commands. If you provide most Ignite
commands with an invalid option they will print out a usage statement. The usage statement from
list_expander provides a lot of information about the options:
# /opt/ignite/lbin/list_expander -?
Usage: list_expander [-f file] [-d] [-l -|file [-S] [-C]] [-s] [-v] [-?]
-f file Used to specify the content_list file to use
-d Used to request a list of disks/vgs and indicate
PARTial or FULL inclusion
-l -|file Used to request a list of files or "-" to stdout
-s Used to request a cumulative size of files
-S Used to request the size and date on each file in list
-C Used to request the checksum on each file in list
-A Used to indicate that all files on each selected disk
or volume group are included. If this is in
conjunction with the -d option, inclusion is set to
FULL
-v Used to specify verbose output (show lvols in disk/vg
list)
-m tar|cpio|pax Used to specify the pax format that will be used by
pax.
-? Displays this help screen
Some general notes about list_expander:
1. Ignite-UX no longer uses the –C option and has not in a very long time to generate chksum values
for files. The last time it was actively used was when make_recovery was shipped as part of
Ignite-UX. It is very time consuming and resource intensive (for both disk and CPU). You should
not ever need to use this option.
2. Ignite-UX (make_net_recovery and make_tape_recovery) does not use the –A option only the –f
option to give an archive_content file. The archive_content equivalent of –A is inc_all_affected.
make_net_recovery after generating the flist file

• The next step is to create the archive_cfg file
(/var/opt/ignite/client_mnt/<MAC>/recovery/<date/time>/archive_cfg). Since multiple programs
are called during this phase we will look at the steps in more detail.
1. The impact levels that need to be generated are determined. The impact levels are based
upon the mount point of a filesystem, the more directories in a mount point that is fully or
partially included into an archive the higher the impact level that will be used. The
command that is run is “/opt/ignite/lbin/list_expander -d -v -f
/var/opt/ignite/client_mnt/<MAC>/recovery/<date/time>/archive_content 2>/dev/null”.
The output from this command is then parsed to determine the filesystems affected and
what level the impacts need to be.
In this example the Ignite-UX should generate impacts at level 3 (because of

/var/opt/ignite):
# /opt/ignite/lbin/list_expander -d -v -f ./archive_content 2>/dev/null


/dev/vg00/lvol2
/dev/vg00/lvol3 / 2
/dev/vg00/lvol9
/dev/vg00/lvol10 /var/tmp 2
/dev/vg00/lvol13 /var/opt/ignite 2
/dev/vg00/lvol15
2. Now the arguments for the make_arch_config command are prepared. If the
(undocumented) option –N is used “-C n” is added to the arguments (the default is to gzip
the archive). In the tables below this will not be mentioned but it is added to the
arguments to make_arch_config if –N is given to make_net_recovery.
The arguments put together for the make_arch_config command now depend on the
archive type chosen, the following table
Table 14 - make_arch_config commands called by make_net_recovery

Archive type Command
cpio /opt/ignite/lbin/make_arch_config -c
/var/opt/ignite/client_mnt/<MAC>/recovery/<date/time>/archive_cfg -g
/var/opt/ignite/client_mnt/<MAC>/recovery/<date/time>/flist -n <date/time> -r
<architecture> -b <bitness> -d <description> -L <archive_local_mount> -l
<arch_host_dir> -i <impact_level> -m c
pax /opt/ignite/lbin/make_arch_config –c
<arch_host_dir> -i <impact_level> -m p
tar /opt/ignite/lbin/make_arch_config –c
<arch_host_dir> -i <impact_level> -m t
The following new terms were introduced in the above list of commands:
<architecture> - “pa” for HP9000 systems and “ipf” for HP Integrity servers.
<bitness> - 32 or 64 (depends on bitness of the kernel, and can only be 64 only for HP-UX 11.23
and above)
<description> - Archive description (this is a quoted string)
<archive_local_mount> - Local mount point where the filesystem the archive will be stored in is
mounted
<arch_host_dir> - The remote location of the filesystem where the archive will be stored (in NFS
form)
<impact_level> - impact level for recovery archive
The –m option gives an argument to determine the archive type. They are t (tar), p (pax), and c (cpio).
Once make_arch_config completes the archive_cfg file has been created. Although we have looked at how
some other programs work inline with this discussion we’re going to look at make_arch_config separately
after the discussion of make_net_recovery is over (see “Looking at make_arch_config”).

After creating archive_cfg (creating the archive itself)

The next step, now all of the preparation is complete, is to create the archive.
Before we can write the archive we need to mount the remote filesystem where the archive is going to be
stored. The local directory on which this is going to be mounted is /var/opt/ignite/recovery/arch_mnt. The
actual remote filesystem that gets mounted depends on if the –a option was provided to make_net_recovery
or not. If –a was given the remote server/directory provided is used, otherwise the remote directory
mounted will be /var/opt/ignite/recovery/archives on the Ignite server (given with the –s option).
• The directory on which the archive filesystem will be mounted is created.
• If the filesystem that we want to mount at /var/opt/ignite/recovery/arch_mnt is already mounted

then we record this so we don’t attempt to umount it later (Ignite-UX won’t attempt to umount
directories when someone else has already mounted the directory manually).
• If it wasn’t mounted we mount the NFS filesystem that the archive will be written to.
• Once mounted we ensure that the NFS filesystem is writable (there’s no point in continuing if we
can’t write something to the filesystem as writing the archive will fail).
• The umask is changed to be a minimum of 077, this is done to help prevent anyone else from
accessing and reading the archive that will be written.
• Next we get the command together that will be used to call make_sys_image. Similarly to
make_arch_confiug if the undocumented –N option is used the arguments “-c n” will be added to
the call to make_sys_image, again we won’t be including these options into the commands below.
Table 15 - make_sys_image commands called by make_net_recovery

Archive Method Command
cpio /opt/ignite/data/scripts/make_sys_image -d /var/opt/ignite/recovery/arch_mnt -t n -s
local -n <date/time> -m c -w <log_file> -u -R -g
/var/opt/ignite/client_mnt/<MAC>/recovery/<date/time>/flist -a <archive_size>
pax /opt/ignite/data/scripts/make_sys_image -d /var/opt/ignite/recovery/arch_mnt -t n -s
local -n <date/time> -m p -w <log_file> -u -R -g
tar /opt/ignite/data/scripts/make_sys_image -d /var/opt/ignite/recovery/arch_mnt -t n -s
local -n <date/time> -m t -w <log_file> -u -R -g
The following new terms were introduced in the above table:
<log_file> - The name of the log file that messages need to be written to
<archive_size> - The estimate of the archive size previously determined by list_expander.
• The umask is returned to what it was before being changed above.
• The manifest is created by calling print_manifest.
• The CINDEX file for this client is updated to include this newly created recovery archive.
• Cleanup processing is done (this includes unmounting filesystems if make_net_recovery mounted

them) and the creation of the recovery archive is complete.
Complete lab Nine (see “Lab exercise 9 – How make_net_recovery works (part 2)”).

Looking at make_arch_config
The make_arch_config command doesn’t have a manual page. It is located in the /opt/ignite/lbin directory
so it’s not meant to be directly called by anyone. It’s easy to get a usage statement from the program
however:
# /opt/ignite/lbin/make_arch_config -?
Usage: make_arch_config [-r pa|ipf] [-b 32|64] [-c config_file] [-C z|g|n]
[-l [archive_server:]archive_dir] [-m c|t] [-n archive_name]
[-d description] [-g input_file] [-i impact_level] [-L nfs_local_mount]
[-t archive_position]
-r pa|ipf Defines whether the system type is PA-RISC or

Itanium\*R-based
-b 32|64 Defines whether the operating system is 32 or 64-bit
-c config_file Defines an alternate name when creating the config file;
by default this is "archive_cfg"
-C z|g|n Defines whether the compression type is compress, gzip,
or none
-l [a_s:]a_d Defines the archive server and directory; can be local
or a tape drive
-m c|t|p Defines whether the archive method is cpio (c),
tar (t), pax (p) or [default]
-n archive_name Defines the name of the saved archive
-d description Defines the description of the contents of the media.
The description must be enclosed by quotation marks
if the description contains spaces
-g input_file Defines the location of a file previously created by
list_expander containing a list of files to be archived
-i impact_level Defines the impact_level to be used by archive_impact
when generating file system impacts for the archive.
The default is 1
-L nfs_local_mount Describes how to access an NFS mounted directory
through a local directory
-t archive_position Defines whether the skip count of the tape archive
specified by the -l option is 1 (PA-RISC) or 22
(Itanium\*R-based)
-? Displays this help message
And these are the arguments used to call make_arch_config with a tar archive as described in the section
titled “make_net_recovery after generating the flist file”.
/opt/ignite/lbin/make_arch_config –c /var/opt/ignite/client_mnt/<MAC>/recovery/<date/time>/archive_cfg
-g /var/opt/ignite/client_mnt/<MAC>/recovery/<date/time>/flist -n <date/time> -r <architecture> -b
<bitness> -d <description> -L <archive_local_mount> -l <arch_host_dir> -i <impact_level> -m t
The make_arch_config command breaks down into the following main functional areas:
• Write the first part of archive_cfg based on the command line data (this includes the NFS location
of the archive)
• Run /opt/ignite/lbin/archive_impact or /opt/ignite/lbin/gen_impacts (if –g is used gen_impacts is
used to read the flist file directly and generate impacts based on the level provided with –l,
otherwise archive_impact is used to read the archive to create impacts based on the listing of the
archive). The impacts are written directly by these commands into archive_cfg. 92
• Continue writing the rest of archive_cfg
92
Note that –g is always passed to make_arch_config so gen_impacts is always called and the impacts are
created based upon the contents of the flist file.

• Run instl_adm to syntax check the final archive_cfg file.
Note that because make_arch_config when called by make_net_recovery always supplies the –g option
gen_impacts is always called to create impacts based on a flist file never an archive file (the main usage for
calling archive_impacts via make_arch_config is always for a standalone golden image).
Looking into gen_impacts

There is already some discussion of the gen_impacts command in the section titled
"_hp_ignore_sw_impact" of the manual "Ignite-UX Custom Configuration Files" available from here:
It's not an exhaustive discussion and mainly revolves around how make_config calls gen_impacts with the
output from swlist. In this section we will look at little bit more in depth to see how gen_impacts works.
When called from make_arch_config the gen_impacts program is called with the following options 93:
/opt/ignite/lbin/gen_impacts -g /var/opt/ignite/client_mnt/<MAC>/recovery/<date/time>/flist -l
<impact_level>
The gen_impacts program also supports printing a usage message:
# /opt/ignite/lbin/gen_impacts -?
Usage: gen_impacts [-b blocksize] [-f fragsize] [-d dirsize]

[-l levels] [-g inputfile]
-b blocksize Specifies the blocksize to use for calculating archive size
-f fragsize Specifies fragmentation size
-d dirsize Specifies directory size
-l levels Specifies the level of dir for which to find arch size
For example /tmp would be 1, /etc/opt would be 2.
-g inputfile Specifies the input file for reading file sizes
-?|h Used to show the usage of this program
The impact of impacts and blocksize, fragsize and dirsize
Before looking how gen_impacts generates impacts we need to understand some of the assumptions that
are used by gen_impacts:
• We can’t know in advance what kind of filesystem the impacts will be applied to (so assume the
worst case).
• The impacts directly reflect the expected level that will be used.
Let’s look at the second assumption first. When gen_impacts is called via make_net_recovery the level of
impacts expected is determine automatically. The assumption on the highest level of impacts required can
create issues when recovering a system if you wish to define new filesystems 94.
93
here we assume that make_arch_config has been called by make_net_recovery so the argument to the –g
option to make_arch_config is passed as is and the argument to the –i option of make_arch_config is
passed as the argument to the –l option of gen_impacts
94
This issue more directly applies to cold installs but it is worth while discussing this issue here.

Let’s look at an example. A recovery archive is created and the highest level of impacts required for it is 2.
That means that there are no filesystems mounted at more than 2 directory levels down, so there might be a
mounted filesystem at /var/opt or /var/tmp but nothing mounted at 3 directories down like /var/opt/app.
During a recovery let’s say you want to create a new filesystem called /var/opt/app to separate out the
application data files. You have an issue here because the impacts for the recovery archive have been
summarized at level 2 so all of the impacts associated with /var/opt/app have been summarized up into
/var/opt. The impacts for /var/opt/app will be 0 and Ignite-UX during a recovery will insist (because of the
impacts) that you retain enough space in /var/opt to cater for the space used by /var/opt/app.
Because of the way that impacts work you also need to know in advance how much space you need for the
/var/opt/app filesystem. There are no impacts that cover the filesystem so Ignite-UX will be unable to
determine how much space is required based on impacts – you run the risk of filling the filesystem if you
don’t size it correctly.
Please note that this is the expected and correct behaviour with Ignite-UX. For this reason the make_config
command (since it generates configuration files for depots to be used in cold installs) allows you to use the
–l option to define the level at which impacts will be generated, that level should be based on how deep you
expect filesystems to be placed when installing a system. If impacts are created at a lower level by
make_config than you expect to use Ignite-UX cannot force filesystems to be minimum sizes based on
impacts to ensure that you do not experience filesystem full issues during an install.
Now onto the first point about how not knowing what kind of filesystem the archive will be recovered into
affects impacts. Although the configuration for the recovery archive defines the types of filesystems that
will be used, Ignite-UX cannot be sure that these will actually be the types that are used (since, except for
the boot filesystem, you can change a VxFS filesystem to become a HFS filesystem and vise versa during
the recovery).
There are two possible scenarios here that gen_impacts may follow the first is for older versions of Ignite-
UX:
To cater for this issue Ignite-UX assumes that the worst case filesystem usage will occur. The
worst case in terms of space usage is a HFS filesystem. A fragment is a HFS term for how a block
can be split up to cater for smaller files. The term does apply to extent based filesystems like
VxFS.
The gen_impacts program calculates the size of a file using blocks and frags (a block can be split
into 8 frags) with a frag size of 8KiB and a block size of 64KiB and a directory size of 1KiB. The
program also understands when a file will start to use indirect blocks on a HFS filesystem and will
take into account the number of indirect blocks required for the file.
This means that no matter what the actual block/frag sizes used or even if an extent based
filesystem is used (i.e. VxFS) the sizes will be based on HFS filesystems since it gives the worst
case size usage. An example of different size usage would be a small file less than 1KiB, the
impacts for it would give 8KiB for the file since it still requires a frag to be allocated of it is less
than 8KiB however on a VxFS filesystem it’s quite likely that a 1KiB extent will be used for the
file.
The impacts generated are much closer to what would be used on a VxFS filesystem for larger
files. For a lot of smaller files the impacts can be significantly larger than required to store the files
on a VxFS filesystem.
Note again however that this is the expected behaviour of Ignite-UX. It has to cater for the worst
possible case as it’s the only way that it can try to guarantee that no recovery archive would ever
fail to install because the impacts did not allow for enough space.

The second is:
With more recent versions of Ignite-UX the flist format contains more fields. One of these fields is
the expected file size in blocks. The information about the size in blocks is used in preference to
the old method. This will be illustrated in the following section showing the debug output.
In this particular case setting the passing the options to gen_impacts to change the block, frag, or
directory sizes makes no difference to the impacts.
Looking at how gen_impacts works from debug output
In this example we're going to look at some of the debug output from gen_impacts using the following flist
file. Please note that this flist file was manually created for this example.
# cat flist
3 opt 40555 1201455584 8192 8 NA 9 2 40000001
7 opt/app 40755 1081281360 8192 8 NA 2 3 40000001
13 opt/app/file1 100644 1201455725 39996 40 NA 2 4 40000001
13 opt/app/file2 100644 1201455725 39996 40 NA 2 4 40000001
13 opt/app/file3 100644 1118601419 42 8 NA 1 64 40000001
13 opt/app/file4 120755 1201455584 15 0 NA 1 6 40000001
We can now run the gen_impacts command giving our flist file and asking for level 2 impacts.
# export INST_DEBUG=5
# /opt/ignite/lbin/gen_impacts -g ./flist -l 2
DEBUG: /opt/ignite/lbin/gen_impacts is starting up!
DEBUG: imp_debug_flag = 1, debug_flag = 5
DEBUG: gen_impacts: arguments read, about to init_kbyte_sizes.
DEBUG: Starting generate_file_in_sizes
DEBUG: File "./flist" open for reading
DEBUG: Orig line: 3 opt 40555 1201455584 8192 8 NA 9 2 40000001
, str_len = 1, len = 3
DEBUG: File: "opt", remainder line "40555 1201455584 8192 8 NA 9 2 40000001
"
DEBUG: file path: "/opt", Mode values: "40555"
DEBUG: file path: "/opt",Time Stamp values: "1201455584"
DEBUG: file path: "/opt", Block Size values: "8"
DEBUG: There are 7 fields in the input flist. The seventh is checksum.
DEBUG: The input flist may be an new format (> 7 fields).
DEBUG: File "/opt" of type "f" with size "8" and number of hard links "9",
inode number "2", FSID "40000001".
DEBUG: The file has more than one links to it.
DEBUG: Call add_to_cmp_list to add a node.
DEBUG: Add the file to the compare list.
DEBUG: This is a new list.
Added 8 Kbytes for this dir/file
The number of blocks is 8 so the size added to the impacts is 8KiB.
DEBUG: Orig line: 7 opt/app 40755 1081281360 8192 8 NA 2 3 40000001

, str_len = 1, len = 7
DEBUG: File: "opt/app", remainder line "40755 1081281360 8192 8 NA 2 3
40000001
"
DEBUG: file path: "/opt/app", Mode values: "40755"
DEBUG: file path: "/opt/app",Time Stamp values: "1081281360"
DEBUG: file path: "/opt/app", Block Size values: "8"

DEBUG: File "/opt/app" of type "f" with size "8" and number of hard links
"2", inode number "3", FSID "40000001".
DEBUG: The inode number is "9187071506918697256".
Again the size in the flist file is 8 blocks so the size added to the impacts is 8KiB.
DEBUG: Orig line: 13 opt/app/file1 100644 1201455725 39996 40 NA 2 4 40000001

, str_len = 2, len = 13
DEBUG: File: "opt/app/file1", remainder line "100644 1201455725 39996 40 NA 2
4 40000001
"
DEBUG: file path: "/opt/app/file1", Mode values: "100644"
DEBUG: file path: "/opt/app/file1",Time Stamp values: "1201455725"
DEBUG: file path: "/opt/app/file1", Block Size values: "40"
DEBUG: File "/opt/app/file1" of type "f" with size "40" and number of hard
links "2", inode number "4", FSID "40000001".
In this case the number of blocks is 40 so the size added to the impacts is 40KiB.

, str_len = 2, len = 13
DEBUG: File: "opt/app/file2", remainder line "100644 1201455725 39996 40 NA 2
4 40000001
"
DEBUG: Found the hard link.
DEBUG: The link count now is 9187071506918697256.
DEBUG: Delete the node in the list.
DEBUG: Next node is not NULL.
DEBUG: Next node is NULL.
DEBUG: Prev node is NULL, it is head.
Now we have something slightly different, we've found a file with more than one hard link for which the
file it has been linked to has been found. This adds no size to the impacts otherwise we would be double
counting the file.

, str_len = 2, len = 13
DEBUG: File: "opt/app/file3", remainder line "100644 1118601419 42 8 NA 1 64
40000001
"


This is a regular file that says the number of blocks it uses is 8 (the size itself is only 42 bytes).

, str_len = 2, len = 13
DEBUG: File: "opt/app/file4", remainder line "120755 1201455584 15 0 NA 1 6
40000001
"
This file adds nothing to the impacts because it's a symlink not a regular file (you can tell it's a symlink
because the permissions show 120755 and 12 at the start indicate that it's a symlink - see
/usr/include/sys/stat.h for more information on the test for a symlink)
impacts = "/" 8Kb

impacts = "/opt" 8Kb
impacts = "/opt/app" 48Kb
That gives the impacts we would expect.
Going back to list_expander to see how the blocks are calculated
Now that we’ve seen that the more recent flist formats (and hence recovery archives) use the number of
blocks in the flist file rather than calculating the number of blocks based on file size we need to look at how
list_expander calculates the number of blocks (since list_expander produces the flist file).
The number of blocks printed by list_expander into the flist is the st_blocks member of a struct stat
returned from lstat(2) on the file. This makes the impacts more accurate in modern versions of Ignite-UX
(for archives).
Looking into make_sys_image

In this section we’re going to look at the make_sys_image script. In particular we’ll be looking at how it’s
used by make_net_recovery. The whole script isn’t going to be covered only a few of the more important
areas of the script used to write the archive.
Working out the compression and archive part of the command line
Below we have two routines that are important to the archive creation process. They help setup the
commands required to create the archive.
You'll notice in the variables being used to hold the commands that $? (along the command name) is being
echo'ed into the file in the variable cmdres (this is actually set elsewhere to be /var/tmp/cmd_res$$).

When you have a pipeline, for example:
# find /var/tmp –xdev | pax -w -f - | gzip > output
The exit status from the pipeline is the exit status of the last command. In this case that command is gzip.
If one of the earlier commands experiences an issue and terminates it's not directly possible to determine
which one failed from the exit status of the pipeline. More than likely it will have printed an error, but it’s
hard to determine if something went wrong within a program.
To make sure that all of the commands used in a pipeline have completed successfully make_sys_image
takes a different approach. All of the commands being executed in the pipeline write their individual exit
values into a file. Later the file can be read to determine if all of the commands completed successfully.
So if the command above was changed to:
# (find /var/tmp -xdev ; echo find $? >> exit_vals) | (pax -w -f - ; echo pax $?
>> exit_vals) | (gzip > output ; echo gzip $? >> exit_vals)
We can look at the exit_vals file when the pipeline completes and determine the exit value of all of the
commands:
# cat exit_vals
find 0
pax 0
gzip 0
And see that they exited with no errors being reported. That is they all had a 0 exit value.
Now we can start looking at parts of make_sys_image. For each of the compression types supported by
make_sys_image (compress, none, gzip) we setup the compression command, the suffix used by default by
the compression command and the expected average compression ratio.
# how_to_compress()
#
# Setup the compression method for the system image and the filename
# suffix to be used. Default is gzip (gz).
#
how_to_compress() {
case ${1} in
z) COMPRESS="(/usr/bin/compress; echo compress \${?} >> ${cmdres})"
SUFFIX="Z"
RATIO=1.55
;;
n) COMPRESS="(cat; echo cat \${?} >> ${cmdres})"
SUFFIX="none"
RATIO=1.005 # seems odd, but pax has a small compression side effect
;;
*) COMPRESS="(/usr/contrib/bin/gzip; echo gzip \${?} >> ${cmdres})"
SUFFIX="gz"
RATIO=2
;;
esac
} # End how_to_compress()

For each of the archive types supported by Ignite-UX (cpio, pax, and tar) we setup the command that we're
going to use create the archive, and set the default block size for the archive type. Note that we will not be
reviewing the operation of the function filter_pax_bug_files.
how_to_archive() {
typeset input=${1}
# Archive method specific variables.

#
case ${input} in
c) METHOD="cpio"
ARCH_COMMAND="(find_files ; echo find_files \${?} >>
${cmdres}) \
| (${pax_cmd} -dwx cpio -f - ; echo pax \${?} >>
${cmdres})"
BLOCK="5120"
;;
p) METHOD="pax"
ARCH_COMMAND="(find_files ; echo find_files \${?} >>
${cmdres}) \
| (${pax_cmd} -dwx pax -f - ; echo pax \${?} >>
${cmdres})"
BLOCK="5120"
;;
*) METHOD="tar"
if (($bad_pax)); then
ARCH_COMMAND="(find_files ; echo find_files
\${?} >> ${cmdres}) \
| (filter_pax_bug_files ; echo
filter_pax_bug_files \${?} >> ${cmdres}) \
| (${pax_cmd} -dwx ustar -f - ; echo pax \${?}
>> ${cmdres})"
else
ARCH_COMMAND="(find_files ; echo find_files
\${?} >> ${cmdres}) \
| (${pax_cmd} -dwx ustar -f - ; echo pax \${?}
>> ${cmdres})"
fi
BLOCK="10k"
;;
esac
} # End how_to_archive()
The above two functions are called by the archive_setup function:
# Set compression and archive methods.

#
how_to_compress ${COMPRESS_CHOICE:="g"} # Default use gzip.
how_to_archive ${METHOD:="t"} # Default use tar.
The archive size check
This code calculates if the archive is going to fit onto its destination. This is done for every archive created
by make_net_recovery (and for golden images). Some code cannot be called by the script when run by
make_net_recovery, some it has been removed from this discussion 95.
95
where you see ... code has been removed as it is not relevant to this discussion

archive_size_check() {
For recovery archives since the size we have is generated directly by list_expander when called earlier.
This means that list_expander should never be run here. We looked at how the variable ratio was set in the
last section.
In the code below you will see function calls like lessThan, divide, multiply, and more. These functions
perform arbitrary precision math for the script. The POSIX shell is limited in its integer math to values
between -2147483648 to 2147483647. Using arbitrary precision math removes any limitations caused by
relying on the POSIX shell integer math.
The final result of this is that the archive size is lowered by the expected compression ratio.
if [[ ${recovery_mode} = "TRUE" ]]; then #{
# ARCHIVE_SIZE=(list_expander -s)/ratio
# Now check if the ARCHIVE SIZE was already provided on the input line,
# and if not, then run list_expander to calculate it.
if [[ -n "${IN_ARCHIVE_SIZE}" ]]; then
ARCHIVE_SIZE=${IN_ARCHIVE_SIZE}
else # If not, then run list_expander to calculate it.
ARCHIVE_SIZE=$(${LIST_EXPANDER} -f ${EXTERNAL_FILE} -s)
fi
# Make sure there will be no divisions by zero

ratio=${RATIO:=1}
if [[ $(lessThan ${ratio} 1) = "1" ]]
then
ratio=1
fi
ARCHIVE_SIZE=$(divide ${ARCHIVE_SIZE} ${RATIO})
else
This code is not discussed as make_net_recovery always runs make_sys_image in recovery mode.
...
fi #} End of if [[ ${recovery_mode} = "TRUE" ]]
# See if we are actually local or of we are writting archive to a NFS

dest_dir=${DEST_DIR}
server=${SERVER}
if [[ ${SERVER} = "local" ]]; then #{

if [[ -d ${DEST_DIR} ]]; then #{
pair=$(df -n ${DEST_DIR} | grep -E ' nfs[0-9]$' | \
awk 'FS="("{ print $2 }' | \
awk 'FS=")"{ print $1 }')
if [[ -n ${pair} ]] #{
then
dest_dir=$(echo ${pair} | cut -f 2 -d ":" | \
sed 's/ \{1,\}$//')
server=$(echo ${pair} | cut -f 1 -d ":")
fi #}
fi #}
fi #}
# Caller is testing this function so display some debug information.

if [[ ${IUX_TET_REGRESSION_TESTING} = "1" ]]

then
echo "recovery_mode=true; ARCHIVE_SIZE=${ARCHIVE_SIZE}"
fi
The code that was within this test won't be examined as it is only validating that the if the archive was
greater than or equal to 2000000KiB. The check is actually uneccessary until the archive will be greater
than or equal to 2GiB but since the archive size is an estimate there is some leeway in the size at which the
check starts.
If the server is "local" 96 a check is done to ensure that we're not using NFS v2 since that doesn't support
large files and for a remote system a check is done to ensure that the remote directory exists and if the
remote directory is an NFS filesystem that it's not an NFS v2 filesystem.
if [[ $(greaterThanEqual ${ARCHIVE_SIZE} 2000000) = "1" ]]

then
...
fi #} End of if ((ARCHIVE_SIZE >= 2000000))
Although these commands mention the -u option (which inhibits the space check) there is no way to cause
the -u option to be passed to make_sys_image from make_net_recovery.
# Make sure there is enough room in the destination directory.

# If the destination is a device we can't easily check capacity so skip,
# or if the command line specifies "-u".
#
if [[ ${NOCHECK} = "0" ]]; then #{
The main reason arbitrary precision math is used in this script now is because we store need to do
calcuations based on the free space in a filesystem returned from the df -b command. Filesystems with
more than 2TiB of free space this used to cause errors in the free space calculations.
if [[ ${SERVER} != "local" ]]; then #{
DEST_SIZE=$(remsh ${SERVER} -l ${REMSH_USER} -n df -b ${DEST_DIR} |

awk '{cnt=NF-2; print $cnt}')
else
DEST_SIZE=$(df -b ${DEST_DIR} |
awk '{cnt=NF-2; print $cnt}')
fi #}
...
The following should not happen in normal circumstances. The script should have been able to determine a
size. It is possible if the filesystem is already full that the value of amount free may be 0, so the check on it
being (less than or) equal to zero is needed to prevent a problem with a divide by 0.
# If the DEST_DIR doesn't exist then plug in a size so DEST_SIZE has

value.
: ${DEST_SIZE:=1}
# If df reports 0 or less available, plug in 1 to prevent div by zero.
(( $(lessThanEqual ${DEST_SIZE} 0) )) && DEST_SIZE=1
The following code needs some explaination because its effect is not immediately obvious. We'll do that
with an example where we have several values for the archive size and a fixed amount of free space in the
destination filesystem (sizes are in KiB):
96
It is for make_net_recovery since we're writing to an NFS mounted filesystem locally- in this case it
doesn't matter that the actual filesystem is remote.

Table 16 - make_sys_image free space calculation

Archive Size Free space PERCENT_DIFF
2000000 7000000 28.57
4000000 7000000 57.14
6000000 7000000 85.71
8000000 7000000 114.29
The value calculated into PERCENT_DIFF is the percentage of the free space left that we will end up using
for this archive.
mult=$(multiply 100 ${ARCHIVE_SIZE})

PERCENT_DIFF=$(divide ${mult} ${DEST_SIZE} )
...
Now as you can see if PERCENT_DIFF is more than 99 (i.e. we will use more than 99% of the free space
left) that it will generate an error:
# If a volume is more than 99% full, then don't proceed.

if [[ $(greaterThan ${PERCENT_DIFF} 99) = "1" ]]
then
verbose -fe "\

ERROR: Not enough space for archive.
${server}:${dest_dir} needs ${ARCHIVE_SIZE} kbytes free.
There are ${DEST_SIZE} kbytes free."
else # There appears to be enought room to proceed, so do so.
DEST_REMAIN=$(subtract ${DEST_SIZE} ${ARCHIVE_SIZE})

(( $(lessThan ${DES_REMAIN} 0) )) && DEST_REMAIN=0 # Print
reasonable message.
if [[ $SERVER != "local" ]]; then #{
ARCHIVE_SIZE_DESTINATION="${SERVER}:${DEST_DIR}"
else
ARCHIVE_SIZE_DESTINATION=${DEST_DIR}
fi #}
print "\
* The archive is estimated to reach ${ARCHIVE_SIZE} kbytes.
* Free space on ${ARCHIVE_SIZE_DESTINATION}
after archive should be about ${DEST_REMAIN} kbytes."
fi #} End of if (( PERCENT_DIFF > 99 ))
fi #} End of if [[ ${NOCHECK} = "0" ]]
} # End archive_size_check()
As you can see there are approximations in the archive size. We can't actually know the final archive size
until after it's created. This is a best effort check on the size to ensure that it will fit without filling the
filesystem.
The code is written to assume that it will be the only program writing to the filesystem. If two copies of
make_net_recovery are running at the same time on two different clients it is possible that they may fill the
filesystem if there isn't much free space available.
There's nothing that Ignite-UX can do about this issue. Yous should consider that issue an adminstrative
one. It is up the the administrator to ensure that there is enough free space for the expected usage of
make_net_recovery.

Creating the archive
When looking at this function code not used by make_net_recovery has been removed to make it easier to
see the code path. If you look at this function in make_sys_image it is significantly longer. Most of the
code in the function is not executed by make_net_recovery.
archive() {
First up just in case there's anything still running in the background we called "wait" to wait for them to
complete.
# Check for 'find' processes put in background, wait until they are done.
#
verbose " * Waiting for background processes to complete."
wait
...
We've already discussed how the archive size checks see the section "The archive size check" for more
information.
# Get approximate size of compressed archive.

# Make sure the destination has enough space.
#
archive_size_check
# Message telling the method of archiving, where it is going, and how big.
#
message
# Pack it up.
#
if ((! PREVIEW))
then #{
cd /
if [[ ${WHERE} = "device" ]]; then #{
The code to do with writing to a device (local or remote) has been removed as it is not relevant to our
discussion of make_net_recovery.
else #destination is a file system
You can see here in verbose mode the command that will be used to perform the archive will be printed.
We run eval on the pre-built command segments that we've seen created in other functions to create the
archive. The find_files function called at the very start of the sequence of commands will be looked at in
the next section (see “Looking at find_files and $filter_dead_files”).
if [[ "${SERVER}" = "local" ]]; then #{

#
# Writing to local file system.
# NB. to restore:
# gzcat (archive name)|pax -r -pe
#
verbose " * ${ARCH_COMMAND} | ${COMPRESS} >\n
${DEST_DIR}/${ARCHIVE_NAME}"
eval "${ARCH_COMMAND} | ${COMPRESS} >
${DEST_DIR}/${ARCHIVE_NAME}"
else

The code here has been removed because make_net_recovery does not write to remote filesystems using
remsh only to (in effect) a "local" filesystem that is NFS mounted.
fi #} End of if [[ "${SERVER}" = "local" ]]; then #{
fi #} End of if [[ ${WHERE} = "device" ]]; then #{
fi #} End of if ((! PREVIEW))

...
Now we can read the command result file and see if there were any non-zero exit values logged. As you
can see from the code a non-zero exit value from pax or an exit value of 2 from cat only generates a
warning, other commands with non-zero exit values (or cat with an exit value other than 0 or 2) will cause
an error to be printed.
########################################################################
# Check for errors in pipe
#
# 0 is: good
# 2 is: ERROR for pax & cat, put often pax errors can be ignored
# WARNING for find_files (list_expander), gzip, & compress
# other is: ERROR
#
while read cmd result
do
if [[ "${result}" != "0" ]]; then #{ possible error
if [[ ( "${cmd}" = "pax" ) || ( "${cmd}" != "cat" && "${result}" =
"2" ) ]]; then #{
verbose -e "WARNING: The ${cmd} command returned a non-zero
exit status (exit status ${result})." >&2
else
verbose -fe "ERROR: The ${cmd} command failed (exit status
${result})." >&2
fi #}
fi #}
done < ${cmdres}
} # End archive()
Looking at find_files and $filter_dead_files
This function is called as part of the archival processing to generate the list of files to be included into the
archive. In the case that we're looking at (when called by make_net_recovery, and also by
make_tape_recovery) we always have the shell variable recovery_mode is set to "TRUE" and we are
always provided with a flist file.
######################
# find_files()
#
# Do a find on the entire file system, filtering out the undesired files
# as indicated by the ignore lists.
#
#
find_files() {
# Starting find_file
if [[ "${recovery_mode}" = "TRUE" ]]; then #{
# recovery_mode set
if [[ -n "${FILE_LIST}" ]]; then #{
# File List already supplied, using.

Now we have to work out the number of fields in the first line. The minimum number of fields in the flist
file is 10. Currently it's also the expected number.
Part of the awk script is not longer required. Both of the shell variables CS_NMBR_FLDS and
MIN_NMBR_FLDS are set to 10 as there are no optional fields any more. In all cases when called by
make_net_recovery and make_tape_recovery there should be 10 fields unless there was a major error on
the part of list_expander creating the flist file. If there's an empty flist file the exit value will be "ERROR".
# Find out the number of fields in the first line.

# ${MIN_NMBR_FLDS} gives the minimum number for the
# "large" line. The file name line will only have one field.
# However, if the first file does have a space in it, just
# testing against one (1) will give a false result. So, loop
# through as many files as needed to determine actual # of fields.
# If no # of fields is determined, then exit out.
NUM_FIELDS=$(awk -v ck_sum_flds=${CS_NMBR_FLDS} \
-v min_flds=${MIN_NMBR_FLDS} \
-F" " \
'{exit_val="ERROR" # Default is to say
that ERROR occurred.
if (NF==0) {
# Ignore empty lines.
} else if (NF==1) { # If only one field,
then name
exit_val = NF
exit
} else if (NF==min_flds) { # If min number
fields, then OK
exit_val = NF
exit
} else if ($1==length($2)) { # If second field
entire name,
if (NF==ck_sum_flds) { # then if CK_SUM
length, then OK
exit_val = NF
}
exit
}
# If "NF!=0" and
# "NF!=1" and
# "NF!=min_flds [i.e. 10]" and
# "$1!=length($2) [i.e. filename has
spaces(FS)]
# then try next line.
}
END {print exit_val}' ${FILE_LIST})
This is our one and only bit of validation to make sure that there wasn't an error trying to calculate the
number of fields in a line. If the validation failed we print an error and exit with an error return value to let
make_net_recovery know that things went very wrong.
Note with the current exit codes we can only exit with an ERROR, 1, or 10.
if [[ "${NUM_FIELDS}" = "ERROR" ]]; then #{

# JAGaf73846 fix. Since the exit ${ERROR_RET} does not work.
# Add following line so that the ERROR will result in
make_sys_image
# return ${ERROR_RET} (ERROR out).
echo find_files ${ERROR_RET} >> ${cmdres}
verbose -fe "\

ERROR: Could not calculate the number of fields per line in the input
lines; the files will not be archived."
exit ${ERROR_RET}
fi #}
If the number of fields is less than the minimum number of fields then this file only contains file names and
nothing else so the list of names can be passed directly to the script contained in the variable
filter_missing_files (which we will look at immediately after reviewing this function).
# Now check the number of fields per line

if ((NUM_FIELDS < MIN_NMBR_FLDS)); then #{
cat ${FILE_LIST} | ${filter_missing_files}
else
Now we need to extract the file names from the flist file. It's extremely rare for something to go wrong here.
Unlike what the comments below say although the checksum isn't used a field for it is present (containing
"NA"). Even if it is present in a flist file it will not interfere with the operation of this function.
# Extract pathnames from ${FILE_LIST}. Since Checksum is not

yet used,
# using MIN_NMBR_FLDS is OK for now. However, when checksum is
used,
# it will NOT be OK.
awk -v min_flds=${NUM_FIELDS} \
-v bline_file=${bad_line_file} \
-F" " \
'{if (NF==0 ) {
# If nothing on line, print nothing
} else if (NF<min_flds) { # Not enough fields on line,
error
print " line: "$0 >> bline_file
} else if (NF==min_flds) { # Minimum fields on line,
if ($1==length($2)) { # so verify field 2
expected length
print $2
} else { # If not, this is an error.
}
} else {
num_chars = $1 # Make sure at least enough
chars.
len_bgn = length($1) + 2 # Starting position in $0
of pathname.
max_len = length($0) - (length($1) + 1)
frst_end_fld = NF - min_flds + 2
for (i=NF; i>frst_end_fld; i--) {
max_len = max_len - length($i) - 1
}
# Should only be == for test, but this is OK...
if ($1<=max_len) { # If acceptable length,
print
print substr($0, len_bgn, num_chars)
} else { # If too long, error
}
}
Note that lines that are not valid are written to the file bline_file (bline is short for bad line).
Again, once the list of files is generated it's sent as stdin to the script in the variable filter_missing_files.

}' ${FILE_LIST} | ${filter_missing_files}
fi #} End of if ((NUM_FIELDS < MIN_NMBR_FLDS))
else # End FILE_LIST provided, start FILE_LIST not provided
The list_expander command below is never used by make_sys_image when called from
make_net_recovery or make_tape_recovery.
${LIST_EXPANDER} -f ${EXTERNAL_FILE} | ${filter_missing_files}
fi #} End of if [[ -n "${FILE_LIST}" ]] (FILE_LIST not provided)
return
else # End recovery_mode set, start recovery_mode not set

...
This code has been removed as it is not relevant to recovery mode.
fi #} End of if [[ "${recovery_mode}" = "TRUE" ]]
return
} # End find_files()
Now we need to do some investigation into what is in the shell variable filter_missing_files since it
contains the name of a script that gets called. The variable and the script that it points to are setup by the
function archive_setup.
Here we setup the script for filter missing files. It's a temporary script so we need to create a temporary file
name. The mktemp command can do that and with the -p option we provide the prefix and the command
adds something to the end of it to guarantee uniqueness, for example:
$ mktemp -p make_sys_image_fmf.
/tmp/make_sys_image_fmf.a24507
Note that make_sys_image (or make_net_recovery or make_tape_recovery) does not export TMPDIR so
the temporary file is created in /tmp. The script gets written out into that file and we continue after
changing the owner and mode of the script.
#-----------------------------------------------------------------------
# Generate our "filter_missing_files" script.
export filter_missing_files=$(mktemp -p make_sys_image_fmf.)
cat << SH_INPUT_EOF1 > ${filter_missing_files}
#!/usr/bin/sh
# Script : filter_missing_files()
# Purpose: Created (dynamically) and used by the make_sys_image shell
# script.
# Flow : Reads a list of pathnames from standard-input and checks each
# to determine if it still exists on the system; if so, echo the
# pathname to standard-output; otherwise, append the pathname to
# the \${TMP_GONE_FILE_LIST} file which will be printed later.
while read -r FILE_IN
do #{
if [[ ( -L "\${FILE_IN}" ) ||
( -f "\${FILE_IN}" && -r "\${FILE_IN}" ) ||
( -d "\${FILE_IN}" && -r "\${FILE_IN}" ) ||
( -b "\${FILE_IN}" && -r "\${FILE_IN}" ) ||
( -c "\${FILE_IN}" && -r "\${FILE_IN}" ) ||

( -p "\${FILE_IN}" && -r "\${FILE_IN}" ) ||

( -S "\${FILE_IN}" && -r "\${FILE_IN}" ) ]]; then
print -r -- "\${FILE_IN}"
else
print -r " /\${FILE_IN}" >> ${TMP_GONE_FILE_LIST}
fi
done #}
#end of filter_missing_files#
SH_INPUT_EOF1
chown bin:bin ${filter_missing_files}
chmod 555 ${filter_missing_files}
This script doesn't do very much. All if does is test to see if a file exists and if it does print the file name.
The pax command is the next command in the pipeline that reads the list of files from stdin and writes the
archive to the next pipeline stage.
The ordering of the way the test for different types of files is important. The -L test (to see if the file is a
symlink) being first is extremely important. The reason for this this is that testing for -L causes the shell to
call lstat(2) on the file to see if the file is a symbolic link.
Other tests that follow it for other file types may use stat(2) instead of lstat(2). This is important when the
value of $FILE_IN may be a symlink that refers to an autofs or NFS mount point. Using stat(2) on such a
symlink would trigger the mount to happen, if the associated NFS server(s) are currently unavailable
make_sys_image may hang until the mount point starts to respond to requests again. This is why –L is the
first test even though it would make more sense to have –f as the first test.
Complete lab exercise ten (see “Lab exercise 10 – How make_net_recovery works (part 3)”).
Troubleshooting NFS issues that can affect make_net_recovery

Ignite-UX depends on a lot of things being configured correctly and working. One of those things is NFS
and a lot of things can go wrong with NFS.
NFS configuration (11.23 and below)
NFS configuration on HP-UX 11i v2 and below is consistent and familiar. This is the way that NFS has
always been configured on HP-UX. There are two main places that you need to look at on an Ignite server
when you encounter an NFS issue (the most common one is that you are not authorized to mount a
filesystem).
In /etc/exports (the place when you configure NFS exports so what you export is still exported after a
reboot) Ignite-UX always expects something that looks like as a minimum:
# more /etc/exports
This exports the /var/opt/ignite/clients filesystem with anonymous access (remote root access as bin 97)
which is required by Ignite-UX.
# more /etc/exports
/var/opt/ignite/recovery/archives/scm -anon=2,access=scm
/var/opt/ignite/recovery/archives/akhnaten -anon=2,access=akhnaten
97
The bin user is always uid 2 on a HP-UX system.

There is one issue to be very careful of. If you update the /etc/exports file and do not run exportfs to keep
the kernel and /etc/exports in sync what is in the file may not match the running kernel. An example of this
would be if we added /var/opt/ignite/recovery/archives/akhnaten into /etc/exports and then did not run
“exportfs –a” to export the filesystem. If we attempted to run make_net_recovery we would not be able to
remote mount the filesystem that we want to write the archive to.
In this case you can see /etc/exports doesn’t match the output of exportfs so if we run exportfs –a and then
run exportfs again it shows the filesystem is exported:
# more /etc/exports
# exportfs
# exportfs –a 98
# exportfs
Be careful using access= in /etc/exports if your Ignite clients will be using anonymous IP address from a
DHCP/bootp server when performing a network recovery. Giving access= limits what systems can mount
the filesystem, if a client gets an IP address from a DHCP server it may need to be able to mount the
filesystem using that IP address. Ignite-UX will always export client archive directories with access only
allowed to that client (when a client is setup via the ignite(1) command).
NFS configuration (11.31 onwards)
On HP-UX 11.31 the way NFS is configured has changed, instead of using /etc/exports and the exportfs
command the file /etc/dfs/dfstab and the share/unshared commands. The functions of the new commands
are similar, but some of the syntax is different.
To see what is currently exported use the share command. The following output is from a system that has
just been setup:
# share
# share -F nfs 99
# cat /etc/dfs/dfstab
# place share(1M) commands here for automatic execution
# on entering init state 3.
#
# share [-F fstype] [ -o options] [-d "<text>"] <pathname>
# .e.g,
# share -F nfs -o rw=engineering -d "home dirs" /home
share -F nfs -o anon=2 /var/opt/ignite/clients
If you add a client for recovery on the Ignite server an entry will be added to the /etc/dfs/dfstab file 100:
98
Be careful if you need to unexport a filesystem, exportfs –a only exports new entries in /etc/exportfs that
aren’t listed in the kernel. If you wish to also unexport a filesystem you must add the –u option. Use –au to
perform both actions at once.
99
The option “-F nfs” is not required to just view what is currently shared.
100
this example wraps however the entry must occupy one line in /etc/dfs/dfstab

/usr/sbin/share -F nfs -o sec=sys,anon=2,rw=scm

/var/opt/ignite/recovery/archives/scm
With NFS on 11.31 there are a lot more options you can set when sharing filesystems. Note that Ignite-UX
has only been tested with sec=sys. With the configuration of /etc/dfs/dfstab that you need to place full share
commands that would be executable from the command line into the file.
Kernel tunables that can impact on NFS
On HP-UX 11.31 care should be taken with the kernel tunable nfs3_bsize. Setting the tunable to more than
32768 when the NFS server is a HP-UX B.11.11 or B.11.23 system may cause errors to be logged in
syslog.log.
# kctune -v nfs3_bsize
Tunable nfs3_bsize
Description Client block size for future mounts
Module nfs_client_pv3
Current Value 32768 [Default]
Value at Next Boot 32768 [Default]
Value at Last Boot 32768
Default Value 32768
Constraints nfs3_bsize >= 4096
nfs3_bsize <= 2147483647
nfs3_bsize is a power of 2
Can Change Immediately or at Next Boot
Setting this larger will not be a problem if the NFS server that you are communicating with is another HP-
UX B.11.31 system or another system that supports large NFS block sizes. An example of the error you
would see on a lower revision HP-UX system is:
Mar 7 09:10:15 myclient vmunix: NOTICE: KRPC: record fragment from client of
size(39416) exceeds maximum (33576). Disconnecting
The 11.31 kernel tuneable nfs4_bsize is only applicable NFS v4 on HP-UX 11.31 as 11.23 and lower
releases only support up to NFS v3 filesystems:
# kctune -v nfs4_bsize
Tunable nfs4_bsize
Description Client block size for future mounts
Module nfs_client_pv4
Current Value 32768 [Default]
Value at Next Boot 32768 [Default]
Value at Last Boot 32768
Default Value 32768
Constraints nfs4_bsize >= 4096
nfs4_bsize <= 2147483647
nfs4_bsize is a power of 2
Can Change Immediately or at Next Boot
An alternative to lowering nfs3_bsize on 11.31 is to mount the filesystems that make_net_recovery will use
before running it 101 setting the NFS rsize and wsize options to a value supported by the remote system. If
you do this remember that you must also umount them when the command completes. If the filesystems are
already mounted make_net_recovery will not attempt to umount them.
101
We saw in the walkthrough of make_net_recovery works that if the NFS filesystems it needs are already
mounted it will not attempt to mount them.

For example if the system myclient is running 11.31and has the kernel tunable nfs3_bsize set to 65536 and
the Ignite server is running HP-UX 11.23 we could run the following commands to make sure that
make_net_recovery worked correctly:
# mount -o vers=3,rsize=32768,wsize=32768 myserver:/var/opt/ignite/clients

/var/opt/ignite/recovery/client_mnt
# mount -o vers=3,rsize=32768,wsize=32768
myserver:/var/opt/ignite/recovery/archives/myclient
/var/opt/ignite/recovery/arch_mnt
# make_net_recovery –s myserver …
# umount /var/opt/ignite/recovery/client_mnt
# umount /var/opt/ignite/recovery/arch_mnt
NFS versions that support large files
If you are using an Ignite server that supports NFS v2 and you’ve managed to mount an NFS filesystem
using NFS v2 keep in mind that the maximum file size supported by NFS v2 is less than 2GiB. Also
remember that for higher versions of NFS to support large files the underlying filesystem on the remote
server must also support largefiles.
On the remote system run the following command to ensure that the filesystem itself supports large files.
With this command we assume that /var/opt/ignite/recovery/archives/ is part of the /var filesystem:
# fsadm -F vxfs 102 /var

largefiles
and verify that the filesystem has not been mounted with the nolargefiles option 103:
# grep /var /etc/mnttab

/dev/vg00/lvol8 /var vxfs ioerror=mwdisable,delaylog,dev=40000008 0 0
1210841375
On the system which the NFS mount has happened on verify that the mount has happened with NFS v3 or
later. The following is an example from a HP-UX B.11.11 system:
# mount -o vers=3,rsize=32768,wsize=32768 green:/var/opt/ignite/clients

# grep ignite /etc/mnttab
green:/var/opt/ignite/clients /var/opt/ignite/recovery/client_mnt nfs
rsize=32768,wsize=32768,NFSv3 0 0 1210917688
For NFS v3 the /etc/mnttab file shows that the filesystem was mounted with NFS v3 and below we can see
that it says nothing when we mounted it with NFS v2 so we can assume that for NFS v3 and above the NFS
version should be listed in /etc/mnttab and for NFS v2 it will say nothing.
# umount /var/opt/ignite/recovery/client_mnt
# mount -o vers=2,rsize=32768,wsize=32768 green:/var/opt/ignite/clients
# grep ignite /etc/mnttab
green:/var/opt/ignite/clients /var/opt/ignite/recovery/client_mnt nfs defaults
0 0 1210917751
102
Set the filesystem type appropriately – use hfs if you are using a hfs filesystem.
103
A filesystem created with largefiles (or modified to be largefiles capable) should automatically mount
with largefiles enabled (unless nolargefiles is given as a mount option and there are no largefiles currently
in the filesystem).

Wrong ownership/permissions
Another issue that you might sometimes experience (especially if you manually create files in a directory
that Ignite-UX wants to create files in remotely) problems is with the ownership and permissions of files.
Let’s look at the following example:
# cd /var/opt/ignite/clients
# mkdir 0x000000000001
# ll -d 0x000000000001/
drwxrwxrwx 2 root sys 96 May 16 16:25 0x000000000001/
# chmod 755 0x000000000001/
# hostname
green
The per-client directory 0x000000000001 is owned by root:sys which will prevent any other system
(running commands as root) from creating anything in the directory 104. That would prevent
make_net_recovery from creating anything – this will lead to failures as you can see we can’t create a file
in the directory:
# cd /var/opt/ignite/recovery/client_mnt
# cd 0x000000000001/
# touch config
touch: config cannot create
So why? Remember the filesystems are exported with anon=2 so root access is done as bin? If the directory
is owned by root and our access is effectively done as bin we won’t have permission to create anything in
the directory.
We can fix that by changing the ownership back on the server:
# cd /var/opt/ignite/clients
# cd 0x000000000001/
# chown bin:bin .
# touch config
# chmod 644 config
Of course if we create a file we need to be careful about it and it’s permissions since back on the client
system we can’t update the file owned by root:sys with permissions 644.
# touch config
touch: cannot change times on config
# rm config
Of course we can still remove the file since we have write permission to the directory.
It’s important that all files exported by the Ignite server (and archive server if it’s not the Ignite server) are
owned by bin:bin and no-one else.
Complete lab exercise eleven (see “Lab exercise 11 – How make_net_recovery works (part 4)Lab
exercise 10 – How make_net_recovery works (part 3)”).
104
Remember remote root access is mapped to use bin when Ignite-UX exports filesystems.

A quick look at save_config

When looking at save_config we’re not going to discuss the complete script the main discussion item will
be the main part of the script rather than the functions. Although some functions will be discussed.
Looking at save_config - main

This is the main part of the save_config script, all of the code previous to this are function definitions
which end up being called (directly or indirectly) from main. Note that save_config can be called from
Ignite-UX or DRD (both products share a lot of code in common). However we will only be looking from
the context of Ignite-UX.
Effort has been made to prevent line wrapping where possible with this script (by modifying some parts of
it) however when reading you should be aware that some lines may wrap around.
#-----------------------------------------------------------------------
# Main section of save_config
#
#
# Set constants
#
DEFAULT_CONFIG_FILE=/var/opt/ignite/local/config.recovery
PROD_IGNITE=ignite
PROD_DRD=drd
IGNITE_HOST_PATH=/var/opt/ignite/local
DRD_HOST_PATH_DEFAULT=/var/opt/drd/tmp
IGNITE_TMP_DIR_DEFAULT=/var/opt/ignite/tmp/save_config$$
#
# Set variables
#
everything=0
config_file=$DEFAULT_CONFIG_FILE
command=$(basename $0)
prod=$PROD_IGNITE
host_path=$IGNITE_HOST_PATH
d_host_path=""
vxvm_version=0
pdisk_paths_in_temp_dg_file=""
When setting the product context we are not going to look at the DRD section of the code (it has been
removed from this discussion and replaced with ...). Ignite-UX sets up a heap of variables to control what
happens in the rest of the script.
#
# set product context - ignite or drd?
#
if [[ "$SW_SESSION_IS_DRD" = "1" || -n $(echo $command | grep 'drd') ]]

then
...
else # Ignite-UX

prod=$PROD_IGNITE
product_tmp_dir=${IGNITE_TMP_DIR:-$IGNITE_TMP_DIR_DEFAULT}
if [[ "${IGNITE_TMP_DIR}" = "" ]]
then # IGNITE_TMP_DIR not exported or set to NULL
testdir=$product_tmp_dir
while [[ "$testdir" != "/" ]]
do
testdir=$(dirname $testdir)
if [[ ! -d ${testdir} ]]
then
fatal "\"${testdir}\" not a directory."
fi
done
if [[ ! -d ${product_tmp_dir} ]]
then
mkdir -p ${product_tmp_dir}
# If we had to create the IO directory, then it will be removed at the
end
remove_io_dir_when_done=1
else
# Otherwise do not remove it
fi
# Always clean up the IO files
remove_io_files_when_done=1
else # IGNITE_TMP_DIR exported and set to non-null
if [[ ! -d ${product_tmp_dir} ]]
then
fatal "No such directory when IGNITE_TMP_DIR set to
\"${IGNITE_TMP_DIR}\"."
fi
if [[ ! -f ${product_tmp_dir}/io.info ]]
then
fatal "Could not find io.info file when IGNITE_TMP_DIR set to
\"${IGNITE_
TMP_DIR}\"."
fi
if [[ ! -f ${product_tmp_dir}/hw.info ]]
then
fatal "Could not find hw.info file when IGNITE_TMP_DIR set to
\"${IGNITE_
TMP_DIR}\"."
fi
remove_io_files_when_done=0
fi
temp_io_file=${product_tmp_dir}/io.info
temp_hw_file=${product_tmp_dir}/hw.info
temp_io_log=${product_tmp_dir}/io.log
fi
# Use location other than /tmp or /var/tmp for these files

ioscan_temp_file=${product_tmp_dir}/ioscan.tmp
temp_dg_file=${product_tmp_dir}/disk_grp_out
temp_vg_file=${product_tmp_dir}/vol_grp_out
vxvm_dg_list_file=${product_tmp_dir}/vxvm_dg_list_file
pvg_disks_temp_file=${product_tmp_dir}/pvgdisks.tmp
all_disks_temp_file=${product_tmp_dir}/alldisks.tmp
vol_temp_file=${product_tmp_dir}/vol.tmp
listener_io_hw_input=${product_tmp_dir}/io_data

listener_dg_input=${product_tmp_dir}/disk_grp_data
listener_vg_input=${product_tmp_dir}/vol_grp_data
listener_pvg_input=${product_tmp_dir}/pvol_grp_data
config_temp_file=${product_tmp_dir}/config.tmp
vgdisplay_temp_file=${product_tmp_dir}/vgdisplay.tmp
lvlnboot_temp_file=${product_tmp_dir}/lvlnboot.tmp
lvdisplay_temp_file=${product_tmp_dir}/lvdisplay.tmp
mount_temp_file=${product_tmp_dir}/mount.tmp
tunefs_temp_file=${product_tmp_dir}/tunefs.tmp
ifconfig_temp_file=${product_tmp_dir}/ifconfig.tmp
swapinfo_temp_file=${product_tmp_dir}/swapinfo.tmp
dumpinfo_temp_file=${product_tmp_dir}/dumpinfo.tmp
mkfs_temp_file=${product_tmp_dir}/mkfs.tmp
whole_disk_temp_file=${product_tmp_dir}/whole.disk.tmp
We need to setup some initial values for variables; these are used for controlling the LVM/VxVM
functionality in the script.
#
# set initial value
#
is_LVM=$FALSE
is_VXVM=$FALSE
not_in_lvm=$FALSE
not_in_vxvm=$FALSE
vxvm_dg_list="" # list of all VxVM disk groups, populated by

# populate_vxvm_dg_list
vxvm_dg_list_is_valid=0 # Do not need to call listener every time dg_list
# is needed.
#
# Check if the user is super user (JAGag16477 fix).
#
if [[ $(/usr/bin/id -u) -ne 0 ]]
then
fatal "You must have super-user permission to run this program!"
fi
Now we need to handle the arguments to the script. The save_config script only accepts two types of
arguments. The first is -f and the name of the configuration file to write to (both make_tape_recovery and
make_net_recovery always provide a specific file with the -f option) and a list of devices, disk groups, or
volume groups that will be included into the configuration.
# Number of arguments for vgs and disks.
num_vg_list=0
num_disk_list=0
# Flag for -f option
fflag=0
# Check arguments using getopts
while getopts :f: option

do
case $option in
f)
if [[ $fflag -eq 1 ]]

then
usage "the -f option is allowed only once"
fi
config_file=$OPTARG
fflag=1;;
\?)
usage;;
:)
usage "missing argument for -$OPTARG option";;
esac
done
Some sanity checking is done on the argument to the -f option, if it's not - (which means print to stdout) we
need to create the directory where the configuration file will go if it doesn't exist and make sure that the
user didn't give a directory name as the name of the configuration file.
Note that the configuration file is never written directly to the file provided with the -f command (unless it's
- and being written to stdout), it's always put into a temporary file first (there is code near the end to handle
copying it to its final destination).
# If -f argument is not -, check out status of output file
if [[ "$config_file" != "-" ]]
then
# Try to create config file directory if it doesn't exist.
config_dir=$(dirname $config_file)
if [[ ! -d $config_dir ]]
then
mkdir -p $config_dir
if [[ $? -ne 0 ]]
then
fatal "cannot make directory $config_dir"
fi
fi
# Check to see if config is a directory. This is an error condition.
if [[ -d $config_file ]]
then
fatal "$config_file cannot be a directory, it must be a file"
fi
You can see here that file descriptor 4 is used to write the configuration to (and if it exists it is removed
first).
# Set up file descriptor 4 (referenced to $config_temp_file) for use as

# output destination for all print commands.
rm -f $config_temp_file
touch $config_temp_file
exec 4>$config_temp_file
else
# Set up file descriptor 4 (referenced to stdout) for use as

# output destination for all print commands.
exec 4>&1

fi
shift $((OPTIND -1))
We need to build up a list of disks and volume groups/disk groups that the script needs to include into the
configuration. All volumes groups and disk groups need to be refered to by basename (e.g. vg00 not
/dev/vg00) and disks refered to by full device file (including the path).
Without a list of disks and volume groups/disk groups save_config will produce a configuration file that
describes the complete system (covering all disks and volume groups/disk groups used by the system). The
make_net_recovery and make_tape_recovery commands never call save_config in this way they always
supply a list of disks and volume groups/disk groups that need to be processed.
# If no arguments are present now, look at all vgs and disks; otherwise
# process arguments and determine whether they are vgs or disks. Store
# names in vg_list and disk_list arrays as appropriate.
if [[ $# -eq 0 ]]
then
everything=1
else
while [[ $# -gt 0 ]]
do
# Check if argument has a leading / character
if [[ ${1} = ${1#/} ]]
then
# Store argument in volume group list
vg_list[$num_vg_list]=$1
((num_vg_list += 1))
else
# Store argument in disk list
disk_list[$num_disk_list]=$1
((num_disk_list += 1))
fi
shift 1
done
fi
Now we start printing out the configuration file, as you will see some of the text is static and other parts
derived from the configuration of the system.
# Set cfg and _hp_cfg_detail_level
print -u4 cfg \"HP-UX System Recovery\"=TRUE

print -u4 _hp_saved_detail_level=\"vfph\"
# Print out variable assignments separator
print -u4 "#\n# Variable assignments\n#"
# Cache output from mount and swapinfo commands. Only deal with hfs and
# vxfs file systems from mount (exclude cdfs).
mount -lp | grep -E "hfs|vxfs" > $mount_temp_file

if [[ $? -ne 0 ]]

then
fatal "mount command returns a non-zero value."
fi
swapinfo -d > $swapinfo_temp_file

if [[ $? -ne 0 ]]
then
fatal "swapinfo command returns a non-zero value."
fi
crashconf -v > $dumpinfo_temp_file 2>/dev/null

if [[ $? -ne 0 ]]
then
fatal "crashconf command returns a non-zero value."
fi
If we don't have the io.info and hw.info files then we call get_system_info to create them. The
get_system_info command is a front end to the various listeners. There is no public documentation about
the get_system_info command or how it works.
# If io.info or hw.info are missing, then call get_system_info to create them

if [[ ! -f $temp_io_file || ! -f $temp_hw_file ]]
then
/opt/$prod/lbin/get_system_info -i ${product_tmp_dir} -x
blocked_protocol=fibre_channel >$temp_io_log 2>&1
if [[ $? -ne 0 ]]
then
cat $temp_io_log
fatal "get_system_info failed to get IO information."
fi
# rm -f $temp_io_log
fi
We need to determine the value of _hp_root_disk and make sure that it's not /dev/root then print it as the
value of _hp_root_disk, if we can't work out what the root disk was we need to give up as we can't create a
valid configuration. The function disk_to_path will be covered in detail later.
# Determine _hp_root_disk
find_root_disk
if [[ "$root_disk" = "/dev/root" ]]; then

fatal "cannot determine actual root disk/volume referenced as /dev/root"
fi
for root_disk in ${rdisk[*]}

{
if ! echo $root_disk |grep -Ee "/dev/vg00|/dev/vx" > /dev/null
then
root_hardware_path=$(disk_to_path $root_disk)
print -u4 "init _hp_root_disk=$root_hardware_path"
fi
}
# If a root disk cannot be determined, give up
if [[ -z $root_disk ]]
then
fatal "cannot determine root disk"
fi
We print out some more variables that will go into the configuration file:

# Print out _hp_root_grp_disks
print -u4 "init _hp_root_grp_disks=$root_grp_disks"
# Print out _hp_root_grp_striped
if [[ $root_grp_striped -eq 0 ]]
then
print -u4 "init _hp_root_grp_striped=\"NO\""
else
print -u4 "init _hp_root_grp_striped=\"YES\""
fi
Now we need to print out some information about the size of the EFI and HPSP partitions (covered in detail
later). That's followed by the size of primary swap and some other static information.
# Handle IPF Partitions (EFI and HP Service Partitions)

# Determine _hp_efi_partition_size
# Determine _hp_service_partition_size
#
process_partitions $root_disk
# Determine _hp_pri_swap
pri_swap_size=$(awk '/^dev/ { print $2 ; exit } ' $swapinfo_temp_file )

pri_swap_dev=$(awk '/^dev/ { print $NF ; exit } ' $swapinfo_temp_file )
if [[ $pri_swap_dev != ${pri_swap_dev#/dev/dsk} ]]
then
# Round down whole disk swap size to nearest MB
(( pri_swap_size = ( pri_swap_size / 1024 ) * 1024 ))
fi
if [[ -z $pri_swap_size ]]
then
fatal "cannot determine primary swap size"
fi
print -u4 init _hp_pri_swap=${pri_swap_size}KB
# Determine "primary" dump device. JAGaf82161 fix.
pri_dump_dev=$(awk '/^[ ]*[0-9]*:/ { print $NF ; exit } ' $dumpinfo_temp_file )
# Make variables that should not show up in the Additional screen

# invisible:
print -u4 "_hp_locale visible_if false"
print -u4 "_hp_cfg_detail_level visible_if false"
print -u4 "_hp_pri_swap visible_if false"
print -u4 "_hp_min_swap visible_if false"
print -u4 "_hp_disk_layout visible_if false"
print -u4 "_hp_default_cur_lan_dev visible_if false"
print -u4 "_hp_default_final_lan_dev visible_if false"
print -u4 "_hp_keyboard visible_if false"
print -u4 "_hp_root_disk visible_if false"
print -u4 "_hp_boot_dev_path visible_if false"
print -u4 "_hp_saved_detail_level visible_if false"
print -u4 "_hp_root_grp_disks visible_if false"
print -u4 "_hp_root_grp_striped visible_if false"
# Set _hp_disk_layout
print -u4 init _hp_disk_layout=\"HP-UX save_config layout\"

# Print out disk and filesystems separator
print -u4 "#\n# Disk and Filesystems\n#"

print -u4 _hp_disk_layout+={\"HP-UX save_config layout\"}
print -u4 "(_hp_disk_layout==\"HP-UX save_config layout\") {"
print -u4 "\t# Disk/Filesystem Layout:"
This section of code is not used in a recovery scenario as make_tape_recovery and make_net_recovery
always provide a list of disks and volume groups/disk groups to include into a configuration.
We will not be discussing this code (however it simply ensures that all LVM volume groups, VxVM disk
groups, and whole devices used by the system are reflected in the configuration). The code has been
removed as we will not be discussing it here (see the actual script for more details).
# Print out VGs/disks as necessary

if [[ $everything -eq 1 ]]
then
# Process all LVM volume groups
...
# Process all VXVM disk groups
...
# Determine all disk used by mounted filesystems and swap partitions
...
else
is_LVM=$FALSE
is_VXVM=$FALSE
# If any volume groups were given on command line process them
If we have any volume or disk groups we process them one by one. Note that this can raise some potential
issues if you have a LVM volume group and a VxVM disk group of the same name. If you want to include
an LVM volume group called mydata into a recovery archive but you also have a VxVM disk group of the
same name you can include both or neither you can't include one or the other.
This is important for configurations produced by make_tape_recovery and make_net_recovery. If you have
a system that has a bootable LVM volume group called vg00 and a VxVM disk group (containing only
application data) of the same name both will be included into the recovery. This will end up being recreated
after a recovery as an LVM volume group using all of the disks and volume names from both 105.
if [[ $num_vg_list -gt 0 ]]
then
i=0
while [[ $i -lt $num_vg_list ]]
do
vg_in_vxvm=0
vg_in_lvm=0
check_vxvm
if [[ $is_VXVM -eq $TRUE ]] ; then
check_vg_in_vxvm ${vg_list[$i]}
if [[ $? -eq 0 ]] ; then
# Print Disk hostid
host_id=$( vxdctl list |grep hostid |awk '{print $2}' )
print -u4 "\tvxvm_hostid=\"$host_id\""
process_vxvm_volume_group ${vg_list[$i]}
105
This will be addressed in a future release of Ignite-UX by making save_config print an error and exit
when it finds an LVM volume group and VxVM disk group of the same name.

vg_in_vxvm=1
(( i += 1 ))
continue
fi
fi
check_lvm
if [[ $is_LVM = $TRUE ]] ; then
check_vg_in_lvm ${vg_list[$i]}
if [[ $? -eq 0 ]]
then
process_lvm_volume_group ${vg_list[$i]}
vg_in_lvm=1
fi
fi
if [[ $vg_in_vxvm -eq 0 && $vg_in_lvm -eq 0 ]]; then
fatal "${vg_list[$i]} not in the volume/disk group"
fi
(( i += 1 ))
done
fi
is_LVM=$FALSE
is_VXVM=$FALSE
Note that the function process_disk ignores any disk that is in a volume or disk group since it does not need
to be processed as a whole disk.
# If any disks were given on command line process them

if [[ $num_disk_list -gt 0 ]]
then
i=0
while [[ $i -lt $num_disk_list ]]
do
process_disk ${disk_list[$i]}
(( i += 1 ))
done
fi
fi
print -u4 "} # end \"HP-UX save_config layout\""
# If we need to reinitialize _hp_pri_swap, do it now.
if [[ -n $reset_hp_pri_swap ]]
then
print -u4 init _hp_pri_swap=${reset_hp_pri_swap}KB
fi
This prints the io_info and hw_info sections of the configuration file.
# Print out io.info and hw.info

if [[ -f /opt/$prod/lbin/get_system_info ]]
then
print_io_hw_info
fi
Now we print out the hw_instance_num requests into the configuration file.
# Print out instance numbers
ioscan -kf | awk ' BEGIN { Op = "=" }

{ if ($1=="bc")
next;
if ($1=="root")
next;

if ($1=="unknown")
next;
if (match($3,"[0-9]+([/.:][0-9]+)*")==0)
next;
if (NR>2)
{
printf "hw_instance_num %s %s \"%s\" \"%s\" %d\n",
Op, $3, $1, $4, $2 ;
Op = "+="
}
} ' >&4 2>/dev/null
Next we have some other things that need to be printed such as the release variable, timezone information,
and the VxVM version (if VxVM is in use). The VxVM version is important as it controls how any VxVM
disk groups will be recreated.
# Print out release variable
print -u4 "release=\"$(uname -r)\""
# Add timezone
if [[ -r /etc/TIMEZONE ]]
then
( process_timezone_file )
fi
# JAGaf97419 fix. Print out vxvm_version

check_vxvm
if [[ $is_VXVM -eq $TRUE && ( "$vxvm_version" > "0") ]]
then
print -u4 "vxvm_version=\"$vxvm_version\""
fi
Then we have networking information and hyperthreading state information (on HP Integrity systems only)
to go into the configuration file and then it's closed.
# Print out System/Networking Parameters header
print -u4 "#\n# System/Networking Parameters\n#"
process_system_networking
# Print out Hyperthread state
process_hyperthread_state
# Close file descriptor 4
exec 4>&-
Lastly we need to clean up the temporary files that we created
# Clean up files
rm -f $mount_temp_file $swapinfo_temp_file $dumpinfo_temp_file

$ioscan_temp_file
$lvlnboot_temp_file
rm -f $listener_dg_input $temp_dg_file $vxvm_dg_list_file
rm -f $listener_vg_input $temp_vg_file

rm -f $listener_pvg_input
rm -f $listener_io_hw_input
if [[ $remove_io_files_when_done -eq 1 ]]
then
rm -f $temp_io_file $temp_hw_file
rm -f $temp_io_log
fi
Now we need to copy the file to its final destination. There is code here to move any current file of the
same name to .prev, this is never used in a recovery situation since save_config is called once and no
system_cfg file exists in the destination directory when it is called.
# Now that config file is complete, save away old one if it exists, and
# copy temporary file to real one if the file was not "-".
if [[ "$config_file" != "-" ]]
then
saved_config_file=${config_file}.prev
if [[ -f $config_file ]]
then
rm -f $saved_config_file
cp $config_file $saved_config_file
rm -f $config_file
fi
# Use cp instead of mv'ing the file since this is over
# an NFS mount in the case of make_net_recovery, and mv tries
# to preserve the 'root' ownership instead of allowing it to
# be owned by bin:bin.
cp $config_temp_file $config_file
rm -f $config_temp_file
fi
We remove the temporary directory we created early and we're done.
if [[ $remove_io_dir_when_done -eq 1 ]]
then
rm -rf ${product_tmp_dir}
fi
exit 0
# End of script "save_config" #
Looking at save_config - disk_to_path

This function has had a major rewrite recently. Later we'll be looking at the old version of this function.
You can see that this function uses get_system_info. This program uses information created by the I/O
listener along with other files to print out information about a device. Note that the function always
removes the information about partitions (for legacy and agile DSFs) before calling get_system_info.
#-----------------------------------------------------------------------
# Function to map a disk to a devSpec (i.e. /dev/dsk/c1t60 to a variety
# of formats depending on protocol, WWID, etc.)
#
# Argument is a block device file. It uses the new get_system_info
# functionality to return the devSpec for the disk.
#
disk_to_path() {

typeset diskPath="${1}"
if echo $diskPath |grep -q "/dev/dsk"

then
# old DSF
if [[ ! -b ${diskPath} && ! -c ${diskPath} ]] ; then
if [[ -b /dev/dsk/${diskPath} ]] ; then
diskPath="/dev/dsk/${diskPath}"
fi
fi
root_disk_no_s2=${diskPath%s2}
/opt/$prod/lbin/get_system_info \
-d $(dirname $temp_io_file) -D $root_disk_no_s2 \
-a devSpec | read junk dev_spec
else
# New DSF, use io.info to get hardware path
root_disk_no_p2=${diskPath%_p2}
/opt/$prod/lbin/get_system_info \
-d $(dirname $temp_io_file) -D $root_disk_no_p2 \
-a devSpec | read junk dev_spec
fi
echo $dev_spec
return
} # End of function "disk_to_path()"
Instead of trying to explain what is happening we're going to see what information is actually returned on
HP-UX B.11.31 when we ask for information about the boot device from the get_system_info command.
To do this we're going to start the I/O listener first to create our own hw.info and io.info files (see "The
listener(s)” for more information about the listeners. Then we’ll create a minimalist host.info file and ask
for the same information that the above disk_to_path function does (for the boot disk):
# export listener_io_hw_input=./io_data
# export temp_io_file=./io.info
# export temp_hw_file=./hw.info
# echo "action_name=ADVICE_INVENTORY" > $listener_io_hw_input
# echo "attribute_name=blocked_protocol" >> $listener_io_hw_input
# echo "attribute_value=fibre_channel" >> $listener_io_hw_input
# echo "action_name=CONFIG_SAVE" >> $listener_io_hw_input
# echo "attribute_name=instance_file[io_info]" >> $listener_io_hw_input
# printf "%s\n" "attribute_value=${temp_io_file}" >> $listener_io_hw_input
# echo "attribute_name=instance_file[hw_info]" >> $listener_io_hw_input
# printf "%s\n" "attribute_value=${temp_hw_file}" >> $listener_io_hw_input
# /opt/ignite/lbin/get_system_info -m -N io -f $listener_io_hw_input
# ACTION NAME:ADVICE_INVENTORY
message=O::Boot device is: 0/0/0/3/0.0x5.0x0

* Boot device is: 0/0/0/3/0.0x5.0x0
# ACTION NAME:CONFIG_SAVE
_hp_instance_file[hw_info]=./hw.info
_hp_instance_file[io_info]=./io.info
# vgdisplay -v vg00|grep -i disk

PV Name /dev/disk/disk4_p2
# echo MODEL=\"$(model)\" > ./host.info
# print "_hp_ikernel_os_release=\"B.11.31\"" >> host.info

# /opt/ignite/lbin/get_system_info -d $(dirname $temp_io_file) -D

/dev/disk/disk4 -a devSpec
devSpec: "WWID='HP 300 G/MAW3300NC /E0002463
0623/0x01.0x00.0x02.0x00000e1100cd5e6f' HW_PATH='0/0/0/3/0.0x5.0x0'"
We can more closely see exactly what gets printed by adding a tiny bit extra to that get_system_info
command to have it print just the device specification.
# /opt/ignite/lbin/get_system_info -d $(dirname $temp_io_file) -D

/dev/disk/disk4 -a devSpec | read junk devspec ; print $devspec
"WWID='HP 300 G/MAW3300NC /E0002463 0623/0x01.0x00.0x02.0x00000e1100cd5e6f'
HW_PATH='0/0/0/3/0.0x5.0x0'"
If we run save_config that’s exactly what the command places into the value of _hp_root_disk (using
Ignite-UX version C.7.6.100) 106:
init _hp_root_disk="WWID='HP 300 G/MAW3300NC /E0002463

0623/0x01.0x00.0x02.0x00000e1100cd5e6f' HW_PATH='0/0/0/3/0.0x5.0x0'"
The instl_adm(4) manual page contains information on device specifiers:
Device Specifier (dev_spec):

A method that combines the above four types into a single
prioritized list of attributes that refer to a disk. The
format is a String, which means the entire method is
surrounded by double quotes. Tools that create this method
determine the order of attributes, based upon which I/O
Protocol applies and what release is involved. Attributes
are separated by white space and the value part is
surrounded by single quotes. Any embedded single or double
quote characters must be escaped. The following attributes
are supported:
WWID='wwid'
A disk with the specified World-Wide Identifier wwid is
searched for.
PHYS_LOC='phys_loc'
A disk at the specified physical location phys_loc is
searched for.
HW_PATH='hw_path'
A disk at the specified hardware path hw_path is
searched for. Pattern matching expressions are
supported as the hw_path.
DEVICE_ID='device_id'
A disk with the device ID device_id is searched for.
These attributes can then be listed in a prioritized list,

as in:
disk["WWID='wwid' PHYS_LOC='phys_loc' HW_PATH='hw_path'"]
In this example, Ignite-UX would first look for a disk with

a WWID of wwid, and if it could not be found, then it would
look for a disk with a PHYS_LOC of phys_loc, and if that
106
If you need to make manual changes to a configuration file to, for example, change the value of
_hp_root_disk you will probably need to replace the device specification with another. That is somewhat
difficult if you don’t know the device identification information.

could not be found, then it would look for a disk with a

HW_PATH of hw_path and return that if found. If all
attributes are exhausted, then Ignite-UX will find a
replacement disk if allow_disk_remap is set to true.
The release notes for Ignite-UX C.7.5 also included the following information about device specifiers:
- To better support I/O agility, Ignite-UX has made enhancements to the way
that disks can be identified using the config file syntax as described in
instl_adm(4). Disks can now be identified by one or more of the attributes:
- Hardware path (HW_PATH)

- World wide ID (WWID)
- Physical Location (PHYS_LOC)
- Device ID (DEVICE_ID)
make_net_recovery, make_tape_recovery, save_config, and the itool user

interface now produce config files that specify combinations of these
attributes as appropriate for the disk I/O protocol and HP-UX release. This
allows devices (especially SAS disks) to be relocated, replaced or additional
devices added, and still be correctly selected during a recovery, an automated
install or an install using previous settings.
This functional change resolves many of the issues described in the "Ignite-UX
and SAS Devices" white paper at: http://www.docs.hp.com/en/5992-1948/5992-
1948.pdf This functionality does not address the issue of device file names
being changed during a recovery in the case that devices have been relocated,
replaced or added. Because of this issue, data volumes may fail to be re-
imported during a recovery. See the document mentioned above for more details.
If you have existing config files that automatically select SAS disk devices
during install, you should consider changing them to use a Physical Location
(PHYS_LOC 107) value rather than a HW Path value to ensure the correct device is
used.
Compare the way that disk_to_path works now with how the disk_to_path function used to work (before
Ignite-UX C.7.5):
#-----------------------------------------------------------------------
# Function to map a disk to a path (i.e. /dev/dsk/c1t60 to 52.6.0)
#
# Argument is a block device file
#
# This is the same algorithm used in bootsys_prep. It takes care of the
# differences in output of lssf between SCSI and HPFL disks.
#
# If neither of these are found, issue fatal error
#
disk_to_path() {
typeset diskPath="${1}"
if echo $diskPath |grep -q "/dev/dsk"

then
# old DSF, use lssf to get hardware path
if [[ ! -b ${diskPath} && ! -c ${diskPath} ]] ; then
if [[ -b /dev/dsk/${diskPath} ]] ; then
diskPath="/dev/dsk/${diskPath}"
fi
fi
107
The only disk technology that PHYS_LOC currently applies to is SAS.

hw_path=$(lssf ${diskPath} |
awk 'BEGIN { p="unknown" }
{ for(x=1; x< NF; x++) if ($x == "address") p=$(x+1)}
END { print p }')
if [[ $hw_path = "unknown" ]]
then
fatal "unknown disk type for ${diskPath}, not SCSI or HPFL"
fi
# JAGad89164 fix. Under some circumstances not totally known, lssf
# will return ??? as the path. If it does, error out now.
if [[ $hw_path = "???" ]]
then
fatal "cannot determine disk path, lssf ${diskPath} returned
$hw_path as hardware path"
fi
else
# New DSF, use /tmp/io.info to get hardware path
tmp_root_disk=$(echo $diskPath |sed 's/^\/dev\/disk\///')
root_disk_no_p2=${tmp_root_disk%_p2}
hw_path=$(find_field $root_disk_no_p2 diskp: 12)
fi
echo $hw_path
return
} # End of function "disk_to_path()"
For legacy devices we had to rely on parsing the output of the lssf command. If there was something wrong
with the device the hardware path in the output might show up as ??? and that would cause errors to be
printed. For the new hardware path it would require parsing the io.info file and there have been multiple
revisions of the format of the io.info file (it’s currently at revision 2.1) and save_config had to be changed
to cope every time the format changed.
That’s different now as get_system_info is used to parse the file and it understands the versions of the files
so that the save_config script does not have to.
Looking at save_config - process_partitions

This function processes the partition information for HP Integrity systems. We're going to discuss this
function because of an issue (QXCR1000714063) that you may see on HP-UX B.11.31 running a version
of Ignite-UX prior to version C.7.5.
#-----------------------------------------------------------------------
# Function to process IA partitions:
#
# The partition size variables should be visible during recovery so that
# users can change partition sizes during system recovery. Without this,
# users would have to cold install with new partition sizes.
#
# Argument is the root device name (e.g. /dev/dsk/c2t1d0s2)
#
process_partitions() {
This function isn't applicable to HP9000 systems so it only needs to run on HP Integrity sytems and only on
HP-UX B.11.23 or later.
if [[ (-x /usr/sbin/idisk) \
&& ("x$(uname -m)" = xia64) \
&& ("x$(uname -r)" > xB.11.22) ]] # B.11.23+.

then
We need to remove the s? or _p? from the device so we can get information about how the complete disk is
partitioned.
echo $1 | grep -q "dev/dsk"

ret=$(print $?)
if [[ $ret -eq 0 ]]
then
partition_rdisk=$(echo $1 | sed ' s/dsk/rdsk/ ; s/s[0-9]$// ' )
else
partition_rdisk=$(echo $1 | sed ' s/disk/rdisk/ ; s/_p[0-9]$// ' )
fi
We're attempting to get the partition number of the EFI partition (it's normally number 1). The idisk
command would normally print out a lot of information about how the disk is partition with the awk
statement it is looking for the following line " Partition 1 (EFI):" where it will print the partition number
(1 in this case).
efi_partition=$(/usr/sbin/idisk -p $partition_rdisk | \
awk '/ *Partition [0-9] .*(EFI)/ { print $2 ; exit } ' )
# Determine if the root disk has an EFI Boot Partition

if [[ -n $efi_partition ]]
then
With the partition number we can build the applicable legacy or agile DSF and then get the EFI partition
size using diskinfo with the -b option.
if [[ $ret -eq 0 ]]
then
efi_rdisk=${partition_rdisk}s${efi_partition}
else
efi_rdisk=${partition_rdisk}_p${efi_partition}
fi
efi_part_size=$(diskinfo -b $efi_rdisk)
The next step is required because on HP-UX B.11.31 the idisk command will steal a small amount of space
from the EFI partition to ensure that the HPUX partition starts on a MiB boundary. Officially this is to
prevent performance issues on some disk arrays because the alignment of the HPUX partition doesn't match
alignment of data on the array and can potentially cause less than optimal data access patterns.
Because the size of the EFI partition is stored in MiB by Ignite-UX this caused a problem where after every
recovery the size of the EFI partition would decrease by 1MiB. Rounding it up by 512KiB and then
converting to MiB keeps the size from dropping.
# QUIXCR1000714063 fix. On 11.31 and later, idisk steals

# 32K from the EFI partition for alignment purposes. So the
# size ends up a bit smaller than actually asked for. When
# the size gets rounded down below, it loses 1MB. So in
# this case, add 512K back in to counteract this behavior.
# It was decided to add 512K instead of 32K to give us as
# much leeway as possible in case idisk changes again.
if [[ "x$(uname -r)" > "xB.11.23" ]]; then
(( efi_part_size = efi_part_size + 512 ))
fi
# Convert partition size to MB (round down to nearest MB)

(( efi_part_size = efi_part_size / 1024 ))

We can then print out the details of the EFI partition variable:
# Print the EFI partition configuration

print -u4 _hp_efi_partition_size = {
print -u4 " 500Mb,"
print -u4 " 1000Mb,"
print -u4 " 4000Mb"
print -u4 "}"
print -u4 init _hp_efi_partition_size=${efi_part_size}MB
print -u4 _hp_efi_partition_size help_text "\"EFI Boot Partition
(KB)\""
We can now do something similar for the HPSP partition. This partition does not have the same issue as the
EFI partition the idisk command will create it as specified during the recovery.
# Determine if the root disk has a HP Service Partition

hsp_partition=$(/usr/sbin/idisk -p $partition_rdisk | \
awk '/ *Partition [0-9] .*(HPSP)/ { print $2 ; exit} ' )
# Print the HPSP partition configuration

print -u4 _hp_service_partition_size = {
print -u4 " 0Mb,"
print -u4 " 400Mb,"
print -u4 " 4000Mb"
print -u4 "}"
if [[ -n $hsp_partition ]]
then
if [[ $ret -eq 0 ]]
then
hsp_rdisk=${partition_rdisk}s${hsp_partition}
else
hsp_rdisk=${partition_rdisk}_p${hsp_partition}
fi
hsp_part_size=$(diskinfo -b $hsp_rdisk)
# Convert partition size to MB (round down to nearest MB)

(( hsp_part_size = hsp_part_size / 1024 ))
print -u4 init _hp_service_partition_size=${hsp_part_size}MB

else
print -u4 init _hp_service_partition_size=0MB
fi
print -u4 _hp_service_partition_size help_text "\"HP Service
Partition (KB)\""
else
If we couldn't find an EFI partition about the disk may not be partitioned (it won't be bootable if it doesn't
have an EFI partition).
warning "An EFI partition is not found on the root disk

$partition_rdisk. It may be that this disk is not partitioned. See "idisk"
message above."
fi
fi
} # End of function "process_partitions()"

Complete lab exercise twelve (see “Lab exercise 12 – A quick look at save_configLab exercise 11 –
How make_net_recovery works (part 4)Lab exercise 10 – How make_net_recovery
works (part 3)”).
How make_tape_recovery works

This section deals with the way that make_tape_recovery works. This discussion assumes that none of the –
p, –i, or –s options have been used with this command. The make_net_recovery program has already been
explained in an earlier section of this course (see “How make_net_recovery works”).
As noted previously they are in fact the same binary, you can see that each binary has two hard links:
$ cd /opt/ignite/bin
$ ll make*recovery
-r-xr-xr-x 2 bin bin 479232 Feb 14 2007 make_net_recovery
-r-xr-xr-x 2 bin bin 479232 Feb 14 2007 make_tape_recovery
If we change the ll command slightly to see the inode number we will see that they are in fact hard links to
each other:
$ ll -i make*recovery
5963 -r-xr-xr-x 2 bin bin 479232 Feb 14 2007 make_net_recovery
5963 -r-xr-xr-x 2 bin bin 479232 Feb 14 2007 make_tape_recovery
The following is a high level overview of what programs make_tape_recovery calls. The options and
arguments passed to these commands are not discussed here. This list also assumes that none of the options
–i, –s, or -p have been used.
Table 17 - Programs called by make_tape_recovery

Program Brief Description
make_sys_image Check for pax patches (ensures that minimum required pax patches are present on the
system).
list_expander Display what devices, volume and/or disk groups are fully, partially, or not included
into the archive.
check_version check to see if all filesets on client are the same revision
make_sys_image Backup LIF (saves a copy of the non-default LIF contents to /usr/lib/ignite_bootlif).
list_expander Create the list of devices, volume/disk groups to be included into the archive.
I/O Listener 108 Perform system inventory.
save_config Create the system_cfg configuration file.
instl_adm Validate the syntax of the system_cfg file.
model Used to get the hardware model of the system for certain configuration syntax written
to control_cfg (controls cloning).
instl_adm Validate the syntax of the control_cfg file.
list_expander Create the flist file (a list of all of the files and directories that will be placed into the
archive) and the archive size.
list_expander Provides the raw data for generating impacts for the archive.
make_arch_cfg Create archive_cfg
vgcfgbackup Run on all on all volume groups defined on this system
vgexport Creates map files for each volume group that vgcfgbackup was successfully run on
(does include –s option to enable easy import in the event of recovery issues).
instl_adm All of the configuration files (system_cfg, archive_cfg, and control_cfg) are
108
The program name is not given here as the I/O listener is a complex topic and will be discussed
separately.

rechecked for syntax issues (this is mainly done is of a preview was done we can
ensure that if the configuration files were modified that they are still ok).
make_ipf_tape Called on HP Integrity servers to create and write the first 21 109 files to the tape.
make_medialif Called on HP9000 systems to create the lif and write it ot tape.
make_sys_image Create archive (on HP Integrity servers writes the 22nd and 23rd files)
print_manifest Run the print_manifest command (there is no way to disable this command from
being run).
A significant portion of the programs called by make_tape_recovery are scripts. Some are quite simple and
others complex but it is possible to troubleshoot them and attempt to determine what data needs to be
collected to gain valuable insight into what the problem may be. The following programs from the list
above are all scripts supplied by Ignite-UX and can be read by anyone:
• make_sys_image
• check_version
• save_config
Remember: in this discussion we’re not covering the usage of make_tape_recovery with the –s option. The
behaviour of command with –s option involves calling a lot of the programs that make_net_recovery does
to mount (and later unmount) NFS filesystems and determine the per-client directory on the Ignite server.
make_tape_recovery from the start to the version check

The make_tape_recovery command starts by performing the following actions:
• Clear the environment variable “ENV”. This ensures that unexpected commands are not run (when
Ignite-UX runs any shell scripts). Sourcing a .kshrc (ENV is usually set to ~/.kshrc when it is set)
has been known to cause Ignite-UX problems in the past so it is cleared. The umask for the
process is also set (in conjunction with the current umask) to be at least 022 (preventing at least
write access group and other). The effective uid is also checked to ensure that it is 0 (if not an
error is logged and the program exits).
• Internal support for debug mode output is setup (the environment variable INST_DEBUG). Note
that the log file (recovery.log) has not been opened yet.
• The name of the configuration directory that will be created is determined. This is the same name
make_net_recovery creates store the configuration and other files associated with a recovery. The
name always takes the following form:
# date +"%Y-%m-%d,%H:%M"
2008-05-12,19:24
When refered to later in this discussion any reference to this value will be <date/time>.
• Variables are setup at this point to determine if this is make_net_recovery or make_tape_recovery

that is running. Note that past this point we will not discuss those variables again or if code is
being conditionally run based on the variables as it will be assumed that this is
make_tape_recovery that is running.
• The lock file (/var/opt/ignite/recovery/mnr_lockfile) is created and Ignite-UX attempts to lock it.
Failing to lock the file with errno values indicating that someone else already has the lock causes a
message about another instance of make_tape_recovery already running to be printed. Other errno
values cause a more general error message to be printed.
109
This means that there are still two files to be written later.

If the lock file exists but is not locked this causes no problems for Ignite-UX there is no reason to
remove the file. If Ignite-UX reports that there is another instance of make_tape_recovery running
when there should not be - do not remove the file first investigate with fuser on the lock file to
determine who has the file locked. With the pid information you can determine if there really is
another instance of make_tape_recovery running.
Note that this is the same lock file that is used by make_net_recovery so you cannot run both at
the same time.
• The hostname is retrieved, normally we won’t be discussing actions such as this but it is
mentioned here because if the hostname of a system is a fully qualified domain name Ignite-UX
will remove the domain part of the hostname and leave just the hostname.
• The configuration directory on the local client is created (/var/opt/ignite/recovery/<date/time>).

The “latest” symbolic link is created (or recreated) to point to this new directory.
• The recovery log file is opened (in the newly created configuration directory). The name of the log
file is /var/opt/ignite/recovery/<date/time>/recovery.log.
• Now we need to run make_sys_image using the command line

“/opt/ignite/data/scripts/make_sys_image –p” to determine of the system needs pax patches.
Please refer to the section “make_sys_image does some pax patch checks” for additional
information about this step.
• After calling make_sys_image we process the exit value. If it is 3 (indicating an error as discussed
previously since the user chose to cancel the archive creation) we exit with error 110. An exit value
of 4 (indicating a warning) is ignored, so chosing to ignore the missing pax patch won’t cause
make_tape_recovery to exit with warnings when it’s complete.
• Next the archive_content file is created. The information placed into this file is created based up
the usage of the –A and –x options (if provided) otherwise the archive_content file given to the
command with the –f option is used. If there were no –A, -x, or –f options provided and the –i
option was used (to run the user interface) the archive contents file written by the user interface is
used, finally if none of the above were performed a default archive_content file is written that only
allows for a minimal system to be included into the archive.
The section of the make_tape_recovery manual page titled “Including and Excluding From
Archive” explains the format of the archive_content file (all of the values defined there can also be
given with a combination of the –x and –A options).
• The defaults file is read if it exists. This file is /var/opt/ignite/recovery/defaults on the local system.
The values from the defaults file are only used if there are no arguments that override them given
on the command line. If there are no values in the defaults file for any item the builtin defaults
used by make_tape_recovery will be used instead. The defaults file is automatically created by the
make_tape_recovery GUI to communicate back information to make_net_recovery but it can be
created manually.
The valid information for the defaults file is:
RECOVERY_LOCATION=<NFS source>
RECOVERY_DESCRIPTION=”string”
SAVE_NUM_ARCHIVES=<number>
110
Actually “exit with error” when discussing make_net_recovery we actually mean we call a routine to do
some cleanup indicating that we want to exit with an error after the cleanup has been done.

TAPE_DESTINATION=<device>
ARCHIVE_TYPE=tar|cpio|pax
RECOVERY_LOCATION is the remote NFS filesystem where the archive needs to be stored, for
example 10.10.20.1:/var/opt/ignite/recovery/archives/mysystem (ignored by make_tape_recovery).
RECOVERY_DESCRIPTION is a quoted string describing the archive. The value for
SAVE_NUM_ARCHIVES must be a number, it is the number recovery archive configurations
(including the one being created) that make_tape _recovery should leave after it completes 111. For
TAPE_DESTINATION you can set this to the device you want to use with make_tape_recovery
(ignored by make_net_recovery). You can set ARCHIVE_TYPE to the archive type required for
your recovery archive. The pax option is not available on systems that do not support it 112.
• If not set (by command line options or the defaults file) the following default values are assigned:
1. The recovery description becomes "Recovery Archive"

2. The number of archives to save becomes 2
3. The archive type is tar (i.e. portable tar interchange format)
• Next we need to complete the version checks to check that the system has its Ignite-UX filesets all
at the same revision (mixed filesets are not supported on a system).
make_tape_recovery and the version check

The command run by make_tape_recovery to perform the version check is “/opt/ignite/lbin/check_version -
p”. The check_version script defines its own return codes:
# Returns
# 0 - if the versions are the same
# 1 - if they are not the same. (See also -g, and exit 5)
# 2 - if there was an error determining the versions on the server.
# 3 - if the server's IUX version does not support this client's release.(-r)
# 4 - if there was an error determining the versions on this client.
# 5 - if -g option given, and server's version is greater than client.
# This version check ignores A/B/C differences, and includes the ticker
# 6 - if -g option given, and server's major version is greater than client.
# The major version number is the first numeric element of the version.
The only action make_tape_recovery takes however if is if the return code is 1 the error message will be
printed:
ERROR: All filesets in the Ignite-UX product must be the same revision.
Please update any old Ignite-UX filesets.
and the make_tape_recovery command will exit with an error return code. The initial code of interest in
check_version is:
if [ $p_opt = true ] ; then

check_fileset_revs
exit_val=$?
111
Since the make_tape_recovery command writes the archive to tape a later clean up only removes the
directory containing the configuration information created for the tape archive.
112
Supported on B.11.31 and should be supported on B.11.23 with a future version of Ignite-UX – requires
a patch and enhancement bundle to be installed on HP-UX 11.23 to enable pax for support for pax archives
on that HP-UX release.

# if no ther check options were given then exit with the fileset check
# results, else continue with the other checks.
if [[ -z "$server" && ${g_opt} = "false" && ${recovery} = "false" ]]
then
exit $exit_val
fi
fi
We can see from this that p_opt is true. The variable p_opt is set to true when the –p option is given. The
function check_fileset_revs is called to make sure that the fileset revisions are consistent on this system.
For the test after that we do exit since –p was the only option supplied to check_version.
The function check_fileset_revs is short and to the point:
check_fileset_revs()
{
ret=0
swlist $SD_OPTS -l fileset Ignite-UX | awk '$1 !~ /^\#|^$/ {print $1 " " $2}
' |
while read fst rev
do
if [ "$rev" != "$my_vers" ] ; then
echo "\
ERROR: Fileset: \"$fst\" (rev=$rev) is a different
version than the rest of Ignite-UX (rev=$my_vers). You must
update all filesets of the product to the same version for
proper behavior."
ret=1
fi
done
return $ret
} # end check_fileset_revs()
The routine parses the output of swlist on the Ignite-UX product and the awk command using /^\#|^$/
removes any lines that start with # (using ^#) and any blank lines (^$). The output passed to the while read
looks like:
# swlist -l fileset Ignite-UX | awk '$1 !~ /^\#|^$/ {print $1 " " " $2} '
Ignite-UX.BOOT-COMMON-IA C.7.6.100
Ignite-UX.BOOT-COMMON-PA C.7.6.100
Ignite-UX.BOOT-SERVICES C.7.6.100
Ignite-UX.CD-TOOLS C.7.6.100
Ignite-UX.CD-TOOLS-DOC C.7.6.100
Ignite-UX.CD-TOOLS-SRC C.7.6.100
Ignite-UX.DVD-TOOLS C.7.6.100
Ignite-UX.DVD-TOOLS-DOC C.7.6.100
Ignite-UX.DVD-TOOLS-SRC C.7.6.100
Ignite-UX.IGNITE C.7.6.100
Ignite-UX.IGNT-ENG-A-MAN C.7.6.100
Ignite-UX.IGNT-JPN-E-MAN C.7.6.100
Ignite-UX.IGNT-JPN-S-MAN C.7.6.100
Ignite-UX.IGNT-OBAM-RUN C.7.6.100
Ignite-UX.MGMT-TOOLS C.7.6.100
Ignite-UX.RECOVERY C.7.6.100

The version of the fileset from the swlist output is checked against the shell variable my_vers (which holds
the contents of the /opt/ignite/Version file). An error is printed if any fileset doesn’t match that version and
the return code is set to 1 (otherwise the default value of 0 is returned).
A discussion of compatibility
Unlike the discussion of compatibility for make_net_recovery (see “A discussion of compatibility” in the
section on make_net_recovery) we don’t have the same issue for make_tape_recovery. A tape recovery
archive is a self contained tape holding everything it needs to recover a system. The only issue where
compatibility arises is with dual media recovery (see “Dual Media Recovery” for more information).
make_tape _recovery after the version check

Now we can continue on with what make_tape_recovery does to create the recovery archive.
• The command “/opt/ignite/data/scripts/make_sys_image -s local –L” is run to backup the non-

default contents of the LIF on the boot disk. The lif contents are written to /usr/lib/ignite_bootlif.
We’re not going to look at how this is done in make_sys_image, if you wish to review the code
remember that make_sys_image is a script that anyone can read.
• The list_expander command is run to determine the list of devices that are going to be assocated
with the recovery archive. The command run to do this is “/opt/ignite/lbin/list_expander -d -f
<archive_content> (we’ve previously discussed the archive content file and where it is written to).
The information is gathered by the command is saved away inside make_tape_recovery.
• The io.info file is created by starting the I/O listener and asking it to perform an inventory of the
system (we will be briefly discussed in a separate section about the listeners).
• The system_cfg file is created by calling “/opt/ignite/bin/save_config –f /var/opt/ignite/

recovery/<date/time>/system_cfg …”. The volume groups, disk groups, or whole disks that will
be included into the archive (fully or partially) are provided to the save_config command so it can
generate the disk layout for the archive (replacing the … above). Only some parts of the
functionality in the save_config script will be covered in this course. When complete the
command use to check the syntax of a configuration file is run over system_cfg (the command is
/opt/ignite/bin/instl_adm –T –f <configfile>).
For more information about save_config see the section “A quick look at save_config“.
• The next step is to backup all of the volume group information. The vgcfgbackup command is run
for all volume groups (any error causes the program to stop doing this and exit in error). After
each vgcfgbackup command is run the command “vgexport –p –s –m /etc/lvmconf/<vg>.mapfile”
is created. The –s option is used to include information into the map file to make it easier to
vgimport volume groups manually later if required.
• The configuration file /var/opt/ignite/recovery/<date/time>/control_cfg is created. The file is

created directly by make_tape_recovery not by a separate program. The control_cfg file contains
configuration used to control aspects of the recovery, these include:
1. Shell scripting to run vgimports, vgchange, and vgcfgbackup commands and sets up the
variable _IMPORT_VG so the user can stop volume groups from being imported via the
additional button in the advanced user interface on the basic tab.
2. If the system is using VxVM disk groups a series of VxVM commands will also be
included into the configuration file to allow VxVM to re-start successfully after a

recovery. If these commands are run or not is also controlled by the setting of the
_IMPORT_VG variable.
3. Setting up the _HP_CLONING variable based on the model string of the system this can
also be changed via the additional button in the advanced user interface on the basic tab
in case a cloning session is being performed to an identical model of system.
4. The configuration variable _hp_hide_other_disks to allow disks that are used by the
system to be hidden so they cannot be accidentally ovewritten. The disks in
_hp_hide_other_disks are the disks that will be imported rather than recreated and
recovered. This is controlled by the _hp_allow_use_of_imports variable which appears as
"Allow use of other disks" on the additional button in the advanced user interface on the
basic tab. A value of "NO" means you cannot use them (it is the default). If you change it
to "YES" it means that they can be used during the recovery.
5. Set the internal variable RECOVERY_MODE to TRUE so Ignite-UX knows that this is a
recovery session.
After the configuration file has been written the syntax of the file is validated using the instl_adm
command. The command is /opt/ignite/bin/instl_adm –T –f <configfile> (where <configfile> is
control_cfg, including the complete path to the file).
• Now we can generate the flist file. This has to be done before we can generate the archive_cfg file
(in the next step) because the information about what files will be included into the archive is used
to generate the impacts information. The command run to generate the flist file is
“/opt/ignite/lbin/list_expander -s -S -f /var/opt/ignite/recovery/<date/time>/archive_content -l
/var/opt/ignite/recovery/<date/time>/flist 2> /dev/null”.
• The next step is to create the archive_cfg file (/var/opt/ignite/recovery/<date/time>/archive_cfg).

Since multiple programs are called during this phase we will look at the steps in more detail.
1. The impact level that needs to be generated is determined. The impact level is based upon
the mount point of a filesystem, the more directories in a mount point that is fully or
partially included into an archive the higher the impact level that will be used. The
command that is run is “/opt/ignite/lbin/list_expander -d -v -f
/var/opt/ignite/recovery/<date/time>/archive_content 2>/dev/null”. The output from this
command is then parsed to determine the filesystems affected and what level the impacts
need to be.
In this example the Ignite-UX should generate impacts at level 3 (because of

/var/opt/ignite):
# /opt/ignite/lbin/list_expander -d -v -f ./archive_content 2>/dev/null

/dev/vg00/lvol2
/dev/vg00/lvol3 / 2
/dev/vg00/lvol9
/dev/vg00/lvol10 /var/tmp 2
/dev/vg00/lvol13 /var/opt/ignite 2
/dev/vg00/lvol15
2. The arguments put together for the make_arch_config command now depend on the
archive type chosen, the following table shows the command and its options. The

commands are exactly the same except for that final –m option to indicate the archive
type.
Table 18 - make_arch_config commands called by make_tape_recovery

Archive Command
type
cpio /opt/ignite/lbin/make_arch_config -c /var/opt/ignite/recovery/<date/time>/archive_cfg -g
/var/opt/ignite/recovery/<date/time>/flist -n <date/time> -r <architecture> -b <bitness> -t
<archive_position> -i <impact_level> -m c
pax /opt/ignite/lbin/make_arch_config –c /var/opt/ignite/recovery/<date/time>/archive_cfg -g
<archive_position> -i <impact_level> -m p
tar /opt/ignite/lbin/make_arch_config –c /var/opt/ignite/recovery/<date/time>/archive_cfg -g
<archive_position> -i <impact_level> -m t
The following new terms were introduced in the above list of commands:
<architecture> - “pa” for HP9000 systems and “ipf” for HP Integrity servers.
<bitness> - 32 or 64 (depends on bitness of the kernel, and can only be 64 only for HP-UX
B.11.23 and above).
<archive_postition> - 1 for HP9000 systems and 22 for HP Integrity systems (it is the number of
files to skip forward from the beginning of the tape to reach the archive).
<archive_local_mount> - Local mount point where the filesystem the archive will be stored in is
mounted.
<arch_host_dir> - The remote location of the filesystem where the archive will be stored (in NFS
form).
<impact_level> - impact level for recovery archive.
The –m option gives an argument to determine the archive type. They are t (tar), p (pax), and c (cpio).
Once make_arch_config completes the archive_cfg file has been created. Although we have looked at how
some other programs work inline with this discussion we’re going to look at make_arch_config separately
after the discussion of make_tape_recovery is over.
• A check is done to ensure that there is enough space free in the filesystem where the LIF will be
created for the tape. Note that the space check only ensures that there is approximately 32MiB free
in the filesystem and the LIF is significantly larger than that.
• The instl_adm command is involved to syntax check the system_cfg, control_cfg, and archive_cfg
files.
• If the /var/opt/ignite/recovery/config.local file exists it is it will be added to the arguments that

will be passed to make_medialif or make_ipf_tape. If the /opt/ignite/Version file exists the –V
option will be added to the arguments that will be passed to make_medlif or make_ipf_tape.
• The next steps are specific to the architecture of the system that make_tape_recovery is running on.
The next two sections are separate for that reason. After they are complete the discussion of
make_tape_recovery will merge back into a single thread.
Complete lab exercise thirteen (see “Lab exercise 13 – How make_tape_recovery works (part 1)Lab
exercise 11 – How make_net_recovery works (part 4)Lab exercise 10 – How
make_net_recovery works (part 3)”).

Continuing on HP Integrity servers

This section deals with specific actions taken to create a bootable tape that are specific to HP Integrity
servers.
• On HP Integrity systems the following warning message is printed: "You are about to create an
Itanium-based recovery tape. If this system does NOT support direct tape boot, you will need to
perform "two-step media recovery" where the boot media (CD or DVD) has the same version of
Ignite-UX as the version on this tape.".
• A file is created (/var/tmp/tmp_cfg_file) that contains the information that will be placed into the
install filesystems that will be written to tape, this information when written looks like:
use_expert_ui=TRUE
env_vars += "INST_ALLOW_WARNINGS=10" 113
run_ui=TRUE|FALSE 114
sysadm_message = "Recovery tape created from system: <hostname> on <date>"
Where <hostname> is the name of the host and <date> is the result returned by ctime(2). If the –t
option is supplied to make_tape_recovery the user supplied description is used instead for
sysadm_message
• The temporary file containing information to be added into the install filesystem is syntax checked
using instl_adm.
• The command line for calling make_ipf_tape is prepared. The command used depends on if the –
D option (to give a tape volume name was given):
Table 19 - make_ipf_tape commands called by make_tape_recovery

With –D /opt/ignite/lbin/make_ipf_tape -f /var/opt/ignite/recovery/<date/time>/system_cfg -f
/var/opt/ignite/recovery/<date/time>/control_cfg -f
/var/opt/ignite/recovery/<date/time>/archive_cfg –f /var/opt/ignite/recovery/config.local –V
-F /var/tmp/tmp_cfg_file -d <tape_device> -l <boot_destination> -C <description> -n
<tape_volume_name>
Without -D /opt/ignite/lbin/make_ipf_tape -f /var/opt/ignite/recovery/<date/time>/system_cfg -f
/var/opt/ignite/recovery/<date/time>/archive_cfg –f /var/opt/ignite/recovery/config.local –V
-F /var/tmp/tmp_cfg_file -d <tape_device> -l <boot_destination> -C <description>
Italicised options are conditional see the previous information to determine under what conditions they may
appear.
The following new terms were introduced above:
<boot_destination> - the name of the temporary file where a LIF should be assembled (see the –B option to
make_tape_recovery)
<tape_volume_name> - The ANSI tape label volume serial number (see the information about the VOL1
ANSI label here “The first ANSI label (file 1)”).
113
Added if INST_ALLOW_WARNINGS is not already present. On HP Integrity servers this file is not
primed with any data (unlike for HP9000 systems, see the next section for more information). This has the
effect of always writing this line to the file.
114
Is set to TRUE if the –I option is given to make_tape_recovery, otherwise it is set to FALSE.

Continuing on HP9000 servers

This section deals with actions that are specific to creating bootable tapes on HP9000 systems.
• The make_medialif command is run with the following options to create the LIF that will be
written to tape:
/opt/ignite/bin/make_medialif -a - f /var/opt/ignite/recovery/<date/time>/system_cfg -f
/var/opt/ignite/recovery/<date/time>/control_cfg -f /var/opt/ignite/recovery/<date/time>/archive_cfg –f
/var/opt/ignite/recovery/config.local –V -l <boot_destination> -C <description>
Italicised options are conditional see the previous information to determine under what conditions they may
appear.
• The default contents of the install filesystems are written to the file /var/tmp/tmp_cfg_file:
use_expert_ui=TRUE
env_vars += "INST_ALLOW_WARNINGS=10" 115
run_ui=TRUE|FALSE 116
sysadm_message = "Recovery tape created from system: <hostname> on <date>"
Where <hostname> is the name of the host and <date> is the result returned by ctime(2). If the –t
option is supplied to make_tape_recovery the user supplied description is used instead for
sysadm_message
• The file /var/tmp/tmp_cfg is tested using instl_adm to ensure that it passes a syntax check.
• The configuration file /var/tmp/tmp_cfg is written back to the install filesystems in the newly
created LIF.
• The LIF is written to tape using dd and a block size of 2KiB
make_tape_recovery after writing some of the tape

Now we’re back to the common part of the code.
• The make_sys_image script is called to write out the archive to tape 117. The following commands
are used depending on archive type:
Table 20 - make_sys_image commands called by make_tape_recovery

Archive Command
Type
cpio /opt/ignite/data/scripts/make_sys_image -c n -d <tape_device> -t n -s local -n <date/time> -m c
-w /var/opt/ignite/recovery/<date/time>/recovery.log -u -R -g
/var/opt/ignite/recovery/<date/time>/flist -a <archive_size>
pax /opt/ignite/data/scripts/make_sys_image -c n -d <tape_device> -t n -s local -n <date/time> -m
115
Added if INST_ALLOW_WARNINGS is not already present. On HP Integrity servers this file is not
primed with any data (unlike for HP9000 systems, see the next section for more information). This has the
effect of always writing this line to the file.
116
Is set to TRUE if the –I option is given to make_tape_recovery, otherwise it is set to FALSE.
117
As we will see later though on HP Integrity systems make_sys_image first writes out another ANSI
label.

p -w /var/opt/ignite/recovery/<date/time>/recovery.log -u -R -g
tar /opt/ignite/data/scripts/make_sys_image -c n -d <tape_device> -t n -s local -n <date/time> -m t
-w /var/opt/ignite/recovery/<date/time>/recovery.log -u -R -g
Note that “–c n” requests that the archive be written uncompressed.
• The tape is rewound to the beginning of the tape.
• The print_manfest command is called to create the manifest.
• Cleanup processing is done.
Looking at make_arch_config
We’re not going to look at make_arch_config as the usage of the command is almost identical to
make_net_recovery (the arguments are the same only the locations of the files is different. Please see
“Looking at make_arch_config”, “Looking into gen_impacts” (and the sections within) for additional
information about make_arch_config.
Looking at make_sys_image
Most of the discussion about make_sys_image in the section on make_net_recovery is applicable to
make_tape_recovery. However the discussion of the archive function needs to be looked at again since we
are writing to a device. The size check discussed in the section on make_net_recovery does not end up
being performed – it doesn’t make sense when the archive is being written to tape.
#######################
# archive()
#
# Capture a system image.
#
# CALLS: file_list_processing
# archive_size_check
# message
# verbose
#
archive() {
# Check for 'find' processes put in background, wait until they are done.
#
verbose " * Waiting for background processes to complete."
wait
The make_tape_recovery command does run make_sys_image with recovery mode set so the function
file_list_processing never gets called.
# Expand the ignore lists and check for proper layout for find_files
#
if [[ ${recovery_mode} != "TRUE" ]]; then
file_list_processing
fi
This function doesn't do anything for a tape archive (since the device file being written to is not a directory).
That means a lot of the code in the function doesn't get executed.

# Get approximate size of compressed archive.

# Make sure the destination has enough space.
#
archive_size_check
# Message telling the method of archiving, where it is going, and how big.
#
message
The code path exercised for make_tape_recovery is for a local server to a device.
# Pack it up.
#
if ((! PREVIEW))
then #{
cd /
if [[ ${WHERE} = "device" ]]; then #{
if [[ ${SERVER} = "local" ]]; then #{
#
# Writing to local device.
verbose " * Writing to local system."
# NB. to extract individual files from the compressed archive:
# dd ibs=(tar-10k,cpio-5120) if=/dev/rmt/0m |gzcat|pax -r -pe
# to extract the archive as a file:
# dd ibs=(tar-10k,cpio-5120) if=/dev/rmt/0m of=archive.gz
# if no compression is set then
# pax -rvf /dev/rmt/0m
#
# For IPF system and tape only.
So the first thing we need to do is work out if this is a HP Integrity server. If it is we need to write the last
label onto the tape before producing the archive. The following code is really important it points to an issue
should you ever have a tape drive that is not controlled by stape or estape on a HP Integrity system:
The 22nd file will not be written to the tape unless the tape is controlled by stape or estape. If you have a 3rd
party tape drive that requires a 3rd party tape driver you cannot create bootable recovery tape for a HP
Integrity system on the tape drive. The tape will be missing one label file so the archive will be the 22nd file
on the tape not the 23rd file.
MODEL=$(uname -m)
DEV_TYPE=$(lssf ${DEST_DIR} |awk '{print $1}')
if [[ $MODEL = "ia64" && ( ${DEV_TYPE} = "stape" \
|| ${DEV_TYPE} = "estape") ]]
then #{
# Write a archive label on recovery tape for bootloader.
# The HPUX bootloader needs to know
# file size to allocate space prior to reading in tape data
for all
# bootloader related files.
The following code puts together a UHL3 header to be written as a label before the archive. What it does is
straightforward and the format of the user defined ANSI label is defined in the comments. In the dd
command the conv=sync ensures that the data is padded with spaces when written to the tape drive.
verbose " Writing archive label.."

arch_size=/tmp/arch_size_f
block_size=/tmp/block_size_f

echo ${IN_ARCHIVE_SIZE} |awk '{printf("%020d", $1)}' >

${arch_size} 2>&1
if [[ ${BLOCK} = "10k" ]]; then #{

echo "10240" |awk '{printf("%016d", $1)}' >
${block_size} 2>&1
else
echo "5120" |awk '{printf("%016d", $1)}' >
${block_size} 2>&1
fi #}
# Write an user defined ANSI archive label content
# BP Field Name Len Content
# ----------------------------------------------------
# 1-3 Label Identifier 3 UHL
# 4 Label Number 1 3
# 5-10 Implementation Qualifier 6 EFIAUX
# 11 Archive Flag 1 A or F
# 12-31 File size 20 Digits
# 32-47 Block Size 16 Digits
# 48-80 (reserved for future standardization) Spaces
print -n "UHL3EFIAUXA$(cat ${arch_size})$(cat

${block_size})" > /tmp/arch_label
dd if=/tmp/arch_label bs=80 cbs=80 conv=sync
of=${DEST_DIR}2>/dev/null
rm ${arch_size}
rm ${block_size}
rm /tmp/arch_label
fi #} End of if [[ $MODEL = "ia64" && ${DEV_TYPE} = "stape" ]]
if [[ $SUFFIX = "none" ]]; then #{
#
# with no compression the archive command is modified to
put the
# pax command at the end of the pipe so that it's multi-
volume
# capabilities can be used
#
Here we need to replace the "-f -" that is part of the pax command that would cause the recovery archive to
be written to stdout to write to the device file instead. This is done using sed to replace with -f and the
device file to write to.
DEV_FILE=$(echo ${DEST_DIR} | sed 's/\//\\\//g')

ARCH_COMMAND=$(echo "${ARCH_COMMAND}" | sed "s/\-f \-/\-f
${DEV_FILE}/")
Lastly we print the command if the -v option was used and then run it via the eval builtin. That writes the
archive to the tape device.
verbose " * ${ARCH_COMMAND}"

eval "${ARCH_COMMAND}"
# ${ARCH_COMMAND} checks return value
else
This code path is never taken when called by make_tape recovery.
...
fi #} End of if [[ ${SUFFIX} = "none" ]]

else
The device is always local when called by make_tape_recovery never remote so this code path is never
taken when called by make_tape_recovery.
#
# Writing to device file on remote.
verbose " * Writing to remote system: ${SERVER}"
...
fi #} End of if [[ ${SERVER} = "local" ]]
else #destination is a file system
Since make_tape_recovery writes to a tape device never to a filesystem this code path is also never taken:
...
fi #} End of if [[ ${WHERE} = "device" ]]; then #{
fi #} End of if ((! PREVIEW))
We've previously discussed the error file and the command results file in terms of how they work see
“Working out the compression and archive part of the command line” and "Creating the archive" for more
information.
########################################################################
# Check for any files in the pax_bug_files file
#
[[ -s ${err_file} ]] && verbose -e "WARNING: There were files that were not
successfully archived because
of a pax bug. Check ${err_file} for the list."
########################################################################
# Check for errors in pipe
#
# 0 is: good
# 2 is: ERROR for pax & cat, put often pax errors can be ignored
# WARNING for find_files (list_expander), gzip, & compress
# other is: ERROR
#
while read cmd result
do
if [[ "${result}" != "0" ]]; then #{ possible error
if [[ ( "${cmd}" = "pax" ) || ( "${cmd}" != "cat" && "${result}" =
"2" ) ]]; then #{
verbose -e "WARNING: The ${cmd} command returned a non-zero
exit status (exit status ${result})." >&2
else
verbose -fe "ERROR: The ${cmd} command failed (exit status
${result})." >&2
fi #}
fi #}
done < ${cmdres}
} # End archive()
That's how an archive gets written to tape.
Looking at make_ipf_tape

Here we will be looking at the make_ipf_tape command, it is responsible for writing the first 21 files to
tape. There are really 7 “files” being written each with header and trailer ANSI labels (to give a total of 21
files).
Code not relevant to a general discussion of what the script does has been removed, to investigate what this
script does in greater detail please review the script itself (/opt/ignite/lbin/make_ipf_tape).
# This program is for creating ANSI label tape. It writes

# following files with ANSI labels (header, trailer labels around
# the files).
# (1) EFIBOOTHPUX (descriptor block file)
# (2) BOOTLOADER
# (3) FPSWAEFI
# (4) AUTO
# (5) IINSTALL
# (6) IINSTALLFS
# (7) HPUXIUXLIF (includes INDEX, CONFIG, INSTCMDSIA, SYSCMDSIA, RECCMDSIA,
SCRIPTS)
# Set ENV="" (null). Major problems have been caused in
# the past because users reset values in dot '.' files pointed
# to by the ENV variable, particularly in the case of locale
# related variables. Any file pointed to by ENV is always
# sourced when the posix shell is invoked. This will
# keep configuration files from being sourced automatically
# from this point on. See IUX FAQ entry 1.18.

We start out by setting up some initial values.
ENV=""
PATH=/usr/bin:/usr/contrib/bin:/opt/ignite/bin:/opt/ignite/lbin
unset LANG
# initial values
aflag=0
dflag=0
nflag=0
fflag=0
Fflag=0
cflag=0
Cflag=0
lflag=0
rflag=0
tflag=0
Vflag=0
wflag=0
This is important if you use tapes that are in a tape library that also have bar code labels, failing to give a
volume serial number via the -D option to make_tape_recovery (also know as a tape volume name on the
make_tape_recovery manual page) it will be of the form "HP" followed by a 2 digit month and 2 digit day.
Giving a matching volume serial number to a bar code on the tape may make managing your tape volumes
easier when the ANSI labels and the tape give the same information. This only helps when a recovery
archive fits onto one tape as subsequent tapes are not labeled.
month=$(date +%m)
day=$(date +%d)
vol_name=HP$month$day

Then we setup some defaults:
tape_title=""
typeset script_files[1]=/opt/ignite/data/scripts/os_arch_post_l
typeset script_files[2]=/opt/ignite/data/scripts/os_arch_post_c
typeset -i num_script_files=2
typeset -i num_config_files=0
# get release information and model information

rel=$(uname -r)
sys_model=$(uname -m)
# default LIF volume file

def_lif_file="/var/tmp/HPUXIUXLIF"
# LIF file varible, may changed by user

lif_file=${def_lif_file}
# other default values

tape_device_file=/dev/rmt/0mn
description=""
Cfg_clause="HP-UX $rel Default"
config_tmp="/var/tmp/config_tmp"
scripts_tmp="/var/tmp/scripts_tmp"
sys_name=$(hostname)
The usage and fatal functions have been removed from this discussion, as has the argument processing code.
The first thing we need to do is rewind the tape. This script expects to lay down files from the start of the
tape so we have to be at the start of the tape before writing any files. That's followed by a check to ensure
that we're running on at least HP-UX B.11.23. The reason for this is that earlier releases of HP-UX that
supported Itanium systems aren't supported by the versions of Ignite-UX that can write natively bootable
tapes.
# rewind tape to BOT

mt -f ${tape_device_file} rew
if [[ $? -ne 0 ]]
then
fatal "Rewind tape failed."
fi
# check command line options

if [[ $rel < "B.11.23" ]]
then
fatal "Native tape boot is not supported for $rel."
fi
In all of the configuration files that we have we need to find release keyword, if it's been set, in one of the
files (which will be used shortly).
# Check release information inside configuration files

if [[ $fflag -eq 1 ]]
then
index=1
while [[ $index -le $num_config_files ]]
do
config_file=${config_files[$index]}

cfg_release 118=$(grep release $config_file |

awk 'FS="=" {if($1 ~ /^release/ ){
gsub("\"","")
if ( $2 ~ /^B/ ){
print $2
}
}
}')
if [[ "$cfg_release" != "" ]]
then
break
fi
(( index += 1 ))
done
fi #fflag
The -c option is not used by make_tape_recovery so the code that would be executed if it were present is
not shown here.
# If -c was used, get list of config files from manage_index

# First check to be sure config clause exists
if [[ $cflag -eq 1 ]]
then
...
fi #cflag
If we had a release keyword setting a HP-UX release we need to make sure that it's the same release as the
system that this command is running on. This would seem to be a somewhat restrictive test as it means that
you cannot create a natively bootable tape for a HP Integrity system on anything but the HP-UX release
that it matches. For example, you cannot convert a B.11.31 network recovery archive to a bootable tape on
an Ignite server that is running HP-UX B.11.23 – it must be done on a HP-UX B.11.31 system.
#
# Check if the $rel matches $cfg_release
#
if [[ "$cfg_release" != "" ]]
then
if [[ "$cfg_release" != "$rel" ]]
then
fatal "The release from the configuration file, $cfg_release, does NOT
match $rel."
fi
fi
The next section of the script involves preparing all of the files that will be written to tape. For most files
this is doing to involve copying them using the dd command making sure that they end up as multiple of
the block size that they will end up being written to tape with.
The first two files we deal with are the bootloader and the boot tape descriptor block. They're dealt with
around the opposite way to which they will be written to tape. If any of the files that we're dealing with are
missing it's considered a fatal error as we're not going to be able to create a valid bootable tape.
# Detect the existence of bootloader for IPF system (hpux.efi)

# rename it to BOOTLOADER. Pad every input block to the block size (bs) if the
bootloader
# size is not n times of bs, where n is a integer.
if [[ ! -r /opt/ignite/boot/hpux.efi ]]
118
The way this variable is determined has been changed from Ignite-UX version C.7.8 onwards to address
a defect.

then
fatal "The /opt/ignite/boot/hpux.efi does not exist or is not readable."
fi
dd if=/opt/ignite/boot/hpux.efi of=/var/tmp/BOOTLOADER bs=32768 conv=sync
2>/dev/null
if [[ $? -ne 0 ]]
then
fatal "\"dd\" command failed to write bootloader."
fi
/opt/ignite/lbin/writetapedb 3 32768 /var/tmp/BOOTLOADER >
/var/tmp/EFIBOOTHPUX 2> /dev/null
if [[ $? -ne 0 ]]
then
fatal "\"writetapedb\" command failed to create boot tape descriptor
block."
fi
Next we'll make sure that the floating point software simulator is there and copy if ensuring that it's padded
to a multiple of 32KiB.
# Detect the existence of HP-UX floating point simulator (fpswa.efi)

# rename it to FPSWA.EFI
if [[ ! -r /opt/ignite/boot/fpswa.efi ]]
then
fatal "The /opt/ignite/boot/fpswa.efi does not exist or is not readable."
fi
dd if=/opt/ignite/boot/fpswa.efi of=/var/tmp/FPSWA.EFI bs=32768 conv=sync

2>/dev/null
if [[ $? -ne 0 ]]
then
fatal "\"dd\" command failed to write floating point simulator."
fi
We create our own AUTO file padding it out to 512 bytes.
# Generate a temp AUTO to put on tape. Do not use the default AUTO file on disk
# check the supplied AUTO file first
if [[ $aflag -eq 1 ]]
then
...
This code has been removed as make_tape_recovery does not use the -a option to this command.
else
# Create a AUTO file. This is a 14-byte file.
echo "boot IINSTALL" |dd bs=512 conv=sync of=/var/tmp/AUTO 2>/dev/null
fi #aflag
We need to make sure that the install kernel and filesystem exist.
#
# Detect the existence of IINSTALL
#
if [[ ! -x /opt/ignite/boot/Rel_$rel/IINSTALL ]]
then
fatal "The IINSTALL kernel either does not exist or is not executable!"
fi

# Detect the existence of IINSTALLFS

#
if [[ ! -r /opt/ignite/boot/Rel_$rel/IINSTALLFS ]]
then
fatal "The IINSTALLFS file either does not exist or is not readable!"
fi
Now we need to make sure that some of the files that we're going to be putting into a LIF that will end up
the tape exist.
#
# Detect the existence of all the command files
#
if [[ ! -r /opt/ignite/data/Rel_$rel/INSTCMDSIA ]]
then
fatal "The INSTCMDSIA file either does not exist or is not readable!"
fi
if [[ ! -r /opt/ignite/data/Rel_$rel/SYSCMDSIA ]]
then
fatal "The SYSCMDSIA file either does not exist or is not readable!"
fi
if [[ ! -r /opt/ignite/data/Rel_$rel/RECCMDSIA ]]
then
fatal "The RECCMDSIA file either does not exist or is not readable!"
fi
Now we're going to create the LIF (note the size is limited to ~246MiB - this size may be increased over
time as the files that need to go into it increase in size):
#
# put INDEX, CONFIG, INSTCMDSIA, SYSCMDSIA, etc. into file HPUXIUXLIF
#
# 1) initialize HPUXIUXLIF
# Create lif volume
lifinit -v246000000 -d24 -nISL10 -K2 $lif_file ||fatal "lifinit failed"
chmod u+w $lif_file
Now we create the INDEX file. Even on bootable tapes for HP9000 systems the INDEX file in lif looks
like this. It defines a cfg clause that refers to the CONFIG file on the lif as that's where the configuration
that defines the archive will be located.
# 2) Create the INDEX file

if [[ -z $description ]]
then
description="This selection supplies the default system configuration given
to make_medialif for the $rel release."
fi
cat << EOF | lifcp -K2 -r - ${lif_file}:INDEX || fatal "lifcp INDEX failed.
The probable cause is insufficient size for $lif_file."
cfg "$Cfg_clause" {
description "$description"
"CONFIG"
}
EOF
Most users of Ignite-UX tend to think of make_tape_recovery as not having a system_cfg, archive_cfg, and
control_cfg file.

We've seen earlier that make_tape_recovery does actually create them. This code is the reason why people
assume that they don't exist. We cat all of the configuration files together into one file and that's the file that
gets writing into the LIF as the LIF file "CONFIG".
# 3) Create and copy the CONFIG file

if [[ $fflag -ne 0 || $cflag -ne 0 ]]
then
rm -f $config_tmp
index=1
while [[ $index -le $num_config_files ]]
do
cat ${config_files[$index]} >> $config_tmp
(( index += 1 ))
done
lifcp -K2 -r $config_tmp ${lif_file}:CONFIG || fatal "lifcp CONFIG failed,
probable insufficient size for $lif_file"
fi
Next we copy in the required commands archives. RECCMDSIA is always copied in so a natively bootable
tape for HP Integrity systems will always have access to recovery shell.
# 4) copy INSTCMDSIA, SYSCMDSIA and RECCMDSIA

lifcp -r -K2 /opt/ignite/data/Rel_$rel/INSTCMDSIA ${lif_file}:INSTCMDSIA ||
fatal "lifcp INSTCMDSIA failed. The probable cause is insufficient size for
$lif_file."
lifcp -r -K2 /opt/ignite/data/Rel_$rel/SYSCMDSIA ${lif_file}:SYSCMDSIA || fatal
"lifcp SYSCMDSIA failed. The probable cause is insufficient size for
$lif_file."
lifcp -r -K2 /opt/ignite/data/Rel_$rel/RECCMDSIA ${lif_file}:RECCMDSIA || fatal

"lifcp RECCMDSIA failed. The probable cause is insufficient size for
$lif_file."
We need to turn the list of script files into a path relative list of the same scripts (when discussing the
installation/recovery process you will see why). Then they get tar'ed up and gzipped into the one file. That
file is then copied into the LIF.
# 5) copy scripts. Put leading . on all script file names in preparation for
tar
script_files_list=$( index=1
while [[ $index -le $num_script_files ]]
do
echo .${script_files[$index]}
(( index += 1 ))
done )
cur_dir=$(pwd)
cd /
# QXCR1000761661 fix. Need to catch potential failure from tar command.
tar_error_file=$(mktemp -d /var/tmp -p tarbaby)
rm -f ${tar_error_file}
( tar -cfb - 20 $script_files_list 2>/dev/null || touch ${tar_error_file} )
|gzip -f -9 -c > $scripts_tmp || fatal "gzip failure on scripts, probable
insufficient disk space in /var/tmp"
cd ${cur_dir}
if [[ -f ${tar_error_file} ]]
then
fatal "tar failure on scripts, probable insufficient disk space in /var/tmp"
fi
rm -f ${tar_error_file}

lifcp -r -K2 $scripts_tmp ${lif_file}:SCRIPTS || fatal "lifcp SCRIPTS failed.

The probable cause is insufficient size for $lif_file."
Next we copy the put the /opt/ignite/Version file into the LIF (this makes it easy to identify the version of
Ignite-UX used to create the tape) and that's follow by adding a PAD file into the LIF. Doing this isn't
strictly required but the other LIFs created by make_medialif all have it 119.
# 6) put Version file in HPUXIUXLIF

if [[ $Vflag -eq 1 ]]
then
# Copy the /opt/ignite/Version file
lifcp -r -K2 /opt/ignite/Version\
${lif_file}:VERSION || fatal "lifcp VERSION failed. The probable
cause is insufficient size for $lif_file."
fi
# 7)
# create a temp file for padding 64Kb to the end of LIF volume
TMP_file=$(/usr/bin/mktemp -d /tmp -p PAD)
prealloc ${TMP_file} 65536 # 64Kb
# copy the PAD file

lifcp -r -K2 ${TMP_file} ${lif_file}:PAD || fatal "lifcp PAD failed, probable
insufficient size for $lif_file"
# Assemble above files and write to tape

# Explaination of ansitape with the options
# -c created a new tape
# -v in verbose mode
# vo volume name
# wo label output file name
# cc=e used in the case of binary data file
# rs= specify the output recordsize in bytes
# rf=f record format is fixed length
# bs= specify the output blocksize in bytes
#NOTE: Once we deside where "ansitape" resides, change the /tmp.
#
If the -w flag was used (make_tape_recovery does not use this option) the volume information is written to
a file as well as the tape boot block descriptor being written to tape wrapped by ANSI labels (the later
happens regardless of the -w option).
# Export volume label information to a file

#
if [[ $wflag -eq 1 ]]
then
/opt/ignite/lbin/ansitape -cp wo=${output_file} vo=${vol_name} cc=e
mt=${tape_device_file} rs=1024 rf=f bs=1024 /var/tmp/EFIBOOTHPUX
else
/opt/ignite/lbin/ansitape -cp vo=${vol_name} cc=e mt=${tape_device_file}
rs=1024 rf=f bs=1024 /var/tmp/EFIBOOTHPUX
fi
119
The “PAD” file was introduced because on older HP9000 systems some CD-ROM drives could not read
the last few blocks of burnt CD-ROM media. When combined with a HFS image (since the LIF is placed at
the end of the filesystem) or a LIF is burnt standalone to a CD accessing the last LIF file on the media
caused a hang. For this reason a “PAD” file which was not access in any way was added to the end of the
LIF. It is not required here but is present because HP9000 systems have the file in LIFs created by
make_medialif.

if [[ $? -ne 0 ]]
then
fatal "\"ansitape\" command failed writing descriptor block file to tape."
fi
rm -f /var/tmp/EFIBOOTHPUX
Next we write the bootloader to the tape.
#
# Write bootloader onto tape
#
/opt/ignite/lbin/ansitape -rp cc=e mt=${tape_device_file} rs=32768 rf=f
bs=32768 /var/tmp/BOOTLOADER
if [[ $? -ne 0 ]]
then
fatal "\"ansitape\" command failed writing boot loader file to tape."
fi
rm -f /var/tmp/BOOTLOADER
That's following by the HP-UX floating point simulator:
#
# Write floating point simulator into tape
#
/opt/ignite/lbin/ansitape -rup cc=e mt=${tape_device_file} rs=32768 rf=f
bs=32768 /var/tmp/FPSWA.EFI
if [[ $? -ne 0 ]]
then
fatal "\"ansitape\" command failed writing floating point simulator file to
tape."
fi
rm -f /var/tmp/FPSWA.EFI
Then the AUTO file:
#
# Write AUTO file onto tape
#
/opt/ignite/lbin/ansitape -rup cc=e mt=${tape_device_file} rs=512 rf=f bs=512
/var/tmp/AUTO
if [[ $? -ne 0 ]]
then
fatal "\"ansitape\" command failed writing AUTO file to tape."
fi
rm -f /var/tmp/AUTO
Then the install kernel is first copied to ensure it is a multiple of the block size it will be written to tape
with. After that the ansitape command is used to write the file to tape wrapped in ANSI labels:
#
# Write IINSTALL kernel onto tape
#
dd if=/opt/ignite/boot/Rel_$rel/IINSTALL bs=32768 conv=sync
of=/var/tmp/IINSTALL 2>/dev/null
if [[ $? -ne 0 ]]
then
fatal "\"dd\" command failed to write IINSTALL."
fi


bs=32768 /var/tmp/IINSTALL
if [[ $? -ne 0 ]]
then
fatal "\"ansitape\" command failed writing install kernel file to tape."
fi
rm -f /var/tmp/IINSTALL
That's followed by the install filesystem. Again the filesystem is converted to a multiple of the block size
using the dd command. The install filesystem then has its configuration updated if the -F option is used
(make_tape_recovery always does this). The configuration in the install filesystem is then tested to make
sure that there are no syntax issues and then it's written off to the tape by the ansitape command.
#
# Write RAM file system onto tape
#
dd if=/opt/ignite/boot/Rel_$rel/IINSTALLFS bs=32768 conv=sync
of=/var/tmp/IINSTALLFS 2>/dev/null
if [[ $? -ne 0 ]]
then
fatal "\"dd\" command failed to write IINSTALLFS."
fi
# Put addition_cfg into the first 8KB of IINSTALLFS
if [[ $Fflag -eq 1 ]]
then
/opt/ignite/bin/instl_adm -F /var/tmp/IINSTALLFS > /tmp/cfg
cat ${addition_cfg} >> /tmp/cfg
/opt/ignite/bin/instl_adm -F /var/tmp/IINSTALLFS -f /tmp/cfg
fi
/opt/ignite/bin/instl_adm -T -f /var/tmp/IINSTALLFS
if [[ $? -ne 0 ]]
then
fatal "There is a syntax error detected in the install file system."
fi
bs=32768 /var/tmp/IINSTALLFS
if [[ $? -ne 0 ]]
then
fatal "\"ansitape\" command failed writing RAM file system file to tape."
fi
rm -f /var/tmp/IINSTALLFS
rm -f /tmp/cfg
The next step is to write the LIF off to the tape. Note the copy of the LIF file, that effectively doubles the
space requirements in /var/tmp (by default) for handling the LIF file. The LIF file is then converted to a
multiple of the block size required and then it's written off to tape.
#
# Write HPUXIUXLIF, According to the design document for IPF ANSI tape, since
the
# search tool will look for HPUXIUXLIF header string to locate the LIF volume
# on tape, the final LIF volume name to be written to tape has to be HPUXIUXLIF.
#
tmp_lif="${lif_file}.tmp"
cp ${lif_file} ${tmp_lif}
dd if=${tmp_lif} bs=2048 conv=sync of=${def_lif_file} 2>/dev/null
if [[ $? -ne 0 ]]
then

fatal "\"dd\" command failed to write HPUXIUXLIF."

fi
/opt/ignite/lbin/ansitape -rup cc=e mt=${tape_device_file} rs=2048 rf=f bs=2048
${def_lif_file}
if [[ $? -ne 0 ]]
then
fatal "\"ansitape\" command failed writing HPUXIUXLIF file to tape."
fi
We then clean up any left over files and exit. Note that the fatal function (not discussed here) also does a
cleanup so if a fatal error occurs all of the files created by this script should be removed after a fatal error.
#
# Cleanup
#
rm -f ${def_lif_file}
rm -f ${config_tmp}
rm -f ${scripts_tmp}
rm -f ${addition_cfg}
rm -f ${TMP_file}
rm -f ${tmp_lif}
exit 0
If you're interested in information about the ansitape command Ignite-UX ships a manual page for it. Be
very careful if you rely on the functionality provided by the ansitape command, the command shipped by
Ignite-UX has been modified - it is not exactly the same as the public domain version of the command.
Looking at make_medialif
In this section we're only going to be looking at the main part of the script and a few functions rather than
the whole script (it's quite long).
...
CheckOptions
# FINISH INITIALIZING:
#
# Set shorthand $OneHWType to indicate whether to make a LIF volume for a
# specific HW type only, not all available types; true in a tricky case:
# without $opt_m if not $opt_a, or with $opt_m if also $opt_o:
if [[ ("$opt_m $opt_a" = 'false false') \

|| ("$opt_m $opt_o" = 'true true' ) ]]
then OneHWType='true'
else OneHWType='false'
fi
DefaultLIFMsg='; possibly insufficient disk space, or max size for LIF'

DefaultLIFMsg="$DefaultLIFMsg volume in file \"$LIF_File\" (see"
DefaultLIFMsg="$DefaultLIFMsg \$LIFVolSize)."
In the code below unless the -d option is given to make_medialif (this option is not passed in by
make_tape_recovery) the shell variable TmpDir is /var/tmp and the variable MyName is the basename of
the command (make_medialif) and of course $$ is the pid of the current process. The directory gets
forcibly removed.
After that a trap handler is installed for the signals SIGHUP, SIGINT, SIGQUIT, SIGPIPE, and SIGTERM
(the 0 of course is not a signal but something that causes the trap to be executed when the shell is exiting).
The temporary directory is created.

# Where to put temporary files:
TmpDir="$TmpDir/$MyName$$"
rm -rf "$TmpDir"
trap "rm -rf $TmpDir; exit" 0 1 2 3 13 15
mkdir -p "$TmpDir" || exit 2
Stderr="$TmpDir/cmd_stderr"
ReleaseTmp="$TmpDir/release"
We now setup some more variables.
# Note: These basenames matter, they must be legal LIF filenames:
ISLTmp="$TmpDir/ISL"
ConfigTmp="$TmpDir/CONFIG"
ScriptsTmp="$TmpDir/SCRIPTS"
PadTmp="$TmpDir/PAD"
The function CheckRequireFiles ensures that all of the files that we're after are present on the system. This
function is covered below.
# CHECK, PREPARE, AND THEN CREATE LIF VOLUME FILE:
CheckRequiredFiles # before checking config files.
When called by make_tape_recovery the -m option is not passed (this creates a minimal LIF) so we know
that we enter this section of code. The -c option is not used as make_tape_recovery calls make_medialif
with multiple -f entries instead.
if [[ $opt_m = false ]]
then
[[ $opt_c = true ]] && GetConfigFileList
# If not already specified, set the cfg clause tag-string to use; for $opt_F
# this value is ignored:
The make_tape_recovery command does use the -C option to provide a description so the contents of this if
are never executed.
if [[ $opt_C = false ]]
then
if [[ $opt_c = true ]]
then CfgClauseOut="$CfgClauseIn"
else CfgClauseOut="$(CfgClauseOutDefault)"
fi
fi
The first function here CheckConfigFileRelease makes sure that any configuration files that will end up
being placed into the "CONFIG" file in the LIF that defined the release keyword matches the HP-UX
release of the system. It would be compared against the release given by the -r option, if it was used, but
make_tape_recovery does not use this option.
The other functions behave similarly to make_ipf_tape so PrepareConfigFiles joins all of the configuration
files into one (that will end up in the "CONFIG" file. The PrepareScriptsFile function gathers the scripts
that have been refered to (os_arch_post_l and os_arch_post_c by default) to make a gzipped tar archive that
will end up in the LIF in the "SCRIPTS" file.

CheckConfigFileRelease
PrepareConfigFiles
PrepareScriptsFile
fi
Now we create the LIF volume, we discuss this function below.
CreateLIFVol
[[ $opt_v = true ]] && Summarize
exit 0
#} Main()
This function checks that the files we want to go into the LIF exist and lists of files that need to go in are
built at the same time.
function CheckRequiredFiles
{
# DEFINE IEM FILENAMES:

#
# Install kernel files:
#
# Note:
#
# - The $kernel_* parameters are local, and the same values are used later for
# lifcp's.
#
# - The PA/IA names are asymmetric for historical reasons, and V/W/I must be
# distinguished by prefix, not suffix, due to boot loader constraints.
typeset kernels_PA=" $BootDir/INSTALL

$BootDir/VINSTALL
$BootDir/WINSTALL"
typeset kernels_IA=" $BootDir/IINSTALL"
# Expert Recovery tar IEMs:

#
# Note: The PA/IA names are asymmetric for historical reasons.
RECCMDS_PA="$DataDir/RECCMDS"
RECCMDS_IA="$DataDir/RECCMDSIA"
# Install-commands tar IEMs:
INSTCMDS_PA="$DataDir/INSTCMDS"
INSTCMDS_IA="$DataDir/INSTCMDSIA"
# System-commands tar IEMs:
SYSCMDS_PA="$DataDir/SYSCMDS"
SYSCMDS_IA="$DataDir/SYSCMDSIA"
# CREATE LISTS OF REQUIRED FILES BASED ON OPTIONS AND PARAMETERS:
Kernels_PA=''; Kernels_IA=''
RAMFS_PA=''; RAMFS_IA=''
In terms of the following code make_tape_recovery uses the -a option so the shell variable OneHWType
won't ever be true (the code inside the if has been removed because it is not executed and irrelevant to this
discussion).

# For "specific HW type", require only the appropriate kernel + RAM FS files:
if [[ $OneHWType = true ]]
then
…
else # not $OneHWType:
This causes us to add in all of the install kernels and filesystems into the list of things that need to be
included into the LIF.
typeset file; for file in $kernels_PA

do
if [[ (-f "$file") && (-f "${file}FS") ]]
then
Kernels_PA="$Kernels_PA $file"
RAMFS_PA="$RAMFS_PA ${file}FS"
fi
done
for file in $kernels_IA

do
if [[ (-f "$file") && (-f "${file}FS") ]]
then
Kernels_IA="$Kernels_IA $file"
RAMFS_IA="$RAMFS_IA ${file}FS"
fi
done
[[ -z "$Kernels_PA$RAMFS_PA$Kernels_IA$RAMFS_IA" ]] \
&& Error 'No pair of kernel (*INSTALL) and matching RAM file' \
'system (*INSTALLFS) files (ordinary or symlink to' \
"ordinary) found in \"$BootDir\"; with the -a option," \
'or with the -m option by default (no -o option), at' \
'least one pair is required.'
fi
# If $opt_R, require the corresponding $RECCMDS* files; also if not $opt_m,

# require the corresponding $INSCMDS* and $SYSCMDS* files:
#
# Note: Put $RECCMDS* first in $CMDs because the entry point for Expert
# Recovery precedes when either $INSTCMDS* or $SYSCMDS* is needed (for normal
# installs). Better Expert Recovery performance results from having $RECCMDS*
# first on serial (tape) media, and $RECCMDS* is so much smaller than
# $INSTCMDS* or $SYSCMDS* anyway that putting it first doesn't hurt much when
# it's not needed.
CMDs=''
The make_tape_recovery command doesn't give the -R option to make_medialif. That means there's no
RECCMDS/RECCMDSIA added into the LIF (this means no recovery shell from a PA-RISC recovery
tape).
if [[ $opt_R = true ]]
then
[[ -n "$Kernels_PA" ]] && CMDs="$CMDs $RECCMDS_PA"
[[ -n "$Kernels_IA" ]] && CMDs="$CMDs $RECCMDS_IA"
fi

The make_tape_recovery command doesn't give the -m option so the following code does get run. That
adds the INSTCMDS/INSTCMDSIA and SYSCMDS/SYSCMDSIA files (as appropriate) into files that
will make it into the LIF.
then
[[ -n "$Kernels_PA" ]] && CMDs="$CMDs $INSTCMDS_PA $SYSCMDS_PA"
[[ -n "$Kernels_IA" ]] && CMDs="$CMDs $INSTCMDS_IA $SYSCMDS_IA"
fi
# CHECK FOR ALL REQUIRED FILES:

#
# Note: $BootLIF is always required; also, constructed files like $ConfigTmp
# and $ScriptsTmp are not checked here.
#
# JAGaf72065: The long message here is an attempt to give good feedback in an
# invalid default or specified -r/-o combination while not trying to be too
# clever and guess (incorrectly) the user's intentions, which could result in
# writing unintended/invalid physical media.
typeset version=''; [[ $opt_V = true ]] && version="$VersionFile"
Lastly we check that we can access most of the files that we need to add into the LIF.
for file in $BootLIF $Kernels_PA $RAMFS_PA $Kernels_IA $RAMFS_IA \

$CMDs $version
do
CheckFileAccess "$file" 'A required file' \
' The file is not installed, was removed, or is invalid. If' \
"it's a kernel file (ending in \"INSTALL\"), specify" \
"consistent -r and -o options. $GetUsage" \
'\nNote: Some required files are determined by the default or' \
"specified OS -r(elease) value (\"$Release\") and by the" \
'default (with the -a or -m options) or specified (with the' \
"-o option) HW-type value (\"$HWType\"). Some combinations" \
'are invalid; for example, there is no 32-bit PA-RISC' \
'(INSTALL) file on B.11.23 and later releases.'
done
} # CheckRequiredFiles()
This function actually creates the LIF.
###############################################################################
# C R E A T E L I F V O L
#
# Given various globals, (re)create $LIF_File. Error out if anything goes
# wrong.
function CreateLIFVol
{
rm -rf "$LIF_File" # no old file around to cause trouble.
# INITIALIZE LIF VOLUME:

#
# JAGaf55041: Determine and use ISL options from $BootLIF:ISL:
Notice here that we need to copy the ISL file out of the /opt/ignite/boot/boot_lif and run iplopt on the
command:

$ lifcp -r /opt/ignite/boot/boot_lif:ISL ./ISL

$ /opt/ignite/lbin/iplopt ./ISL
-e4096 -l63488
We're not going to discuss what they mean or why they're required only note that failing to do this and not
include the options in the lifinit command will create a LIF that won't be bootable.
Lifcp $BootLIF:ISL "$ISLTmp" -r

typeset options="$(iplopt "$ISLTmp")"
options="$options -v$LIFVolSize -d24 -nISL10 -K2 -s4096"
lifinit $options "$LIF_File" 2>"$Stderr" \
|| Error "$DefaultLIFMsg" 'Cannot lifinit LIF volume file' \
"\"$LIF_File\" with options \"$options\""
chmod u+w "$LIF_File"
# COPY/CREATE INITIAL FILES:

#
# Note:
#
# - The order in which files are copied to the LIF volume probably matters only
# for performance reasons on serial (tape) media (except for RAM FS symlinks,
# see CopyLinkRAMFS()). The following order is known to work.
#
# - The ISL, AUTO, and HPUX files are only used by PA-RISC "32" and "64w"
# systems, but are always copied for historical reasons; they are relatively
# small.
# Copy the ISL (Initial System Loader) file:
Now we have our initialised LIF file we can start to copy some required files, in this case ISL. We noted
earlier that when copying LIF to LIF we don't need to specify extra arguments to preserve information like
type as that information is preserved when copying between LIF files. If you were to copy the ISL file to
the filesystem and then copy it back into the new LIF file without giving extra options this LIF would not
be bootable.
Lifcp $BootLIF:ISL "$LIF_File:ISL" -K2
# Create the AUTO file (tells "HPUX" what to do):

#
# Note: The secondary loader (HPUX) makes a PDC call to determine the word
# size of the processor(s). If it's wide (64w), the secondary loader changes
# the kernel name from "INSTALL" to "WINSTALL", and also uses the correct RAM
# FS image ("WINSTALLFS"). The translation does not happen in the other
# direction; if the AUTO file specifies "WINSTALL", that's what's used.
#
# The AUTO file is not used with "64v" (VINSTALL*) and "IA" (IINSTALL*)
# systems.
Now we have the AUTO file, we've already discussed how the "INSTALL" in the AUTO file works for
64bit systems since the loader automatically translates the INSTALL to a WINSTALL on systems that only
support 64bit kernels.
echo "hpux (;0):INSTALL" | # see above.

Lifcp - "$LIF_File:AUTO" -K2 -r -T -12289
# Create/copy the Ignite-UX INDEX and CONFIG* files except with $opt_m (they're
# only needed for installing, not for booting):
then #{

if [[ -z "$CfgDesc" ]] # set default description:

then
CfgDesc='This selection supplies the default system'
CfgDesc="$CfgDesc configuration given to make_medialif for the"
CfgDesc="$CfgDesc $Release release."
fi
The make_tape_recovery command does not give a -F option so the default cfg clause is built here. It will
end up in the INDEX file, as you can see it being piped to the Lifcp function below (this function pretty
much only issues a lifcp command).
if [[ $opt_F = false ]]
then
cat <<-UNQUOTED_HERE_DOC
cfg "$CfgClauseOut" {
description "$CfgDesc"
"CONFIG"
}
UNQUOTED_HERE_DOC
# Reference each $ConfigFile[] entry; with $opt_F, some of them can be -C

# tag-string values, and for each of those emit one cfg clause with a new
# CONFIG* filename:
#
# Note: With $opt_F, other code already ensured $ConfigFile[1] is a cfg clause
# tag-string, that there aren't two -C options in a row, and the last array
# element is a -F filename, not a -C option.
else
...
fi |
Lifcp - "$LIF_File:INDEX" -K2 -r
for configtmp in $ConfigTmpList

do Lifcp "$configtmp" '' -K2 -r
done
fi #} not $opt_m
Now we can copy the secondary loader into the LIF. We don't need to worry about extra options as the
attributes of a LIF file are preserved when copying between LIFs.
# Copy the HPUX (secondary loader) file:

#
# Note: This goes after INDEX and CONFIG for historical reasons, although it
# might cause a slight backup of serial (tape) media to retrieve the two prior
# (small) files later.
Lifcp $BootLIF:HPUX "$LIF_File:HPUX" -K2
# COPY KERNEL AND RAM FS FILES:

#
# For simplicity and consistency, use the $Kernel_* and $RAMFS_* lists already
# set in CheckRequiredFiles(); assume basenames are legal LIF filenames.
#
# Note: Copy/link all RAM FS files immediately after the first kernel file for
# each platform (PA or IA); see CopyLinkRAMFS().

We saw earlier that we don't have one hardware type so we start to execute this code. The
MultiFWWorkaround creates the lif files FWWKAR6, FWWKAR7, and FWWKAR8 that we discussed in
"Contents of the LIF".
[[ $OneHWType = false ]] && MultiFWWorkaround # see the function.
typeset kernel first='true'
Here we put the kernels into the LIF. If the kernels are compressed (which they are except for HP-UX
B.11.11) we uncompress them before placing them into the LIF. The reason why the kernels are
compressed is that they are more than 32MiB (minus 512 bytes) when network booting this prevents them
from being downloading on HP9000 systems. This is because of a tftp limitation in the firmware of
HP9000 systems. The kernels don't need to be compressed for tape boot because there's no firmware
limitation that can be hit because of their size.
The install kernels for HP Integrity servers are normally compressed to lessen the amount of time it takes to
network boot.
The install filesystems are copied in after the kernel. Note that the install filesystems for HP9000 systems
are linked together.
for kernel in $Kernels_PA

do
# determine if kernel is gzip compressed
if Is_compressed_kernel $kernel
then
# uncompress the kernel and copy to LIF
suffix='.orig'
saved_kernel=$kernel${suffix}
mv $kernel ${saved_kernel}
/usr/contrib/bin/gunzip -f < ${saved_kernel} > $kernel
Lifcp $kernel '' $LifcpOptsKR
mv $saved_kernel $kernel
else
fi
if [[ $first = true ]] # see above.

then CopyLinkRAMFS $RAMFS_PA; first='false'
fi
done
first='true'
for kernel in $Kernels_IA

do
# determine if kernel is gzip compressed
if Is_compressed_kernel $kernel
then
# uncompress the kernel and copy to LIF
suffix='.orig'
saved_kernel=$kernel${suffix}
mv $kernel ${saved_kernel}
/usr/contrib/bin/gunzip -f < ${saved_kernel} > $kernel
mv $saved_kernel $kernel
else
fi
if [[ $first = true ]] # see above.

then CopyLinkRAMFS $RAMFS_IA; first='false'

fi
done
Now we can copy all of the commands archives into the LIF.
# COPY TAR IEM FILES IF ANY:

#
# For simplicity and consistency, use the $CMDs list already set in
# CheckRequiredFiles(), which could be empty (if $opt_m). Each file's basename
# must be a legal LIF filename.
typeset file; for file in $CMDs

do Lifcp $file '' -r -K2
done
[[ $opt_m = false ]] \
&& Lifcp "$ScriptsTmp" '' -r -K2
Now the VERSION and PAD files go into the LIF. We discussed in the section on make_ipf_tape where
there is a PAD file, the CR that reports the problem is given below.
# COPY TRAILING FILES:

#
# Optionally copy $VersionFile:
[[ $opt_V = true ]] \
&& Lifcp $VersionFile "$LIF_File:$VersionFileLIF" -r -K2
# JAGae47732: Copy a dummy file to the end of the LIF volume file to resolve a
# hang problem while reading the last file in a LIF volume on some old CD-ROMs:
#
# This workaround is required until the problem no longer exists on any
# supported hardware or drivers, which is hard to determine.
prealloc "$PadTmp" 65536 # 64Kb

Lifcp "$PadTmp" '' -r -K2
We're now done and the LIF is complete.
} # CreateLIFVol()

The listener(s)
The listeners is a term used to describe a collection of programs that perform tasks for Ignite rather have the
functionality built into Ignite-UX, currently the following listeners exist:
Table 21 - Currently available listeners

Name Usage Owner
I/O Listener Performs I/O inventory and I/O related tasks. HP
VxVM Used for creating VxVM disk groups and VxFS Symantec
Listener filesystems based on attributes passed to the listerner.
The number of listeners may increase over time.
The interfaces used to call the listeners are not publicly documented and this course does not document
them. We will look at the few glimpses you can see of indirect usage via save_config.
Please note that no applications should ever attempt to directly interface with the listeners or rely on the
indirect usage examples we will end up looking at. The information produced by any listener is subject to
change without notice.
The files involved

The following files are involved with the listeners:
Table 22 - Files involved with the listeners

File Name Description
/opt/ignite/lib/libsmapi.2 Interface library for HP9000 systems, all programs using
the listeners need to link against this library.
/opt/ignite/lib/libsmapi.so.2 Interface library for HP Integrity servers all programs
using the listeners need to link against this library.
/opt/ignite/listenersia/IO/1123io/smapi_listener 11.23 I/O listener for HP Integrity systems.
/opt/ignite/listenersia/IO/1131io/smapi_listener 11.31 I/O listener for HP Integrity systems.
/opt/ignite/listenersia/VM/vxvm/smapi_listener VxVM listener for HP Integrity systems.
/opt/ignite/listenerspa/IO/1111io/smapi_listener 11.11 I/O listener for HP9000 systems
/opt/ignite/listenerspa/VM/vxvm/smapi_listener VxVM listener for HP9000 systems
The VxVM listener

The VxVM listener is provided by Symantec who also have engineering responsibility for the listener.
This listener is used by Ignite-UX to create all VxVM disk groups and VxFS filesystems by passing the
listener the configuration items the affect the disk group or filesystem and then asking it to perform an
action (e.g. creating the disk group).
If you have access to the VxFS/VxVM source code you will find the VxVM listener included with it.
The I/O listener

The I/O listener is responsible for gathering a complete I/O inventory of the system. Previously (“Inventory
blocking best practices”) I/O inventory blocking was discussed. When blocking some hardware paths or
protocols it is the I/O listener that actually implements the blocking functionality, if used this limits what
the I/O listener will inventory.
The I/O listener is pretty much the same program on all versions of HP-UX (with some differences from
11.31 to handle the agile I/O stack). The implementation of the I/O listener as of Ignite-UX version C.7.0
did bring with it benefits to other versions of HP-UX, for example this from the Ignite-UX version
C.7.4.155 release notes:
- This release includes enhancements to Ignite-UX to be more aware

of multiple path I/O configurations for HP-UX 11.23 and 11.11.
When installing or recovering 11.11 and 11.23 Ignite-UX will now
automatically configure all paths to selected disks as links in
an LVM volume group. A config file only has to specify one path
for each disk. Ignite-UX will detect the other paths and configure
them as alternate links. The selected path will become the primary
link. This behavior is similar to what is already done for 11.31
and VxVM.
The presense of the I/O listerer enabled this functionality. Of course the I/O listener during its initial
introduction was also responsible for a few defects as well (this is not a complete list):
- If a storage adapter has no disks attached the I/O listener may core dump (fix in C.7.6)
- Unclaimed devices cause the I/O listener to core dump (fixed in C.7.6)
When looking at a problem with the I/O listener it is always important to gather debug level logs showing
the problem along with the hw.info and io.info files (if they were created).
Indirect usage examples

The following is from a very recent version of the save_config script:
...
# If io.info or hw.info are missing, then call get_system_info to create them
if [[ ! -f $temp_io_file || ! -f $temp_hw_file ]]
then
# Generate input file for IO listener
echo "action_name=ADVICE_INVENTORY" > $listener_io_hw_input
echo "attribute_name=blocked_protocol" >> $listener_io_hw_input
echo "attribute_value=fibre_channel" >> $listener_io_hw_input
echo "action_name=CONFIG_SAVE" >> $listener_io_hw_input
echo "attribute_name=instance_file[io_info]" >> $listener_io_hw_input
printf "%s\n" "attribute_value=${temp_io_file}" >> $listener_io_hw_input
echo "attribute_name=instance_file[hw_info]" >> $listener_io_hw_input
printf "%s\n" "attribute_value=${temp_hw_file}" >> $listener_io_hw_input
# call the listener wrapper to get output file io.info and hw.info
/opt/$prod/lbin/get_system_info $d_host_path -m -N io -f
$listener_io_hw_input > $temp_io_log 2>&1
if [[ $? -ne 0 ]]
then
cat $temp_io_log
fatal "get_system_info failed to get IO information from IO listener."
fi
...
It causes the hw.info and io.info files to be created by the I/O listener. We can translate that directly into a
set of commands that creates the files we’re interested in looking at in the current working directory:

# export listener_io_hw_input=./io_data
# export temp_io_file=./io.info
# export temp_hw_file=./hw.info
# echo "action_name=ADVICE_INVENTORY" > $listener_io_hw_input
# echo "attribute_name=blocked_protocol" >> $listener_io_hw_input
# echo "attribute_value=fibre_channel" >> $listener_io_hw_input
# echo "action_name=CONFIG_SAVE" >> $listener_io_hw_input
# echo "attribute_name=instance_file[io_info]" >> $listener_io_hw_input
# printf "%s\n" "attribute_value=${temp_io_file}" >> $listener_io_hw_input
# echo "attribute_name=instance_file[hw_info]" >> $listener_io_hw_input
# printf "%s\n" "attribute_value=${temp_hw_file}" >> $listener_io_hw_input
Important: On a system with a large amount of I/O running the following command may take an extended
amountof time to complete:
# /opt/ignite/lbin/get_system_info -m -N io -f $listener_io_hw_input
message=N::Boot device is: 0/1/1/0.1.0

NOTE: Boot device is: 0/1/1/0.1.0
# ACTION NAME:ADVICE_INVENTORY
message=N::Boot device is: 0/1/1/0.1.0

NOTE: Boot device is: 0/1/1/0.1.0
# ACTION NAME:CONFIG_SAVE
_hp_instance_file[hw_info]=./hw.info
_hp_instance_file[io_info]=./io.info
This creates the following files (a definition of all of the fields is in the io.info file – no additional
information is available about what the fields actually mean).
# ll hw.info io.info
-rw-rw-rw- 1 root sys 1280 Apr 5 04:18 hw.info
-rw-rw-rw- 1 root sys 3466 Apr 5 04:18 io.info
# cat hw.info
OO: 0/0/2/0 0 UsbOhci n/a USB_OHCI_Interface
OO: 0/0/2/1 1 UsbOhci n/a USB_OHCI_Interface
OO: 0/0/2/2 2 UsbEhci n/a USB_EHCI_Interface
ext_bus: 0/0/3/0.0 0 side n/a IDE_Primary_Channel
cdrom: 0/0/3/0.0.0.0 0 sdisk 188 31 0 _NEC_DVD+-RW_ND-6650A 0 /dev/rdsk/c0t0d0
/dev/dsk/c0t0d0 -1 -1 0 1 0
ext_bus: 0/0/3/0.1 1 side n/a IDE_Secondary_Channel
graphics: 0/0/4/0 0 gvid_core /dev/crt0 n/a 0 0 0 0
ext_bus: 0/1/1/0 2 mpt n/a SCSI_Ultra320_A6961-60011
disk: 0/1/1/0.1.0 2 sdisk 188 31 21000 HP_300_GMAW3300NC 292968750
/dev/rdsk/c2t1d0 /dev/dsk/c2t1d0 -1 -1 3145733 1 -1
disk: 0/1/1/1.0.0 1 sdisk 188 31 30000 HP_300_GST3300007LC 292968750
/dev/rdsk/c3t0d0 /dev/dsk/c3t0d0 -1 -1 4 1 -1
lan: 0/1/2/0 0 n/a iether n/a HP_AB352-60001_PCI/PCI-X_1000Base-T_Dual-
port_Core -1
lan: 0/1/2/1 1 n/a iether n/a HP_AB352-60001_PCI/PCI-X_1000Base-T_Dual-
port_Core -1
processor: 120 0 processor n/a Processor


# cat io.info
io.info: 2.1 B.11.23 C.7.3.148
# Created: Sat Apr 5 04:18:57 2008
OO_fields: hw_path instance driver model state_flags
diskid_fields: unique_name wwid phys_loc c_major b_major minor c_device
b_device state_flags instance driver model capacity format usage alias
device_id performance device_type lun_hw_path
diskp_fields: unique_name wwid c_major b_major minor c_device b_device
state_flags instance driver hw_path protocol locality priority leg_driver
leg_hw_path leg_instance
escsi_ctlr_fields: hw_path instance driver model state_flags
ext_bus_fields: hw_path instance driver model state_flags
fc_fields: hw_path instance driver model state_flags
graphics_fields: hw_path instance driver c_device model crt_x crt_y crt_planes
crt_id
iscsi_hl_fields: hw_path instance driver model state_flags
lan_fields: hw_path instance driver c_device model lla ppa
processor_fields: hw_path instance driver model
ps2_fields: hw_path instance driver c_device model
tapeid_fields: unique_name wwid phys_loc c_major b_major minor c_device
b_device state_flags instance driver model capacity format usage alias
device_id performance device_type lun_hw_path
tapep_fields: unique_name wwid c_major b_major minor c_device b_device
state_flags instance driver hw_path protocol locality priority leg_driver
leg_hw_path leg_instance
usb_fields: hw_path instance driver model state_flags
OO: 0/0/2/0 0 UsbOhci USB_OHCI_Interface 0

OO: 0/0/2/1 1 UsbOhci USB_OHCI_Interface 0
OO: 0/0/2/2 2 UsbEhci USB_EHCI_Interface 0
ext_bus: 0/0/3/0.0 0 side IDE_Primary_Channel 1
diskid: iux-0000-0002 [] [\] 188 31 0x0 /dev/rdsk/c0t0d0 /dev/dsk/c0t0d0 1 0
sdisk _NEC_DVD+-RW_ND-6650A 18446744072875603968 [\] [\] [\] [\] [\] cdrom [\]
diskp: iux-0000-0002 [] 188 31 0x0 /dev/rdsk/c0t0d0 /dev/dsk/c0t0d0 1 0 sdisk
0/0/3/0.0.0.0 ide 6 [\] sdisk 0/0/3/0.0.0.0 0
ext_bus: 0/0/3/0.1 1 side IDE_Secondary_Channel 1
graphics: 0/0/4/0 0 gvid_core /dev/crt0 PCI_Display_(10025159) 0 0 0 0
ext_bus: 0/1/1/0 2 mpt SCSI_Ultra320_A6961-60011 1
diskid: [HP 300 G/MAW3300NC /E0001768
0614/0x01.0x00.0x02.0x00000e1100c6d332] 0x00000e1100c6d332 [\] 188 31 0x21000
/dev/rdsk/c2t1d0 /dev/dsk/c2t1d0 3 2 sdisk HP_300_GMAW3300NC 292968750 lvm [\]
[\] [] [\] disk [\]
diskp: [HP 300 G/MAW3300NC /E0001768
0614/0x01.0x00.0x02.0x00000e1100c6d332] 0x00000e1100c6d332 188 31 0x21000
/dev/rdsk/c2t1d0 /dev/dsk/c2t1d0 -65535 2 sdisk 0/1/1/0.1.0 parallel_scsi 5 [\]
sdisk 0/1/1/0.1.0 2
diskid: [HP 300 G/ST3300007LC
/3KR2BMF000007649PRPT/0x01.0x00.0x03.0x50014c30038e3780] 0x50014c30038e3780 [\]
188 31 0x30000 /dev/rdsk/c3t0d0 /dev/dsk/c3t0d0 1 1 sdisk HP_300_GST3300007LC
292968750 lvm [\] [\] [] [\] disk [\]
diskp: [HP 300 G/ST3300007LC
/3KR2BMF000007649PRPT/0x01.0x00.0x03.0x50014c30038e3780] 0x50014c30038e3780 188
31 0x30000 /dev/rdsk/c3t0d0 /dev/dsk/c3t0d0 -65535 1 sdisk 0/1/1/1.0.0
parallel_scsi 5 [\] sdisk 0/1/1/1.0.0 1
lan: 0/1/2/0 0 iether [\] HP_AB352-60001_PCI/PCI-X_1000Base-T_Dual-port_Core [\]
-1
lan: 0/1/2/1 1 iether [\] HP_AB352-60001_PCI/PCI-X_1000Base-T_Dual-port_Core [\]
-1


processor: 120 0 processor Processor
The save_config script (especially in more recent versions of Ignite-UX, C.7.6 onwards) contains more
commands using get_system_info. These commands allow the save_config script to receive output specific
to the version of HP-UX that it is running on without needing to cope with extra commands or data that
may only be applicable to HP-UX B.11.23 and below or HP-UX B.11.31 onwards (e.g. agile vs legacy I/O
considerations).

check_net_recovery and check_tape_recovery

The check_net_recovery and check_tape_recovery commands perform very similar actions. They are both
scripts so it’s easy to see what is happening inside them. They perform the same basic actions:
1. Locate the indicated recovery archive

2. Locate the flist assocated with the recovery archive
3. Locate the archive content file associated with the recovery archive and create a new,
temporary, flist file.
4. Compare the two flist files to work out additions, deletions, and changes between the two
flists.
The check_tape_recovery command replaces the check_recovery command. The check_net_recovery and
check_tape_recovery commands were introduced in Ignite-UX version C.6.1. The check_recovery
command was removed in Ignite-UX version C.6.0 (along with make_recovery).
Looking at check_net_recovery
The only option supported by the check_net_recovery command is the –s option to point to an Ignite server.
This needs to be the Ignite server that the client has previously created a network recovery archive on. It’s
important to note that this command only supports comparing the current system to the latest network
recovery archive created. You cannot compare previous recovery archives to the current system.
These are the major functional areas of the script:
1. Make sure that the user running the script is root and process the –s option. The -s option is
required and script will exit if the name of the Ignite server is not given
2. The ignite server is pinged to ensure that it is contactable.
3. The /var/opt/ignite/clients directory from the ignite server is mounted on /var/opt/ignite/client.mnt.
4. Which directory to use for this client is determined (see “Looking at add_new_client to understand
why lanscan is called” for more information on how the client directory is determined)
5. If the archive_content file exists in the latest recovery configuration directory that is used to create
a new, temporary, flist file. If it doesn’t exist an error is logged and we exit.
6. The program /opt/ignite/lbin/chk_rec is used to compare the two flist files.
The longest part of this process is creating a new flist file to compare the old flist file to. The actual
comparison of the two files is extremely quick. The reason why it’s quick is because the chk_rec program
uses libJudy string lists as part of the comparison algorythm.
Looking at check_tape_recovery
There are no options supported by the check_tape_recovery command. It is assumed that all of the required
files are local to the system that the check is being performed on. It’s important to note the command only
supports comparing the current system to the latest tape recovery archive created. You cannot compare
previous recovery archives to the current system.
These are the major functional areas of the script:
1. Make sure that the user running the script is root and that no options are given to the command.
2. The archive_content file /var/opt/ignite/recovery/latest/archive_content is checked to make sure
that it exists, the script exits with an error if it does not exist. A new flist file is created from the
archive_content file.
3. The program /opt/ignite/lbin/chk_rec is used to compare the two flist files.

The longest part of this process is creating a new flist file to compare the old flist file to. The actual
comparison of the two files is extremely quick. The reason why it’s quick is because the chk_rec program
uses libJudy string lists as part of the comparison algorythm.
The operation of chk_rec

The chk_rec program produces all of the output from the two scripts. There is one thing that isn’t
documented about the operation of chk_rec that is important to understand.
The chk_rec program does not process what it considers “optional” parts of a flist file. That is everything
from the optional check sum value. That includes the number of hard links, the inode number, and the
filesystem id. These values can change and the file will not be considered to have changed.
The values used to determine of something has changed are the permissions, the mtime, and size. When
comparing the two flist files they are compared both ways to determine additions and deletions. You only
need to compare the two flist files one way to determine what has changed.

Running recovery commands from an Ignite server

In this section we’re going to look at some of the commands that can be run from an Ignite server onto one
of the clients. When doing this we will see how they get executed. This won’t cover all commands that can
be run just a few of the most common ones.
Adding a new client

The first issue when adding a new client to an Ignite server via the ignite(1) 120 command is that it is
somewhat unlikely that there will be any Ignite-UX software installed on the remote system. So the first
thing that Ignite-UX needs to do is get part of itself installed on the client 121.
This is done by getting the add_new_client script onto the client system. The ignite(1) command will first
attempt to do so by running one the following commands. Which commands depends on if the system has
been configured to be accessed via remsh or ssh. The way this command is called it will not be allowed to
prompt for a password.
Type Command
ssh cat /opt/ignite/bin/add_new_client | /usr/bin/ssh -X -o
BatchMode=yes <client> /sbin/sh -c cat
>/var/tmp/add_new_client; chmod +x /var/tmp/add_new_client;
/var/tmp/add_new_client [-d] -s <server>
rexec cat /opt/ignite/bin/add_new_client | /usr/bin/remsh <client>
/sbin/sh -c cat >/var/tmp/add_new_client; chmod +x
/var/tmp/add_new_client; /var/tmp/add_new_client [-d] -s
<server>
Where <client> is the name of the client (which if is a fully qualified domain name the optional –d option
will be supplied to the add_new_client script when executed on the remote system) and <server> is the
name of the Ignite server.
Note the use of the –X option to ssh to allow X11 tunnelling so the remote system doesn’t need to open the
X display from the remote system. It’s unlikely it would need to do so with add_new_client however in
other cases within ignite(1) X11 tunnelling via ssh makes it a lot easier to support X11 programs.
If this fails Ignite-UX will see if the user has configured the client (or the default options) to use ssh or
rexec and use that instead (this step can prompt for a password). The text that will be shown before this is
done is as follows (the message depends on the type of access method used):
Table 23 - Inquiry message from ignite(1)

Type Message
ssh Command access using ssh -X to <client> was denied. Would you
like to make a second attempt supplying the root password?
(Note: The password will be encrypted with SSH)
rexec Command access using rexec to <client> was denied. Would you
like to make a second attempt supplying the root password?
(Note: The password will be transmitted over the network as
clear text)
120
In case you are wondering why when referring to the ignite command it always has a (1) after it this is
the section number for the manual page of this command. Because it’s easy to confuse the ignite command
with the Ignite product it is easier and clearer to always refer to it as ignite(1).
121
Note that if it does not already exist at this point adding a new client to the Ignite server forces the
creation of the recovery commands depot. If this isn’t done Ignite-UX would not be able to install the
relevant parts of itself onto the client.

If answered in the affirmative the command will get run and the user will be prompted for the root
password on the remote system. When looking further at add_new_client we’re going to assume that this
step passes if the first step fails. When prompted for the root password Ignite-UX will configure the remote
system for access using the selected access method.
Looking at add_new_client - main
This is the main part of add_new_client when it starts running we need to remember that it does not have
Ignite-UX installed.
We can immediately see an issue in the script it only prevents it from being run on HP-UX 9.x, it doesn't
prevent it from running on HP-UX B.10.00, B.10.01, B.10.10, B.10.30, B.11.00, B.11.20, or B.11.22. The
script would fail later anyway when it wants to install Ignite-UX onto the system later any way. It's not a
serious issue as no one could reasonably expect Ignite-UX to support those HP-UX releases with current
releases of Ignite-UX.
#
# Complain and exit if the command is being run on a
# HP-UX 9.x systems
#
case $(uname -r) in
*9.??)
print "ERROR: $(uname -r) is not a supported release for this command"
exit 1
;;
*)
continue
;;
esac
We're going to define a file to hold the result of the lanscan command. We've already looked at how the
output of the lanscan command is used earlier in this course. See "Looking at add_new_client to understand
why lanscan is called" for more details.
#
# Construct a temporary file for the
# lanscan(1M) results
#
LANSCAN_RESULTS=/tmp/lanscan$$
We must have some options supplied to this command and it must be executed as root.
#
# If number of options is '0', print usage and exit.
# The user must specify a server name
#
if [[ $# -eq 0 || $1 = "-" || $1 = "-?" ]]; then
usage
elif [[ $(id -u) -ne 0 ]]; then
print 'ERROR: This command must be run as root' >&2
exit 1
fi

Here we handle the options to the script. The -f option tells the script that it should overwrite files that are
created during the initial setup of a system even if they still exist (i.e. the script is being run again 122 for an
existing client on the Ignite server).
The –s option sets the name of the Ignite server, that system will be the one that a client directory will be
created on and parts of Ignite-UX installed from (out of the recovery commands depot). The –d option is
used later when determining the hostname, the –d option will make the script attempt to work out a fully
qualified domain name for the system.
#
# Initialize the server variable from
# the command line
#
while getopts ":s:R:fd" opt; do
case $opt in
s )
SERVER_NAME=$OPTARG
;;
f )
FORCE_OVERWRITE=1
;;
d )
USE_DOMAIN_NAME=1
;;
#
# the release that you will install on the client, not necessarily the
# release it is currently running.
#
R ) TARGET_RELEASE=$OPTARG
;;
\? )
usage
exit 1
;;
esac
done
#
# Shift the processed arguments out of the way
#
shift $(($OPTIND - 1))
The command (of course) needs to know the Ignite server otherwise it can't create a client directory on it or
attempt to install any software from it.
#
# If the SERVER_NAME was not specified, issue
# usage message and exit
#
if [[ -z $SERVER_NAME ]]; then
usage
exit 1
fi
_LocalDebug "SERVER_NAME = " $SERVER_NAME
We ping the Ignite server to make sure that it can be reached before we later attempt to do anything.
122
The ignite(1) command does not set this option, if would only apply if you were running the command
manually.

#
# Ping the server and make sure that it can be contacted
# via the network
#
PingSystem $SERVER_NAME
err=$?
if [[ $err -eq 1 ]]; then
print "ERROR: Client could not ping Ignite-UX Server: \"$SERVER_NAME\"" >&2
exit $err
fi
If the -d option was passed to the script (this is done when the name of the client entered into the ignite(1)
command contains one or more "." characters) we attempt to determine the fully qualified name of the host
(i.e. including the domain), for example:
nslookup $(hostname) | awk '{if ($0 ~ /Name:/) {print $2}}'

fish.rc.aus.hp.com
The LOCAL_HOSTNAME variable is used later in the script.
#
# Set the LOCAL_HOSTNAME variable
#
if [[ $USE_DOMAIN_NAME -eq 1 ]]; then
LOCAL_HOSTNAME=$(\
if [ -x /usr/contrib/bin/nsquery ]
then
/usr/contrib/bin/nsquery hosts $(hostname) | awk '{if ($0 ~ /Hostname/)
{print $2}}'
else
nslookup $(hostname) | awk '{if ($0 ~ /Name:/) {print $2}}'
fi )
else
LOCAL_HOSTNAME=$(hostname)
fi
The ValidateCommandsExist function is called to determine if the loadfile, rescan_hw_host, and

update_tools commands (all are supplied by Ignite-UX) exist. If they don't exist the script attempts to
install IUX-Recovery from the recovery commands depot on the Ignite server. If those commands do exist
we still call the update_tools script to make sure we have the correct release of Ignite-UX on the system
(compared to the Ignite server).
In this situation it is best if no Ignite-UX bundles are currently installed when adding a new client. It's easy
to get into a situation where it will fail. Some examples are:
1. The Ignite-UX revision on the client is more recent than what is on the Ignite server.
2. A full Ignite bundle, for example IGNITE, is installed potentially leading to mismatched filesets.
#
# Check for the commands that we know we will
# need. If they do not exist, attempt to pull
# them from the recovery depot on the Ignite-UX
# server
#
# The commands we need are:
# /opt/ignite/lbin/loadfile
# /opt/ignite/lbin/rescan_hw_host

#
ValidateCommandsExist
if [[ $? -eq 1 ]]; then
swinstall $SD_OPTS -x mount_all_filesystems=false \
-s $SERVER_NAME:$DEPOT_NAME IUX-Recovery
err=$?
print "swinstall failed to install recovery tools from:
\"$SERVER_NAME:$DEPOT_NAME\""
print "Run /opt/ignite/lbin/pkg_rec_depot on \"$SERVER_NAME\" to
construct the depot"
exit $err
fi
else
update_tools -s $SERVER_NAME
err=$?
print "/opt/ignite/lbin/update_tools failed to validate the recovery
tools version using \"$SERVER_NAME\" as the Ignite-UX Server"
exit $err
fi
fi
Here we mount /var/opt/ignite/clients from the Ignite server onto the directory /var/opt/ignite/client.mnt.
#
# Mount /var/opt/ignite/clients from the server
#
if [[ ! -d /var/opt/ignite/$CLIENT_MNT_DIR ]]; then
mkdir -p /var/opt/ignite/$CLIENT_MNT_DIR
fi
mount -o soft,bg $SERVER_NAME:/var/opt/ignite/clients
/var/opt/ignite/$CLIENT_MNT_DIR >/dev/null
err=$?
print "ERROR: Failed to mount: \"$SERVER_NAME:/var/opt/ignite/clients\""
>&2
exit $err
fi
Information about SetupClientDirectory works (to determine the client directory) is covered in another
section of this document. See "Looking at add_new_client to understand why lanscan is called" for more
information.
#
# Verify that the client directory exists (either active or in history).
# Construct the client directory if necessary
#
SetupClientDirectory
err=$?
print "ERROR: Failed to initialize client directory in
/var/opt/ignite/$CLIENT_MNT_DIR" >&2
exit $err
else
_LocalDebug "INST_CLIENT_DIR = " $INST_CLIENT_DIR
fi
We need to initialise the file client_status in the client directory to an initial value that will allow the system
to be reinstalled if we need to. This is done if it doesn't exist or if -f option was supplied to the script.

# Initialize the client status file so that the Ignite console

# can take "action"n on the client at startup
#
# Note: The name of the file "client_status" is tied to a literal
# found in src/inst_misc.h
#
if [[ ! -f $INST_CLIENT_DIR/client_status || $FORCE_OVERWRITE -eq 1 ]]; then
print "Waiting_To_Install\tWaitBoot" > $INST_CLIENT_DIR/client_status
fi
For the next file to be created - config.sys - this is the configuration from the install filesystem. We should
be able to access the install filesystem from the Ignite server using the loadfile command. The loadfile
command will use tftp to get the file 123. We need to work out the target release and architecture we want to
get the file for (if the -R option was supplied to the script that will be the release used).
#
# Request config.sys from the Ignite-UX server using 'loadfile'
#
if [[ ! -f $INST_CLIENT_DIR/config.sys || $FORCE_OVERWRITE -eq 1 ]]; then
export SOURCE=$SERVER_NAME
export SOURCE_TYPE=NET
ramfs=""
if (( ${#TARGET_RELEASE} ))
then
#
# try to be helpful in the case where the user put -R 11.23
# but really meant -R B.11.23
#
if [[ ${TARGET_RELEASE} != [A-Z]* ]]
then
# use the prefix from the current machine
REL_PREFIX=$(uname -r | cut -d. -f1)
TARGET_RELEASE=${REL_PREFIX}'.'${TARGET_RELEASE}
fi
os_rel=${TARGET_RELEASE}
else
os_rel=$(uname -r)
fi
if uname -m |grep -qi ia64

then
ramfs=/opt/ignite/boot/Rel_${os_rel}/IINSTALLFS
else
if [[ ${os_rel} > "B.11.11" ]]; then
ramfs=/opt/ignite/boot/Rel_${os_rel}/WINSTALLFS
else
ramfs=/opt/ignite/boot/Rel_${os_rel}/INSTALLFS
fi
fi
loadfile -r -l ${ramfs} > $INST_CLIENT_DIR/config.sys 2>/dev/null
err=$?
print "ERROR: Failed to copy config.sys from ${ramfs}" >&2
print " on \"$SERVER_NAME\"." >&2
print " You must use the '-R release' option to specify a
release" >&2
print " that is supported by \"$SERVER_NAME\"." >&2
123
We only need the first 8KiB of the install filesystem (at most). The first 8KiB of a filesystem is unused.
Ignite-UX uses the feature to keep a small amount of configuration in the filesystem.

print " On \"$SERVER_NAME\" list the contents of /opt/ignite/boot

to" >&2
print " determine the supported releases." >&2
exit $err
fi
# if the INSTALLFS on the server has been blanked out with instl_adm -b
# then even though we can retrieve the file it is empty.
#
if [[ ! -s $INST_CLIENT_DIR/config.sys ]]; then
print "WARNING: Zero length config.sys copied from ${ramfs}" >&2
print " on \"$SERVER_NAME\"" >&2
fi
fi
The hostname goes into the client_name file.
#
# Write the hostname to the client directory. This is needed
# by the Ignite-UX server during its parsing of the
# /var/opt/ignite/clients directory. Always update this file
# even if the -f option wasn't specified. If the client dir
# already exists, this is effectively just a client rename
# operation.
#
# Note: The name of the file "client_name" is tied to a literal
# in src/inst_misc.h
#
print $LOCAL_HOSTNAME > $INST_CLIENT_DIR/client_name
Now we can create the host.info, io.info, and hw.info files for the system in the client directory by calling
rescan_hw_host. Some extra entries are added into the host.info file.
#
# Generate host.info, io.info and hw.info to the client
# directory. Note that INST_CLIENT_DIR has been set
# during the call to 'SetupClientDirectory'
#
#
if [[ ! -a $INST_CLIENT_DIR/hw.info || ! -a $INST_CLIENT_DIR/io.info || ! -a
$INST_CLIENT_DIR/host.info || $FORCE_OVERWRITE -eq 1 ]]
then
export INST_LOG_FILE=$INST_CLIENT_DIR/install.log
rescan_hw_host
err=$?
print "ERROR: I/O scan of \"$LOCAL_HOSTNAME\" failed" >&2
exit $err
fi
#
# Write the current release information out to host.info. This
# enables the IUX server to perform a version check prior to allowing
# a network_recovery_archive
#
print "_hp_current_client_release=\"$(uname -r)\"" >>
$INST_CLIENT_DIR/host.info
print "_hp_current_client_release visible_if FALSE" >>
$INST_CLIENT_DIR/host.info

#
# Also write the hostname to host.info. This is required for the IUX
# console to be able to run bootsys. Note: the format of the string
# being written to host.info is dependent on thte lib/libcfg library.
# Please verify any changes to this with the current behavior of the
# library.
#
print "system_name=\"$LOCAL_HOSTNAME\"" >> $INST_CLIENT_DIR/host.info
print "source_type=\"NET\"" >> $INST_CLIENT_DIR/host.info
fi
Now we're done.
#
# Cleanup prior to exiting
#
exit 0
Running make_net_recovery
When running the ignite(1) text interface if you attempt to run make_net_recovery on a client you will get
the following message in a dialog asking if you wish to continue anyway:
Without X windows, this dialog may be used to install the

network recovery tools on a client but not to complete
archive creation. You will need to run make_net_recovery
on the client to create the archive after the tools are installed.
Do you want to proceed with the dialog?
So while you can install the recovery tools you can’t actually run make_net_recovery unless you’re running
the X windows interface of ignite(1). From here we’re going to assume that the X interface can be run so
make_net_recovery can be run via the ignite(1) command.
The following steps are done to allow the command to run:
• The directory /var/opt/ignite/recovery/archives/<client> is created if it does not exist (this includes

creating all missing directories down to the client archive directory).
• The NFS exports 124 are checked to ensure that the client archive directory is exported and that the
options are set as expected. If Ignite-UX finds options that it does not expect the following
messages will be printed:
Table 24 - Unexpected NFS options messages

HP-UX release Message
B.11.31 or later "/var/opt/ignite/recovery/archives/<client>" is already
exported with options different from the ones Ignite-UX writes
for network recovery archive creation. Review the options if
you plan to use the directory for archive creation. See
"/etc/dfs/dfstab" or (share(1M)).
B.11.23 or earlier "/var/opt/ignite/recovery/archives/<client>" is already
exported with options different from the ones Ignite-UX writes
for network recovery archive creation. Review the options if
you plan to use the directory for archive creation. See
"/etc/exports" or (exportfs(1M)).
124
We won’t discuss the clients directory here it is exported and checked in a different place when you run
the ignite(1) command.

• If the filesystems haven’t been exported Ignite-UX does the exporting using the exportfs
command (on HP-UX B.11.23 or earlier) or using the share command (on HP-UX B.11.31). Note
that even if the directory was already shared but it had to be created Ignite-UX always unshares
and then shares the directory. Attempting to use the newly created directory via NFS that has been
previously exported/shared will return errors (permission denied).
• If an entry for the directory doesn’t exist in /etc/exports (HP-UX B.11.23 or earlier) or
/etc/dfs/dfstab (HP-UX B.11.31) they will be added now.
• If the recovery commands depot does not exist it will be created now.
• If we’re on a local X display the command “xhost +<client>” is run to allow the
make_net_recovery command to open windows on this X server. Otherwise the user is told to
allow access to the X server they are running by running “xhost +<client>” on their local
system 125.
This step does not matter when using ssh tunneling of X11 traffic as any X windows opened will
appear to via the ssh connection. Note you will need to use ssh with X11 tunnelling enabled from
the system where the X server is running. If that is a local PC you will need to run ssh with X11
tunnelling enabled from your local PC to the Ignite server.
• The client_status file in the per-client directory is truncated.
• Determine if remsh or ssh 126 should be used to access the client.
• One of the following commands are run depending on if the client will use remsh or ssh:
Table 25 - Commands run by ignite(1) to run make_net_recovery on client

Type Command
ssh cat /opt/ignite/lbin/update_tools | /usr/bin/ssh -X cat
>/var/tmp/update_tools; chmod +x /var/tmp/update_tools;
/var/tmp/update_tools -s <server> -d
/var/opt/ignite/depots/recovery_cmds; make_net_recovery -i -b -P s
-l <MAC> -s <server> <XOptions>
remsh cat /opt/ignite/lbin/update_tools | /usr/bin/remsh cat
/var/opt/ignite/depots/recovery_cmds; make_net_recovery -i -b -P s
-l <MAC> -s <server> <XOptions>
Where <server> is the Ignite server, <MAC> is the MAC address of the client that should be used
for the client directory on the Ignite server and <XOptions> are the X Options passed to ignite(1)
that should also be forwarded onto the make_net_recovery command (Note that if a –display
option is given to ignite(1) it is dropped when using ssh for communication with the client system).
Note the use of the –i option, this causes the interactive interface to make_net_recovery to start.
Running make_tape_recovery
125
On a PC based X server it is up to the user to determine how to achieve a functionally equivalent
outcome (if required).
126
Note that the –X option is used with ssh to enable X11 tunnelling via ssh so X traffic will end up
tunneled via your ssh connection to the Ignite server and then onto the X display.

The following actions are performed to run make_tape_recovery (we’re not going to cover any dialogs that
may happen before make_tape_recovery runs):
• If the recovery commands depot does not exist it will be created now.
• If we’re on a local X display the command “xhost +<client>” is run to allow the
make_net_recovery command to open windows on this X server. Otherwise the user is told to
allow access to the X server they are running by running “xhost +<client>” on their local system.
• The client_status file in the per-client directory is truncated (when run from the Ignite server the –s
option to make_tape_recovery will be used so the client status is updated on the Ignite server).
• Determine if remsh or ssh should be used to access the client.
• One of the following commands are run depending on if the client will use remsh or ssh:
Table 26 - Commands run by ignite(1) to run make_net_recovery on client

Type Command
ssh cat /opt/ignite/lbin/update_tools | /usr/bin/ssh -X cat
/var/opt/ignite/depots/recovery_cmds -t; make_tape_recovery -i -b -
P s -l <MAC> -s <server> <XOptions>
remsh cat /opt/ignite/lbin/update_tools | /usr/bin/remsh cat
/var/opt/ignite/depots/recovery_cmds -t; make_tape_recovery -i -b -
P s -l <MAC> -s <server> <XOptions>
Where <server> is the Ignite server, <MAC> is the MAC address of the client that should be used
for the client directory on the Ignite server and <XOptions> are the X Options passed to ignite(1)
that should also be forwarded onto the make_tape_recovery command (Note that if a –display
option is given to ignite(1) it is dropped when using ssh for communication with the client system).
Using ssh or remsh and their requirements

Strictly speaking there are no requirements (assuming you don’t mind entering passwords) for either,
except when using bootsys (which is not covered in this course) since it requires access to a client system
without entering a password. There is information on the bootsys(1m) manual page about how to setup ssh
to work with bootsys.

The process of a recovery or cold install

This part of the course starts after the install kernel and filesystem has been downloaded and init is about to
be started from the install filesystem. Before we can look at what happens when init starts running we need
to look at the structure of the install filesystem and the different phases of a recovery or cold install session.
The code that runs a recovery or cold installation session is almost identical, unless stated otherwise the
actions described in this section should be taken as applying to both.
The install filesystem, init, and the contents of inittab

The install filesystem is really just an image of a filesystem that is loaded and treated as the root filesystem
by the install kernel. It’s easy to look at the contents of an install filesystem (the size and contents may
different between HP-UX revisions but they contain basically the same contents):
# ll IINSTALLFS
-r--r--r-- 1 bin bin 61341696 Apr 4 23:43 IINSTALLFS
# dd if=IINSTALLFS of=/dev/vg00/rlvol10 bs=64k
936+0 records in
936+0 records out
# mount /dev/vg00/lvol10 /cdrom
Note that the filesystem type is not ISO9660. It has only been mounted temporarily at /cdrom because the
directory already existed:
# fstyp /dev/vg00/lvol10
hfs
Now we can look at /sbin/init:
# what sbin/init
sbin/init:
Ignite-UX Revision C.7.3.148
ignite/launch (opt) Revision: /branches/IUX_RA0709w/ignite/src@71360
Last Modified: 2007-08-24 09:42:50 -0600 (Fri, 24 Aug 2007)
ignite/headers $Revision: 70774 $ $Date: 2007-06-20 18:06:53 -0600 (Wed,
20 Jun 2007) $
We know from the output of the what command that /sbin/init is not the standard HP-UX init program (it
doesn’t have Ignite-UX output in it’s what output).
We’ll look at what this program does and how it invokes the regular init later (including the reasons why
this is done). For the moment though the standard init program that ends up running is in the install
filesystem as the following program:
# what sbin/system.init
sbin/system.init:
$Revision: B.11.31_LR

Now we can look at inittab from the install filesystem to get idea of what gets run in what order by init:
# cd /cdrom
# cat etc/inittab
#
# $Header: /svn/ignite/ignite/src/init/inittab,v 10.7 2006/08/22 21:37:22
ajmiller Exp $
#
# IGNITE_UX_COPYRIGHT 2006 #
# "(C) Copyright 2006 Hewlett-Packard Development Company, L.P." #
#
init:0:initdefault
rfs0:0:bootwait:/sbin/ramfs </dev/console >/dev/console 2>&1
rfs1:1:bootwait:/sbin/ramfs 1 </dev/console >/dev/console 2>&1
iuxl:0:bootwait:/sbin/launch </dev/console >/dev/console 2>&1
dbg1:1:bootwait:/sbin/launch 1 </dev/console >/dev/console 2>&1
shll:0123456:bootwait:/sbin/sh </dev/console >/dev/console 2>&1
rbt1:0123456:bootwait:/sbin/reboot </dev/console > /dev/console 2>&1
The first uncommented line in inittab show that the default run level for Ignite-UX is run level 0.
init:0:initdefault
In the default situation only the following things will be run by init.

iuxl:0:bootwait:/sbin/launch </dev/console >/dev/console 2>&1
In normal circumstances the third and fourth entries in inittab will never be run. When it is complete Ignite-
UX will cause a reboot to happen. It will not let the reboot occur from /etc/inittab.
So what are the other entries for? The other run levels correspond to debug levels for Ignite-UX. The only
thing slightly different is run levels 5 and 6 – these should never be used when booting a kernel the only
thing that will happen if you add –i5 or –i6 to the boot loader arguments is you will be left at a shell prompt.
The install filesystem is a very limited environment and little can be achieved from the shell.
Note the difference with /etc/inittab from the install filesystem with Ignite-UX version C.7.6.100:
# more etc/inittab
#
ajmiller Exp $
#
#
init:0:initdefault
#
# Allocate additional RAM filesystems
#


#
# Run launch, configure disks, load archive software.
#
iux0:0:bootwait:/sbin/launch </dev/console >/dev/console 2>&1
iux1:1:bootwait:/sbin/launch 1 </dev/console >/dev/console 2>&1
#
# Should never get to this point.
#
Run levels 5 and 6 no longer start you with a shell prompt it will start the installation or recovery session.
It’s important to discuss the meaning of bootwait since it appears in every entry. This is from the inittab(4)
manual page:
bootwait Process the entry only at boot init's

boot-time read of the inittab file.
Boot init starts the process, waits
for its termination, and, when it
dies, does not restart the process.
This causes the programs to be run once and not restarted, after each program is run the next program for
that run level is executed. That is /sbin/ramfs is run and that is followed by /sbin/launch. If /sbin/launch
died prematurely init would provide a shell to the user – when you exit from that shell the system would
reboot.
The phases
There are 3 phases to a recovery, they are:
Phase 1 – startup, create disk/volume groups, and install software.
Phase 2 – install software, configure system, create kernel, run scripts,

reboot
Phase 3 – run using final kernel and complete recovery or install session
These phases have distinct and different jobs to complete. All three phases work in concert to cold install or
recover a system. The phases of a recovery/installation session are not externally visible, they are an
internal Ignite-UX concept.

Phase 1
In this section we will deal with how the install or recovery process starts and how it interacts with the user.
We will assume that this is not an automated recovery. There will also be some differences discussed
between a media based and a network based recovery or installation session.
init starts
The first visible sign that the Ignite supplied init is running is when you see the message “* Preparing to
execute init...”. The only task of the Ignite supplied init is to write any arguments supplied to init into the
file “/init-argv” in the install filesystem. After doing this /sbin/init is unlinked and /sbin/system.init is
renamed to /sbin/init and then exec’ed.
So why do we have this added complexity? The reason is that the HP-UX init doesn’t provide any support
for processing arguments that it doesn’t understand. You should see something like this if you provide
unexpected arguments to the HP-UX init:
Main Menu: Enter command or menu > bo pri

Interact with IPL (Y, N, or Cancel)?> y
Booting...
Boot IO Dependent Code (IODC) revision 1
HARD Booted.
ISL> hpux -i'server=\"10.92.172.54\"' (;0)/stand/vmunix
Boot
: disk(0/1/1/0.0.0.0.0.0.0;0)/stand/vmunix
14983168 + 4681728 + 4279704 start 0x234668
...
/sbin/ioinitrc:
/sbin/krs_sysinit:
NOTICE: mod_fs_reg: Cannot retrieve configured loading phase from KRS for
module
: cifs. Setting to load at INIT
* The module 'rng' has been loaded.

* The module 'dmpaa' has been loaded.
* The module 'dmpaaa' has been loaded.
* The module 'dmpap' has been loaded.
* The module 'dmpapg' has been loaded.
* The module 'dmpapf' has been loaded.
* The module 'dmpjbod' has been loaded.
* The module 'dmphpalua' has been loaded.
* The module 'dmphdsalua' has been loaded.
* The module 'fdd' has been loaded.
* The module 'ipf' has been loaded.
insf: Installing special files for ipmi instance 0 address 16
INIT: Overriding default level with level 'server="10.92.172.54"'

INIT: SINGLE USER MODE
INIT: Running /sbin/sh
You end up in single user because the first letter of the argument was “s”. What happens if an argument is
used that doesn’t correspond to a run level? In that situation you’ll be prompted to enter a run level:
Main Menu: Enter command or menu > bo pri

Interact with IPL (Y, N, or Cancel)?> y
Booting...
Boot IO Dependent Code (IODC) revision 1
HARD Booted.
ISL> hpux -i'_my_variable=\"TRUE\"' (;0)/stand/vmunix
Boot
: disk(0/1/1/0.0.0.0.0.0.0;0)/stand/vmunix
14983168 + 4681728 + 4279704 start 0x234668
...
/sbin/ioinitrc:
/sbin/krs_sysinit:
NOTICE: mod_fs_reg: Cannot retrieve configured loading phase from KRS for
module
: cifs. Setting to load at INIT
* The module 'ipf' has been loaded.

* The module 'fdd' has been loaded.
* The module 'dmphdsalua' has been loaded.
* The module 'dmphpalua' has been loaded.
* The module 'dmpjbod' has been loaded.
* The module 'dmpapf' has been loaded.
* The module 'dmpapg' has been loaded.
* The module 'dmpap' has been loaded.
* The module 'dmpaaa' has been loaded.
* The module 'dmpaa' has been loaded.
* The module 'rng' has been loaded.
insf: Installing special files for ipmi instance 0 address 16
ENTER RUN LEVEL (0-6, s, or S):
This is the reason why Ignite-UX has a program that runs before the real init is loaded.
Note that older versions of Ignite-UX don’t work this way. It’s only been in the last few years that Ignite-
UX switched to using the real init to run the recovery. Prior to this change the init program was completely
custom and the HP-UX init was never involved in the recovery/installation process.
The real init starts
When init is exec’ed it does its startup processing then proceeds to run what is in /etc/inittab. That is
basically run /sbin/ramfs and then /sbin/launch.

What does /sbin/ramfs do?
Before looking at /sbin/ramfs in the install filesystem does we need to understand something else about the
structure of some of the Ignite commands in the install filesystem. If we look at the ramfs binary you can
see that it has 18 hard links:
# ll sbin/ramfs
-r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 sbin/ramfs
And in this case the inode number is 33:
# ll -i sbin/ramfs
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 sbin/ramfs
With that information we can grep for 18 and then for 33 and luckily no other programs match that
criteria 127 so we can see what all of the hard links are 128.
# ll -i sbin |grep 18 |grep 33

33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 bdf
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 cat
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 fs_type
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 funzip
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 get_disk_layout
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 get_partition_info
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 init
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 launch
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 loadfile
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 map_root_lv
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 mkdir
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 mknod
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 pstat
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 ramfs
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 rescan
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 rm
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 sync
33 -r-xr-xr-x 18 bin bin 2500536 Aug 30 2007 unlink
So why are we looking at this? The first thing that /sbin/ramfs does is determine its basename. This is done
so that code specific to ramfs can be run after testing on the basename of the command used to invoke it 129.
The major functional steps in running ramfs are:
• Determine the basename for the program.
• Set the group of the process to be “sys” (gid 2). When init starts it only has a uid/gid of 0.
Normally not many things are owned by group root so the group id is changed to be a more
expected value.
• The console device is initialized with some sensible default attributes.
127
If they had we could have used the find command with the –inum option to easily locate all of the
hardlinks within the one filesystem.
128
During the recovery or installation process the number of hard links may increase as sometimes his
program may have additional hard links created.
129
This discussion is not going to point out which code is common and which code is specific to ramfs (or
later to launch).

• The file “/init-argv” is opened (if it exists) and the arguments passed to init are loaded.
• Debug support is setup based upon the arguments passed to init.
• The initial message that first appears into the log file (install.log) is printed:
======= 06/01/08 20:57:05 EDT HP-UX Installation Initialization. (Sun Jun 01

20:57:05 EDT 2008)
@(#)ignite/launch (opt) Revision:
/branches/IUX_RA0709w/ignite/src@71360 Last Modified: 2007-08-24
09:42:50 -0600 (Fri, 24 Aug 2007)
The log file is initially opened in /tmp in the install filesystem as there is no where else to store it –
apart from the install filesystem.
• We load any configuration present in the install filesystem and save it into the file /installfs.cfg.
This file is then parsed by Ignite-UX to ensure that it is valid.
• Next is a memory check to ensure that the minimum and minimal amount of memory is present in
the system. This table shows both memory values:
Table 27 - Minimum and Minimal memory sizes

HP-UX revision Minimum Size Minimal Size
B.11.11 256 512
B.11.23 450 950
B.11.31 950 1400
The following message is printed if the amount of memory fails to meet the minimum size
(afterwards a reboot is done and the recovery or installation session is stopped):
ERROR: The system does not contain the minimum supported amount
of memory needed to install and run HP-UX. HP-UX requires
<minimum> MB of available memory for the <release> release.
The system has only <current> MB of memory available for HP-UX
use (this may be less than physical memory installed due to
space reserved by system firmware). The amount of memory in
the system must be increased if this release is to be installed
successfully.
The following message is printed when the system fails to meet the minimal amount of memory
required for that version of HP-UX
WARNING: The system does not contain the minimal amount of memory needed
for install or recovery. Ignite-UX requires <minimal> MB of
available memory for the <release> release. The system has only
<current> MB of memory available for use (this may be less
than physical memory installed due to space reserved by
system firmware). The install or recovery may or may not complete,
and it may take an extraordinary amount of time to complete.
It is advised to increase the amount of memory in the system.
The following terms were used that require definitions:
<release> - HP-UX revision from the above table

<minimum> - The minimum memory size required for the revision of HP-UX from the above table
<minimal> - The minimal memory size required for the revision of HP-UX from the above table
<current> - The amount of memory currently in the system

These messages are not strictly accurate. The minimum supported memory sizes to install or
recover a system are documented in the Ignite-UX release notes:
1.3 Minimum Memory Size

========================
During installation and recovery, Ignite-UX uses system memory to hold a

RAM-based installation environment with a subset of HP-UX. Ignite-UX
requires installation and recovery client systems to have at least a
minimum amount of RAM to hold this installation environment while
leaving enough space to run HP-UX. The minimum required RAM size is
specific to the HP-UX version to be installed or recovered. The
required minimum memory for this release of Ignite-UX is:
Client OS IMM* HP 9000 HP Integrity

--------- ------ ------- ------------
11.11 128 MB 256 MB N/A
11.23 N/A 1.0 GB+ 1.0 GB+
11.31 N/A 1.5 GB 1.5 GB
* The IMM size is the size of the initial memory module on HP 9000
(PA-RISC) systems. The first memory module must be large enough to
hold the install kernel and install file system.
+ The Minimum Ignite-UX memory size specified is larger than the

original HP-UX release memory requirement. OS content and install
environment changes since initial release requires more memory.
Install or recovery of a system with less memory may take much
more time than expected or may hang.
Note that they don’t strictly match and aren’t consistent between the two.
• Set the current client directory to be /tmp. There’s no networking or disk/volume groups
configured yet the client directory has to be in the install filesystem until later. The names of some
of the files that need to be created are setup pointing to the client directory (e.g. hw.info and
io.info).
• The message "Configuring RAM filesystems..." is printed.
• Depending on the release up to 2 RAM filesystems are created of differing sizes, those sizes are:
Table 28 - RAM filesystem sizes

HP-UX Release Number Percentage of Minimum and Percentage of Minimum and
Memory – Maximum size – Memory – Maximum size –
ramfs 1 ramfs 1 ramfs 2 ramfs 2
B.11.11 1 NA NA 10 64-512
B.11.23 2 1 30-100 10 128-1536
B.11.31 2 1 30-100 10 256-1536
The mount points created for the the filesystems are /RAMFS1 and /RAMFS2 130. The /RAMFS1
filesystem on 11.23 and 11.31 is always used for device files. Depending on the HP-UX release
different directories may be relocated to /RAMFS2 (with a symlink at the original directory
pointing to the relocated directory in a ram filesystem). We won’t discuss which directories are
relocated. The debug output however does print a lot of information about what RAM filesystems
are setup and what relocations are performed.
130
As described in the table above HP-UX B.11.11 only has a /RAMFS2 created.

• Once complete /sbin/ramfs exits as all of the RAM filesystems have now been setup.
What does /sbin/launch do?
The launch program is not that much longer than /sbin/ramfs, it invokes other programs to continue the
recovery or installation process once it has completed what it needs to do. The initial steps that the program
takes are the same as for /sbin/ramfs since it is a hard link to the same program.
Some of the steps need to be redone (e.g. setting the group id) because this is a new program being run by
init and it has inherited its execution environment.
• Determine the basename for the program.
• Set the group of the process to be “sys” (gid 2). When init starts it only has a uid/gid of 0.
Normally not many things are owned by group root so the group id is changed to be a more
expected value.
• The console device is initialized with some sensible default attributes.
• The file “/init-argv” is opened (if it exists) and the arguments passed to init are loaded.
• Debug support is setup based upon the arguments passed to init.
• We load any configuration present in the install filesystem and save it into the file /installfs.cfg.
This file is then parsed by Ignite-UX to ensure that it is valid.
• If the undocumented variable _hp_launch_delay is defined in the installfs configuration we sleep

for how many seconds it is set to (if it is a number).
• Set the current client directory to be /tmp (since there’s no networking or disk/volume groups
configured yet the client directory has to be in the install filesystem until later. The names of some
of the files that need to be created are setup pointing to the client directory (e.g. hw.info and
io.info).
• The reordering of SAS disks into their default order is performed now 131 (so increasing bay order
matches increasing hardware path order).
• The I/O listener is started and told to perform an inventory and write out the hw.info and io.info
files.
• The I/O listener is stopped (depending on future usage it is highly likely that stopping the I/O
listener will happen later).
• If the I/O listener did not find any disk devices you will see the following note printed:
NOTE: There were no disk devices found during the scan. Make
sure that the destination disks are connected and powered on.
You may choose to scan for more disk drives from next menu
on the console.
131
The order that SAS devices can be discovered in can be indeterminate. This code ensures that the SAS
devices are initialized into a known consistent state before any information is gathered about hardware.
This also ensures that after a cold install the hardware paths are always consistent and the same if the same
SAS bays are occupied.

• Now the host.info file is created. The following entries are added into the file at this point:
MEMORY=<memory_size>
HARDWARE_MODEL=<machine_model>
MODEL=<model>
_hp_ikernel_os_release=<release>
can_run_64bit=<64_bit>
can_run_32bit=<32_bit>
is_numa=<numa>
is_hppa=<HP9000>
is_ia64=<HP_Integrity>
is_ht_capable=<HT_Cap>
_hp_boot_dev_path=<boot_hw_path>
init _hp_default_cur_lan_dev=<lan_dev>
_hp_default_cur_lan_dev visible_if false
Where the following definitions apply:
Table 29 - host.info definitions

Value Description 132
<memory_size> is the amount of memory in the system in KiB
<machine_model> is the output of “getconf CS_MACHINE_MODEL”, if that fails it is the output
of uname –m.
<model> is the output of the model command.
<release> is the HP-UX release of the currently running install kernel
<32_bit> is “TRUE” if the system can run 32bit HP-UX, otherwise “FALSE”. Never
“TRUE” on HP Integrity systems.
<64_bit> is “TRUE” if the system can run 64bit HP-UX, otherwise “FALSE”. Always
“TRUE” on HP Integrity systems.
<numa> is “TRUE if the system has a non-uniform memory architecture, otherwise
“FALSE”
<HP9000> is “TRUE” if the system is a HP9000 system, otherwise “FALSE”
<HP Integrity> is “TRUE” if the system is a HP Integrity system, otherwise “FALSE”
<HT_Cap> is “TRUE” if the system is a HP Integrity server that supports Hyperthreading,
otherwise “FALSE”. Never written to host.info for HP9000 systems.
<boot_hw_path> is the hardware path of the boot device.
<lan_dev> is the current default lan device if the system booted from the network (not
written if the system did not boot from a lan device). The following line
“_hp_default_cur_lan_dev visible_if false” is always written if the
first line is written 133.
• The primary path is retrieved from the output of the setboot command and placed into the
environment (it’s retrieved later by net_cfg_prep).
• On HP9000 systems the EISA configuration files are cleaned up. These files are still required for
32bit HP-UX B.11.11 installs. EISA is not supported on 64bit HP-UX B.11.11 or on HP-UX
B.11.23 onwards.
• The log file is closed.
132
Some of the methods described here for getting data is not the actual method used by Ignite-UX to
gather the data, where a command is given the direct system call to get the data instead. When given the
commands are presented here to allow you to more easily understand where the data comes from.
133
The “visible_if FALSE” prevents the variable from being shown (and allowing it to be modified) via the
additional button on the basic tab in itool.

• The net_cfg_prep command is run. This may require one or more files to be uncompressed in the
install filesystem before it gets run. The next section “Running net_cfg_prep” gives details on
what net_cfg_prep does. The section after that continues on with the operation of the /sbin/launch
command.
Running net_cfg_prep
This section describes what happens in net_cfg_prep. It also breaks out into relevant sub areas of
net_cfg_prep. It should be noted that inspite of the name net_cfg_prep is not run only in network based
situations. All installations or recoverys that are not fully automated run net_cfg_prep to show the initial
menus to the user.
The start of net_cfg_prep

• The debug flags are retrieved from the environment. This enables the logging functionality later to
log debug level messages if required.
• The current client directory is located (this is in the local install filesystem, for network based
installs and recover we’re yet to relocate it to an Ignite server).
• The names of the configuration (only config.sys – the file created based on the contents of the
install filesystem) and other files that have been created so far (hw.info, host.info, io.info, and the
environment variables file) all have their names initialised.
• The client status file is updated to indicate that the discover system phase is pending and the
source type (network, disk, etc) is determined.
• The configuration available so far is parsed. The only configuration so far is from the install
filesystem and loader. Configuration supplied by the loader is written into a temporary file. All of
the configuration is then parsed.
The configuration needs to be parsed at this point as we will need certain information soon. For example
the setting of the configuration item “control_from_server” and other information later on such as the IP
address of the Ignite server to use.
Following the next section about net_cfg_prep being able to change the source type we will go immediately
into what happens when the install calls for a non-interactive install, that will be followed by the interactive
part.
Coming to a decision about what source type to use

If the source type is not currently network (i.e. you booted from a DVD or tape) it’s still possible that you
may be forced to use the network. This can happen in the following circumstances.
1. The media has no SYSCMDS 134 file.

2. The media has a SYSCMDS file, but no RECCMDS or INSTMCDS file.
3. The media has a SYSCMDS file and an INSTCMDS file but no INDEX file.
If the media has a SYSCMDS file and a RECCMDS file (but no INSTCMDS file) the source type is not
changed as the media is assumed to be recovery media.
134
In general when referring to command archives like SYSMCDS etc you can assume that on HP Integrity
systems the check is for SYSCMDSIA.

If the source type is changed from media to network you will see the following message printed:
NOTE: Default (boot) source does not appear to be a valid (or complete)
install source, switching source to Network
Regardless of what is on the media if “control_from_server=true” is set in the install filesystem

net_cfg_prep always changes to a network based install or recovery. If this is true the following message is
always printed:
NOTE: Switching from the local tape/disk source to network because

control_from_server=true is set in the INSTALLFS file.
Back to net_cfg_prep (non-interactive)

This section describes the non-interactive path of net_cfg_prep. To be non-interactive the configuration
item run_ui must be set to false (in the install filesystem).
The configuration item control_from_server must also be set to false otherwise the system will wait for the
Ignite server to tell it to proceed with the installation. This is sort of non-interactive in that you no input is
required on the console but interaction will be required on the Ignite server when control_from_server is set
to true.
• The first thing determined is if this is a non-interactive install or recovery session. If it is not the
program goes down the interactive path (go to the section “Back to net_cfg_prep (interactive)” to
continue).
The following occurs if control_from_server is set to false.
• The sysadm message is printed (set automatically for make_tape_recovery). The following
message is then printed:
WARNING: The configuration information calls for a non-interactive

installation.
Press <Return/Enter> within <x> seconds to cancel batch-mode

installation:
Where <x> is the number of seconds to wait before continuing with a batch mode install or
recovery session (determined by the environment variable INST_BATCH_MODE_TIMEOUT). It
is unusual to give a value to the environment variable INST_BATCH_MODE_TIMEOUT, if you
do it must be given in the install filesystem as follows:
env_vars="INST_BATCH_MODE_TIMEOUT=20"
If you set other environment variables using env_vars remember after setting the first one you
must use += instead of =. Not doing this will cause only the last environment variable to be
recognized.
When not set INST_BATCH_MODE_TIMEOUT defaults to 10 seconds. If enter or return is

pressed within the timeout the session continues as interactive (go to the section “Back to
net_cfg_prep (interactive)” to continue).
• The loopback interface is started.
If the system contains LAN cards the following steps are performed:

• We locate the current default LAN card. If it can’t be found batch mode is cancelled and we
continue in interactive mode interactive (go to the section “Back to net_cfg_prep (interactive)” to
continue).
• If the source is network, or there’s an IP address defined for the network interface in the
configuration, or we need to enable network regardless 135 then we try to setup networking.
The following steps are used to setup networking. If this fails the message “Failed to startup
networking, user interaction required” is printed and the user asked to press enter. The Ignite
session will continue as an interactive session (go to the section “Back to net_cfg_prep (interactive)” to
continue).
• If the source type is network and there is no IP address for the Ignite server (server= keyword)
then the error “The install server's IP address is not set. See instl_adm(1M)
on how to set the default on the server.” is printed and an error is returned.
• If we have a current default LAN interface we will attempt to use DHCP with that interface to gain
an IP address (if the configuration has not defined one for the interface).
• If there is no current default LAN interface then we see if networking information has been set for
any lan interface (if so that becomes the current default lan interface).
• As a last resort we run through every lan interface (if disable_dhcp has not been set to true) and
attempt to use DHCP on each interface until we get a response. This is done by attempting the
DHCP request on the first interface, then the last interface, then all of the interfaces in between (if
any) until a response is received.
Important: Depending on how the network is setup there is no guarantee that the interface what an
IP address is gained on will be able to talk to the Ignite server.
• We attempt to start networking. If this fails we will continue on with an interactive install (go to
the section “Back to net_cfg_prep (interactive)” to continue). Note that if we failed to gain any IP
address via DHCP starting networking will fail causing an interactive install.
• We start the DHCP daemon so we can maintain our DHCP lease (assuming we got a DHCP lease).
• Now that networking has been started we load the INDEX file and parse it. If it couldn’t be parsed
correctly batch mode is cancelled (go to the section “Back to net_cfg_prep (interactive)” to
continue).
• Some additional files are setup (resolv.conf and hosts) along with a few configuration file changes
to take the new networking information gained from DHCP.
If the system does not contain any LAN cards then the following message is printed after which the user is
forced into interactive mode (go to the section “Back to net_cfg_prep (interactive)” to continue).
ERROR: Boot source is network, but no network hardware was found.
• The hostname is set.
135
Controlled by the environment variable INST_ENABLE_NETWORK, setting this to 1 will force the
network to be configured, setting it to 0 has no effect if networking must be started. That is you cannot
prevent it from being started when Ignite determines it must be started.

• The /var/opt/ignite/clients directory from the Ignite server is mounted on the local system at
/var/opt/ignite/clients. Note that if this fails it does not cause the recovery or install session to stop,
instead a local directory is created in the install filesystem and this is used instead. We will assume
in this discussion that mounting the filesystem is always successful.
• The client directory is located (see “Looking at add_new_client to understand why lanscan is
called” for the method used). If it doesn’t exist it will be created.
• If we’re not being controlled from the server the install.log file is moved to the client directory on
the Ignite server (any existing install.log file is renamed to install.log.prev). The log file is closed
during the move and then later opened again 136.
• The following files are also moved to the Ignite server from the local install filesystem: config.sys,
env.vars, hw.info, io.info, and host.info.
• If the environment variable IGNORE_PRIOR_CONFIG_VAR is set to true (case insensitive) the

per-client config file on the Ignite server is moved from config to config.ignore. If this is done you
will see a message like the following printed:
NOTE: The client's prior saved config file:

/var/opt/ignite/clients/<MAC>/config is being ignored, and was
renamed to /var/opt/ignite/clients/<MAC>/config.ignore (because
IGNORE_PRIOR_CONFIG_VAR="true").
Different error messages can be printed if mounting the client directory from the Ignite server fails they are:
1. For general failures the following message is printed and the user needs to press enter to continue
with an interactive install/recovery session (go to the section “Back to net_cfg_prep (interactive)”
to continue).
ERROR: Could not create the client specific directory.

Will switch to an interactive installation.
2. If the session is controlled from the server the following message is printed and the user is
prompted to answer the question. Answering y/Y will get the system to attempt to remount the
/var/opt/ignite/clients directory from the Ignite server, answering n/N will continue with an
interactive install (go to the section “Back to net_cfg_prep (interactive)” to continue).
ERROR: Could not mount the client specific directory from server.
Control of the installation cannot be done from the server until
the problem is fixed and the client is allowed to mount the
directory: "/var/opt/ignite/clients” from the server with
read/write permissions.
Would you like to attempt the mount again?"
This gives you the opportunity to go back and fix any NFS export/share issues on the Ignite server
and attempt to remount the clients directory from the Ignite server.
• The host.info file is updated with the source type and source path along with the primary path. The
config.sys file is updated with the settings for disable_dhcp, run_ui, control_from_server, and
use_expert_ui.
• The Ignite-UX revision of the Ignite server is checked against the client Ignite-UX revision. The
Version file from the Ignite server is downloaded (via tftp). The version is not checked for other
136
If an error happens while the log file is closed the only record of any errors will be on the console of the
system.

source types (currently tape and DVD/CD media). The version from the file is compared against
the Ignite version that the system booted.
If the version numbers are identical no messages are logged. If the letter, major and minor number
of the versions are the same and the ticker number is within 10 you will see the following note:
NOTE: The version of Ignite-UX on the server you are using (U.VV.XX.YY) is
different than the version of Ignite-UX that the client booted (U.VV.XX.ZZ).
However they are within an allowable difference to continue.
And if the letter, major or minor number of the versions are different you will see the following
error:
ERROR: The version of Ignite-UX on the server you are using (U.VV.XX.YY) is
different than the version of Ignite-UX that the client booted (A.BB.CC.DD).
The versions must match in order to ensure correct behavior. You may need to
update the device you booted from with the components found on the server.
After this error the user is prompted to answer the following question:
Continuing the installation with a tape version mismatch is likely

to cause indeterminate problems. Do you want to continue anyway?
It is worth while noting that HP does not support for situations where y/Y was answered to this
question as using mismatched versions of Ignite-UX is not supported. Great care should be taken
before deciding to answer y/Y to this question.
• They keyboard language is set by running itemap (applies only to graphics consoles).
• If this session is controlled from the server we wait for instructions (typically this involves waiting
to be told either to go or to cancel or perform some other action while waiting for the Ignite
administrator to run itool on the Ignite server and choose and/or modify a configuration for the
installation or recovery session).
• If we’re not being controlled from the server we add the per-client config file into the
configuration files to be parsed (if it exists at the moment).
• If we’re being controlled from the server and we’ve gotten the go ahead to start the install or
recovery session the client status file is updated to indicate that we’ve completed waiting for
instructions.
• The final parse of the configuration is done.
• If the final parse of the configuration set run_ui to be true then we switch back to an interactive
install or recovery (go to the section “Back to net_cfg_prep (interactive)” to continue) after
printing the message:
NOTE: The final configuration information requests an interactive install.
And then prompting the user to confirm the switch back to an interactive install or recovery with
the message “Switching to an interactive install.”.
• Sanity checks are performed on the configuration to try to make sure that there is nothing
obviously wrong with the configuration. Some of the things sanity checked include 137:
137
This is not an exhaustive list.

1. Make sure that the release being installed is supported to be installed with the HP-UX revision
of the install kernel (with current versions of Ignite-UX the install kernel HP-UX release must
match the HP-UX release being installed).
2. Ensure that the “release” keyword has been defined (otherwise Ignite-UX has no idea what
HP-UX release is being installed).
3. Memory checks are done again (see “What does /sbin/ramfs do?” for more information about
the memory checks)
4. Volume/Disk groups are checked to ensure that they fit onto the disks that they’re configured
to use. They’re also checked to ensure that there are no empty volume/disk groups defined.
5. Bad mount points are checked for. Bad mount points are defined as any mount point that
contains characters in the “C” locale character classes “space” (see isspace(3)) or “cntrl” (see
iscntrl(3)).
6. Make sure there are no errors in the disk configuration, for example no root filesystem
(nothing with a mount point of “/”) and there is no swap on the root disk (or its size is 0).
• If there was an error in the configuration we go back to waiting for instructions from the server.
The errors from the sanity checking would be printed and that would be followed by the following
message:
NOTE: Configuration failed to pass sanity checks, please correct

the problem on the server.
• We’re now at the point we can no longer fall back to an interactive install or recovery session and
the following message is printed:
NOTE: Attempting a non-interactive installation.
• Any pre_config_cmd hooks defined in the configuration are now run. Note that this command
hook is the only command hook at has access to the ram based install filesystem. All future
command hooks are chrooted into the disk based root filesystem. If an issue causes you to need to
change something in the the ram based install filesystem it must be done at this point.
• net_cfg_prep exits with an exit value that tells /sbin/launch to attempt a non-interactive install
(continue to the section “Back to /sbin/launch”).
Back to net_cfg_prep (interactive)

This section follows the interactive path of net_cfg_prep.
• The first thing done is to set the keyboard language. The command “/sbin/itemap -i -L -w
/etc/kbdlang” is run to do this. If the configuration sets the keyboard language using
_hp_keyboard 138 then –l followed by the selected language is added to the command.
If the system does not have a keyboard attached (or does not have the hardware to support one) the
itemap command does nothing and exits with a return code of 0. The recovery or installation
session continues – you are not given the chance to select the keyboard type.
If the system does have a keyboard attached you will be given a list of keyboards to choose if the
configuration did not define a keyboard via _hp_keyboard. At this point you need to select which
keyboard you have attached to the system.
138
Previously know as the kbdlang keyword.

If present the contents of the /etc/kbdlang file are read and _hp_keyboard is set in the
configuration to the selected value.
• The ttytype program is run to try and determine the terminal type of the console. After
determining the terminal type (which in the worst case may end up being prompted for). Curses is
initialized.
• Setup is done so the following screen can be displayed:
Before the screen is shown the following actions are taken.
• The sysadm message is shown if present. As stated on the instl_adm(4) manual page this message
is only shown when defined in the install filesystem configuration:
sysadm_message = cplx_string
Sets the message displayed to you when the client first boots the
cold install process. This message is only recognized when
stored in the configuration file that exists in the first 8KB of
the *INSTALLFS file. The instl_adm -a option to make this easy to
change.
It’s typically only seen during a tape recovery (it’s possible that someone may use it in other
circumstances).
• The information for the hardware summary at the top of the screen is gathered. As of versions of
Ignite-UX around C.7.2 Ignite-UX will only count unique paths to disk luns in the number of
disks. Prior to this Ignite-UX counted all paths to all luns and added up their capacity. That gave a
potentially misleading result for the number of disks and amount of disk space connected to the
system.
• The screen is built directly using curses. The contents of the screen however can vary. This list
summarises the differences.
1. The title at the top reads “Welcome to Ignite-UX!” if INSTCMDS exists but RECCMDS does
not.

2. The title at the top reads “Welcome to the HP-UX installation/recovery process!” if both
INSTCMDS and RECCMDS both exist.
3. The title at the reads “Welcome to the HP-UX recovery process!” if only RECCMDS exists.
Note that during a network install the network is not active yet and INSTCMDS is assumed to
exist by default and the presense of RECCMDS cannot be determined so “Welcome to Ignite-
UX!” is always used as the title during a network install or recovery.
If RECCMDS is not available the option to “Run an Expert Recovery Shell” is not shown. If
INSTCMDS is not available the option to “Install HP-UX” is not shown.
• At this point the screen shown above is displayed.
From here we’re going to follow what happens when you select “Install HP-UX” (see “Install HP-UX”)
and “Run an Expert Recovery Shell” (see “Run an Expert Recovery Shell”).
Run an Expert Recovery Shell

This section describes how an expert recovery shell is started but it does not cover the functionality and use
of the expert recovery shell.
• The loopback interface is started (lo0).
• If a LAN card exists and the current install source is the network and networking has not been
configured yet we need to start networking.
o If networking has not been configured yet the following message is printed:
o Next the question “Would you like to startup networking at this time?” is asked of the
user. Answering Y/y will start networking (see “Start Networking” for how this is done),
if N/n is answered the user will go back to the initial menu.
• If no LAN card exists and the current install source is the network you will see the message “No
networking hardware was found”. This will be followed by the error “Error: Boot source is
network, but no network hardware was found.”, after seeing this you will need to press enter to
continue and the system will reboot.
The most likely cause for seeing this message is the version of Ignite-UX you are using does not
have the driver required in the install kernel or the version of the driver in the install kernel cannot
claim the device. The solution in this situation is to upgrade Ignite-UX to a version that does
support the LAN interface.
• The hostname is now set. The host.info file is updated with the information gained and any
environment variables required are now set. See the section “Start Networking” for information on
how networking is started. Starting the Expert Recovery Shell only requires running a subset of
the steps given.
• To commence the process of starting the expert recovery shell net_cfg_prep exits with a value that
indicates to /sbin/launch that the recovery shell should be started (see “Back to /sbin/launch” for
more information).

Install HP-UX
This section deals with the option to “Install HP-UX”.
• The first thing checked is to ensure that some disks were found, if none were found the following
message is printed:
There were no disks found during the IO scan. You will need to
correct any hardware problems and either use the "Scan Again" button,
or reboot and try again.
• The “User Interface and Media Options” screen is shown. When installing from the network the
screen looks like:
Note that there are no media options since we are installing from a network source. Compare that to the
media version of the screen:

When selecting a media only install from a CD or DVD then the option for two step recovery is presented.
This option is only presented if a tape drive is also connected to the system and visible to the install kernel.
This option is only currently available for when booted from media you cannot perform two step recovery
from a network boot.
• The install source is set to the type of install chosen.
• For two step recovery the version of Ignite-UX on the tape is compared to the version of Ignite-
UX on the CD/DVD media.
• Networking is now started (see “Start Networking” for how this is done). Although networking is
started now most of the code described in that section is not executed for anything other than
network installs. As an example the code that loads the INDEX file is executed but it loads the

INDEX file from the tape or CD/DVD instead of the network. When performing a media install or
recovery the main part of networking that is started is the loopback interface.
• For a network install or recovery session we now attempt to mount the client directory from the
Ignite server. First the directory /var/opt/ignite/clients is created (if it does not already exist). Then
the following command is run to NFS mount the directory from the Ignite server
“/sbin/fs/nfs/mount –orw <Server IP address>:/var/opt/ignite/clients /var/opt/ignite/clients”).
Where <Server IP Address> is the IP address of the Ignite server.
If NFS mounting the directory fails you are likely to see the following errors. If the installation or
recovery session is being controlled from the server you will see the following message if the
client directory cannot be mounted:
ERROR: Could not mount the client specific directory from server.
Control of the installation cannot be done from the server until
the problem is fixed and the client is allowed to mount the
directory: "/var/opt/ignite/clients" from the server with
read/write permissions. The /etc/exports file on the server
should contain the line "/var/opt/ignite/clients -anon=2".
Would you like to attempt the mount again?
If you have a problem with the way the directory is exported you can fix it then answer Y/y to
attempt to try the mount again. If not controlled from the server the client directory isn’t actually
required to be mounted and you will see the following message:
NOTE: Could not NFS mount the server, system configuration will not be
saved on the server for future use.
NOTE: Could not mount or create the client specific directory
Lastly if we could mount the filesystem but could not create the client directory you get the
following error:
ERROR: Could not create the client specific directory on the server.
This typically means that the server is not NFS exporting the
/var/opt/ignite/clients such that the root user on remote systems
has write permission to the directory. Please fix the problem
on the server. The /etc/exports file on the server
should contain the line "/var/opt/ignite/clients -anon=2".
And all files and directories under "/var/opt/ignite/clients"
must be owned by "bin".
The client system will now reboot.
• Now we locate the client directory. See “Looking at add_new_client to understand why lanscan is
called” for information on how the client directory is located on the Ignite server 139 (this includes
creating it).
For the following file moves the file is moved into the per-client directory on the Ignite server.
• If any install.log file exists on the Ignite server it is renamed to install.log.prev. The install.log file
is closed and the install.log file is moved from the install filesystem to the per-client directory on
the Ignite server. The log file is reopened on the Ignite server.
Consider the consequences of this step. Up to this point the install.log file only exists in the RAM
filesystem. If there is a failure at any point before the log file is moved and reopened the only
record of what has happened will be on the console of the system. This means that it is sometimes
139
The method used is the same although in this case the code knows all of the MAC addresses for the lan
interfaces already from the I/O inventory that has already been performed.

necessary to gather a log of what is happening from the console as it is not possible to get the
install.log file.
• The config.sys file is moved to the Ignite server and the configuration updated to point to the
moved file.
• The environment variables file is moved to the Ignite server. A symlink from the install filesystem
pointing to the newly moved file is created.
• The hw.info, io.info, and host.info files are moved to the Ignite server.
• The variable _hp_ignore_prior_config is checked to see if it is set, if it is the per-client config file
“config” is renamed to be config.ignore. Setting this variable means that you do not have to worry
about being prompted if you wish to retain the previous settings when running itool as the config
file will have been renamed to config.ignore.
• If the install source is network or tape the revision of the client version of Ignite-UX is checked
against the server (in the tape case the revision of the tape is checked instead of the server). The
check made is the functionally the same as here “make_net_recovery and the version check”. If
the versions are identical no messages are printed and we continue.
The following definition of the Ignite-UX revision is from the Ignite-UX release notes:
The format is:
{A|B|C}.major-rev.minor-rev.ticker
{A|B|C} => Major version identifier; rarely changes except when a

major Ignite-UX design change occurs.
=> A and B versions of Ignite-UX are no longer supported.
=> C: supports HP-UX B.11.11, B.11.23 and B.11.31

Ignite-UX servers installing HP-UX B.11.11, B.11.23
and B.11.31 targets. HP-UX 11.31 server and target
support is not available prior to the C.7.0 version
of Ignite-UX.
major-rev => Major software release number; rarely changes except

when a major change occurs (for example, adding support
for a new operating system)
minor-rev => Changes at each release
ticker => Changes each time we rebuild the product
If the versions are within a difference of 10 in the tickers the following message is printed
(network first tape second):
NOTE: The version of Ignite-UX on the server you are using (<Version1>)
is different than the version of Ignite-UX that the client booted
(<Version2>). However they are within an allowable difference to
continue.
NOTE: The version of Ignite-UX on your tape (<Version1>) is different

than the version of Ignite-UX that the client booted (<Version2>).
However they are within an allowable difference to continue

Otherwise the following error messges are printed. The error for network based install/recovery
sessions is first and the error for tape based install/recovery sessions second):
ERROR: The version of Ignite-UX on the server you are using (<Version1>)
is different than the version of Ignite-UX that the client booted
(<Version2>). The versions must match in order to ensure correct
behavior. You may need to update the device you booted from with
the components found on the server.
Continuing the installation with a server version mismatch is likely
ERROR: The version of Ignite-UX on your tape (<Version1>) is different

than the version of Ignite-UX on the media that the client booted
(<Version2>). The versions must match in order to ensure correct
behavior.
Continuing the installation with a tape version mismatch is likely
You will be prompted to indicate if you wish to continue anyway, please note that answering Y/y
to this question is (as stated) likely to lead to failures. Answering N/n will cause the system to
reboot – you should attempt to resolve the mismatch before continuing.
Important: As noted previously if the major or minor numbers in the version are different HP
does not support the result of the install or recovery session.
If the /opt/ignite/Version file on the Ignite server or the VERSION file on the tape cannot be found
the following messages are printed:
WARNING: Failed to read Version file from server using: "loadfile -rl
/opt/ignite/Version". This indicates that the server may have an
older version of Ignite-UX. 140
WARNING: Failed to read Version file from tapeusing: "loadfile -qrl

VERSION -f <device>".
• Now we add the per-client configuration file (if it exists) into the configuration files that we’re
going to be using.
• We’re finished with the menus so we can stop curses.
• Now we do a full parse of the configuration. This involves parsing all of the special configuration
files (e.g. the per-client config file) and the INDEX file and downloading and parsing all of the
files refered to in the cfg clauses in the INDEX file (this includes media installs). Syntax errors in
the full configuration are found at this point. 141
• Any pre_config_cmd hooks defined in the configuration are now run.
Note that this command hook is the only command hook at has access to the ram based install
filesystem, all future command hooks are chrooted into the disk based root filesystem. If an issue
140
Note that although it is possible to defeat the version checking by moving the Version file out of the way
on the Ignite server doing so it not supported by HP and the installation is likely to fail with mismatched
Ignite versions (this applies to booted from media then switching to a network installation or recovery or
booting from a boot helper and then contacting another Ignite server running a different version of Ignite-
UX.
141
For media installs the INDEX file contains a single cfg clause that refers to a single LIF file called
CONFIG.

causes you to need to change something in the the ram based install filesystem it must be done at
this point.
• Sanity checks are performed on the configuration.
• We exit with an exit value that tells /sbin/launch if it should start itool in wizard or expert mode.
Important: Wizard mode has been deprecated and is no longer the default mode for the user
interface. The default mode is expert. The Ignite-UX release notes announced the deprecation of
Wizard mode saying it will be removed in a future release. No work has started yet on the
replacement UI for Ignite-UX. The only thing known about it currently is that it will use the
cmenu interface like HP SMH.
Start Networking
In this section we will only be covering what happens the first time through network configuration, we will
not be discussing in detail what happens on any subsequent tries. That is if the information entered the first
time is incorrect and the Ignite server cannot be contacted the screens will take the user through network
configuration again.
This section is slightly misnamed, it is still executed for media and tape based installs and recovery but
most of the code is only executed when using the network as an install source.
• We first need to have the user select the lan device to user for the network install/recovery on the
“LAN Interface Selection” screen (if there is only one lan interface on the system this screen is not
shown):
• If the system booted from the network the network interface that was used for booting will be pre-
selected. If you booted from media and then changed to a network install or recovery the first
interface will be selected and you will need to choose the correct one.
• Once a LAN interface has been chosen the new LAN interface is written into a configuration file
and the configuration reparsed. This allows any configuration that relies on the MAC address or
the value of the default LAN interface to be re-evaluated.

Once the LAN interface has been selected Ignite-UX knows what LAN interface it is going to use from
here onwards.
• If the LAN interface doesn’t already have an IP address assigned we need to get one via DHCP.
Note that DHCP is not used if disable_dhcp is set to true (the default is false) and this step is
skipped. The following steps are done to gain an IP address via DHCP:
o An initial command line is built containing the following “/usr/lbin/dhcpclient –u –b

<lanx>”. <lanx> is the name of the interface that the DHCP request will be sent out on,
e.g. lan0, lan1, etc. The LAN interface is the interface selected on the LAN interface
selection screen.
o If the dhcp_class_id keyword has been used in the install filesystem the option –g is
added to the dhcpclient command line with the class id as the argument to the –g option.
o If the dhcp_server keyword has been used in the install filesystem the option –s is added
to the dhcpclient command line with the IP address of the server as the argument to the –s
option.
o If the dhcp_misc_opts keyword has been used in the install filesystem those arguments
are added onto the dhcpclient command line now 142.
o The dhcpclient command is called to see if a DHCP lease can be obtained.
o If successful the dhcpdb file is read to determine if a valid DHCP lease was obtained or
not.
The following is shown on the screen when DHCP starts:
If DHCP times out or Control-C is pressed to interrupt getting an IP address via DHCP the following is
then printed:
The value return from dhcpclient may vary depending on what has happened.
The user is then prompted with the “Network Configuration” screen which contains the following data:
142
It should be noted that the dhcpclient command is not a documented command, it does not have a
manual page and it is not intended to ever be called directly by an end user.

This screen is from a system that did not use DHCP, if DHCP was used the information would be fully
populated.
• If cancel is used from this screen any DHCP lease will be released if you answer Y/y to the
question below. Answering in the affirmative resets everything back to the start and leaves you
back at the initial menu.
Do you want the DHCP lease on IP address: "<IP Address>" (<hostname>), from
DHCP server: "<IP Address>", released so that it can be reallocated to a
different system?
Where <hostname> is the hostname allocated by DHCP, the first <IP Address> is the IP address
of the client from DHCP and the second <IP Address> is the IP address of the DHCP server.
If the IP address was gained from DHCP and the IP address was changed on the “Network
Configuration” screen the IP address gained via DHCP will be released.
If you cancelled this screen you will go back to the initial menu.
• If _hp_tftp_cmds was set in the install filesystem it is placed into the environment so it impacts on
the tftp requests that we will be performing shortly.
• The following message is printed if the install source is from the network:
* Reading configuration information from server...
• See the section “Network startup - Part 2”
• We download the INDEX file from the Ignite server and parse it (an error here may cause a non-
interactive install or recovery session to become interactive) 143. Although this section is titled
143
This doesn’t load the contents of the INDEX file yet, it only loads information about the cfg clauses and
the files referenced by each cfg clause.

network startup, non-networking installs and recoveries also go through this code and in this case
for non-network install sources the INDEX file is loaded from the LIF on the install source. A
failure here causes the following message to be printed:
Failed to read "INDEX" file from install server. Check that the
install server's IP address is correct and the server has the
"Ignite-UX" product loaded and is available via the tftp(1)
service.
Press any key to return to the network configuration menu:
Pressing any key will stop networking, release any IP address gained from DHCP, and go back to
the start (see “Start Networking”). This message is never printed for a media install as the INDEX
file must exist otherwise we wouldn’t have gotten to this code.
• Some information about the LAN interface using used is written to the host.info and config.sys
files.
Network startup - Part 2

This section is discussed separately to the first section since this code is also used later in a network or
recovery session to start the network after the reboot into the final kernel.
• Networking is now started, this is done by performing the following actions:
• The network is checked to see if it’s already up or not (if it is nothing is done). The network is
defined to be up by defining an environment variable.
• Check to see if a hostname exists for the system (it must have one), it is possible that if an IP
address was gained via DHCP that no hostname was given as part of the DHCP response.
• If we still have no hostname or IP address (you cannot get into this situation during an interactive
install or recovery session) the installation or recovery session will fail at this point.
• The following message is printed:
NOTE: Bringing up Network (<lanx>)
• The value of _hp_lanadmin_args is checked to see if there have been any special options set for
the LAN interface. If there are the following actions are performed:
1. If the lanscan command exists it is run and the output parsed to determine the PPA of
the LAN interface.
2. lanadmin is run to set the interface up according to the contents of
_hp_lanadmin_args.
• The command “ifconfig <lanx> inet <IP address> up” is run to bring the interface up with the
assigned IP address (the netmask, if present, is added into the command as well).
• If there was a default route defined by the configuration (including information gained via DHCP
or on the Networking Configuration screen) it is added now using the route command (“route add
default <IP Address> <Gateway IP Address>”).
• The environment variable that defines the network to now be up is set.
If starting the network failed we go back to the start (see “Start Networking”).

• The DHCP daemon is now started to defend the DHCP lease.
Back to /sbin/launch
• After net_cfg_prep is complete a large number of the programs and files no longer required in the
install filesystem are removed. This action is not takem when net_cfg_prep indicated that it
aborted, a reboot was requested, or when a halt was requested.
• We read in and put the environment variables set by net_cfg_prep into the current environment.
• The log file is opened again.
• Check to see if the client directory can still be read (set during net_cfg_prep since when using
networking to perform an install the client directory will now be located on an Ignite server)
The exit values from net_cfg_prep cause different actions to occur. The exit values cause the following
actions:
Table 30 - net_cfg_prep exit values and actions

Exit Value Action
-1 See the action for exit value 1
0 Not used by net_cfg_prep
1 Sets the client status file to indicate an error a reboots the system
2 Causes itool to be started in wizard mode
3 Causes itool to be started in expert mode
4 Causes itool be be bypassed (non-interactive mode)
5 Start the recovery shell
6 Causes a reboot to occur
7 Causes the system to halt (no reboot)
8 Not used by net_cfg_prep
• If itool needs to be run the itool program 144 is loaded along with any files it requires to run (if the
option to start a recovery shell was chosen from itool go to the bottom of this section).
• The itool program is run. Note that the exit values used match those from net_cfg_prep, there are
some differences because the two programs do not return all of the same exit values.
Table 31 – itool exit values and actions

Exit Value Action
-1 Not used by itool
0 Continue
1 Sets the client status file to indicate an error a reboots the system
2 Causes itool to be restarted in wizard mode
3 Causes itool to be restarted in expert mode
4 Not used by itool
5 Not used by itool
6 Causes a reboot to occur
7 Causes the system to halt (no reboot)
8 Causes the hardware to be rescanned and itool to be restarted
All others The user is prompted to ask if they wish to push a shell or not. This includes the values not
used by itool.
144
This program presents the wizard and advanced user interfaces to the user. This allows anyone to change
the configuration via the user interface.

• The /sbin/configure1 program is run to start the install or recovery session, however if the option
to start a recovery shell was chosen the recovery shell (not covered in this course) is started (this
causes the entire RECCMDS or RECCMDSIA command archive be extracted as part of the
process of starting a recovery shell). Please note that there is no way to return back to
net_cfg_prep.
• If net_cfg_prep returned an unknown value an error is placed into the client status file and the
system is rebooted (this should never happen).
Running itool
This course does not cover the itool program or what it does. We will however take a brief look at how to
run it on a running system how that can be used to quickly debug configurations. This is especially useful
when writing custom configurations.
To run itool interactively you need a per-client directory. In this case well use the one for this system (a
HPVM guest):
# pwd
/var/opt/ignite/clients/vm001
# ll
total 720
-rw-r--r-- 1 bin sys 6 Nov 19 11:46 client_name
-rw-r--r-- 1 bin sys 462 Nov 19 13:23 client_status
-rw-r--r-- 1 bin bin 8799 Feb 20 09:45 config
-rw-r--r-- 1 bin bin 8799 Feb 20 09:45 config.bak
-rw-r--r-- 1 bin bin 72492 Nov 19 12:45 config.full
-rw-r--r-- 1 bin bin 674 Nov 19 11:46 config.sys
-rw-r--r-- 1 bin sys 224 Nov 19 11:46 env.vars
-rw-r--r-- 1 bin bin 729 Nov 19 11:46 host.info
-rw-r--r-- 1 bin bin 595 Nov 19 11:46 hw.info
-rw-r--r-- 1 bin bin 166892 Nov 19 13:23 install.log
-rw-r--r-- 1 bin bin 3076 Nov 19 11:46 io.info
drwxr-xr-x 2 bin bin 8192 Nov 19 13:22 manifest
-rw-r--r-- 1 bin bin 45 Apr 19 00:20 server.state
-rw-r--r-- 1 bin bin 8799 Feb 20 09:45 tmp.cfg
We can run itool as follows:
# itool –d . –m push
The itool program requires that you give the location of the per-client directory with the –d option (in this
case “.” because it’s the current working directory. You should always use the option “–m push” when
running itool on a live system. Using “-m pull” can cause the system clock to be changed 145. The “-m push”
option is used by Ignite-UX when running itool on an Ignite server when you choose to control the session
from a server (running the graphical user interface remotely). The screen that comes up looks like:
145
When visiting the system tab if “-m push” is not used the system clock can be changed. When “-m
push” is used during an actual install or recovery that is controlled from the Ignite server changing the time
in itool causes the time change to be written to the server.instr file in the per-client directory so the client
when reading the file knows what time to set. Using “-m push” interactively like this will not cause the
time to be changed on the Ignite client system.

This is the itool that everone has become familiar with. If we choose to retain the settings we can see itool
as it was during the last system install:
You can make changes freely in itool, however you should not use a per-client directory that is actively in
use by a client system 146. The changes are reflected in the per-client config file. This also makes it possible
to test problems reported about itool outside of the install environment.
146
You can take a copy of a per-client directory and place it anywhere and use itool on it.

Once your changes are complete there is another command you can use to print information about how the
final system would look – instl_dbg. As an example if we change the size of the root filesystem to be
1500MiB instead of 1024MiB:
You can however make changes on other screens. And choose go we will go to the confirmation screen:
Pressing “Go!” again returns us back to the command line. Out of interest we can see that when getting
back to the command line that pressing “Go!” returns an exit value of 0 telling /sbin/launch to continue (see
“Back to /sbin/launch”):

# print $?
0
Now staying in the same directory we can run instl_dbg to print out the expect layout of the filesystems
Ignite-UX would create:
# instl_dbg -D . -d
======= Disk and Volume allocation ======
Mount Size Usage Disk / impact amount
Directory (Mb) Group (MB / %) shy (Kb)
----------------------------------------------------------------------
/stand 1792 VxFS vg00 800 44% 0
(swap_dump) 2048 SWAP_DUMP vg00 0 0% 0
/ 1500 VxFS vg00 295 19% 0
/tmp 512 VxFS vg00 0 0% 0
/home 104 VxFS vg00 0 0% 0
/opt 7164 VxFS vg00 5372 74% 0
/usr 4056 VxFS vg00 3040 74% 0
/var 1916 VxFS vg00 542 28% 0
----------------------------------------------------------------------
Size unallocated from group: vg00: 0Mb
* Expected physical allocation of volumes on disks:
* 0/0/0/0.0x1.0x0 (/dev/disk/disk4) (vg00)
* 7168 - 1842176 KB /stand
* 1842176 - 3939328 KB primary
* 3939328 - 5475328 KB /
* 5475328 - 5999616 KB /tmp
* 5999616 - 6106112 KB /home
* 6106112 - 13442048 KB /opt
* 13442048 - 17595392 KB /usr
* 17595392 - 19557376 KB /var
* 0 KB unallocated
In this case instl_dbg need to be told where the per-client directory is with the –D option and the –d option
asks for the disk and volume allocation information to be printed.
The instl_dbg command can also perform other tasks such as:
1. Run sanity checks on the parsed configuration

2. Allow you to define variables or make software selections from the command line to see how it
impacts the configuration.
3. Write out a fully parsed configuration (using the –f option)
4. Quickly investigtate and find mistakes in your custom configuration.
Complete lab Sixteen (see “Lab exercise 16 – cold install and recovery (part 1)”).
Running configure1
At this point we’re at the start of the process that performs the recovery or installation process.
• Logging is initialized (including support for debug level logging) and the log file is opened.
• Allocate and setup the configuration that will describe how the system needs to be installed or
recovered.
• Set umask so files that are created aren’t world writable (can be changed via the variable
_hp_umask) and set the gid of the process to be “sys” (i.e. gid 3) to match the gid that root would
have on a normal system after a normal login.

• On 11.31 the listener is asked to restore the I/O configuration from the configuration describing
the install or recovery. Note that io_info data is only created by Ignite-UX for recovery archives so
this is only likely to happen during a recovery 147. If changes are made the system is inventoried
again. The following message is printed when this happens:
* Mapping LUN Instance Data
• Any devices that require renaming after the instance changes are made are renamed now.
• The HP-UX release identifier from uname(2) is retrieved and checked against the release keyword
defined by the configuration being installed 148. If the release keyword was not defined for the
configuration you will see the following warning:
WARNING: No OS release set via the "release" keyword. Will assume "<ikern>".
Where <ikern> is the HP-UX release of the install kernel. At this point the following message is
also printed:
* Setting the release to <ikern>.
• A directory to hold temporary files and a directory where the disk filesystems will end up being
mounted are created. The directory where the disk filesystems will be mounted is always at
/d_cfg_mnt_sb61. The filesystem structure that is always used by Ignite-UX during an installation
or recovery looks like:
At this point the installation or recovery process is at the “After boot” stage, and the “Phase 1”
stage will be reached soon.
147
The remapping requests are printed in debug mode.
148
At this point it is unlikely that we would be attempting to install a HP-UX using the wrong kernel
version as in itool you can’t see cfg clauses that defined configurations intended for a different release of
HP-UX other than the install kernel. This was different in older releases of HP-UX when the HP-UX 11.11
kernel was used to install HP-UX 11.00.

• The file that will contain the environment variables needed for Phase 3 of the install or recovery
process is constructed and those environment variables are placed into the environment of the
current process.
• Server halt instruction checks are enabled (this is only applicable to an install or recovery session
that is using an Ignite server). Server halt instruction checks are done every 10 seconds from this
point (using the alarm system call):
1. The server.instr file from the per-client directory is opened and the contents read.
2. If the contents read “halt_client” we release our DHCP lease, remove the server.instr file,
and halt the system.
3. If the contents read “reboot_client” we release our DHCP lease, remove the server.instr
file, and reboot the system.
This is how the “ignite” command on the Ignite server can control the client and get it to reboot or
halt when choosing the following menu option for an active client on the Ignite server:
Then in the dialog that comes up you have the choice of rebooting or halting the client:

Instruction checks are only used with an Ignite server. It does not make any sense to use them with
a media based install.
• We check to make sure that SYSCMDS exists. If it doesn’t exist the installation or recovery
session will be aborted since we cannot continue. At this point no disks have been modified yet so
aborting now is much better than modifying some disks and then finding that SYSCMDS doesn’t
exist and then aborting.
Running configure1 – disk setup
This part of Phase 1 marks the start of the disk configuration.
• Any empty volumes are dropped from the configuration. Ignite-UX won’t create volumes with
size less than or equal to 0.
• Dump volumes are checked to ensure that they are setup correctly (this step is not performed for
whole disk configurations). For LVM dump volumes they are checked to ensure that they have
bad block relocation turned off. If any need to be modified to do this the following message is
printed:
NOTE: Logical volume used for dump will be changed to not use bad
block relocation. Bad block relocation is never allowed for
LVM dump volumes.
If LVM is being used and there were no dump volumes found then all of the contiguous swap
spaces in the root volume group are set to be swap and dump spaces (bad block relocation is
turned off on these volumes). No messages are displayed to indicate what swap spaces may be
changed to swap and dump. However if bad block relocation is turned off on any swap space for it
to become a dump space the following message is printed:
NOTE: Logical volume used for swap and dump will be changed to not
use bad block relocation. Bad block relocation is never allowed

for LVM dump volumes.
• All of the disks that will be used by Ignite-UX create LVM volume groups or VxVM disk groups
will have the start of the disk overwritten so they no longer appear as LVM or VxVM disks.
Important: If clean_all_disks is set to true 149 in the configuration then all disks visible to the
system will be overwritten in this way.
• On HP Integrity servers the root disk is partitioned. The sizes are set according to the values of
_hp_efi_partition_size and _hp_service_partition_size. The HPUX partition is given the rest of the
space available on the disk.
There have been changes to the way this works on HP-UX 11i v3. Previously the size requested
for _hp_efi_partition_size and _hp_service_partition_size were fully realized by the idisk 150
command. The behaviour of idisk on 11i v3 has been changed so that the HPUX partition always
starts on an even MiB boundary, this involves taking back some space from EFI partition (the
HPSP partition is not changed). This leaves the EFI partition with slightly less space (less than
1MiB). The reason this was done on 11i v3 is for performance on disk arrays.
Note the following defect fixed in Ignite-UX version C.7.5:
QXCR1000714063. The save_config command will now account for the

lost disk space consumed by idisk on 11.31 IPF installs, such that
the _hp_efi_partition_size is not fully realized. Thus repetitive
recoveries do not end up with the EFI partition size shrinking
through each iteration of the cycle. It will remain as stated (for
example the default 500MB).
Because of the changes (which Ignite-UX was unaware of) the EFI partition started shrinking
1MiB at a time after every recovery that was made on 11.31 system. The defect fix changed the
behaviour so the correct size was retained.
• Next the VxVM disk groups are created. All of the commands required to enable VxVM are
loaded and the VxVM listener started 151. The listener is told all of the information it needs to
create the VxVM disk groups and volumes and then is told to create them. Note that if there are no
VxVM disk groups to be created none of the files required to support VxVM are loaded and the
VxVM listener is not started.
• LVM volume groups are now created. All of the required LVM commands are now loaded. The
disks that will be part of LVM volume groups are pvcreated and then the volume groups created.
Logical volumes are creating using lvcreate and extended to their expected size using lvextend.
The commands used are than cleaned up.
The root volume group is created carefully by using pvcreate –B on the boot disk (and then any
alternate links to the boot disk are skipped to prevent accidental overwriting of information on the
device). This is especially important for boot devices on HP Integrity servers as there has been a
defect in the past where the partition information on the boot device was removed because
pvcreate –B was done on the whole full device of a partitioned disk (fixed in C.7.4):
149
It is extremely uncommon for anyone to use the clean_all_disks feature of Ignite-UX. Extreme care
should be taken with this feature as it really will remove the LVM/VxVM information from EVERY disk
the system can access.
150
This is the command that actually performs the partitioning.
151
The VxVM listener is provided by Symantec and the functionality inside the VxVM listener will not be
discussed as it is 3rd party software.

* JAGaf22673 fix. Installs will no longer see pvcreate failures similar to this:
pvcreate: Couldn't open physical volume "/dev/rdsk/c5t1d1s2": I/O error

ERROR: Command "/sbin/pvcreate -f -B /dev/rdsk/c5t1d1s2" failed.
• All of the filesystems are now created in two passes. The first pass creates HFS filesystems and
the second pass creates VxFS filesystems via the VxFS listener. For VxFS filesystems Ignite
passes the attributes and other information about the filesystems to the VxFS listener and it creates
them.
• The filesystems are mounted. Ignite-UX at this point does not use the mount commands to mount
the filesystems but uses the mount system call directly passing in the required arguments.
Filesystems are mounted according to their level, that is / first, filesystems mounted one directory
downwards, then two and so on until there are no more filesystems left to mount.
We saw this earlier, once the filesystems are mounted this is what they look like from the
perspective of the install environment:
At this point disk creation is almost finished. There are still some steps to complete but there’s a step that
needs to be done before we can do that.
Running configure1 – download mini-system
• At this point of the install or recovery process you always seen the following output:
* Download_mini-system: Begin
x ./sbin/fs/hfs/mkfs, 229376 bytes, 448 tape blocks

x ./sbin/fs/hfs/newfs, 147456 bytes, 288 tape blocks
x ./sbin/fs/vxfs/mkfs, 262144 bytes, 512 tape blocks
x ./sbin/fs/vxfs/newfs, 208896 bytes, 408 tape blocks
x ./sbin/mkfs symbolic link to /sbin/fs_wrapper
x ./sbin/newfs symbolic link to /sbin/fs_wrapper
x ./sbin/lib/mfsconfig.d/hfs, 1032 bytes, 3 tape blocks
...
x ./opt/ignite/share/man/man1m.Z/print_manifest.1m, 1948 bytes, 4 tape blocks
x ./opt/ignite/binpa/print_manifest, 40960 bytes, 80 tape blocks
x ./opt/ignite/bin symbolic link to /opt/ignite/binpa
x ./configure3, 479232 bytes, 936 tape blocks
x ./monitor_bpr, 24576 bytes, 48 tape blocks
* Download_mini-system: Complete
This is the extraction of the SYSCMDS (or SYSCMDSIA on HP Integrity systems) onto the disk
filesystem. Note that the paths in the SYSCMDS file (like all of the command archives supplied
with Ignite-UX) are path relative. This allows Ignite-UX to extract the files on an as needed basis

into the install filesystem (before the disk based filesystems are created and mounted) or into the
disk based filesystems.
• There is a clean up done of LVM and VxVM commands so they are removed from the disk
filesystems. They are no longer required at this point since the disk/volume groups and filesystems
have been created and activated/mounted.
Running configure1 – final preparation before loading software
There are a few steps left to complete before we can start loading any software.
• The install filesystem is mounted at /d_cfg_mnt_sb61/tmp/ign_configure/RAMFS. This allows the

contents of the install filesystem to still be visible later when the installation/recovery process has
chroot’ed into the disk based filesystems (the LOFS 152 mount command is located in the
INSTCMDS file, the LOFS mount command is removed after it has been run).
• The NFS mount/umount commands (and dependant libraries) are loaded. They are used in
preference to the commands that will be loaded from the archive.
• All of the software that will be installed is determined now and built up into a list of software that
will be installed from the same sw_source by load order. Bad software such as a sw_sel that does
not reference a valid sw_source is determined. A flag is set to indicate if there is an OS Core
archive defined at load order 0 – this controls the running of the next section (if it is present it is
loaded then).
• The scripts refered to by the configuration are loaded now. They are loaded under
/d_cfg_mnt_sb61/tmp/ign_configure/cfg_script. For a media based install/recoveries they are
loaded from the SCRIPTS 153 file, for network based install/recoveries the individual scripts are
loaded from the Ignite server via tftp. From the location that the scripts are installed to we can tell
that the scripts being refered to are not scripts that are present in the archive. The instl_adm(4)
manual page says:
The keywords that end in _script are used to reference files to be loaded from
the Ignite-UX server using the tftp(1) service and executed as a stand-alone
command.
To execute a script that was loaded as part of some software you would need to refer to the script
as a _cmd hook not a _script hook. That is called as one of post_load_cmd, post_config_cmd, or
final_cmd not pre_load_script, post_load_script, post_config_script, final_script. Note that you
could not use pre_load_cmd in this case as it would attempt to call something before the software
was loaded (this assumes it was defined as part of the sw_sel that referenced the software).
• All global pre_load cmd or script hooks (scripts first then cmds) are run now. Like for the
pre_config_cmd hook there are very few commands available at this point (only the contents of
the SYSCMDS file). Note the major difference with the pre_config_cmd hook – these hooks are
152
Loopback filesystem
153
Note earlier when make_tape_recovery was reviewed that the SCRIPTS file in the LIF was built
containing the os_arch_post_c and os_arch_post_l scripts as these two scripts are refered to by the
configuration.

run chrooted within /d_cfg_mnt_sb61 so only the on disk filesystems can be referenced (and the
install filesystem indirectly at /d_cfg_mnt_sb61/tmp/ign_configure/RAMFS)
• The mkboot command is run to make the boot disk bootable. The boot disks for HP9000 and HP
Integrity systems are setup differently. This is also involves one of:
1. Running lvlnboot appropriately for systems using an LVM root volume group
2. Communicating with the VxVM listener for systems that will be using VxVM for the
root disk group to tell the listener to make the disk group bootable.
3. Correctly making a whole disk system bootable.
* Enabling swap areas.
Depending on how the swap kernel tunables are set and the amount of swap defined by the
configuration there may be messages printed about the need to increase the size of
maxswapchunks and/or swchunk (the exact message varies depending on HP-UX release).
Although unlikely on modern systems it is possible if there is not enough swap 154 Ignite-UX may
enable some filesystem swap.
• The LVM configuration is backed up. The backup files are created in the disk filesystem
(/d_cfg_mnt_sb61/etc/lvmconf/<vgname>.conf), this prevents having to move then there at some
later point from the install filesystem.
• The VxFS commands that were loaded from SYSCMDS are removed. The filesystems have
already been created so there is no need to have them on the disk filesystems any more.
• The value of _hp_locale is determined based on the software selections. It is based upon the
setting of the locale keyword assocated with sw_sel clauses. If none is set then _hp_locale is not
set to any value. If one is set _hp_locale is set to that value. If there is more than one locale set
then _hp_locale is set to ASK_AT_FIRST_BOOT and not given any immediate value.
• We now write the install.vars file (/d_cfg_mnt_sb61/tmp/install.vars). This file contains a subset
of information about the install such as networking information, environment variables, and most
variables defined by the configuration. Access to this information from a script allows the script to
make decisions about what to do based on the settings chosen by the user during the installation or
recovery process.
Important: Great care should be taken sourcing this file into any script. You should only trust the
contents of this file during a cold install or recovery. Once a system has completed its installation
or recovery the contents of the file should never be trusted as it sits in a directory that allows
anyone to modify or replace the file (11.11 and below). The file is safe on 11.23 and above as long
as the sticky bit is maintained on the /tmp directory to prevent anyone else from removing or
moving the file. This also assumes that the permissions on the file don’t permit anyone to update
the contents of the file)
The following is an example install.vars file from a factory Ignited system. The serial number and
order number are not set by Ignite-UX – it only happens as part of the factory instant ignition
process:
# cat /tmp/install.vars
# This file contains some information used during the initial
154
You are unlikely to ever see this happening as you have to have less than 68MiB of swap defined before
Ignite-UX will attempt to setup filesystem swap for the installation or recovery process. Having less than
68MiB of swap defined is unlikely.

# installation of the system. Once the system is up, it is no

# longer needed and may be removed at any time.
TZ="SST-8"
TERM="hp"
AWTERM="console"
LINES="24"
COLUMNS="80"
INST_ENABLE_NETWORK="1"
#
# Variable assignments
#
_hp_ikernel_os_release="B.11.11"
_hp_boot_dev_path="0/0/0/1/0"
_hp_default_cur_lan_dev="0/0/0/1/0"
_hp_primary_path="0/0/0/2/0.6.0"
_hp_keyboard="Not_Applicable"
_iux_nfs_server="15.104.100.222"
_iux_remsh_source="root@15.104.100.222"
_hp_HFS_blksize=65536
_hp_HFS_fragsize=8192
_hp_VxFS_blksize=8192
_hp_FS_stripe_size=64K
_hp_disk_layout="Modified LVM Layout"
_hp_root_disk="0/0/0/2/0.6.0"
_hp_pri_swap=4194304K
_hp_min_swap=4194304K
_hp_sec_swap=0K
_hp_root_grp_striped="NO"
_hp_root_grp_disks=1
_hp_group_name="vg00"
_hp_locale="SET_NULL_LOCALE"
_hp_force_autoboot="NO"
_disable_dhcp="NO"
_hp_addnl_fs_free_pct=10
_hp_os_bitness="64"
_hp_patch_save_files="YES"
_hp_custom_sys="Current System Parameters"
serial_number="SGH45218CM Hard Partition (npar): 1"
order_number="906110954~001~0200"
RUN_UI=FALSE
RUN_SD=TRUE
SD_USE_UI=FALSE
CONTROL_FROM_SERVER=TRUE
HALT_WHEN_DONE=TRUE
USE_EXPERT_UI=FALSE
CLEAN_ALL_DISKS=TRUE
HIDE_BOOT_DISK=TRUE
ERROR_IF_BAD_SW=TRUE
RECOVERY_MODE=FALSE
DISABLE_DHCP=FALSE
ALLOW_DISK_REMAP=TRUE
release="B.11.11"
Running configure1 – loading software (OS Core archive)
At this point if there is a Core OS archive defined by the configuration it is loaded. Note that there can only
be one Core OS archive, it is the archive (if any) defined at load order 0. Very little is done in this section
if there is no Core OS archive.
• Setup for script handling assocated with the sw_source and sw_sel that define the Core OS archive.
Since at this point we haven’t chrooted the entire installation or recovery session we need to setup

an argument for the routine that calls the scripts so they get chrooted into the disk based
filesystems (/d_cfg_mnt_sb61).
• Any pre_load_script or pre_load_cmd hooks assocated with the sw_source and sw_sel of the Core
OS archive are executed now. As noted in the previous step they are run chrooted into
/d_cfg_mnt_sb61.
• A series of files required to achieve the execution of the Core OS archive extraction process are
saved side (this includes any shared libraries required by any binaries being saved). This step is
actually quite complex. The files required to install the system have been extracted to the disk
based filesystem mounted at /d_cfg_mnt_sb61.
The problem here is that the initial OS Core archive load is not executed within a chrooted
environment so any programs or shared libraries that are required need to be accessed from the
install filesystem. This requires some shuffling of files and shared libraries so they can be
executed.
The following example shows that efftectively happens to the ftp program so it can be called to
download an OS Core archive via ftp (On HP-UX B.11.31 the libraries are different on HP-UX
B.11.23). The code does not execute these commands but performs actions equivalent to this.
mv /d_cfg_mnt_sb61/usr/bin/ftp \
/d_cfg_mnt_sb61/usr/bin/%ftp
mv /d_cfg_mnt_sb61/usr/lib/hpux32/libkrb5.so.1 \
/d_cfg_mnt_sb61/usr/lib/hpux32/%libkrb5.so.1
mv /d_cfg_mnt_sb61/usr/lib/hpux32/libk5crypto.so.1 \
/d_cfg_mnt_sb61/usr/lib/hpux32/%libk5crypto.so.1
mv /d_cfg_mnt_sb61/usr/lib/hpux32/libcom_err.so.1 \
/d_cfg_mnt_sb61/usr/lib/hpux32/%libcom_err.so.1
ln -s /d_cfg_mnt_sb61/usr/bin/ftp \
/usr/bin/ftp
ln -s /d_cfg_mnt_sb61/usr/lib/hpux32/%libkrb5.so.1 \
/usr/lib/hpux32/libkrb5.so.1
ln -s /d_cfg_mnt_sb61/usr/lib/hpux32/%libk5crypto.so.1 \
/usr/lib/hpux32/libk5crypto.so.1
ln -s /d_cfg_mnt_sb61/usr/lib/hpux32/%libcom_err.so.1 \
/usr/lib/hpux32/libcom_err.so.1
The libraries and binaries are renamed to have a % in the name of the real file to ensure that they
do not interfere with an archive extraction. Ignite-UX removes or performs other actions (as
defined by Ignite-UX) later when the files are no longer required.
* Processing the archive source (<sw_sel>)
Where <sw_sel> is the description associated with the sw_sel and if there is no description it is the
name of the sw_sel. For example in the following excerpts of configuration “Recovery Archive”
would appear in the above message:
init sw_sel "golden image1" {

description = "Recovery Archive"
sw_source = "core archive"

sw_category = "HPUXEnvironments"

And in the following one “golden image1” would appear as there is no description in the sw_sel
definition:
init sw_sel "golden image1" {
sw_source = "core archive"

sw_category = "HPUXEnvironments"
• If the access method to the archive is NFS then the remote filesystem containing the archive is
mounted now at /d_cfg_mnt_sb61/tmp/ign_configure/archive_nfs (the mount point is created if
required).
• If the source is a CD/DVD it is mounted now at (it will attempt to mount the CD/DVD using both
HFS and the CDFS mount commands since CD/DVD media could have either filesystem type on
it. The mount point is /d_cfg_mnt_sb61/tmp/ign_configure/SD_CDROM. If change media is set to
true for the sw_sel note that the user will be prompted to change the media before continuing. It
would however be unusual to set change media to true for the first disk for media.
• If the media is tape normally no action is taken however if change media is set to true for the
sw_sel note that the user will be prompted to change the media before continuing.
• The sw_sel is now processed, some validation is done. Some examples of this is are:
1. Unless the archive is on tape an archive path must be defined.
2. The format type must be one of cpio, tar, or pax.
* Fri Sep 03 00:59:55 EDT 2008: Starting archive load of the source
(<sw_sel>).
See the definition of <sw_sel> being used in messages above.
• Next a temporary script (/d_cfg_mnt_sb61/tmp/ign_configure/tmp_archive_script) is built to

perform the archive extraction. The script depends on the access method to the archive:
1. The following line is always added to the script 155:
cd /d_cfg_mnt_sb61
2. For CD/DVD the following line is added:
/usr/bin/cat /d_cfg_mnt_sb61/tmp/ign_configure/SD_CDROM/<archive_path > |
3. For tape the following is only done when the archive was also compressed (archives on
tape are never compressed by make_tape_recovery when written to tape). The first line is
for when tar is used and the second when pax or cpio are used as the archive format:
/usr/bin/dd if=<device> ibs=10240 |

/usr/bin/dd if=<device> ibs=5120 |
The different block sizes are used as this reflects the default block sizes of tar (10240)
and pax/cpio (5120).
4. If the access method is remsh then the following line is written into the script:
155
Note that this is different to archive loads when the load order is not 0 as it will instead be “cd /” as
those archive extractions are run chrooted into /d_cfg_mnt_sb61.

/usr/bin/remsh <server> -l <user> ’cat <archive_path>’ |
5. If the source is NFS the following command is written into the temporary script file:
/usr/bin/cat /d_cfg_mnt_sb61/tmp/ign_configure/archive_nfs/<archive_path> |
6. If we get to this point and there is not source type defined the following error is printed:
ERROR: Archive (<sw_sel>) does not have a valid access method.
7. From here we need to add the monitor_bpr command into the pipeline we’re setting up in
the temporary script. The following is not done for archives on tape where the archive is
not compressed at all (using compress or gzip) go to step 10 if this is true.
8. If the archive is on CD/DVD or accessed via NFS (and the NFS source is given) then the
archive is stat’ed (using stat64(2)) to enable support for archives greater than or equal to
2GiB in size. If the archive is greater than or equal to 2GiB in size the size is converted to
KiB and the first command written to the temporary script file otherwise the second
command is written:
/monitor_bpr –s <size_in_KiB> |
/monitor_bpr –o <load_order> |
9. For other archives the command written is:
/monitor_bpr –o <load_order> |
10. For archives that have been compressed using gzip or compress the first command is
added for other archives the second command is written:
/usr/bin/gunzip –c |
cat |
11. The next command written is the pax command to perform the extraction of the archive.
The first command is for tape archives that have not been compressed using the compress
or gzip commands and the second is used in all other cases:
/sbin/pax_iux -r –f <tape_device> -p e
/sbin/pax_iux -r -p e
12. If the archive is on a tape the tape is repositioned to the file number defined by the
archive path (Ignite-UX sets this to 1 for recovery archives on HP9000 systems and 22 on
HP Integrity systems 156).
13. For ftp access to an archive we need to create a file that will be passed as the stdin to the
ftp command, the file is /d_cfg_mnt_sb61/tmp/ign_configure/ftp_stdin. The file contains
the following data:
user <user> <password>

bin
get <archive_path>
quit
156
That is the number of files to skip forward to be at the start of archive from the beginning of the tape.

This allows the ftp command to pass the archive to stdout so it can be processed as part of
the pipeline.
14. If this is a tape archive and the archive is not compressed using compress or gzip the
extraction progress isn’t shown by monitor_bpr instead the following message is printed:
* Archive extraction from tape is beginning. Please wait.
15. The command is now run 157 (remember that for ftp access to archives stdin comes from a
file for other access methods the command is run without any special stdin).
16. Upon successful archive extraction the following message is printed (see earlier in this
section for how the value of sw_sel is determined):
* Fri Sep 03 08:41:26 EDT 2008: Completed archive load of the source
(<sw_sel>).
• Using the above information we can easily determine that the temporary script written to extract
an archive from an NFS source where the archive is greater thank or equal to 2GiB in size and was
compressed using gzip should look like (the second line is continuous):
cd /d_cfg_mnt_sb61
/monitor_bpr –s <size_in_KiB> | /usr/bin/gunzip –c | /sbin/pax_iux -r -p e
• In this section we haven’t discussed how the following messages appear during archive extraction:
* Processed 10% of archive

* Completed 100% of archive
They are printed by the monitor_bpr command which is discussed in the next section.
• Find all of the iux_postload and iux_postconfigure scripts in the IPD 158.
• The last modification date for the swinstall.log file is saved (if the installation or recovery session
has not previously decided to run swconfig).
• Run any post_load_script or post_load_cmd command hooks defined for the sw_source or sw_sel.
• The last modified date on the swinstall.log file is retrieved again. If it has been modified then we
will run swconfig later (this information is saved into the environment and written into a file as we
will not be running swconfig until much later). If software will need to be configured later the the
environment variable ENV_SWAGENT_LOG_MODIFY is set to a value of 1 and saved for
phase 3.
157
In debug mode the script that will be executed and the settings for stdin (for ftp access mode) will be
printed.
158
In case you have never seen this term before it is short for Installed Products Database (see
/var/adm/sw/products on a running system). This refers to the files used by SD to manage installed software.

• Any files from /dev that were saved away before are moved into /dev and any files that were
moved aside earlier (see the discussion of the changes required to make ftp work earlier as an
example) are deleted or put back into place as appropriate. Subsequent archive loads will use the
commands loaded as part of the Core OS archive load.
Archive extraction – monitor_bpr

The function of the monitor_bpr command is simple it is to track the amount of data read and print a
progress message. The command accepts two options:
• -o which prints the amount of data read so far every so often (30 seconds for load order 0 159 and 5
seconds for other archives).
• -s which prints the progress of the data read compared to the size given.
Irrespective of which method is chosen the monitor_bpr command will copy the data from stdin to stdout
and count the amount of data copied.
When the –s option is used the output will look like:

When the –o option is used the output will look like:
* Processed 110312 Kbytes of archive

…
* Completed 2416580 Kbytes of archive
159
Load order 0 archives tend to be large compared to other archives so there is no need to print the size
read as often as for a small archive.

These messages are written to stderr and logged into the install.log file for the client they are not written to
stdout (they would appear mixed in with the archive if they were written to stdout).
Only one defect has ever been reported against monitor_bpr – JAGaf00892. The monitor_bpr command
didn’t keep track of read requests less than 1KiB in size. If the reading of the archive from the source was
relatively slow there could be lots of reads of less than 1KiB. This caused monitor_bpr to show sizes very
different to the archive size. This was fixed a long time ago (2004) given the frequency of defects reported
against this program it is not something you should expected to see problems with.
Complete lab Seventeen (see “Lab exercise 17 – cold install and recovery (part 2)”).
Running os_arch_post_l
This script runs after an archive has been loaded. Ignite-UX makes sure that it is run as part of a recovery
archive, for golden image installs the configuration file /opt/ignite/data/examples/core11.cfg (that should be
used as the basis of a configuration file that describes a golden image) also defines the os_arch_post_l
script (and the os_arch_post_c script):
# The following 2 scripts should be reviewed to see if the defined

# defaults are applicable. If you need to modify them, copy them
# to /var/opt/ignite/scripts first and change the paths here.
post_load_script = "/opt/ignite/data/scripts/os_arch_post_l"
post_config_script = "/opt/ignite/data/scripts/os_arch_post_c"
This raises one interesting issue. If you find yourself needing to change these scripts you should copy them
first and reference the changed scripts as if you modify the scripts in /opt/ignite/data/scripts they will be
overwritten every time you update Ignite-UX and changing those scripts affects all recoveries done from
the system.
When make_tape_recovery is only being used on a system it will impact only the tape recovery but if the
system is an Ignite server the scripts will be referenced (by default) in all recoveries and golden image
installs.
The script is fairly well self documented in the comments.
#!/usr/bin/ksh
#
# $Header: /svn/ignite/ignite/src/scripts/os_arch_post_l,v 10.61 2007/02/22
15:10:09 mbunner Exp $
#
##
## This file is the post_load script which runs when an OS
## archive has been loaded onto a system as part of the Ignite-UX process.
##
## This file may need to be customized to match the OS archive you will be
## using.
##
## WARNING: The version of this file in /opt/ignite/data/scripts will get
## overwritten the next time Ignite-UX is updated and any
## changes will be lost.
## o If you are making modifications for general OS archive installs:
## You should copy this file to /var/opt/ignite/data/scripts and
## modify that copy. You will then need to change any config files
## that reference this file to reference the modified copy.
## o If you are making modifications for inclusion in the SCRIPTS

## area of a make_recovery tape:

## You should copy the original version to a another name, make
## your modifications to /opt/ignite/data/scripts/os_arch_post_l,
## and document those changes so they can be recreated when
## Ignite-UX is updated and a new version is put in place.
##

You can see here that we reference some files that are discussed later. It's this script that takes copies of
certain files (to restore as is or merge with the Ignite configuration) since Ignite-UX is going to want to
replace them temporarily while the recovery or golden image install is happening.
ARCHIVE_SAVE_DIR="/tmp/ign_configure/os/archive_save"
ARCHIVE_SAVE_FILE="/tmp/ign_configure/os/archive_save/ig_save_file"
ARCHIVE_MERGE_DIR="/tmp/ign_configure/os/archive_merge"
ARCHIVE_MERGE_FILE="/tmp/ign_configure/os/archive_merge/ig_merge_file"
INSTALL_VARS_FILE=/tmp/install.vars
RECOVERY_MODE=FALSE
umask g-w,o-w
This function when used later saves copies of files and restores them later exactly as they appeared from
the archive. This is implied by the description below but not that clearly. This allows you to choose to
ignore whatever changes Ignite-UX might want to make and always put back the archive version.
Of course this has drawbacks if you later decide that you don't want this to happen. For a network recovery
it's possible to change the scripts the configuration refers to so they can implement the functionality you
want. However for a tape recovery it's not possible to change the scripts without pulling the tape apart and
rebuilding it.
Note the special processing for the netconf and nsswitch files they are handled separately near the very end
of a recovery or golden image installation session.
###############################################################################
#
# Function: save_file
#
# Purpose: Save a file that was delivered as part of the archive. This
# routine should be called when:
# - the file in question is one that Ignite-UX will
# directly manipulate
# - you want the version from the archive to end up on the
# system
#
# Also keep track of what files were saved so that they can be
# restored by restore_files() in os_arch_post_c (the post config
# script for the OS archive). In the case of netconf and
# nsswitch.conf, the files are saved as .final and put back
# into place at the very end by the IUX configuration code.
#
# Parms: $1 full pathname of the file to save
#
save_file()
{
source=$1
target="$ARCHIVE_SAVE_DIR$source"

if [[ ! -f $source ]]; then

if [ "$INST_DEBUG" -gt 0 ] ; then
echo "DEBUG: Could not save $source from archive: file not found"
fi
return
fi
#
# Handle a couple special cases, the configuration code in
# Ignite-UX will look for these files as ".final" at the end of
# the install and put them in place if they exist.
#
case $source in
/etc/rc.config.d/netconf)
cp -p /etc/rc.config.d/netconf /etc/rc.config.d/netconf.final
return
;;
/etc/nsswitch.conf)
mv /etc/nsswitch.conf /etc/nsswitch.final
return
;;
/etc/mnttab)
# On 11.31 /etc/mnttab is a symbolic link to /dev/mnttab.
# Cannot do a save_file on it.
if [[ "$(uname -r)" = "B.11.31" ]]; then
return
fi
esac
# In the normal case, copy the file to the $ARCHIVE_SAVE_DIR

# which will be examined by os_arch_post_c
ldir=`dirname $target`
mkdir -p $ldir
cp -pf $source $target
echo $source >> $ARCHIVE_SAVE_FILE
} # end of save_file()
The merge_file routine is used to save copies of files that Ignite-UX may modify (based on the
configuration being used) later in the installation or recovery session. Before the modifications happen
however Ignite-UX may temporarily replace some of these files (during a network session) to allow a
network based installation or recovery session to complete. The correct files will be put back in place late
in the recovery or installation process.
###############################################################################
#
# Function: merge_file
#
# Purpose: This routine is used on files that have content
# as they exist in the archive that you want to preserve
# however Ignite-UX also has the ability to modify these
# files based on what the user changes in the user-interface
# and/or the config file.
#
# Ignite-UX will directly read the list of files to be merged
# and will use them at the appropriate time. They are not
# restored in os_arch_post_c as are the save_file files.
#
# Parms: $1 full pathname of the file to merge
#
merge_file()
{

source=$1
target="$ARCHIVE_MERGE_DIR$source"
if [[ -f $source ]]; then

ldir=`dirname $target`
mkdir -p $ldir
echo $source >> $ARCHIVE_MERGE_FILE
else
if [ "$INST_DEBUG" -gt 0 ] ; then
echo "DEBUG: Could not merge $source from archive: file not
found"
fi
fi
} # end of merge_file()
Please note that there is one call to this function that is commented out when in recovery mode. There is no
need to uncomment the function call as despite the comments below the transition links will end up with
the correct permissions and there's not need to forcibly remove them using this function.
###############################################################################
#
# Function: remove_tlinks
#
# Purpose: This routine walks through the transition link table and
# removes all links found on the system. This is necessary when
# an archive contains the links because the extraction cmds
# do not handle the "t" bit. By removing them here and then
# allowing tlinstall to run, it makes it possible
# to use tlremove in the future.
#
# This routine does not need to be run if a tlremove was done on
# the system before the archive was produced.
#
remove_tlinks()
{
# The order is significant here since tl_ttdb typically contains entries

# for directories which have isu_tl_ttdb file entries.
TABLES="/opt/upgrade/lib/isu_tl_ttdb /opt/upgrade/lib/tl_ttdb"
for tab in $TABLES; do
if [[ -f $tab ]] ; then
awk -F: '{print $1}' ${tab} |
while read pathname ; do
if [[ -L ${pathname} ]] ; then
/usr/bin/rm -f ${pathname}
fi
done
fi
done
} # end of remove_tlinks()
There are a heap of devices that may not be appropriate to the system that have just been extracted from the
archive. This function removes them all from under /dev, Ignite-UX will recreate device files at various
times later before it needs the device files.
###############################################################################
#

# Function: remove_devs
#
# Purpose: This routine removes /dev files, that have been loaded from
# an OS archive, which will be remade by insf or by
# /sbin/init.d scripts. This is particularly important
# for core OS /dev files which use dynamic major numbers,
# since they must be recreated with the proper major
# number when loading on different hardware. Not all
# special files listed below use dynamic majors; some
# are removed because they could be inappropriate
# or not applicable to the hardware on the new system.
#
remove_devs()
{
# Remove disk/tape, audio, parallel, dlpi (lan), HIL, ps2,

# and serial HW tty special files. Leave pty's, since the
# number of pty's is configurable.
find /dev ! -type d \
-path "/dev/rmt/*" \
-o -path "/dev/rtape/*" \
-o -path "/dev/dsk/*" \
-o -path "/dev/disk/*" \
-o -path "/dev/rdsk/*" \
-o -path "/dev/rdisk/*" \
-o -path "/dev/floppy/*" \
-o -path "/dev/rfloppy/*" \
-o -path "/dev/audio*" \
-o -path "/dev/c*_lp" \
-o -path "/dev/dlpi*" \
-o -path "/dev/hil*" \
-o -path "/dev/rhil*" \
-o -path "/dev/ps2*" \
-o -path "/dev/tty[0-9]*" | xargs rm -f
# More specific files.

rm -f \
/dev/beep \
/dev/crt \
/dev/crt0 \
/dev/echo \
/dev/hub \
/dev/kepd \
/dev/klog \
/dev/mux0 \
/dev/mux1 \
/dev/ocrt \
/dev/ocrt0 \
/dev/ptmx \
/dev/root \
/dev/rroot \
/dev/sad \
/dev/strlog
# Directories and their contents.

rm -rf \
/dev/diag \
/dev/hid \
/dev/rscsi \
/dev/deviceFileSystem
}

As the usage statement says this script should never be called on a running system it will cause major issues.
For example it would remove /stand/vmunix, /etc/lvmtab, and a few other files along with a heap of device
files that will leave you with a somewhat damaged system.
###############################################################################
#
# MAIN
#
# Manipulate which of the actions take place by commenting or uncommenting
# the various routines below. For the parts you may want to change to
# match your needs below, you will normally be changing the non-recovery
# case.
# Check for usage request first, before doing anything dangerous:
if [ "x$1" = 'x-?' ]
then
print -u2 "\nUsage: $0 # ignores arguments.
\nWarning: This is an Ignite-UX internal tool that can be
destructive when run in the wrong context; see script comments.
\nThis file is the post_load script which runs when an OS
archive has been loaded onto a system as part of the Ignite-UX process.
This file may need to be customized to match the OS archive you will be
using.
"
exit 1
fi
The /tmp/install.vars file contain information about of this is recovery mode. If you look at iux_postload
and similar scripts under the SD-UX IPD you will see them doing something similar.
# Source the install.vars file so we know if this is recovery mode or not.

#
if [[ -f $INSTALL_VARS_FILE ]]; then
. $INSTALL_VARS_FILE
else
echo "Could not source $INSTALL_VARS_FILE: will assume recovery_mode is
false"
fi
For recovery mode we're being called during a recovery session to recover a recovery archive created by
make_net_recovery or make_tape_recovery. You should be extremely careful when uncommenting
anything that has been commented out or changing the way a file is saved by changing a merge_file to a
save_file function call. A save_file function call will cause a file to be saved away "as is" and put back as it
was saved even if Ignite-UX wanted to make changes to it.
#
# Handle the recovery mode case first. Note that recovery mode is only
# used went restoring a system created by make_recovery or make_net_recovery
#
# The files below that are operated on by "merge_file", are files
# that Ignite-UX is allowed to modify based on the information in the
# config file or from the UI. If you do not want to have IUX touch
# these files at all, you can change the merge_file to a save_file.
# However, if you make this change, any changes to their content via
# the user interface will be ignored.
#
# For example if "merge_file /etc/rc.config.d/netconf" is changed to
# a "save_file", then that file will always be preserved. And any
# changes to the hostname and IP address in the user-interface will
# not be made to the file.

#
if [[ "$RECOVERY_MODE" = "TRUE" ]]; then
echo " * Running in recovery mode (os_arch_post_l)."
merge_file /etc/hosts
merge_file /etc/resolv.conf
merge_file /etc/rc.config.d/namesvrs
merge_file /etc/rc.config.d/netconf
merge_file /etc/rc.config.d/netdaemons
merge_file /etc/ntp.conf
merge_file /etc/fstab
# 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.
# JAGag43004 fix. Move call to remove_devs outside this if clause
# so it happens regardless (in recovery, cloning or not).
remove_devs
if [[ "$_HP_CLONING" = "TRUE" ]] ; then
rm -f /stand/vmunix
fi
# The ioconfig files are handled by hw_instance_num config file

# keyword, however IUX can only preserve instance numbers for
# drivers that are in the INSTALL kernel. If this is a problem,
# then you can uncomment the next two lines. However doing this
# can cause some problems when cloning to different hardware.
# save_file /etc/ioconfig
# save_file /stand/ioconfig
# save_file /etc/eisa/config.log
# save_file /etc/eisa/config.err
save_file /etc/eisa/system.sci
merge_file /var/adm/sw/security/_ACL
merge_file /var/adm/sw/security/_OWNER
merge_file /var/adm/sw/security/_PROD_DFLT_ACL
merge_file /var/adm/sw/security/_SOC_DFLT_ACL
save_file /var/adm/sw/security/secrets
save_file /var/adm/sw/defaults
save_file /var/opt/ignite/local/manifest/manifest
save_file /var/opt/ignite/local/manifest/manifest.info
save_file /var/opt/ignite/local/manifest/manifest.oinfo
save_file /var/opt/ignite/local/manifest/manifest.orig
save_file /var/opt/ignite/local/manifest/manifest.seed
save_file /var/opt/ignite/local/manifest/template.def
save_file /opt/ignite/bin/print_manifest
save_file /opt/ignite/share/man/man1m.Z/print_manifest.1m
save_file /etc/kbdlang
save_file /etc/nsswitch.conf
rm -f /stand/bootconf
rm -f /etc/dhcpclient.data
#rm -rf /var/adm/crash/*
# remove_tlinks
# save_file /opt/upgrade/bin/tlinstall
# rm -f /opt/upgrade/bin/tlinstall
# remove the /var/tmp/ign_configure/make_sys_image_flag* if it is left

# on the system by any reasons
if [[ -f /var/tmp/ign_configure/make_sys_image_flag* ]];then
rm -f /var/tmp/ign_configure/make_sys_image_flag*
fi

# JAGag30466: remove /etc/vx/disk.info if it exists. VxVM will re-create it

# with the correct disk specific information for the system.
if [[ -f /etc/vx/disk.info ]];then
rm -f /etc/vx/disk.info
fi
return 0
fi
The rest of the script is executed when not in recovery mode (golden image installs) and is self documented
enough that it does not need any additional explanation.
# JAGag30466: remove /etc/vx/disk.info if it exists. VxVM will re-create it

# with the correct disk specific information for the system.
if [[ -f /etc/vx/disk.info ]];then
rm -f /etc/vx/disk.info
fi
#
# Networking files:
# /etc/hosts
# /etc/resolv.conf
# /etc/rc.config.d/namesvrs
# By default, these files will be constructed from the information
# in the config file. The starting point for the hosts file is the
# /usr/newconfig version, which just has a loopback entry. The other
files
# are built from scratch. To get the archive versions of these files,
# uncomment only the save_file lines here and comment out the rm line.
# Using save_file will restore the file as-is from the archive. Using
# merge_file will allow Ignite-UX to make changes to the file based
# on what the config file or changes made in the UI.
#
#save_file /etc/hosts
#merge_file /etc/hosts
rm -f /etc/resolv.conf
#save_file /etc/resolv.conf
#merge_file /etc/resolv.conf
#save_file /etc/rc.config.d/namesvrs
#merge_file /etc/rc.config.d/namesvrs
#
# Netconf Networking file:
# /etc/rc.config.d/netconf
# By default, this file will be constructed from the information
# in the config file. The starting point for the file is the
# netconf file in the archive (which is normally a newconfig version).
# To get the archive versions of this file, without any modification
# from information supplied in the Ignite-UX config files, uncomment
# the line below.
#
#save_file /etc/rc.config.d/netconf
#
# Disk layout files:
# /etc/fstab
# If you want the fstab file restored from the archive without
# any modifications, then uncomment the save_file line. However
# it is not recommended if you ever plan to make filesystem
# modifications during the Ignite-UX session.

# If you want the fstab file from the archive merged with the
# fstab file that Ignite-UX creates, then uncomment the line that
# does a merge_file on /etc/fstab.
# /etc/mnttab
# /etc/lvmtab
# /var/adm/sbtab
# By default, these files will be constructed from the information
# in the config file. To get the archive versions of these files,
# uncomment the save_file()s here (and comment out the remove of lvmtab).
#
#merge_file /etc/fstab
#save_file /etc/fstab
#save_file /etc/mnttab
rm -f /etc/lvmtab
#save_file /etc/lvmtab
#save_file /var/adm/sbtab
#
# Kernel files:
# /stand/vmunix
# By default, this file is re-generated based on a concatenation
# of:
# - the /stand/system file in the archive
# - the results of running the create_sysfile program (builds a list
of
# drivers needed to match the hardware found on the target system).

# - additions to the kernel via the mod_kernel attribute or changes
# made via SD control scripts
# To get this behavior, the kernel must not be in the archive or must
# be removed here. If you do not want a new kernel built, include a
# kernel in the archive and comment out the remove here.
# /stand/system
# This file should always exist in the archive. If the kernel itself is
# not in the archive, this file will be one of the building blocks
# for the kernel to generate (as described above). This file should
# include directives for everything needed except what create_sysfile
# will generate based on the hardware of the target machine.
# /stand/bootconf
# This file describes where the boot device can be found and how it
# is laid out. By default, the file will be generated to match the disks
# that were produced. This will happen when the file is not in the
archive
# or when it is removed here. If the file is in the archive and is not

# removed here, it will be used regardless of its contents.
#
if [ -x /stand/vmunix ] ; then
# The kernel is not removed if it is not executable, this is a
# behavior relied on by a workaround that makes it appear that
# "diag0" is loading in the kernel. (A workaround for the
# HPAutoRAID product) A non-executable /stand/vmunix is created in
# this case by a pre_load_cmd which is removed later by a
# post_load_cmd.
rm -f /stand/vmunix
fi
rm -f /stand/bootconf
#
# Device files and friends:

# /dev/rmt,dsk,fdsk,floppy,rfloppy, etc.
# By default, most device files in the archive are removed here.
# The insf -e command will be run to create device files for all
# hardware which is present on the system. In most cases, the
# archives should contain a minimum set of device files to let
# the correct device files be generated by insf. Of course, some
# device files are not generated by insf, but are for optional
# drivers. These can be created via add_devfile() in
# os_arch_post_c or just left in the archive (but if they use
# dynamic major numbers, leaving them in the archive is
# dangerous). If certain device files from the archive really are
# needed and they are being removed in the remove_devs function,
# that function must be changed.
# /etc/ioconfig
# /stand/ioconfig
# These files will be re-built with an ioinit -c. If you wish to
# keep the archive versions, you must save them here. However,
# you should consider using the hw_instance_num config file
# keyword instead.
# /etc/lvmconf/*.conf
# Any LVM configuration files in the archive will be overwritten.
# No change to this behavior is possible.
#
remove_devs
#
#save_file /etc/ioconfig
#save_file /stand/ioconfig
#
#
# EISA configuration files
# /etc/eisa/config.log
# /etc/eisa/config.err
# /etc/eisa/system.sci
# By default, any of these files which are put down as part of the
archive
# will be overwritten. If you wish to end up with the archive version

# of any of these files, uncomment the save_file()s here.
#
#save_file /etc/eisa/config.log
#save_file /etc/eisa/config.err
#save_file /etc/eisa/system.sci
#
# SD security files and defaults file
# /var/adm/sw/security/*
# These files are re-initialized after the archive is loaded. If you wish
# the archive versions to end up on the disk, save them here and restore
# them in os_arch_post_c. You may consider using merge_file instead
# of save_file if you want to allow IUX to modify the local hostname.
# /var/adm/sw/defaults
# This file is re-initialized after the archive is loaded. The file will
# be saved from the archive here and restored in os_arch_post_c. If you
# do not want this behavior, comment the steps out. In that case, the
# newconfig version of the defaults file will be installed (if it was
# in your archive).
#
#save_file /var/adm/sw/security/_ACL # or mere_file
#save_file /var/adm/sw/security/_OWNER # or mere_file
#save_file /var/adm/sw/security/_PROD_DFLT_ACL # or mere_file

#save_file /var/adm/sw/security/_SOC_DFLT_ACL # or mere_file

#save_file /var/adm/sw/security/secrets
#save_file /var/adm/sw/defaults
#
# Manifest files
# /var/opt/ignite/local/manifest/*
# Ignite-UX will always try to create a new manifest. If you want your
# existing manifest files to end up on the target system, you should
# uncomment the save_files here. The files will then be restored by
# os_arch_post_c - overwriting the changes made by Ignite-UX.
# /opt/ignite/bin/print_manifest
# /opt/ignite/share/man/man1m.Z/print_manifest.1m
# These files are saved by default if they exist. Ignite-UX will
# supply versions if they are not already installed.
#
#save_file /var/opt/ignite/local/manifest/manifest
#save_file /var/opt/ignite/local/manifest/manifest.info
#save_file /var/opt/ignite/local/manifest/manifest.oinfo
#save_file /var/opt/ignite/local/manifest/manifest.orig
#save_file /var/opt/ignite/local/manifest/manifest.seed
#save_file /var/opt/ignite/local/manifest/template.def
save_file /opt/ignite/bin/print_manifest
save_file /opt/ignite/share/man/man1m.Z/print_manifest.1m
#
# Install vars file
# /tmp/install.vars
# This file is used to tell the set_parms program what the defaults
# are for networking parameters, etc. If this file is in the archive,
# it will be overwritten by Ignite-UX. You should not need to save
# your own version and later restore it, but if you do, this is the
# place.
#
#save_file /tmp/install.vars
# Keyboard language file

# /etc/kbdlang
# If this file is in the archive, it will be overwritten. If you want
# the archive version to end up on the system, save it here and restore
it
# in os_arch_post_c.
#
#save_file /etc/kbdlang
#
# DHCP client data file
# /etc/dhcpclient.data
# If this file is in the archive, it will be overwritten. There is no
# way to get the archive version onto the end system. Do *not* remove
# this remove statement.
#
rm -f /etc/dhcpclient.data
#
# savecore crash dump files
# /var/adm/crash/*

# The files in this directory are as a result of a system crash. By

# default, they are removed.
#
rm -rf /var/adm/crash/*
#
# /etc/nsswitch.conf file
# If you want this file to be put in place from the archive, uncomment
# the following line. By default, the file will be overwritten during
# the install and then removed at the end of the installation.
#
# save_file /etc/nsswitch.conf
#
# Transition Links
# /opt/upgrade/bin/tlinstall
# Most archives do not have any transition links. Ignite-UX will do
# a tlinstall after the archive has been loaded. If you wish to skip
# the tlinstall, remove the cmd here and save it for later if you want it
# on your target system. Some SD control scripts rely on transition
# links being in place, so it is wise to either allow Ignite-UX to
# create them or to ensure that they are in your archive.
#
# If an archive was created without removing transition links, the links
# are in the archive, but as symlinks. In that case, you will need to
# remove the links restored from the archive and then let Ignite-UX
# re-create them by running tlinstall. We remove tlinks here by default.
#
remove_tlinks
#save_file /opt/upgrade/bin/tlinstall
#rm -f /opt/upgrade/bin/tlinstall
# Add fiber channel drivers when needed. /dev/config is needed for

# the ioscan below to work. However it produces output complaining
# about the lack of /etc/ioconfig (so /dev/null it)
if [[ "$(uname -r)" = "B.11.11" ]]; then
insf -e -d dev_config > /dev/null 2>&1
if ioscan -fk |grep -q "^fcp " ; then

grep -q "^fcT1_fcp$" /stand/system
if [[ $? -ne 0 ]] then
echo "fcT1_fcp" >> /stand/system
fi
fi
fi
#
# Exit cleanly.
#
return 0
Running configure1 – after the initial archive load
• If there is networking information available (i.e. we’re installing from a network source) we write
an entry into the /etc/hosts file (in the disk filesystem) to represent the current interface and then
an /etc/resolv.conf is created (this assumes that DNS information is defined by the configuration
or DNS information was picked up via DHCP earlier).

• Some files are relocated (some are copied and some are moved) from the install filesystem to the
disk filesystem:
1. /etc/sbtab (if an archive restored an /etc/sbtab file it is moved to /etc/sbtab.old)
2. /envs.cfg.p3 (The temporary environment file – contains environment variables for phase
3).
3. On HP9000 systems the EISA configuration files are moved to the disk filesystem (if
they exist).
4. If any LVM volume groups were created /etc/lvmtab and /etc/lvmpvg are relocated along
with the device files assocated with any LVM volume groups created by Ignite-UX (any
device files for those volume groups recovered from the Core OS archive are removed
first, if they exist).
5. If any VxVM disk groups were created the files required by VxVM are relocated.
6. /etc/kbdlang is created (if the configuration sets a keyboard language) otherwise if the file
exists in the install filesystem it is moved to the disk filesystem.
7. /etc/dhcpdb is relocated so auto_parms knows about any lease the system may currently
have.
8. Networking device files are relocated to the disk filesystem.
9. If /var/opt/ignite/local exists on the disk filesystem it is removed and is temporarily
replaced with a symlink to the directory currently used as the client directory (it will be
recreated properly near the end of the install or recovery session).
10. If we’re not using an NFS based client directory then all of the files in the current client
directory in the install filesystem are copied (recursively so any directories and their
contents are also copied) to the disk based client directory (/var/opt/ignite/local).
Running configure1 – the chroot (NFS client directory)
If we have an NFS client directory we need to do some special processing as we will need to umount the
NFS client directory and mount it again. Since the NFS client directory is mounted off the install filesystem
not the disk based filesystem if the chroot was to be done now we would loose access to the client directory.
• We stop checking for server instructions (i.e. directions to halt or reboot)
• A temporary log file is opened instead of install.log (since the log file is in the NFS client
directory we cannot umount the filesystem if we have the log file open).
Note that this raises the interesting issue – a failure at this point will not be logged into the
client log file (on the NFS client directory) will only appear on the console until the NFS
filesystem is remounted and the log file reopened. This is a similar issue to one looked at
previously when the install.log file was relocated to the NFS client directory.
• The NFS client directory is unmounted.
• Under some circumstances on HP-UX 11.23 the second RAM filesystem /RAMFS2 may be
released to allow more free memory for the rest of the installation process.
• The chroot is done into the directory /d_cfg_mnt_sb61. From this point the system will behave as
though it was running from the disk filesystem instead of the install filesystem. Programs called
now will be from the disk filesystem. Remember that SYSCMDS was extracted into the disk
filesystems. All of the commands from that commands archive are now present and can be used.
There will be all (or most of) the operating system present if a Core OS archive has already been
loaded.
Important: From this point the installation/recovery process has chrooted into the directory
/d_cfg_mnt_sb61. All actions here will be described as though they are seen from within the chrooted

environment. File and directory names will be given from that perspective and unless really important the
mount point of the disk based filesystem (/d_cfg_mnt_sb61) will not be mentioned.
• The /var/opt/ignite/clients directory from the Ignite server is mounted on the /var/opt/ignite/clients
directory.
• The temporary log file is appended to the install.log file in the client directory and the original
NFS based log file (install.log) opened again. The temporary log file in the install filesystem is
removed (it is accessed via the LOFS mount that mounted the install filesystem onto the disk
based filesystem).
• We start checking for server instructions again.
• A symlink called /d_cfg_mnt_sb61 that points to / is created in the root directory of the disk
filesystems. This is in case anything sees the mount points directly from the kernel so any access
to /d_cfg_mnt_sb61 will effectively point to / in the chrooted environment. Note that
/d_cfg_mnt_sb61 160 is removed before the symlink is created just in case here is a directory or file
of that name in the Core OS archive.
• The /etc/mnttab file is modified by Ignite-UX to fool any process that runs into thinking that the
current system is a real live system and not a chrooted environment mounted at /d_cfg_mnt_sb61.
The following steps are taken:
1. The syncer daemon is killed if it is running (since it can update /etc/mnttab). Note that this is
done on 11.31 although syncer does not update /etc/mnttab since it is a device file
(/etc/mnttab is a symlink to /dev/mnttab).
2. On 11.31 an undocumented ioctl call is made to set a false root directory for the mnttab
device file. This automatically removes the /d_cfg_mnt_sb61 from the leading mount points
when the mnttab device file is read.
3. On 11.23 and below the mnttab file is modified to remove any non-disk filesystems and the
leading /d_cfg_mnt_sb61 removed from the mount points to keep any commands that run
later on that use /etc/mnttab happy. The NFS mounted /var/opt/ignite/clients is not written
into the mnttab file.
4. On 11.23 and below the last modification date on the /etc/mnttab file is changed so no
commands will attempt to rewrite the mnttab file. An undocumented libc function is used to
get the correct time to set the last modification date to.
Running configure1 – the chroot (no NFS client directory)
• The log file is closed and then moved over to the same directory on the disk filesystem (should
end up in /var/opt/ignite/ignite/clients/<MAC> - since is not controlled from an Ignite server it
should however end up finally in /var/opt/ignite/local after the installation or recovery is complete).
• A symlink in the install filesystem pointing to the log file in the disk filesystem is created. This is
in case anything that was started before the chroot needs to write something into the log file.
• The chroot is done into the directory /d_cfg_mnt_sb61. From this point the system will behave as
though it was running from the disk filesystem instead of the install filesystem. Programs called
now will be from the disk filesystem. Remember that SYSCMDS was extracted into the disk
filesystems, all of the commands from that commands archive are now present and can be used
(there will be a complete operating system if a Core OS archive has already been loaded).
160
That is you recover a system and you want to use the directory /d_cfg_mnt_sb61 on a system Ignite-UX
will remove it – it is an uncommon name however never use this directory name for anything on a HP-UX
system.

• A symlink called /d_cfg_mnt_sb61 that points to / is created in the root directory of the disk
filesystems. This is in case anything sees the mount points directly from the kernel so any access
to /d_cfg_mnt_sb61 will effectively point to / in the rooted environment. Note that
/d_cfg_mnt_sb61 is removed before the symlink is created just in case here is a directory or file of
that name in the Core OS archive.
• The /etc/mnttab file is modified by Ignite-UX to fool any process that runs into thinking that the
current system is a real live system and not a chrooted environment mounted at /d_cfg_mnt_sb61.
The following steps are taken:
1. The syncer daemon is killed if it is running (since it can update /etc/mnttab). Note that this is
done on 11.31 although syncer does not update /etc/mnttab since it is a device file
(/etc/mnttab is a symlink to /dev/mnttab).
2. On 11.31 an undocumented ioctl call is made to set a false root directory for the mnttab
device file. This automatically removes the /d_cfg_mnt_sb61 from the leading mount points
when the mnttab device file is read.
3. On 11.23 and below the mnttab file is modified to remove any non-disk filesystems and the
leading /d_cfg_mnt_sb61 removed from the mount points to keep any commands that run
later on that use /etc/mnttab from seeing the install environment details.
Running configure 1 – post chroot
• On 11.31 Itanium systems a link is created so device files in the device filesystem (USB based
devices) can continue to be accessed. You can only have the device filesystem mounted once and
in one location. That location is still in the install filesystem.
• If an ioconfig file was restored from an archive it’s saved aside for later use when instance
renumbering needs to be done.
• The files /etc/ioconfig and /stand/ioconfig are removed. The following commands are then run to
provide a minimal I/O configuration setup "insf -e -d dev_config", “/sbin/ioinit –c”
• The next action is to fix up the major number in device files in /dev (does not change anything
under the /dev/vx directory since those devices are (re)created by VxVM). The reason for this is
that running on the install kernel dynamic major numbers can easily be different to what they were
on the live system.
A list of valid dynamic major numbers is determined (static major numbers will not need to be
changed) and the list is updated with the current major number and if a Core OS archive has been
loaded what it ends up needing to become (eventually). Devices that need their major number
changed are re-created with the new major number. The major numbers will be recovered later this
step is to ensure that the devices in /dev work on the install kernel. If there’s a device associated
with a driver that is not in the install kernel the device files will not be modified at this point (they
will be later in phase 3 where we are running on the real kernel for this system).
Note that this is not done during a SD based cold install as all of the major numbers allocated are
valid dynamic major numbers and do not need to be changed.
The function that does this work will be called again later (see “Running configure1 – building a
kernel”) if there is no master file at this point (there should be a master file,
/usr/conf/master.d/core-hpux, only on HP-UX B.11.11 at this point after an archive load). HP-UX
B.11.23 and above do not have master files.

Phase 2
There is one program to run Phase 2 of a recovery or installation session (configure1) it’s the same program
that runs phase 1. There’s no break in the running of the two phases only a logical break since the same
program executes both steps. There’s also nothing in the output that anyone running Ignite-UX can see to
indicate that phase two has started.
Continuing running configure1
• At this point the command “/sbin/insf –e –C disk” is run to create all disk devices. On HP-UX
B.11.23 the partition devices for the boot device are also created. The insf command does not do
this on HP-UX B.11.23 but does on HP-UX B.11.31. The insf commands “/sbin/insf –e –C
<class>” is also run for the following <class>s: tape_drive, tape. lan, dlpi, ps2, hil, kepd, floppy,
framebuf, sad, and audio. If VxVM is being used the classes vols and dmp are also included into
the list.
• Disk devices are renamed (the major and minor numbers are not changed) so that they appear as
requested by instance renumbering requests 161 in the configuration. This does not include disks
used by VxVM since VxVM handles disk device name changes between reboots by itself. The
instance numbering information is created by make_tape_recovery and make_net_recovery so
these actions are almost always associated with a recovery.
The disks are renamed by moving the raw and block devices to temporary names in one pass and
in a subsequent pass moving the temporary names to the final names. This prevents collisions in
device file names.
It is possible because VxVM device files are not renamed that a conflict between VxVM devices
and other disk devices may cause a conflict that cannot be reconciled. If such a condition happens
the following error is printed and the recovery session stops.
ERROR: A conflict has been detected while attempting to restore the

prior device file names (by restoring ext_bus instance number
assignments). This is caused by conflicting needs between VxVM
and LVM/whole-disk. In order to restore this system, you will
need to disable the hw_instance_num keyword for ext_bus:
<hw_path> by editing the config file. In some cases, just
rebooting and retrying may succeed. See
/opt/ignite/share/doc/FAQ item #1.18 for details.
The value of <hw_path> in the message tells you what you need to change to get a recovery
working. Note that this issue cannot happen on a system that just uses LVM/whole disks or VxVM.
It can only happen on systems that uses both.
• The environment variable SW_INITIAL_INSTALL set to the value of 1 is placed into the
environment. The swinstall manual page says:
SW_INITIAL_INSTALL
This variable is normally unset. If it is set, the
swinstall session is being run as the back end of an
initial system software installation ("cold"
install).
161
Note that the only instance number request that causes disk devices to have to change names is the
instance numbers of the class ext_bus. For disk devices the SCSI LUN and target will not change.

The main function of this variable is to prevent a kernel from being created when installing kernel
filesets. SD control scripts may also look at this variable and choose not to perform certain actions
(deferring them to later).
• If an OS Core archive was loaded and this is a revision of HP-UX before B.11.31 and tlinstall was
loaded onto the system it is run now to install transition links. Ignite-UX will set the sticky bit on
any transition links for which tlinstall reported were not correct.
• If an OS Core archive was loaded Ignite-UX does a check for a few minimum filesets to ensure
that as a minimum certain filesets were loaded (note that no check is made for any VxVM filesets
being present even if the configuration defines VxVM volumes).
Filesets checked always:
OS-Core.C-KRN
OS-Core.CMDS-MIN
OS-Core.CORE-KRN
OS-Core.CORE-SHLIBS
OS-Core.KERN-RUN
OS-Core.UX-CORE
SW-DIST.SD-CMDS
SW-DIST.SD-AGENT
SystemAdmin.OBAM-RUN
DCE-Core.DCE-CORE-SHLIB
Filesets checked if LVM is used:
LVM.LVM-RUN
LVM.LVM-KRN
Filesets checked if VxFS is used:
JFS.VXFS-BASE-KRN
JFS.VXFS-BASE-RUN
• The swagentd process is started at this point (for the swlist command that is about to be run and
also in the case of a cold install it needs to be running later).
• The filesets determined above are put into a temporary file (<temp_file> below) and the following
command is run:
swlist -l fileset -f <temp_file> 2>&1 1>/dev/null | grep \

ERROR: | grep Software | grep \"was not found\" > <temp_swlist_file>
If there was any data written to <temp_swlist_file> the output is logged to the console and the log
file “as is” and the number of lines read added up. If there were one or more errors the following
message is printed (which causes the installation or recovery session from an OS Core archive to
abort):
ERROR: Some key LVM or VxFS filesets are missing from the archive.
Running configure1 – preparing the system file
The only time a kernel should already be in place at this point would be if a recovery is in progress. A
golden image (created by running make_sys_image at level 2) does not include a copy of /stand/vmunix
into the golden image.

• If there’s no kernel in place we need to prepare the system for creating one. If a kernel is present
please go to the section “Running configure1 – after preparing ”.
* Creating the system file.
• The command “/usr/lbin/sysadm/create_sysfile /tmp/ign_configure/tstand.system” is run to create

a new system file. Some modules that aren’t needed in the file are removed by Ignite-UX (e.g. tgt
and root). In debug mode Ignite-UX will print out a copy of the system file that it created.
• If the archive does not contain a system file then the one created by create_sysfile will be used. If
one did exist in the archive it will be merged with the one created by create_sysfile. The merge
needs to be done as the system that the archive was created on may not have needed a driver in the
kernel (and hence the system file) that is required where the recovery archive or golden image is
being installed or recovered. In the case where the golden image did not contain a system file the
following warning is printed:
WARNING: OS archive did not contain a /stand/system file. Will try

to proceed with a newly generated file only.
A recovery archive should always contain a system file. A recovery archive however also always
contains a kernel at /stand/vmunix and unless cloning a new kernel is never created.
• At debug level 3 or higher the final system file is always printed in the debug output.
The kernel is not created at this point only the system file is prepared – during an SD based install SD
scripts may add/remove drivers or change tunables. The kernel is not created until later because during an
SD based install none of the software has actually been loaded yet.
Running configure1 – after preparing the system file
• The bootconf file is now created if it does not already exist (if it does exist no action is taken –
note that during an archive install it is removed by the os_arch_post_l script so it always gets
recreated in recovery mode). Note that Ignite-UX only ever writes one device into the bootconf
file. If you have a mirrored boot disk that needs to be setup during a recovery it is the system
administrators’ job to add the extra entry into the bootconf file 162.
• The primary path to boot from is now set via setboot. Note that on HP-UX 11i v3 normally you set
the device to boot from to be a lun not a specific hardware path. The setboot command however
does accept a lunpath hardware path as an option and Ignite-UX allows you to request that a
lunpath hardware path be used instead of a lun by using the variable _hp_force_setboot_path 163.
• At the same time the value of _hp_force_autoboot is checked and the autoboot flag changed as
appropriate. The description of this variable from the manual page instl_adm(4) is:
_hp_force_autoboot
162
Ignite-UX cannot preserve the previous contents of the bootconf file as it must contain only devices that
are bootable. An example of this is the offline diagnostics for HP9000 systems, the bootconf file is used to
determine what devices need to be updated to contain the offline diagnostics when the diagnostics are
installed. They have to contain a LIF at the time the software is installed.
163
If this variable is set to “true” a lunpath hardware path (which you cannot control) is used instead of the
lun device on HP-UX 11i v3. HP-UX can still change the lunpath hardware path to a different path to the
same LUN in the event of a path failure.

String variable used to modify the behavior of Ignite-UX behavior

with respect to stable store's autoboot flag. The Ignite-UX
configuration process has two parts separated by a reboot. By
default _hp_force_autoboot is set to YES, guaranteeing that the
Ignite-UX autoboot flag is set during the installation process
and then reset to its previous state (if necessary) at the end of
the installation. If _hp_force_autoboot=NO, Ignite-UX will not
touch the autoboot flag in stable storage. Note that this may
mean that you will have to perform a manual boot from the primary
path between the two parts of the Ignite-UX installation.
• On a system that is capable of HyperThreading (on HP-UX 11i v3 and later) we look at the the
value _hp_ht_enable.
_hp_ht_enable
Boolean variable that indicates whether to enable HyperThreading
on HyperThread-capable systems, as reported by the is_ht_capable
variable. Available on HP-UX B.11.31 or later.
If it is set to true HyperThreading is enabled and if it’s set to false HyperThreading is disabled.
The setboot command is used to make this change. In debug mode a debug message will be
printed showing the state of HyperThreading on systems that support it.
Now we’re going to start modifying ioconfig instances in a more complete way.
• We need to work out what all of the devices are on the system along with their current and new
instance numbers. The new instance numbers come from the hw_instance_num configuration
items in the configuration associated with the recovery session. It’s unlikely that there will be any
of these in a cold install environment.
• A list of unique classes is worked out from the list of instances.
• Instance assignements for devices that are not claimed are done now. This involves forcing the
information for the unclaimed device into the ioconfig file in the hope that in phase 3 the kernel
driver will be in the kernel and the device can be claimed then.
On HP-UX 11i v3 the instance information for devices of class disk and tape has already been restored by
the I/O listener. See the section “Running configure1” where one of the action points says “On 11.31 the
listener is asked to restore the I/O configuration from the configuration describing the install or recovery.”.
Requests to renumber instances for those devices classes on 11.31 are ignored at this point.
The command used to perform instance reassignments in the following section is "/sbin/ioinit -f
/tmp/ioinit.in". The configure1 program writes out the instance assignments for the one class to the file
/tmp/ioinit.in and then runs the command once for each device class.
• When going through a class to setup the file to reassign instance numbers the following issues
preclude an instance reassignment from occurring:
1. A class of “unknown” or an instance number of -1
2. There is no hardware for the device currently on the system
3. The device is currently not claimed (handled earlier)
4. Devices that exist but the device class doesn’t match the information in the configuration
5. The instance number already is correct
6. The driver in the kernel says that the configuration should not be saved for the devices it
controls.
Note: the last point above is really important. Not all instance numbers should be preserved. Drivers that
indicate their devices should not have instance numbers saved into the ioconfig files will not have

preserved instance numbers. This behaviour is new at Ignite-UX version C.7.7. If you attempt to try and
save instance information for drivers that do not support it ioinit will return errors. This behaviour was
implemented to more fully support USB devices (in most cases they do not allow their instance numbers to
be changed).
You previously could see error messages such as:
WARNING: Call to io_insert_node failed

io_instert_node failed: Node already exists or parameter error detected.
WARNING: Instance number assignments for device 0/0/2/0.0.1 may not be assigned
correctly.
ioinit: libIO error - Entry not found in ioconfig file.
Input line 3: 0/0/2/2.1 OO 3
WARNING: Command: "/sbin/ioinit -f /tmp/ioinit.in" failed. Instance number
assignments for devices of class "OO" may not be assigned correctly.
With Ignite-UX C.7.7 you will see messages as follows when a device reports that it does not require a
persistent instance number. It is possible these messages may only appear in debug mode from Ignite-UX
version C.7.8 onwards.
NOTE: Skipping hwpath: "0/0/0/0.0" class: "target" new_instance: "0" because

instance number does not need to remain persistent.
Important: some devices may not have instance numbers preserved from Ignite-UX version C.7.7 onwards
because their kernel driver does not require it. It is the expected and correct behaviour of Ignite-UX to no
longer recover instance numbers for devices that report they do not require persistent instance numbers.
• If the device passes the above tests then the information required to reassign the instance numbers
is written to /tmp/ioinit.in (for the format of the file see the manual page ioinit(1m)).
• The command "/sbin/ioinit -f /tmp/ioinit.in" is now run. This happens once for each class
discovered assuming the class has instance numbers that require renumbering.
• The last /tmp/ioinit.in file is removed.
Complete lab Eighteen (see “Lab exercise 18 – cold install and recovery (part 3)”).
Running configure1 – load the remaining software
In this section all of the remaining software is loaded. The only software loaded to date is the Core OS
archive (if there was one). All SD depot loads are done here. Note that unlike the initial Core OS archive
nothing is run chrooted here because the entire session was chrooted earlier.
The following steps are done in a loop for each group of software selections from a sw_source at each
load_order.
• Any pre_load_script or pre_load_cmd hooks assocated with the sw_source and sw_sel of the
software being loaded at this time are executed.
• The software is now loaded. How swinstall 164 gets run is not discussed here, archive loads are
performed in the same way as discussed here “Running configure1 – loading software (OS Core
archive)”
164
From HP-UX B.11.31 swm is used to install software not swinstall.

• All of the iux_postload and iux_postconfig scripts in the SD-UX IPD are located. If any were
loaded as part of a swinstall session they are ignored – only files loaded as part of an archive
install are going to be run later.
• Any post_load_cmd or post_load_script command hooks are now executed.
• The last modified time on the swinstall.log file is checked to see if it has changed. If it has
software will be configured later via swconfig.
This is the end of the loop mentioned above, the next steps happen after all of the software has been loaded.
• Any iux_postload scripts that have been loaded by archive loads are now run.
• Any global post_load_cmd or post_load_script command hooks are now executed
• A list of iux_postconfig scripts is written out so they can be executed in phase 3 (only scripts
loaded as part of an archive load will be run).
• An environment variable indicating if swconfig needs to be run in phase 3 is added into the phase
3 environment variables file (/envs.cfg.p3).
• The tlinstall program (/opt/upgrade/bin/tlinstall) is run to install transition links if it exists. If the
program is not installed the following message will be printed (it is not printed for HP-UX
B.11.31 onwards if tlinstall does not exist)):
NOTE: Will not attempt to create any transition links after software load.
The /opt/upgrade/bin/tlinstall is not present or is not executable.
• The per-client config file is written out into the client directory.
• The config.full file is written out. This file is different to the per-client config file in that it
contains a fully parsed and complete configuration for the cfg clause selected for the install or
recovery session.
• The config.full, hw.info, io.info and host.info files are copied to /tmp/ign_configure. Remember
that /tmp/ign_configure is where Ignite-UX stores a lot of stuff temporarily the install filesystem is
mounted /tmp/ign_configure/RAMFS 165. The files just copied will be present in phase3.
• The file /sbin/pax_iux is unlinked. This file was moved to this name previously it’s the version of
pax that Ignite-UX supplies. It used this version of pax so there would be a known version of pax
to use to extract any archives rather than use the version that got laid down during the install or
recovery. The version installed could be any version of pax from a first release version to the latest
patch so we need to use a known good version to avoid any known defects.
• All disk devices that correspond to devices that are hidden (via the variable _hp_hide_other_disks)
and not part of a disk group are removed.
• If VxVM is used the file “/etc/vx/reconfig.d/state.d/install-db” is removed. This is required to get

VxVM to startup correctly after the reboot if there are disk groups used on this system.
165
Remember between phase 2 and phase 3 there is a reboot. Files copied to /tmp/ign_configure/RAMFS
will be lost during the reboot because it’s a RAM filesystem. Files copied to /tmp/ign_configure will be
preserved since it is part of /tmp.

Running configure1 – building a kernel
In this section we’re going to end up building a kernel (if one isn’t already in place) before we can do that
however there are some other tasks that need to be completed. The first is completing fixing up dynamic
major numbers.
• We test to see if a valid master file exists on the system now. If we can’t access it (we don’t expect
to be able to on 11.23 and above) then we assume that any major number is valid for use as a
dynamic major number (block and character) 166. If it is readable the file is processed to extract the
valid dynamic major numbers for this version of HP-UX.
If the system was installed from an archive and the archive contains an ioconfig file the
information from it about what dynamic major numbers were used in the archive is loaded.
The contents of /dev are recursively processed (using nftw with a depth of 5) to look at all device
files (except those under /dev/vx) and see if they have a block or character major number that will
change after the reboot at the end of phase 2. If they are they are recreated with the major number
that will be correct when running on the final kernel after the reboot.
The above steps are only perfomed if the master file could not be read earlier (i.e. this gets called
and does something for non-archive B.11.11 loads, for archive and SD based B.11.23 and above
loads nothing is done by this code).
• If we find a device that does not have an entry in the new ioconfig file created while running on
the install kernel it’s likely that we are looking at a device that will not have a driver associated
with it until the system has rebooted and is running on the final kernel in phase 3. In this case
information is written into the file /tmp/ign_configure/dyndevstofix so the device can be processed
in phase 3.
• We need to make a special check for the FDDI software if the install process is using FDDI for
networking 167. The fddi2 and fddi drivers require an exernal command to initialize the fddi
interface (this is not all of the fddi kernel drivers). If we’re using either of those drivers then the
/usr/sbin/fddiinit command must exist otherwise the installation or recovery session will fail.
The fddi2 driver is for the inbuilt FDDI interface on the 735/755 HP9000 700 series workstations
and the fddi driver is for the HP-PB 168 FDDI card. For the fddi2 driver the insf command does not
create the required device files so they must be copied from the install filesystem to the disk
filesystem.
Now we are at the stage of preparing fully for creating a kernel by processing any kernel directives from
the configuration (that is mod_kernel, add_kernel, and rm_kernel directives).
• If /stand/vmunix exists no further processing of kernel directives is done. A /stand/vmunix file will
never exist in:
- a golden image or,

- a SD based install
166
The used to be additional complexity in this code when a B.11.11 kernel was used to install HP-UX
B.11.00 as the dynamic major numbers were different and this routine had to do more work to shift drivers
that were using dynamic major numbers on the B.11.11 kernel to valid HP-UX B.11.00 dynamic major
numbers. This code is not really required any more.
167
This is very uncommon on modern systems. It’s even more uncommon to find any systems still using
the fddi or fddi2 drivers for Ignite-UX installation or recovery networking.
168
HP Precision Bus.

and should always exist in a recovery unless:
- The hardware model of the system is different to the model the recovery archive was created
for, or
- In itool the user went to the basic tab pressed the additional button and changed “Cloning to
different HW?” to be TRUE.
• The kernel configuration changes are now processed, they are processed in the following order:
1. global mod_kernel statements
2. mod_kernel statements in a sw_sel clause
3. global set_kernel statements
4. set_kernel statements in a sw_sel clause
5. global rm_kernel statements
6. rm_kernel statements in a sw_sel clause
The changes are perfomed by writing a temporary script for each change that sources
/usr/lbin/sw/control_utils, the mapping of configuration statement to the function in control_utils
used to make the change is:
1. mod_kernel – tunable - chg_tunable
2. mod_kernel – module – add_module
3. set_kernel – tunable – chg_tunable
4. set_kernel – module – add_module
5. rm_kernel – module – rm_module
This implies that rm_kernel cannot be used to remove a tunable from the system file it can only be
used to remove a kernel module/driver. The name of the temporary script used in this step is
/tmp/ign_configure/add_param_sc.
• Some memory is freed. All of information about selected software is deallocated.
• The KRS is now handled. Note that on HP-UX B.11.11 nothing is done since there is no KRS. In a
recovery the complete KRS tree is recovered except for the following subtrees:
1. /escsi
2. /SAS
3. /dumpinfo
4. /ignite/recovery
The /SAS subtree holds information about the mappings of SAS devices to hardware path. Ignite-
UX recovers the mapping of SAS device to hardware path during a recovery so this subtree is not
required.
The /dumpinfo subtree is not required as the root volume or disk group is always created and
Ignite-UX resets the dump information during the recovery process.
The /ignite/recovery subtree is not required as Ignite-UX always sets this during a recovery to the
version of Ignite-UX used to perform a recovery.
On HP-UX B.11.31 the /escsi subtree holds (amoungst other things) persistant information set by
the scsimgr command during a recovery this information is lost. The CR QXCR1000827937
exists asking for this information to be recovered. This is expected to be addressed in a future
version of Ignite-UX in 2009.
During a cold install the KRS is initialized and has /ignite/install set to the version of Ignite-UX
used to install the system. The values of /ignite/image and /ignite/recovery are set to the value
“NONE”. During a golden image install it is possible that /stand/krs/system.krs is present and if so

this is merged into the KRS. The same subtrees that are dropped during a recovery session are
dropped during a cold install.
• The KRS is saved to disk. The code handing the KRS is quite complex and is not described in full
here. Additional work on the KRS is perfomed after the system reboot into phase 3.
At this point we actually start the real work of building a kernel (if required).
• All of the vmunix files under /stand are located and the following actions are taken:
1. The vmunix file is copied to /var/vmunix.hole, if that succeeds it is then copied back to its
original location. If the copy to /var/vmunix.hole fails see step 2 otherwise copy the next file.
If the copy back from /var/vmunix.hole to the original location fails the following error will
be printed:
ERROR: Failed to copy <kernel> to /var/vmunix.hold (<strerror>

(errno = <errno>)), it may not be bootable.
Where <kernel> is the kernel file being copied, <strerror> is a string returned from strerror(3)
when the value of errno at the time of the error and <errno> was the value of errno at the time
of the error.
2. The vmunix file is copied to /stand/vmunix.hole, if that succeeds it is then copied back to its
original location. Remember that this step is not done if the first step succeeds. If the copy to
/stand/vmunix.hole fails see step 3 otherwise start copying the next file. If the copy back from
/stand/vmunix.hole to the original location fails the following error will be printed:
ERROR: Failed to copy <kernel> to /stand/vmunix.hold (<strerror>

(errno = <errno>)), it may not be bootable.
3. If the kernel could not be copied to /stand or /var the following note is printed:
NOTE: Failed to copy <kernel> to either /var or /stand

(<strerror> (errno = <errno>)). Cannot modify it to be non-sparse.
The point of these actions is to make sure that there are no sparse 169 kernels under /stand (pax
recovers all files as sparse). A sparse kernel causes a panic when booting the kernel. After the
kernel files have been copied the files /var/vmunix.hole and /stand/vmunix.hole are removed.
• If /stand/vmunix exists then no further work is done on creating a kernel (go to “Running
configure1 – setting up for the reboot into phase 3” to continue). When no new kernel will be
created the following message is printed:
NOTE: Since the <kernel> kernel is already in place,

the kernel will not be re-built. Note that no
mod_kernel directives will be processed.
• On HP-UX B.11.23 the translation of the new USB drivers to the older drives is done if the new
drivers are not present on the system (if the file /usr/conf/mod/UsbOhci is not found the translation
happens). When the translation happens the following drivers are removed UsbBootMouse,
UsbBootKeyboard, UsbMiniBus, UsbOhci, UsbEhci, MouseMUX, KeyboardMUX,
169
A sparse file does not have all data blocks written to disk, a disk block containing only nul values (hex
0x0) if not written can be read back and appear as nul data but a program does not have to write the block
to disk to be able to read the nul data blocks back.

UsbScsiAdaptor, UsbBulkOnlyMS, OOCdio, and LegacyDeviceDriver and the drivers hub, hcd,
hid, and ehci are added.
• The environment variable SW_INITIAL_INSTALL=0 is placed into the environment so

mk_kernel will create a kernel.
• The kernel parameter maxswapchunks is tuned to try and handle all of the swap currently
configured for releases previous to HP-UX B.11.23.
• The line “dump lvol” is added into the system file if dump is configured to be inside an LVM
logical volume. If we fail to add the line when it’s required the following warning is printed:
WARNING: Could not add the line: "dump lvol" to /stand/system,

the resulting system may not have dump configured properly.
• The kernel tunable maxvgs is set to allow for the maximum number of volume groups currently in
use (it’s never lowered only increased if required). This is no longer required on HP-UX B.11.31
or later (it is always at the maximum and is no longer a tunable).
• The following files are copied into place (to the indicated path) if the file exists under
/usr/newconfig (this is done to fix a very very old compiler issue):
/usr/ccs/bin/ar
/usr/ccs/bin/cc
/usr/ccs/bin/cc_bundled
/usr/ccs/bin/ld
/usr/ccs/bin/size
/usr/ccs/lbin/ccom
/usr/ccs/lbin/cpp
/usr/lib/nls/msg/C/ar.cat
/usr/lib/nls/msg/C/cc.cat
/usr/lib/nls/msg/C/cpp.cat
/usr/lib/nls/msg/C/ld.cat
/usr/lib/nls/msg/C/size.cat
• The command used to compile the kernel is built, on HP-UX B.11.23 and above the following
command is used:
/usr/sbin/mk_kernel –f –o /stand/vmunix
And on HP-UX B.11.11 the following command is used:
/usr/sbin/mk_kernel –o /stand/vmunix
The –f option is an undocumented option used by SD-UX and Ignite-UX to clean up any partial
left over kernel builds that may have been present previously before creating the kernel. The
option doesn’t exist on HP-UX B.11.11.
This marks the start of a loop (if building a kernel fails it is possible to push a shell and then fix the
problem is and then do an “exit”. If that happens we come back to the top of the loop and execute the
following steps over again.
• If a kernel file exists (it won’t exist normally but if it’s been created when a shell has been pushed
after a failure it can exist here on our second time through) we break out of the loop.
• On HP-UX B.11.23 if /stand/system is a symlink then we copy the file through the symlink and
move the file back over the top of the symlink (in effect removing the symlink and leaving us with

a regular file as /stand/system). The directory /stand/current is removed at this time if

/stand/system was a symlink (it was almost definitely a symlink to /stand/current).
• The command put together above to create the kernel is run now. If it fails the following error
message is printed
ERROR: Could not make an executable kernel. An interactive shell will now be
provided. Once you have fixed the problem or a kernel has been built
and placed in /stand/vmunix, "exit" the shell.
If the session is being controlled from an Ignite server the following message is printed instead:
NOTE: If you wish to attempt to recover, go to the target machine's console

and interact there. Otherwise, use the "Stop Install" action to reboot
or halt the target machine.
A shell is pushed to allow the kernel creation issue to be addressed. When exit is used the process
checks to see if a kernel was created or not while at the shell. If it was we continue from here
otherwise we attempt to create a kernel again.
It is probably easier at this point to run mk_kernel manually and ensure that the kernel gets created.
Important: For performance reasons on systems with low memory configurations during the install
process /stand (or really /d_cfg_mnt_sb61/stand) is mounted with the VxFS option delaylog from Ignite-
UX version C.7.5 onwards. Normally it would be mounted with the tranflush option on a running system
(and it was mounted this way prior to C.7.5). With low memory configurations prior to Ignite-UX version
C.7.5 it was possible that the commands used to create a kernel might fail to convert the filesystem options
from tranflush to delaylog. The following change documented from the Ignite-UX release notes in version
C.7.5 announced this change:
- The time needed to build new kernels during cold-installs on certain

systems with less than approximately 4GB of RAM has been reduced.
In some cases, kernel builds that took several hours to complete
will now finish in a few minutes. Additionally, software load
times on these systems may decrease by about 10%.
If you encounter an issue with a kernel build taking a long time move to C.7.5 or later. In reality it can take
up to 9-10 hours (sometimes a bit longer) to complete. After the reboot into phase 3 the /stand filesystem
will come up with its default setting of tranflush.
Running configure1 – setting up for the reboot into phase 3
• The /etc/inittab file is temporarily replaces with a new (modified) version after saving away the
original inittab file (if /etc/inittab is missing the file /usr/newconfig/etc/inittab will be saved away
and placed back as /etc/inittab later). The current version of inittab is saved away at
/tmp/ign_configure/inittab.
• The /etc/inittab file is modified to allow the installation or recovery process to continue. The first
line is always added into the inittab file.
init:3:initdefault
For HP-UX B.11.31 the fsdaemon must be started before we can do almost anything.
ifd1::sysinit:/sbin/fs/fsdaemon -f 1 </dev/console >/dev/console 2>&1

ifd2::sysinit:/sbin/fs/fsdaemon -t </dev/console >/dev/console 2>&1

If instance number changes were made in phase 2 we need to recreate disk and tape devices.
igi3::bootwait:/sbin/sh -c \"/sbin/insf -e -C disk; rm -f /dev/rmt/[0-9]*m*;

/sbin/insf -e -C tape\" </dev/console >/dev/console 2>&1
If /sbin/lvmrc exists we need to enable LVM volume groups (in a recovery this will only make the
root volume group active if VxVM wasn’t used for the root volume group in a cold install this will
activate all volume groups):
igl3::bootwait:/sbin/lvmrc </dev/console >/dev/console 2>&1
If VxVM was used as part of the installation or recovery process the following is added:
ivx1::bootwait:/sbin/init.d/vxvm-startup2 start </dev/console >/dev/console

2>&1
ivx1::bootwait:/sbin/init.d/vxvm-startup start </dev/console >/dev/console 2>&1
ivx2::bootwait:/sbin/vxdctl cachedisable </dev/console >/dev/null 2>&1
The following is added unconditionally:
igm3::bootwait:/sbin/mountall -l </dev/console >/dev/console 2>&1
On HP-UX B.11.31 the following line is added:
ikb1::bootwait:/sbin/kcboot </dev/console >/dev/console 2>&1
Lastly we need to add the line that we add an entry to allow configure3 to run to complete the
installation or recovery session after the reboot.
ign3::bootwait:/configure3 </dev/console >/dev/console 2>&1
All comments and lines containing ":sysinit:"or "stty:" from the original file are dropped from
/etc/inittab. If you wish to see the contents of the modified inittab file the resulting file is shown in
debug mode.
• The system is now rebooted.
Complete lab Nineteen (see “Lab exercise 19 – cold install and recovery (part 4)”).

Phase 3
At this point the systems should have completed its reboot and have executed the other things from
/etc/inittab at the bootwait stage and we’re going to start looking at what happens in the configure3
program.
Important: In most causes if you ever find a /configure3 program on a system the system has been
recovered previously. That recovery however has failed and the system is in an unknown state because the
recovery never completed.
Running configure3 - startup
• The first thing that is done is the file /envs.cfg.p3 is read and the environment variables are placed
into the environment of configure3. Some additional environment and global variables are set
based upon the environment variables just set.
• Support for debug logging is done (this determines the debug logging level). The previous step
also setup a location for a temporary log file if the system is doing a network install, the NFS
based client directory isn’t mounted yet so the logging information must be locally until later (into
/tmp/ign_configure/log_file).
This brings up an important support consideration that was discussed previously, if there is a failure
at this stage of a recovery or installation session until logging is done to the client log file after the
NFS client directory is mounted information about what is happening is only available from the
console and the temporary log file mentioned above.
• The console is in a default state so Ignite-UX sets some basic terminal attributes for the console.
• Signal handlers are setup for SIGINT, SIGQUIT, and SIGUSR1. When SIGINT or SIGQUIT are
received (after the signal handlers are setup) the following message is printed on the console and
the user asked to confirm if they really wish to stop the installation (answering y/Y causes the
session to be aborted and the system is rebooted).
configure: Detected a user interrupt.

Do you really wish to stop the installation?
• A check is made to ensure that libcfg.so/libcfg.sl is the correct version for this program (the Ignite
version compiled into the library is checked against the Ignite version compiled into configure3 to
ensure that they match).
• Some cleanup of some temporary files under /stand is done now (they were left there in an earlier
phase of the installation/recovery session).
• The release of the currently running kernel is retrieved.
• The previously saved full config file is parsed (this includes loading up the previously saved files
like io.info, host.info, etc that were saved before the reboot to /tmp/ign_configure). This needs to
be done now rather than after the client directory has been mounted as we’re about to start to
reference values that are in the configuration that describes the installation or recovery session.

• The umask and group id are now set. The umask is set according to the value of _hp_umask, if not
set 022 is used 170. The group id needs to be sys (gid 3), this is the primary group of root when
logged in – if this wasn’t done any files created now would be created with a group root (gid 0).
It is possible that while running on the install kernel there may have been devices that were not claimed
because there was no device driver for it. That means we need to do some steps to try and make sure that
the devices end up correctly configured.
• The first thing is to remove /etc/ioconfig and /stand/ioconfig. Note that this does not affect the
instance numbers of already claimed devices as the kernel read the ioconfig files during boot and
instance number assignments performed in earlier phases have already taken effect.
• The command “insf -e -d dev_config” is run to ensure that /dev/dev_config exists and is correct.
• The command “ioinit –c” is run to recreate the ioconfig files. As noted above this does not change
or affect any instance number assignments previously performed earlier by Ignite-UX.
• In phase 2 in the section “Running configure1 – building a kernel” we had the following step:
“If we find a device that does not have an entry in the new ioconfig file created while running on
the install kernel it’s likely that we are looking at a device that will not have a driver associated
with it until the system has rebooted and is running on the final kernel in phase 3. In this case
information is written into the file /tmp/ign_configure/dyndevstofix so the device can be processed
in phase 3.”
Now we need to process the file /tmp/ign_configure/dyndevstofix as the devices should have been
claimed. If the file doesn’t exist there’s nothing to do because there were no files to fix.
To make the changes the new ioconfig files are loaded up and then the entries from
/tmp/ign_configure/dyndevstofix are processed one by one finding the name of the device driver
amd the device files changed (if the major numbers have changed).
Note: It is possible during a recovery that dynamic major numbers may change however
Ignite-UX will attempt to make sure that device files under /dev (but no where else) are changed
to reflect changed major numbers. An example of when this might happen is when new drivers are
added into the install kernel (that will be used for recovery) compared to the install kernel that the
system was installed with.
Now we need to start networking, if networking is not going to be started (e.g. a media only install)
proceed past this section to “Running configure3 – after networking has been started”.
• If the /etc/rc.config.d/nddconf does not exist and the /usr/newconfig/etc/rc.config.d/nddconf file

does exist it is copied to /etc/rc.config.d/nddconf.
• The /sbin/init.d/net.init command is run with the start option to setup streams prior to starting
networking.
• If the /usr/sbin/ndd command exists (and it should) the following command is run “/usr/bin/ndd -
set /dev/ip ip_check_subnet_addr 0”. On HP-UX B.11.31 the following command is also run
“/usr/bin/ndd -set /dev/ip ip_ire_gw_probe 0”. If you wish to see further information about these
ndd parameters the output of ndd –h for the parameters is available in “Appendix B – ndd
parameters used by Ignite-UX”.
170
It should be noted that HP does not test Ignite-UX with _hp_umask set to any value, so only the default
value of 022 is ever tested.

• The network interface is checked to see to see if it is a FDDI interface (a LAN interface controlled
by the fddi or fddi2 driver), of so the /usr/sbin/fddiinit command is run to initialize the interface.
Networking is started here:
• The LAN interface that will be used is determined (the LAN interface defined by the configuration
variable _hp_default_cur_lan_dev). If there is an IP address available but there is no hostname
defined the following error is printed and networking is not started:
ERROR: A hostname was not provided from DHCP or from the instl_adm(1M)
settings to match the IP address (<IP address>) given. If you are
using DHCP, make sure that the IP addresses that it manages have a
hostname associated with them on your DHCP server, in which ever host
database you use (/etc/hosts, DNS, NIS).
Where <IP address> is the IP address defined by the configuration or gained via DHCP for the
installation or recovery session. If you see this error networking will not be started.
Otherwise if there is no IP address and/or no hostname set the following error will be printed:
ERROR: Hostname and/or IP address was not set with instl_adm, and not
obtainable via DHCP.
Again if you see this error networking will not be started.
• Next the following message is printed:
* Bringing up Network (<lan_interface >)
Where <lan_dev> is the name of the LAN interface that will be used for networking. Note that if
the LAN interface changes instance numbers between phase 2 and 3 the correct LAN interface
will still be used.
• The value of _hp_lanadmin_args is checked to see if there have been any special options set for
the LAN interface. If there are the following actions are performed:
1. If the lanscan command exists it is run and the output parsed to determine the PPA of the
LAN interface.
2. The lanadmin command is run to set the interface up according to the contents of
_hp_lanadmin_args.
• The command “ifconfig <lanx> inet <IP address> up” is run to bring the interface up with the
assigned IP address (the netmask, if present, is added into the command as well).
• If there was a default route defined by the configuration (including information gained via DHCP
or on the Networking Configuration screen) it is added now using the route command (“route add
default <IP Address> <Gateway IP Address>”).
• The environment variable that defines the network to now be up is set.
If starting the network failed we go back to the start (see “Networking is started here:” above). The steps
taken to start networking are the same steps as used in phase 1 of a recovery/installation session.
Running configure3 – after networking has been started

Although “networking” has been started there are still some steps related to networking that are performed
even if networking is not used (e.g. during a tape recovery).
• If a hostname is defined by the configuration it is used to set the hostname(see sethostname(2))

and node name (see setuname(2)). The hostname “loopback” is used otherwise.
• The loopback interface is enabled on the system by running the command “ifconfig lo0 inet
127.0.0.1 up”.
• If this installation or recovery session was previously using an NFS client directory the following
steps are performed:
1. If the file /etc/netconfig does not exist the file /usr/newconfig/etc/netconfig is copied to
/etc/netconfig.
2. The NFS client directory is mounted.
3. The temporary log file is appended to the log file in the client directory
4. The environment variable pointing to the log file is updated to point to the NFS client
directory.
5. The log file on the NFS client directory is opened.
• The DHCP daemon is now started to defend the DHCP lease (if we have one).
• The command “swapon –a” is run to enable all swap spaces.
• Instruction checks are turned on to monitor if the Ignite server says to abort or halt the installation
or recovery (if we have an NFS client directory).
• Move back the temporary copy of /etc/inittab we made in phase 2 as we no longer need the
commands that were in it to be run any more.
• The names of the files /configure3 (the program that is currently executing) and /monitor_bpr
(only used in earlier phases) are written into /var/adm/sw/cleanupfile (this will get SD-UX to
remove the files later).
• If we had to change the value of autoboot (see setboot(1m)) to make the system boot during the
recovery or installation session autoboot is now disabled. See the description of
_hp_force_autoboot on the manual page instl_adm(4) for more information.
• If the system was booted with bootsys to perform the install or recovery session and the disk that
was modified by bootsys is not the disk that was installed to then the AUTO file on that disk is
restored.
• The files created by filesystem paging enabled during the installation or recovery session is
removed. This step does nothing if no filesystem paging was enabled earlier.
• The fstab files from the original system and the recovered systems are merged. A /etc/fstab file
from the original system should only exist during a recovery. The two files have to be merged
rather as it’s possible to make changes via itool (define new filesystems, change mount points, etc).
• This completes the step of booting the client.
Running configure3 – configuring software
Now we need to configure the software that was loaded in phase 1 and 2 of the installation or recovery
session.

• A list of all of the sw_sel clauses that were installed is built.
On HP-UX B.11.11 and B.11.23 the following steps are performed:
• The value of the environment variable “ENV_SWAGENT_LOG_MODIFY” is retrieved. We

discussed how it was set previously. When installing software the last modification date on the
/var/adm/sw/swinstall.log file was retrieved to see if any software had been installed via SD. If the
date changed we needed to run swmodify later.
Important: Even though the name of the environment variable is

“ENV_SWAGENT_LOG_MODIFY” the value is based on the modification date of the
swinstall.log file not the swagent.log file.
It’s easy to see the value of this environment variable at debug level 4 (the highest possible
verbosity) as one of the following messages will always be printed:
DEBUG: Will not perform swconfig * since ENV_SWAGENT_LOG_MODIFY

environment variable is either not set or is not "1" if set
DEBUG: Will perform swconfig * since ENV_SWAGENT_LOG_MODIFY
environment variable is set and is "1"
• For every SD-UX source in the list of software the following is performed (Note that software is
configured in the same order as the load order):
1. The swagentd process is started if this is the first set of software to be configured.
2. For each set of software loaded it is determined if all of the software was loaded (using
swlist). Software can exclude itself from being loaded and we shouldn’t attempt to
configure software that was never loaded (as it will fail). Software that wasn’t loaded will
be removed from the list of software to be configured.
3. The swconfig command is run with a list of software to be configured.
• Under some circumstances a swconfig \* may be run, e.g. if a match_target operation was used or
the option “-xpatch_filter=*.*” was used as part of a swinstall command. This can also be
triggered if a post_load command hook runs a swinstall command.
These operations may cause software other than the selected software to be installed and just
configuring the software we know about may lead to unconfigured software left over after the
installation session. If swagentd had not been started it is started before running the swconfig \*
command.
• The install version of the SD defaults file (/var/adm/sw/defaults) is replaced by the newconfig
version of the SD defaults file (/usr/newconfig/var/adm/sw/defaults).
• The file /var/adm/sw/needs_config is moved out of the way to /var/adm/sw/config.prev as we’re

controlling how the software is configured not the startup script that configures all unconfigured
software.
On HP-UX B.11.31 the following steps are performed:
• The following environment variable is retrieved “ENV_SWAGENT_LOG_MODIFY”. We

discussed how it was set previously.
• A list of all saved swm jobs from before the reboot are listed by running the command “swm -a
job_id *,save_code=JobSaveAndReboot,status=SAVED” and writing the output to a file.
• The file containing this information is then reopened and the following steps performed:

1. If swagentd is not running it is started now (note that swm does use the same backend as
SD-UX – that is it talks to swagentd).
2. The command “/bin/swm job continue <jobid>” is run to continue each swm job. If any
continued job returns an error an error message is printed. If a warning is printed then the
warning version of the message is printed (any warning or error does not stop Ignite-UX
from continuing to attempt to configure additional software):
WARNING: Warnings occurred while installing software via "swm" job: "<jobid>".
For details, see the messages above, or run "swm job log -xverbosity=1
<jobid>" to see any errors or warnings for that job. Continuing...
ERROR: Warnings occurred while installing software via "swm" job: "<jobid>".
For details, see the messages above, or run "swm job log -xverbosity=1
<jobid>" to see any errors or warnings for that job. Continuing...
• If any swm job continuations had errors or warnings or the environment variable
ENV_SWAGENT_LOG_MODIFY was set to 1 then swconfig is run on software that is not
configured. This may also be done because software may have been loaded using swinstall instead
of swm (e.g. from a post_load command hook). Ignite-UX will always use swm to install software
on HP-UX B.11.31.
• The install version of the SD defaults file (/var/adm/sw/defaults) is replaced by the newconfig
version of the SD defaults file (/usr/newconfig/var/adm/sw/defaults).
From here the different HP-UX releases merge back into the same code path.
• If there is no locale set or it has been set to ask at first boot then the following command is not run.
If there is a locale set then the following script is run:
/tmp/set_locale –l <locale>
The set_locale script is extracted from the SYSCMDS file in phase1 of the installation or recovery
session. We can extract it manually to view its contents:
# pwd
/opt/ignite/data/Rel_B.11.31
# gzcat < SYSCMDSIA | pax -ir ./tmp/set_locale
rename ./tmp/set_locale? /tmp/set_locale
# cat /tmp/set_locale
#! /usr/bin/ksh
# Script for picking off the locale keyword from an hp_ii

# SD bundle attribute.
#
# Returns:
# 0 if a locale value is set, or if no locale is given.
# 1 if some error occured

cleanup_exit()
{
rm -f /tmp/$$*
exit $1
}
# Make sure we have access to the SD commands
PATH=/usr/sbin:$PATH
typeset locale

typeset x_config_file
typeset matchstr
typeset printstr
typeset lang_file=/etc/rc.config.d/LANG
typeset list=/tmp/$$list
typeset tmp_lang_file=/tmp/$$lang
typeset tmp_x_config_file=/tmp/$$x_config
typeset usage="
USAGE: $(basename $0) -l <locale> "
while getopts :x:l:f: opt

do
case "$opt" in
f) # use a different LANG file
lang_file=$OPTARG
;;
The command as called passes only a –l option so the only variable that will be set will be “locale”.
l) # use a preset locale value

locale=$OPTARG
;;
x) # use a X config file
x_config_file=$OPTARG
;;
:|\?) print $usage
cleanup_exit 1
;;
esac
done
Some sanity checks are performed to ensure that we don’t do something wrong. We need to make
sure that there is a value in the locale variable and that it is not the value “default”.
# If no locale value is given, then exit

# without doing anything
if [[ -z "$locale" ]]
then
cleanup_exit 0
fi
if [[ "$locale" = "default" ]]
then
cleanup_exit 0
fi
The next section ensures that the locale selected is actually supported on this system. That is it
needs to appear in the output of the locale –a command:
# Verify that the locale command exists

# If it doesn't, then exit without setting anything.
if $(whence locale) > /dev/null
then
locale -a > $list
else
cleanup_exit 1

fi
if [[ $(grep -c -x $locale $list) -ne 1 ]]

then
# Either the locale is not available on the system,
# or somehow the user specified value matched more
# than one locale. Don't know which to set.
cleanup_exit 1
fi
If we do have a valid locale the file /etc/rc.config.d/LANG is updated to reflect the locale setting.
# Edit the lang_file

if [[ -f $lang_file ]]
then
if [[ $(grep -c "LANG=" $lang_file) -gt 0 ]]
then
sed "s/.*LANG=.*/export LANG=${locale}/" $lang_file >$tmp_lang_file
cp $tmp_lang_file $lang_file
else
echo "LANG=${locale}" >>$lang_file
fi
else
echo "LANG=${locale}" >$lang_file
chown bin $lang_file
chmod 444 $lang_file
fi
We’re not going to look at what it does to enable the locale as the default locale for VUE and/or
CDE. You can extract the set_locale script from the SYSCMDS file to do that yourself. The script
does update them as appropriate.
# Setup the appropriate login value for vue or cde.

for dir in /usr/dt/config /etc/vue/config
do
…
done
cleanup_exit 0
• This ends the configure phase of an installation or recovery and we’re ready for the post-configure
phase.
Running configure3 – post-configure
• The file /etc/resolv.conf is removed. This is performed as during a network based installation or
recovery session if we picked up networking details via DHCP we may have received DNS
information and it could be different to how the system is configured to end up.
• Now we need to open the archive merge file (/tmp/ign_configure/os/archive_merge/ig_merge_file)

and read its contents 171. Each of the files read are moved back into place (excluding the hosts file
as that is done later). The file contains a list of files that had to be saved aside earlier because
Ignite-UX may have needed to modify the file during the recovery or golden image install session.
171
The file contains a list of files that need to be moved back into place that were saved aside earlier (e.g. in
places like the os_arch_post_l script).

• The next section depends on what the value of is_net_info_temporary has been set to in the
configuration. If it’s false then the networking information is not temporary and it is merged with
any “final” networking configuration defined in the configuration describing this recovery or
installation session. In this case the following steps are performed:
1. In the final information if the following values are not set they are copied from the temporary
information if it has a value:
a. hostname
b. DNS domain
c. NIS domain
d. NIS server
e. NTP date server
2. If temporary information for the following items exists for the following items and there is no
final information it will be used on the final system:
a. DNS name servers
b. DNS search domains
c. Routing information
After the networking information has been merged then the same steps are followed to write out
the networking information as used when “final” networking information is present.
The merged or final networking information is applied to the system. The following steps are done
to perform this action 172:
1. The /etc/rc.config.d/netconf file is read and the information in it determined. This is required
because where possible we want to retain the same index values in the configuration file for
LAN interfaces.
2. The hostname is written out into /etc/rc.config.d/netconf. If you have chosen to run set_parms
any existing hostname in the netconf file is removed.
3. The index values that are in use in the old netconf file for LAN interfaces are determined.
4. Networking information for LAN interfaces is written out into the netconf file. Where
possible the same LAN interfaces will continue to use the same index values. If there was no
old information for this LAN interface the first available index entry is used to hold the
information for the newly configured LAN interface. All of the networking information is
then written out 173.
5. The file /etc/resolv.conf is written out (replacing the existing contents)
6. If there is a NIS domain set by the configuration then the file /etc/rc.config.d/namesvrs is
updated to reflect how the configuration has set the following items (if they are not set they
are not written):
a. NIS domain in to the variable NIS_DOMAIN
b. NIS_CLIENT is set to 1
c. WAIT_FOR_NIS_SERVER is set to the the value of the configuration item
wait_for_nis_server.
d. YPSET_ADDR to contain the value of NIS Server (not updated if not set).
7. If an NTP date server has been set it is written into the ntp configuration file. The
/etc/rc.config.d/netdaemons file is also updated to set NTPDATE_SERVER and XNTPD=1.
8. If the configuration defined routes the routing information between the configuration and the
/etc/rc.config.d/netconf is compared to try and preserve index numbers. The routes are then
written to the netconf file.
9. Information in /etc/rc.config.d/netconf that is not present in the configuration is commented
out.
172
Note that if you have chosen to run set_parms some values may be removed from configuration files so
they can be set via set_parms. Values that will be removed in this way are indicated in the list.
173
Note that any network interfaces that were configured in netconf but for which Ignite-UX has no
configuration are commented out in the final version of the netconf file.

10. All SD files that contain SD ACL definitions are updated and the hostname replaced (if the
hostname changes the ACLs would not work). This is not done if the system has not
hostname defined.
11. If the hostname has changed (which it can really only do in a recovery) all of the scripts in
/sbin/ch_hostname.d are called so they can update any configuration that depends upon the
hostname.
• If there is no “final” networking configuration and is_net_info_temporary is true and there is no

lan0 but there are other lan interfaces present the value of INTERFACE_NAME[0] in
/etc/rc.config.d/netconf is set to the lowest numbered lan interface 174. The following message is
logged when this happens:
* Setting INTERFACE_NAME[0] to <lan> in /etc/rc.config.d/netconf.
Otherwise the following message is printed:
* No final networking info and no LAN cards to use for INTERFACE_NAME[0]
• If a timezone has been set in the configuration it is set in /etc/TIMEZONE and /etc/default/tz. If
the timezone information can’t be applied to /etc/default/tz on a HP-UX B.11.23 or later system 175
the following warning is printed:
WARNING: Cannot apply the timezone "<tz>" to /etc/default/tz.
• If a root password was set in the configuration it is now applied to the system. When the root
password is applied the following message is always printed:
* Applying the root password.
• When not in recovery mode a manifest is always created by performing the following steps:
1. The following message is printed:
* Creating the manifest.
2. A manifest.seed file is created if it does not already exist, on a cold installed system it should
contain information like:
DOM 176 "June 18, 2008, 13:51:35 EST"

IGNITE_REVISION C.7.3.148
On a factory ignited system the manifest.seed file will contain extra information such as the
order number. The extra information that can appear is controlled by the following Ignite-UX
configuration items (from the instl_adm(4) manual page):
serial_number = cplx_string
customer = cplx_string
order_number = cplx_string
These three keywords are used to supply information that is
displayed on the client's manifest. They are informational only.
174
This step is in an else condition so if the previous steps to apply networking information to the system
this step cannot occur.
175
The reason for this is that on HP-UX B.11.11 patch PHCO_24396 introduced this file so the file may or
may not exist on that release of HP-UX. From HP-UX B.11.23 and later however the file /etc/default/tz
should exist.
176
Date of manufacture

Information on what software was selected for installation is also added to the manifest.seed
file.
3. The print_manifest command is called to create the manifest.
4. The directories /opt/ignite/share/man/%L and /opt/ignite/share/man are added to
/etc/MANPATH so the manual page for print_manifest can be found even if Ignite-UX is not
installed.
• Now the /etc/hosts file needs to be handled. The following steps are done to perform this:
1. The /etc/hosts file is unlinked. This was a temporary hosts file created for the duration of the
install or recovery session. Any previous /etc/hosts file from a recovery archive or golden
image install was saved aside early during the installation or recovery session.
2. If there was no saved merged file to put back into place then /usr/newconfig/etc/hosts is
copied to /etc/hosts instead (otherwise the saved merged file is moved back into place).
3. If is_net_info_temporary is false the networking information to be written into /etc/hosts is
based on the merged information. If is_net_info_temporary is true and there is final
information then the information to be written into the hosts file is based only upon the final
configuration.
4. The hosts file is upated (note that not all entries may be updated if there are multiple lan
interfaces on the system listed in /etc/hosts) so the default lan interface has it’s IP address and
hostname added into the hosts file.
We need to handle instance numbers again. The same code that handled instance numbers in phase2
handles them in phase 3 as well. There shouldn’t be as many instance requests in phase3 because most of
them should have already been handled in phase2. The most likely reason for instance requests being
performed here is hardware that was not claimed when running the install kernel.
• At the start we need to work out what all of the devices are on the system along with their current
and new instance numbers. The new instance numbers come from the hw_instance_num
configuration items in the configuration associated with the recovery session (it’s unlikely that
there will be any of these in a cold install environment).
• A list of unique classes is worked out from the list of instances including if they actually need to
be preserved.
The command used to perform instance reassignments in the following section is "/sbin/ioinit -f
/tmp/ioinit.in". The program writes out the instance assignments for the one class to the file /tmp/ioinit.in
and then runs the command once for each device class.
• When going through a class to setup the file to reassign instance numbers the following issues
preclude an instance reassignment from occuring:
1. A class of “unknown” or an instance number of -1
2. There is no hardware for the device currently on the system
3. The device is currently not claimed (handled earlier)
4. Devices that exist but the device class doesn’t match the information in the configuration
5. The instance number already is correct
6. The driver in the kernel says that the configuration should not be saved for the devices it
controls.
Note: the last point above is really important. Not all instance numbers should be preserved. Drivers that
indicate their devices should not have instance numbers saved into the ioconfig files will not have
preserved instance numbers. This behaviour is new at Ignite-UX version C.7.7.
• If the device passes the above tests then the information required to reassign the instance numbers
is written to /tmp/ioinit.in (for the format of the file see the manual page ioinit(1m)).

• The command "/sbin/ioinit -f /tmp/ioinit.in" is now run (as noted above this happens once for each
class discovered).
• The last /tmp/ioinit.in file is now removed.
Now we’re going to run all of the post_configure scripts. The following message is printed first:
* Run all specified post-configure scripts.
• All iux_postconfig scripts that are in /tmp/ign_configure/iux_postconfig_list are executed.
• All of the per sw_source and per sw_sel post_config command and script hooks are executed (the
per sw_sel hooks are executed before each per sw_source hooks and command hooks 177 before
script hooks). For a golden image or recovery archive this includes running os_arch_post_c.
• All global post_config command hooks are now executed (command hooks before script hooks).
Important: A recovery session imports volume groups with post_config command hooks, so at this point
(assuming it was successful) volume groups should have been imported.
Complete lab Twenty (see “Lab exercise 20 – cold install and recovery (part 5)”).
Running os_arch_post_c
This is the os_arch_post_l script, it is always executed as part of a recovery session and should be executed
as part of a golden image install (if the configuration file describing the installation session is based on
/opt/ignite/data/examples/core11.cfg and the definition of the script is not removed).
#!/usr/bin/sh
#
# $Header: /svn/ignite/ignite/src/scripts/os_arch_post_c,v 10.35 2006/06/13
22:1
6:11 draper Exp $
#
##
## This file is the post_configure script which runs when an OS
## archive has been loaded onto a system as part of the Ignite-UX process.
## There are 3 classes of steps taken here:
## - In some cases, the archive creation/extraction tools don't do a
## complete job, so we account for that here.
## - Some SD configure scripts make changes based on the hardware of
## the machine. Since the machine where the archive is created may
## have different hardware than the target machine, we need to account
for
## those actions here.

## - Defects which were found too late to fix in the SD ctrl scripts are
## sometimes handled here.
##
## WARNING: If you need to modify this file, you should copy this file to
## /var/opt/ignite/scripts and modify that copy. You will
## then need to change any config files that reference this
177
This terminology may be slightly confusing both *cmd and *script hooks are called command hooks on
the instl_adm(4) manual page but in this context it means that post_config_cmd hooks are executed before
post_config_script hooks.

## file to reference the modified copy. Otherwise the

## version of this file in /opt/ignite/scripts will get
## overwritten the next time Ignite-UX is updated and any
## changes would be lost.
##

ARCHIVE_SAVE_DIR="/tmp/ign_configure/os/archive_save"
ARCHIVE_SAVE_FILE="/tmp/ign_configure/os/archive_save/ig_save_file"
INSTALL_VARS_FILE=/tmp/install.vars
RECOVERY_MODE=FALSE
umask g-w,o-w
This is the chmog function it is used to change permissions and ownership of a file.
###############################################################################
#
# Function: chmog()
#
# Purpose: Change mode, owner and group on the specified file(s)
# If mode is 0, the mode is left unchanged
# If any value is the null string, that value is not changed.
chmog ()
{
if [[ $# -lt 4 ]]; then
echo "Usage: chmog mode owner group files..." >&2
return 1
fi
typeset mode="$1"
typeset owner="$2"
typeset group="$3"
typeset -i cmd_result=0
shift 3
if [[ -n "$group" ]]
then
chgrp $group $* || cmd_result=1
fi
if [[ -n "$owner" ]]
then
chown $owner $* || cmd_result=1
fi
if [[ -n "$mode" && "$mode" != 0 ]]

then
chmod $mode $* || cmd_result=1
fi
return $cmd_result
} # end of chmog()
This is the restore_files function it's an important function since it puts back into place all of the files saved
by os_arch_post_l by reading the contents of the file /tmp/ign_configure/os/archive_save/ig_save_file and
moving the files listed within back into place (from the directory /tmp/ign_configure/os/archive_save).

###############################################################################
#
# Function: restore_files
#
# Purpose: Restore all files that were previously saved by save_file() in
# os_arch_post_l.
#
restore_files()
{
if [[ ! -f $ARCHIVE_SAVE_FILE ]]; then
return
fi
while read target; do

source="$ARCHIVE_SAVE_DIR$target"
if [[ -f $source ]]; then
else
echo "WARNING: Could not restore $target: file not found"
fi
done < $ARCHIVE_SAVE_FILE
} # end of restore_files()
This function is required because when Ignite-UX is manipulating device files (as the comments say)
/dev/lan ends up as a device files but on the final system it needs to end up as a symbolic link to /dev/dlpi
so it makes that change.
###############################################################################
#
# Function: fix_dev_lan_link
#
# Purpose: The device file /dev/lan exists as a character device file in
# the RAMFS but needs to end up as a symlink to /dev/dlpi on the
# final system.
#
#
fix_dev_lan_link()
{
##
## Handle /dev/lan symlink
##
if [[ -c /dev/lan ]] ; then
rm -f /dev/lan
ln -s /dev/dlpi /dev/lan
fi
The comments on this function don't make that much sense, pax is always used by Ignite-UX to extract
archives. However since it is always run it makes sure that the device files that should be hard links are
always changed to make sure that they correctly hard linked together.
###############################################################################
#
# Function: fix_dev_file_links
#
# Purpose: When the archive contains device files which are links to
# other device files, some of the archive/extraction tools
# do not put the link back as a link. This routine fixes a

# bunch of the known offenders.

#
# This routine should not be needed if:
# - device files are not included in the archive -or-
# - the archive was created by pax
#
fix_dev_file_links()
{
##
## Handle the ptys.
##
find /dev/pty /dev/ptym -type c |
while read dev
do
if [[ -c /dev/${dev##*/} ]] ; then
# The same file exists both places. Link them.
rm -f /dev/${dev##*/}
ln $dev /dev/${dev##*/}
fi
done
##
## Handle the audio device files.
##
for audio_file in /dev/audi*[a-zA-Z] ; do
if [[ -c ${audio_file}_0 ]] ; then
rm -f ${audio_file}_0
ln ${audio_file} ${audio_file}_0
fi
done
##
## Handle the crt files.
##
if [[ "$ARCH" = "700" ]] ; then
if [[ -c /dev/crt ]] ; then
rm -f /dev/crt0
ln /dev/crt /dev/crt0
fi
if [[ -c /dev/ocrt ]] ; then
rm -f /dev/ocrt0
ln /dev/ocrt /dev/ocrt0
fi
fi
##
## Handle the hil files.
##
if [[ "$ARCH" = "700" ]] ; then
for i in 1 2 3 4 5 6 7 ; do
if [[ -c /dev/hil${i} ]] ; then
rm -f /dev/hil_0.${i}
ln /dev/hil${i} /dev/hil_0.${i}
fi
done
if [[ -c /dev/hilkbd ]] ; then
rm -f /dev/hilkbd_0
ln /dev/hilkbd /dev/hilkbd_0
fi
if [[ -c /dev/rhil ]] ; then
rm -f /dev/rhil_0

ln /dev/rhil /dev/rhil_0
fi
fi
} # end of fix_dev_file_links()
This is just a helper function for creating device files that do not exist (but should). As you can see if they
already exist nothing is done by the function.
###############################################################################
#
# Function: add_devfile
#
# Purpose: Construct a device file. Often used when a configure script
# builds a device file. Since devfiles are normally not in the
# archive, they must be built here. If the file already exists,
# we do not re-create it.
#
# Parms:
# $1 the devfile name, e.g. /dev/netman
# $2 the type of devfile ("c" or "b")
# $3 the major number
# $4 the minor number
# $5 the chmod value
# $6 the owner id
# $7 the group id
#
add_devfile()
{
if [[ ! -c $1 ]]; then
mknod $1 $2 $3 $4
fi
chmod $5 $1
chown $6:$7 $1
} # end of add_devfile()
This function sets up VUE/CDE Xserver configurations as required. This ensures that when cloning or cold
installing from a golden image that the X server (if the system has a graphics card) is correctly setup.
###############################################################################
#
# Function: set_up_Xservers
#
# Purpose: This routine fixes the Xservers file(s) based on the hardware.
# It is necessary because the archive is created on one
# particular machine and the configure script sets up this
# file with that machine's hardware in mind. To load the archive
# onto a different machine with a different graphics top,
# we need to do some cleanup here.
#
# Example Xserver entry (the leading # comments it out):
# * Local local@console /usr/bin/X11/X :0
#
set_up_Xservers()
{
VUECONFIG=/etc/vue/config
XSERVERTMP=/tmp/Xservers.tmp

if [[ -f $VUECONFIG/Xservers ]]; then

if [[ -z $(ioscan -kC graphics) ]]; then
sed 's/$^[ ]*\*[ ]*Local$/#\1/' $VUECONFIG/Xservers \
> $XSERVERTMP
else
sed 's/^[ ]*#$[ ]*\*[ ]*Local.*$$/\1/' $VUECONFIG/Xservers \
> $XSERVERTMP
fi
cp $XSERVERTMP $VUECONFIG/Xservers
rm -f $XSERVERTMP
fi
XSERVERS=/etc/dt/config/Xservers
if [[ -f $XSERVERS ]]; then

if [[ -z $(ioscan -kC graphics) ]]; then
sed 's/$^[ ]*\*[ ]*Local$/#\1/' $XSERVERS \
> $XSERVERTMP
else
sed 's/^[ ]*#$[ ]*\*[ ]*Local.*$$/\1/' $XSERVERS \
> $XSERVERTMP
fi
cp $XSERVERTMP $XSERVERS
rm -f $XSERVERTMP
fi
} # end of set_up_Xservers()
If the system has audio hardware then we make sure that the audio server is started. If it doesn't have audio
hardware we turn off the audio server as it's not required.
###############################################################################
#
# Function: set_up_audio
#
# Purpose: The AudioSubsystem.AUDIO-SRV configure script sets up the
# /etc/rc.config.d/audio file according to what audio hardware is
# available on the system where the archive was created. Since
the
# target machine may differ from the archive source machine, we

# need to set this up again here.
#
# This routine does not need to be run if all target machines
# have the same audio capabilities as the machine where the
# archive was created.
#
set_up_audio()
{
if [[ -f /etc/rc.config.d/audio ]]; then

if [[ -c /dev/audio ]]; then
ch_rc -a -p AUDIO_SERVER=1 /etc/rc.config.d/audio
else
ch_rc -a -p AUDIO_SERVER=0 /etc/rc.config.d/audio
fi
fi
} # end of set_up_audio()

This function creates any of /var/adm/wtmp, /var/adm/btmp, or /etc/shutdownlog if they don't exist and sets
their permissions and ownership correctly.
###############################################################################
#
# Function: wtmp_btmp_setup
#
# Purpose: The OS-Core.UX-CORE configure script sets up the
# /var/adm/wtmp and /var/adm/btmp files to track login activity.
# Since these files contain system specific information they
# are not put in the archive, but they need to be in place for
# commands like last, and who to work correctly.
#
wtmp_btmp_setup()
{
[ ! -f /var/adm/wtmp ] && > /var/adm/wtmp

chmog 664 adm adm /var/adm/wtmp
[ ! -f /var/adm/btmp ] && > /var/adm/btmp

chmog 600 root other /var/adm/btmp
[ ! -f /etc/shutdownlog ] && > /etc/shutdownlog

chmog 644 bin bin /etc/shutdownlog
} # end of wtmp_btmp_setup()
This function adds the ups_mond daemon into initttab (note however that it is not enabled). This inittab line
has pretty much always been present in HP-UX. Note that this daemon is only applicable to HP PowerTrust
UPS systems and does not work with other UPS types (including more recent HP UPS products which
require a different software product to monitor them).
###############################################################################
#
# Function: add_ups_line
#
#
# Purpose: Fix a hole for UPS. If a Core archive install (vs.a
# Core depot install) is done, the OS-Core.UPS-TOOLS
# configure script (along with all other Core SD control
# scripts, of course) is not run. This configure script
# adds a commented-out ups line that the user might later
# need. The following code duplicates that action, but
# only if there is no commented-out or active ups line
# present.
#
add_ups_line()
{
if [[ $ARCH = 800 && -r /etc/inittab ]]; then

grep -q -e '^ *#* *ups::respawn' /etc/inittab ||
echo '#ups::respawn:rtprio 0 /usr/lbin/ups_mond -f /etc/ups_conf' \
>> /etc/inittab
fi
} # end of add_ups_line()
We need to make sure that the VxVM startup lines in /etc/inittab are present in case VxVM is being used.

###############################################################################
#
# Function: add_vxvm_lines
#
#
# Purpose: If an OS-archive has been used, and if VxVM startup
# scripts are found on the system but are not in
# /etc/inittab, then restore them. The lines in
# /etc/inittab might not be there due to /etc/inittab
# being reset to its newconfig state by older versions of
# make_sys_image. If a customer gets Revision 10.263 or
# later of make_sys_image (which will not reset
# /etc/inittab) and re-creates their image, then this will
# effectively become a no-op. If they do not re-create
# their image but do update Ignite-UX with this new
# version, then this change will fix /etc/inittab up for
# them.
#
add_vxvm_lines()
{
# Handle VxVM 3.5 cases. Note releases earlier than 11.11 will not
# have these commands so this will have no effect for them.
if [[ -x /sbin/init.d/vxvm-sysboot ]] ; then
grep -q "^vol1::sysinit:/sbin/init.d/vxvm-sysboot" /etc/inittab
if [[ $? != 0 ]] ; then
# VxVM startup line is missing. Add it back in.
sed -e '/^brc1:/ i\
vol1::sysinit:/sbin/init.d/vxvm-sysboot </dev/console >/dev/console 2>&1 ##vxvm
' < /etc/inittab > /tmp/it.$$
mv /tmp/it.$$ /etc/inittab
chmog 444 bin bin /etc/inittab
fi
fi
if [[ -x /sbin/init.d/vxvm-startup ]] ; then
grep -q "^vol2::sysinit:/sbin/init.d/vxvm-startup" /etc/inittab
if [[ $? != 0 ]] ; then
# VxVM startup line is missing. Add it back in.
sed -e '/^brc1:/ i\
vol2::sysinit:/sbin/init.d/vxvm-startup start </dev/console >/dev/console 2>&1
#
#vxvm
' < /etc/inittab > /tmp/it.$$
mv /tmp/it.$$ /etc/inittab
chmog 444 bin bin /etc/inittab
fi
fi
} # end of add_vxvm_lines()
This function recreates any missing lost+found directories under /var/adm which are likely to be missing
after an OS archive load.
###############################################################################
#
# Function: fix_var_adm_lostfound
#
# Purpose: Any mount points at or under /var/adm will lose their
# lost+found directory since that is blown away prior
# to loading the OS archive. This function restores those
# directories using the mklost+found command if they are
# indeed missing. JAGaf78257 fix.

#
#
fix_var_adm_lostfound()
{
[[ -x /usr/sbin/mklost+found ]] || return
pdir=$(pwd)
mount -l | grep ^/var/adm | awk ' { print $1 } ' |
while read varadmdir
do
cd ${varadmdir}
[[ -d lost+found ]] || /usr/sbin/mklost+found >/dev/null
done
cd ${pdir}
}
# MAIN
#
# Manipulate which of the actions take place by commenting or
uncommenting
# the various routines below.
# Check for usage request first, before doing anything dangerous:
if [ "x$1" = 'x-?' ]
then
print -u2 "\nUsage: $0 # ignores arguments.
\nWarning: This is an Ignite-UX internal tool that can be
destructive when run in the wrong context.
This file is the post_configure script which runs when an OS

archive has been loaded onto a system as part of the Ignite-UX process.
There are 3 classes of steps taken here:
- In some cases, the archive creation/extraction tools don't do a
complete job, so we account for that here.
- Some SD configure scripts make changes based on the hardware of
the machine. Since the machine where the archive is created may
have different hardware than the target machine, we need to account
for those actions here.
- Defects which were found too late to fix in the SD ctrl scripts are
sometimes handled here.
"
exit 1
fi
# Grab the release and architecture since some of the actions

# are only necessary in certain circumstances.
#
arch_type=$(uname -m | cut -f2 -d"/")
case $arch_type in
7*) ARCH=700
;;
8*) ARCH=800
;;
esac
release=$(uname -r)
#
# Source the install.vars file so we know if this is recovery mode or not.
#

if [[ -f $INSTALL_VARS_FILE ]]; then

. $INSTALL_VARS_FILE
else
echo "Could not source $INSTALL_VARS_FILE: will assume recovery_mode is
false"
fi
In recovery mode only a subset of the functionality in the script is used:
#
# Handle the recovery mode case. Note that recovery_mode is FALSE by default.
#
if [[ "$RECOVERY_MODE" = "TRUE" ]]; then
echo " * Running in recovery mode (os_arch_post_c)."
fix_dev_lan_link
# fix_dev_file_links
# add_devfile /dev/nettrace c 46 0x000000 0644 2 2
# add_devfile /dev/netlog c 46 0x000001 0644 2 2
# add_devfile /dev/netman c 60 0x000000 0666 0 1
# add_devfile /dev/ni c 56 0x000000 0666 0 1
# add_devfile /dev/inet_cots c 72 0x00007a 0666 0 1
# add_devfile /dev/inet_clts c 72 0x00007e 0666 0 1
# set_up_Xservers
# set_up_audio
fix_var_adm_lostfound
restore_files
rm -rf $ARCHIVE_SAVE_DIR
if [ ! -d /var/sam ] ; then
# If we restored a minimal archive of a system, then
# sam needs a few dirs created in /var (which is not in
# the mnr_essential list). Users may need to use sam to
# recover files from backup, etc once the system is up.
mkdir -p /var/sam/log
mkdir -p /var/sam/lock
chown bin:bin /var/sam
chown bin:bin /var/sam/log
chown bin:bin /var/sam/lock
chmod 555 /var/sam
chmod 777 /var/sam/lock
chmod 555 /var/sam/log
fi
return 0
fi
At this point when in recovery mode the script will have already returned and configure3 will be running
again. Outside of recovery mode during a golden image install the following is done to fix up any issues
with the system:
#
# Clean up device file links if the archive has this problem.
# - commented out because most archives do not contain these devfiles
#
#fix_dev_file_links
fix_dev_lan_link
#
# Add some networking device files. Not needed if they are included in the
# archive.
#
add_devfile /dev/nettrace c 46 0x000000 0644 2 2
add_devfile /dev/netlog c 46 0x000001 0644 2 2

This code isn't strictly needed any more (within the test for HP-UX 10.x) as
Ignite-UX no longer supports any HP-UX 10.x release.
if [[ $release = B.10* ]]; then

add_devfile /dev/netman c 60 0x000000 0666 0 1
add_devfile /dev/ni c 56 0x000000 0666 0 1
add_devfile /dev/inet_cots c 72 0x00007a 0666 0 1
add_devfile /dev/inet_clts c 72 0x00007e 0666 0 1
else
ln -s /dev/tcp /dev/inet_cots 2>/dev/null
ln -s /dev/udp /dev/inet_clts 2>/dev/null
ln -s /dev/dlpi /dev/snap 2>/dev/null
ln -s /dev/dlpi /dev/lan 2>/dev/null
fi
#
# Set up the Xservers files for this hardware.
#
set_up_Xservers
#
# Make sure the audio server is set up right for this hardware.
#
set_up_audio
#
# Touch and set permissions on wtmp and btmp so that login activity is
# tracked. In an SD load this would be done by a CORE configure script.
#
wtmp_btmp_setup
#
# Fix a minor UPS hole for 800 hardware. Again, normally done by a Core
# configure script.
#
add_ups_line
#
# Restore any missing /etc/inittab lines used by VxVM that might be
# removed by make_sys_image.
#
add_vxvm_lines
#
# Make a couple of directories made by CORE configure scripts in 11.00.
#
if [[ $release = B.11* ]]; then
mkdir /dev/screen 2>/dev/null && # OS-Core.UX-CORE

chmod 0777 /dev/screen && chown bin:bin /dev/screen
mkdir /dev/telnet 2>/dev/null && # InternetSrvcs.INETSVCS-DTC

chmod 0555 /dev/telnet && chown bin:bin /dev/telnet
fi
#
# Put back lost+found directories under /var/adm
#
fix_var_adm_lostfound

#
# Restore any files saved in os_arch_post_l.
#
restore_files
#
# Remove the temporary save dir.
#
rm -rf $ARCHIVE_SAVE_DIR
#
# Exit cleanly.
#
return 0
Running configure3 – winding down
• The /tmp/install.vars file is written to disk. In phase 3 this file contains environment variables and
user variables 178 from the Ignite-UX configuration, and a small amount of other information.
• If the tlinstall program is present it is executed with the –f option telling it to fix up any transition
links. This does not apply to HP-UX B.11.31 which does not provide this command. It is possible
for Ignite-UX to mount filesystems from volume groups that were recently imported to allow
tlinstall to process all of the transition links. For example /opt may not be in the root volume group.
The following steps only happen on HP9000 systems:
• If the file /usr/lib/ignite_bootlif exists we need to restore some LIF files. If it doesn’t exist there is
nothing to do (skip forwards to where the steps start to apply to both architectures again).
• The following commands are used (the command differs depending on if we are using a volume
manager or not):
Table 32 - mkboot commands used to recover LIF files

Volume Manager mkboot command
LVM/VxVM mkboot –b /usr/lib/ignite_bootlif –p <file> … <device>
Whole disk mkboot –b /usr/lib/ignite_bootlif –W –u -p <file> … <device>
Where <file> is a LIF file to be preserved. A list of LIF files on the boot device is determined
using lifls. The lif entries to be preserved are added to the command; this allows multiple –p
options to be generated. The … in the above command indicates that there can be more than one –
p option. Note that AUTO file will be preserved if it is currently set to something other than the
default of “hpux”, otherwise the AUTO file from /usr/lib/ignite_bootlif will be restored by the
mkboot command.
From here the steps apply to both architectures:
• Now we need to handle the Kernel Registry Service (KRS). Nothing is done here on HP-UX
B.11.11 since there is no KRS. Handling the KRS is done by performing the following steps:
1. The KRS is started.
178
Most variables in the configuration that start with an underscore (“_”).

2. The directory /stand/krs is checked to ensure it exists, if it doesn’t the routine returns and
nothing further is done with the KRS. If it does not exist you can tell by the following
message being printed:
WARNING: Ignite-UX krs_registry_save directory does not exist: /stand/krs
3. The directory /stand/current/krs is checked to ensure it exists, if it doesn’t the routine returns
and nothing further is done with the KRS. If it does not exist you can tell by the following
message being printed:
WARNING: Ignite-UX krs_registry_save directory does not exist:

/stand/current/krs
Both of these directories should have been created (or recovered) in an earlier phase.
• The program krsd is called with the -1 (the number one) option to have it save the KRS to disk.
• In debug mode the contents of the KRS are printed (both the active and saved registries – however
at this point since the KRS was just saved to disk they should be the same). The contents of the
KRS will only be printed at debug level 4.
• At this point if we gained an IP address via DHCP we need to decide if we are going to release the
lease or not.
The lease is not released if we don’t have any final networking information and the value of
is_net_info_temporary is false (i.e. we need to save the networking information) or if the final
information and the current information are the same. If we don’t release the DHCP lease we
enable DHCP on the interface with index 0 in /etc/rc.config.d/netconf.
Else if we’re going to release the lease and is_net_info_temporary is true we release the lease and
do nothing more. If is_net_info_temporary is false we release the lease and disable DHCP on the
interface at index 0 in netconf.
Else if we were not using DHCP in the install and is_net_info_temporary is true and there is final
information we disable DHCP on the interface at index 0 in netconf.
Finally if disable_dhcp was set to true in the configuration we disable DHCP on the interface at
index 0 in netconf unconditionally (even if we used DHCP during the install 179).
At this point we need to do some final clean and moving around of files.
• The file /etc/nsswitch.conf is removed if it exists. If the file /etc/nsswitch.final exists it is moved
into place as /etc/nsswitch.conf.
• If the file /etc/rc.config.d/netconf.final exists it is moved into place as /etc/rc.config.d/netconf.
For the two files above the “final” files can only exist during the load of a recovery archive (this is not done
when loading a golden image Ignite-UX must be in recovery mode). In a default Ignite setup only
/etc/nsswitch.final will exist. The files are created by the os_arch_post_l script when the save_file function
is called with the file name, by default only the /etc/nsswitch.conf file is handled this way and
/etc/rc.config.d/netconf is handled using merge_file.
179
This assumes that disable_dhcp was set to true and used in the configuration read from the Ignite server
if it was given in the install filesystem it would have stopped the installing system from using DHCP at all.

If you were to change the os_arch_post_l script to call save_file for netconf it would save it as
/etc/rc.config.d/netconf.final and it would be moved back into place at this time.
Important: Note that doing this prevents Ignite-UX from changing /etc/rc.config.d/netconf, this is likely to
cause issues if you use a recovery archive for cloning a system as the system will not take up any changes
that need to be made to /etc/rc.config.d/netconf.
• Both /envs.cfg.p3 and /d_cfg_mnt_sb61 are removed.
• If we have an NFS client directory then the SIGALRM handler is removed. This stops instruction
checks from the server (so from this point we no longer listen for reboot or halt requests from the
Ignite server).
• If the directory /opt/swm.iux exists it is removed. The directory should only exist on HP-UX
B.11.31 as swm was introduced with that HP-UX release.
• If the directory /var/opt/ignite/local exists it is removed. It is also immediately recreated. If

recreating the directory fails the following message is printed
WARNING: Could not make directory "/var/opt/ignite/local “: <error>
Where <error> is a text string detailing the current value of errno (from the function strerror(3)).
The install.log file is closed and we’ve almost done.
If the creation of /var/opt/ignite/local succeeded the follow steps are performed:

1. The file “config” is copied from the client directory to /var/opt/ignite/local.
2. The file “hw.info” is copied from the client directory to /var/opt/ignite/local.
3. The file “io.info” is copied from the client directory to /var/opt/ignite/local.
4. The file “host.info” is copied from the client directory to /var/opt/ignite/local.
5. The directory “manifest” (and it’s contents) are copied from the client directory to
/var/opt/ignite/local.
6. The install.log file is closed and copied to /var/opt/ignite/local.
7. If we had a NFS client directory it is now unmounted 180.
8. If we didn’t have an NFS mount client directory we remove the client directory (as we’ve
saved all of the important information from it just before). Note that this isn’t done if the
client directory contains a CINDEX file or a recovery directory.
Important: Note that in step 6 above the install.log file has been closed. There are still some steps
to be completed however since the log file has been closed they will not appear in the log file any
issues will only be printed to the console.
• All of the final command hooks are executed (final_cmd and final_script). The execution order
happens as for other command hooks. For each sw_source any final command hooks assocated
with a sw_sel are executed first and then the sw_source final hooks. Lastly any global final hooks
are executed.
• We need to handle the situation where Ignite-UX did not create the /var filesystem or did not
create some of the filesystems under /var. The directories we are interested in are
/var/opt/ignite/local, /var/opt/ignite, /var/opt, /var/adm, and /var.
180
Note the issue here, if we had a DHCP lease for networking and assuming we released it a short time
ago (and we’re going to keep using it) we’re still performing actions that require networking to be active.
There exists a small chance that the lease will be given out to someone else and cause problems with a
network based recovery or installation session. This issue has been reported to the Ignite lab and should be
addressed in a future release of Ignite-UX.

If Ignite-UX created any of those directories as a mount point then it is ignored, otherwise
/etc/fstab is read to determine if they exist somewhere else (e.g. on an imported volume group). If
there is a directory found that fits this description the following message will be printed for the
filesystem:
* Mounting dir: "<dir>" in order to copy files created by Ignite-UX to

it.
Where <dir> is the mount point of the filesystem.
When this happens the directories created by Ignite-UX are renamed (and a new directory with the
original name to mount the filesystem on created) and the volume mounted (performing whatever
volume management tasks are required first). If mounting the filesystem fails the following
warning message will be printed:
WARNING: Failed to mount dir: <dir>, cannot copy newer files created during
install to it. See files in <olddir>
Where <olddir> is the name of the directory that Ignite-UX renamed the directory it created to (as
an example if /var/adm is the mount point being complained about then the directory created by
Ignite-UX will be /var/adm_iux).
For /var and /var/adm the following action is performed for the sbtab file, if we have a new sbtab
file and an already existing sbtab file the already existing file is moved to sbtab.old
(/var/adm/sbtab holds information about the locations of HFS superblocks).
For all filesystems (including /var and /var/adm) all of the files under the temporary directory are
copied to their final places in the newly mounted filesystems. After the copy completes the
filesystem is unmounted.
• Everything under and including /tmp/ign_configure is removed.
• The system is rebooted. At this point Ignite-UX has completed its tasks and the system should
have been installed or recovered.

The new 11.31 I/O stack, HPVM, and vPars

This section contains information on a few issues that are not large enough to have their own section in this
course.
The new 11.31 I/O stack

There aren’t really any differences that you need to be aware of when using Ignite-UX on 11.31. Ignite-UX
attempts to hide the differences between releases and the I/O stack there were really only two changes that
you should be aware of:
1. Ignite-UX does not support legacy device files when cold installing or recovering HP-UX B.11.31
systems. You can create recovery archives with systems that contain legacy device files in use
however anything recreated by Ignite-UX during a recovery (or created new in a cold install) will
automatically use agile DSFs. There is no way to change this and it is the expected behaviour
of Ignite-UX on HP-UX B.11.31.
2. This isn’t really related to HP-UX B.11.31, because of the changes to support HP-UX B.11.31 it
became possible to extend some of the functionality from the B.11.31 changes back to HP-UX
B.11.11 and B.11.23. Now when installing or recovering a system you get the added features of
selecting one path to a disk and having it automatically extend in all alternate links to the disk (up
to 8) and not double counting the disk space when a configuration specifies multiple paths to the
same disk.
HPVM and Ignite-UX

With HPVM guests apart from how they are managed they should operate the same with Ignite-UX as a
normal non-virtual system. The only issue with HPVM 3.5 that you should be aware of is that dbprofiles do
not work. They will work in HPVM 4.0.
It is possible that there may be subtle issues with HPVM versus other HP systems. The base HPVM EFI
firmware was taken from an Intel code drop instead of being from an existing HP Integrity server. There
have been a few small differences in the way things work because of this. They are mainly related to the
way network booting occurs (typically any tftpd server used must support the file size option otherwise the
HPVM guest may not boot) 181.
vPars and Ignite-UX

With vPars there also is very little difference that you need to be aware of apart from:
1. Ensuring that you install the required software during a cold install
2. On HP Integrity servers since you cannot access the EFI prompt you cannot use dbprofiles with
vPars even if the system supports them (you must use PXE booting if you want to network boot
the system).
3. You should read the white paper “Ignite-UX Installation Booting” available from
http://www.docs.hp.com/en/IUX/infolib.html for additional information about vPars on HP9000
systems boot. It is important to understand the issues involved with vPars on HP9000 systems
especially that they cannot network boot.
Complete lab TwentyOne (see “Lab exercise 21 – cold install and recovery (part 6)”).
181
HP-UX B.11.23 and B.11.31 support this option by default (as does HP-UX B.11.11 with patches).

Appendix A
This appendix contains a procedure that is not documented elsewhere but is referenced in this course.
Combining two OE DVDs into one for use with HPVM

The following instructions are intended for use with HPVM. They give details on how to take an OE depot
and create an ISO image capable of installing a system without having to change DVD media. It is possible
that this image could be burnt onto a DVD DL disk and used to install a system but this has never been
tested.
This procedure assumes that you have a lot of free space located until /var/tmp (at least 12GB).
# cd /var/tmp
# mkdir build
# cd build
# mkdir dvd
# make_depots -s /var/opt/ignite/depots/Rel_B.11.31/0709_MCOE -d
/var/tmp/build/dvd
If you did this step from the OE media instead of from a pre-existing depot you'd need to run it twice to
completely copy the OE depot from the media to the build area.
# cp /opt/ignite/boot/Rel_B.11.31/EFI_CD_image /var/tmp/build/dvd/my_image
# make_config -s /var/tmp/build/dvd -c /var/tmp/build/DVD.config
Change the sw_source in /var/tmp/build/DVD.config to look like (instead of being "NET" etc):
sw_source "core" {
description = "HP-UX Core Software"
source_format = SD
source_type = "DSK"
load_order = 0
}
If the file /var/tmp/build/DVD.config contains entries like:
(release <= "B.11.23") {

sw_category = "OrderedApps"
} else {
sw_category = "Internet"
sw_category += "-OE- Recommended"
}
You will need to change them to be (this example creates 11i v3 media if you are creating media for 11i v2
(or earlier releases of HP-UX) you will need to change what is preserved):
sw_category = "Internet"
sw_category += "-OE- Recommended"
The reason for this change is that using Ignite-UX version C.7.3 make_medialif complains about the test on
the release keyword against B.11.23. This defect in make_medialif has been reported in QXCR1000831560
and should be addressed in Ignite-UX version C.7.8.
The following commands are then run to produce the ISO image.

# make_medialif -f /opt/ignite/data/Rel_B.11.31/config -f
/opt/ignite/data/Rel_B.11.31/hw_patches_cfg -f /var/tmp/build/DVD.config -r
B.11.31 -aR -l /var/tmp/build/dvd/mylif
# /opt/ignite/lbin/mkisofs –R -D -U -v -max-iso9660-filename -no-emul-boot -b
my_image -hide dvd/EFI_CD_image -eltorito-alt-boot -no-emul-boot -b dvd/mylif -
hide mylif -o 0709.DVD.11.31 dvd
# /opt/ignite/lbin/instl_combine -C /var/tmp/build/0709.DVD.11.31
# mv 0709.DVD.11.31 /var/dvd
The /var/dvd directory was used in this example as a file based backing store for a virtual DVD drive on the
HPVM host system. This is so the HPVM guests can mount the image. The image created was able to
successfully install a system.
# cd /var/dvd
# ll 0709.DVD.11.31
-rw-r--r-- 1 root sys 5240729600 Feb 5 13:42 0709.DVD.11.31
This procedure has one advantage over using two separate DVD images (like regular OE media) you do not
have to change the media part way through an install. If required it also allows you to change the
configuration used in the OE media.
Important: When using the –hide option care should be taken with the file name you give to the option. If
you use an option like “-hide EFI_CD_image” it will hide every occurrence of the file name
EFI_CD_image. This is not a good thing for an image containing Ignite-UX since it will hide the file in the
depot and cause swinstall errors if you attempt to install Ignite from it. Instead ensure that you use a name
like “dvd/EFI_CD_image” (where in this case “dvd” is the top level root directory of the media you are
creating) or change the name completely to one that does not exist elsewhere on the media, for example
my_EFI_CD_image.
The –hide option is used in the above example with the mkisofs command so that the extra files do not
appear in the root directory of the ISO image. The hide option does not place the files into any directory
structure although their data does appear in the image – this is important because otherwise the media
wouldn’t be bootable. The files are actually accessed via the El Torito boot information. The
EFI_CD_image file used access this way via EFI on an Itanium system and the LIF directory rewritten in
the start of the ISO image to point into the LIF file contained within the ISO image.
There is one final issue that you may wish to do something about when creating the DVD image. The
configuration from the install filesystem will be left in tact in the DVD image unless you change it or
remove it. For example in the above DVD image the following configuration exists:
# instl_adm -F 0709.DVD.11.31
server="16.144.207.33"
netmask[]="255.255.254.0"
route_gateway[0]="16.144.206.1"
If you create an image and move it to a new server on a different network the networking information will
be applied to the final system you install. At an appropriate time you should change it182 if you do not wish
the configuration that exists in there to stay:
182
The instl_adm command can operate on an ISO image because it contains a LIF at the front that the
command uses to locate the install filesystems. It does not know about (or care about) the fact that the LIF
is actually located within an ISO9660 filesystem.

# instl_adm -F 0709.DVD.11.31 > installfs.cfg

# vi installfs.cfg
... (edit the file to remove the networking information)
# instl_adm -F 0709.DVD.11.31 -f installfs.cfg
# instl_adm -d -F 0709.DVD.11.31
Alternatively if you will also use the full DVD image at times to boot and connect to an Ignite server you
can set the IP address of the Ignite server you wish to contact.
It is also easy to create a minimal DVD image in this way. You simply follow all the same steps but do not
create the depot or the configuration. The make_medialif command would change slightly since you would
need to use the –m option, see the make_medialif(1m) manual page for more information.

Appendix B – ndd parameters used by Ignite-UX

The following ndd parameters can be set by Ignite-UX. The parameters ip_check_subnet_addr and
ip_ire_gw_probe can be set in phase 3 of an Ignite-UX install or recovery session (if the install or recovery
has a network interface active).
ip_check_subnet_addr:
The ifconfig subnet mask default allows all 1s or all 0s

in the masked part of the subnet field.
The subnet field (the portion of an IP address that identifies

the subnet beyond the network portion of the address) can now be
all 0's or all 1's, as described in RFC 1878. For example, a
class A IP address used with the mask 255.192.0.0 (0xffc000000)
has a two-bit subnet field:
subnet field
v
--
11111111 11 000000 00000000 00000000
ifconfig can now assign the following IP address and subnet mask
to an interface, although the subnet field (subnet portion of the
address) is all ones:
IP address: 15.192.1.1
Subnet mask: 255.192.0.0 (0xffc00000)
In binary:
00001111 11 000000 00000001 00000001
11111111 11 000000 00000000 00000000
ifconfig can now also assign the following IP address and subnet
mask to an interface, although the subnet field is all zeroes:
IP address: 15.1.1.1
Subnet mask: 255.192.0.0 (0xffc00000)
In binary:
00001111 00 000001 00000001 00000001
11111111 11 000000 00000000 00000000
To disallow subnet fields with all ones or all zeroes (revert to

RFC 1122 behavior), set ip_check_subnet_addr to 1 in the nddconf
file (/etc/rc.config.d/nddconf).
[0-1] Default: 0
ip_ire_gw_probe:
Enable dead gateway probes. This option should only be disabled on

networks containing gateways which do not respond to ICMP echo
requests (ping).
[0-1] Default: 1 (probe for dead gateways)
Please note that (although not discussed in the text) the ndd option ip_check_subnet_addr may be set to 0
when the I/O listener is started by Ignite-UX during phase 1 of an install or recovery session. This option
does not affect the final installed system.

Appendix C - Course lab exercises

You may not be able to perform some of the following lab exercises. They may rely on equipment that is
not available when this course is being run. You are encouraged to try the lab exercises that cannot be done
in class at work as a learning exercise if you have the equipment available to you to perform them.
Lab exercise preparation – installing a system and setting things

up
If it has not been done already you will need to setup the systems that you will be using to perform all of
the other labs. There is a good chance that all of the systems you will be using are HPVM guests rather than
physical systems.
If you need to create the HPVM guest systems your instructor will provide the details you need to create
them.
Some labs may not be able to done with only HPVM guests your instructor will tell you if there are things
you cannot do.
Lab exercise 1 – pulling a part a recovery tape

The following lab exercise will have you pulling apart and putting back together a recovery tape. To extract
the contents of the tape you will require a large amount of free space.
- If the tape in the tape drive you are using does not contain a recovery tape create one now.
- Extract the contents of the tape. Note that the number of files that will be extracted is different on HP9000
and HP Integrity systems.
1. How many files did you extract from the tape?
2. Did the format of the tape match the definition of the tape format for the architecture of system
that the recovery tape was created on?
3. How can you show the version of Ignite-UX that was used to create the tape?
4. How can you show the configuration associated with the tape?
5. Are the files in the archive written with relative of absolute paths?
6. Explain why the archive is written that way.

The pax command can support automatic detection of the block size used when a recovery archive was
written. We’re going to look at how this is done and see how it allows us to write a program that can
automatically extract the contents of a tape.
When issuing a read to a tape device no matter what the size of the block used to read is the data returned is
the size of the block that was written. That allows us to read a large block and then the read(2) system call
will tell us how much data we actually got back. This allows a program to provide support for multiple
block sizes read from tape.
The following example program partially implements this functionality. There are multiple enhancements
that can be made to the program as at the moment it contains a bare minimum of code to extract the data
from the tape and it assumes it is always fixed length (this is always true for tapes created by
make_tape_recovery).
The program produces a file called file.info which contains a list of files written along with the block sizes
of the files read. The block size is the size of the first block read from a tape file.
# cat readtape.c
#include <stdio.h>
#include <fcntl.h>
#include <limits.h>
#define BLEN 32*1024

static char write_buf[BLEN*4];
/* Compile with +DD64 won't compile as a 32bit program */
main(int argc, char *argv[])

{
int tape_fd, num=1;
FILE *fp, *tfp;
char buffer[BLEN], fname[MAXPATHLEN];
ssize_t len;
/* Make sure that there is at least one argument - no validation is done

to ensure that it is a no rewind tape device. */
if (argc<2) {
fprintf(stderr, "Not enough arguments\n");
exit(1);
}
/* Open the tape drive - needs to be rewound outside of this program */
if ((tape_fd=open(argv[1], O_RDONLY))==-1) {
fprintf(stderr, "Error opening %s\n", argv[1]);
exit(2);
}
/* Create a file to hold the file names extracted from tape along with
the block size of each file. */
if ((fp=fopen("file.info", "w"))==(FILE *)0) {
fprintf(stderr, "could not create file.info\n");
exit(3);
} else {
/* Set to no buffering so as each file is processed we can see the
information being written to the file.info file. */
setbuf(fp, (char *)0);
}
/* Endless loop, we know when we are end of tape however because the first
read of the newly opened tape will return a 0 size read. Not sure if it's
possible for a tape to be written like that normally however it doesn't
happen with Ignite-UX */
while (1) {

if ((len=read(tape_fd, buffer, BLEN))==0) {

printf("end of tape reached\n");
close(tape_fd); fclose(fp); exit(0);
} else {
/* Report an error if the first read from tape returned a value <0 */
if (len<0) {
fprintf(stderr, "Error on first tape read\n");
exit(8);
}
/* Generate the name of the file that we're going to write */
if (snprintf(fname, MAXPATHLEN, "file%i", num++)<=0) {
fprintf(stderr, "Could not produce fname\n");
exit(4);
}
/* Open the output file and set a large output buffer to reduce the number of
write system calls. */
if ((tfp=fopen(fname, "w"))==(FILE *)0) {
fprintf(stderr, "could not open %s\n",
fname); exit(6);
} else {
setvbuf(tfp, write_buf, _IOFBF, BLEN*4);
}
/* Write the name of the file and the block size to the file.info file */
if (fprintf(fp, "%s,%lli\n", fname, len)<=0) {
fprintf(stderr, "Could not write to file.info"
"\n"); exit(5);
}
/* Loop reading the tape and writing to the file until we've finished with
this tape file. The len returned from read will be 0 when we hit the end
of the file on the tape. */
while (len > 0 ) {
if (fwrite(buffer, len, 1, tfp)<=0) {
fprintf(stderr, "Could not write to "
"%s\n", fname); exit(7);
}
if ((len=read(tape_fd, buffer, BLEN))<0) {
fprintf(stderr, "Error on tape read\n");
exit(8);
}
}
/* Close the tape and the output file */
close(tape_fd);
fclose(tfp);
/* Opening the tape drive again takes us along to the next file on the tape. */
if ((tape_fd=open(argv[1], O_RDONLY))==-1) {
fprintf(stderr, "Error opening %s\n", argv[1]);
exit(2);
}
}
}
}
This program is provided “as is” and is not officially supported by HP.
7. Compile and run the readtape program (the program expects a no rewind tape device file as its one
and only argument).
8. Look at the files extracted by the program. Look at a few files and verify that the block size
written to file.info for the file and the size of the file is correct. Also compare the block sizes in
file.info to the expected block sizes for the files.

Hint: for a tape created on a HP Integrity system you will need to look at the ANSI header label
describing the files for the file size and block size information. For a HP9000 recovery tape the
LIF always has a block size of 2048 and the archive will have a block size of 5 or 10KiB.
9. Were all of the files extracted correctly by the program?
Note that the block size of 32KiB was chosen because it is currently the largest block size written to a HP
Integrity recovery tape. The largest block size supported by pax is less than 32KiB (32256 bytes to be
exact).
10. If you are using Ignite-UX version C.7.7 or later use the ansitape command to list and then extract
the contents of the tape. Would this command be very useful in extracting the contents of a tape
and putting them back together again?
Lab exercise 2 – comparing archive types

This lab exercise asks you to compare archive types for different features. The three archive types are pax
(pax interchange format), tar (aka ustar or extended tar interchange format), and cpio (ASCII cpio
interchange format).
1. What archive type supports the largest file size?
2. What archive type supports the smallest range of uid/gid values?
3. What archive type has a limitation on the filename length of a symlink target?
4. What archive type supports ACLs?
5. Which format has a larger default block size?
6. What format does not store the user/group names in side an archive?
7. What format supports files as large as HP-UX does? Why could this be a potential issue if you
were using a different format and then change to this format?

8. Why can’t the limitations inherent in the cpio and tar formats be removed?
9. What format has a limitation on the maximum length of a file name?
10. Bonus question (not covered in the course notes) – do you know why extended tar interchange
format is sometimes called ustar format?
Lab exercise 3 – Looking at an install filesystem

Locate an install filesystem, create a logical volume and then use the dd command to copy the install
filesystem into the logical volume. Please ensure that the logical volume is large enough to hold the install
filesystem.
# ll /opt/ignite/boot/Rel_B.11.31
total 317024
dr-xr-xr-x 2 bin bin 8192 Feb 27 2007 .
dr-xr-xr-x 5 bin bin 8192 May 19 16:36 ..
-r--r--r-- 1 bin bin 5242880 Apr 16 22:18 EFI_CD_image
-r-xr-xr-x 1 bin bin 49341362 Apr 16 22:14 IINSTALL
-r--r--r-- 1 bin bin 61341696 May 19 16:38 IINSTALLFS
-r-xr-xr-x 1 bin bin 13576576 Apr 16 21:52 WINSTALL
-r--r--r-- 1 bin bin 32768000 May 19 16:38 WINSTALLFS
-r--r--r-- 1 bin bin 76 Apr 16 20:52 auto_conf_ia
-r--r--r-- 1 bin bin 94 Apr 16 20:52 auto_conf_pa
# lvcreate -L 64 vg00
# dd if=/opt/ignite/boot/Rel_B.11.31/IINSTALLFS of=/dev/vg00/rlvol11 bs=64k
936+0 records in
936+0 records out
1. What kind of filesystem is the install filesystem that you have just dd'ed into the logical volume?
Hint: Try looking at the manual page for fstyp(1m).
2. Why do you think there is a directory called core in the root directory of the install filesystem?
3. From the root directory of the install filesystem run the following command:
# find .
There are only a relatively small number of files present in the install filesystem, what do most of
them relate to?

4. Run the following commands:
# cd sbin
# ll -i |more
What group of programs has the most hard links? What does that mean? Where does the program
come from (run what on one of the hard linked files)?
5. Run the what command on sbin/system.init, try to explain the what output. If the relevant section
of the course has been completed explain why sbin/init is an Ignite-UX program and the “real” init
exists as sbin/system.init in the install filesystem.
6. Explain the contents of etc/inittab from the install filesystem.
Lab exercise 4 – inventory blocking and the AUTO file

In this section you will create a minimal DVD image and boot a system from it with each question below.
Each question will ask you to perform some kind of change to the AUTO file to customize the media. You
will be using this media with a HPVM guest there is no need to change the AUTO file in the LIF to allow it
to work with HP9000 systems.
In all of these exercises where you need modify the boot loader menu please do not change the default
entries – add new entries.
1. Create a minimal boot DVD image that overrides the setting for the Ignite server to give you a
choice of booting from at least two specific Ignite servers (yours and a different one).
2. Create a minimal boot DVD that blocks SCSI as a protocol (in this case it could be done from the
install filesystem but please do it as a boot loader option). What happens when you reach itool, can
you see any SCSI devices?
3. Create a minimal boot DVD with boot loader menu options that enables these two conditions
(each one separately):
(_noscsi == 1)
{
inventory_block_protocols = { “scsi” }
}
(_nofc == 1)
{
inventory_block_protocols = { “fibre_channel” }
}

4. Enable debug support when booting from one of the above DVD images, what information is
printed by Ignite-UX about boot loader options adding to the configuration? Note that you will
need to connect over the network to an Ignite server to perform this exercise.
5. Create another DVD image based upon one of the above images, this time change the boot loader
option so it contains invalid configuration syntax. What errors do you see when Ignite-UX
attempts to process this configuration?
Lab exercise 5 – File formats and product structure

The lab exercises in this section are relatively easy to answer. They mostly involve reading the relevant
sections of the course notes.
1. What version of Ignite-UX was the first version to drop support for HP-UX B.10.20?
2. What version of Ignite-UX added support for HP9000 systems for HP-UX B.11.23 and what
version of Ignite-UX first added support for HP-UX B.11.31?
3. What version of Ignite-UX changed the name of the main bundle wrapper (containing the full
version of Ignite-UX) and what was the name of the bundle wrapper before and after the change?
4. Why can’t you install the version of Ignite-UX on OE or AR media onto a different version of HP-
UX (different to the HP-UX revision that the OE or AR media was intended for)?
5. What is contained in the IGNT-JPN-E-MAN fileset in the Ignite-UX product?
6. How do you create the recovery commands depot if it does not already exist? If it does already
exist and you have issues with it how do you recreate it?
7. In the recovery commands depot what is the IUX-Recovery bundle for? If you install this onto a
system can you create a recovery tape?
8. Why was the format of the flist file changed with Ignite-UX version C.7.1?

9. The archive content file can include a keyword inc_entire. What is the effect of providing a disk
device as the argument?
10. Run the following list_expander commands, can you explain the resulting output? You will need
to create the files for show to provide the archive_content file argument to list_expander.
inc_all_affected
# /opt/ignite/lbin/list_expander -dv –f archive_content_one

include /var
include /opt
# /opt/ignite/lbin/list_expander -dv –f archive_content_two

inc_cross /
# /opt/ignite/lbin/list_expander -dv –f archive_content_three
11. Inspect the recovery commands command archive (list the contents using tar or pax), what file
present in the archive do you think is most likely to provide the recovery shell menu?
12. Why should you never modify a commands archive that is shipped with Ignite-UX? Given the
close relationship between the commands archives and install kernel/filesystem how do you think
this impacts on dual media recovery?
Lab exercise 6 – network booting a system

Choose one of your systems to be the Ignite server, make sure that Ignite-UX is installed on the system.
1. Setup an entry in /etc/bootptab for your other system.
Please ensure that bootpd is running (look in /etc/inetd.conf). If it is commented out please
uncomment it then run the command inetd –c.
2. Attempt to network boot your system, were you successful?

3. From the system you are booting from capture the packets involved in tftp transfers. Do the files
requested by the booting client match those in the course notes?
4. From the system you are booting from capture the packets involved in the DHCP transaction
between the client and server.
5. Describe what errors you see if you disable tftpd from running on your system?
6. Reenable tftpd but this time add the following line into /var/adm/inetd.sec:
tftp allow loopback
Next run inetd –c to allow inetd to see the changes made. What errors do you see when network
booting the system? Make sure that you ensure that no tftpd daemons are running before
attempting the network boot.
Lab exercise 7 – Network Booting – HP9000 systems

1. What is different between the initial boot of a HP9000 system and a HP Integrity system?
2. What difference is there in how the files required by a HP9000 are stored and transfered compared
to a HP Integrity system?
3. What vendor specific options does a HP9000 system supply when booting (as part of the bootp
request)
4. Indicate if the following questions are true or false
a) Loading an install kernel on a HP9000 system requires the vPar to perform a full network
boot?
b) Being able to boot a vPar on a HP9000 system implies network connectivity to the Ignite
server (or boot helper)?
c) Being able to boot a vPar on a HP Integrity system implies network connectivity to the
Ignite server (or boot helper)?

d) The size field in a lif is given in multiples of 512 bytes?
Lab exercise 8 – How make_net_recovery works (part 1)

1. What environment variable is used to enable debug level logging by Ignite-UX commands?
2. Run lanscan and look at the MAC address of the lan interface. What issues do you think you might
have during a recovery if you were to change the MAC address (depending on the lan interface
you may or may not be able to change the burnt in address (BIA) of a lan interface).
3. What happens when you don't have a LAN interface that has an ethernet, FDDI, or token ring
(802.5) type MAC address?
4. When make_net_recovery fails a pax check what happens?
5. What will be the return code from check_version when the following revisions are compared?
Server Client Exit Value

C.6.10.50 C.6.9.66
C.7.2.42 C.7.3.50
C.7.6.100 C.7.6.101
C.7.7.98 C.7.7.125
C.7.7.98 C.7.7.98
Assume that the -r -g -s <server> options are used when run from the client system.

1. Why does HP not support newer versions of Ignite-UX on clients writing to an older version of
Ignite-UX running on an Ignite server?
2. When using the -u option to make_net_recovery what issues could you encounter (in terms of the
various Ignite bundles)?

3. Look at the /opt/ignite/lbin/update_tools script. When it is executed how does it determine if

Ignite-UX needs to be updated from the Ignite server?
4. In the upodate_tools script (when called by make_tape_recovery) why is additional work required
when it is found that the versions match?
5. Confirm on a HP Integrity system that the boot device has a LIF. Although not discussed in the
course why do you think the LIF exists?
6. On one of your client systems create the following archive_content files. Explain why
list_expander shows something as being fully included, partially include, or not included into the
recovery archive. Give the options that would be required for make_net_recovery to end up with
such an archive_content file.
# cat archive_content1
inc_entire vg00
exclude /var/tmp
inc_cross /
exclude /var/tmp
include /
include /opt
include /usr
inc_all_affected
exclude /var/tmp

1. Run the following command (substitute <server> with the name of your Ignite server):
# make_net_recovery -A -p -s <server>
Using the configuration create by the preview command run make_arch_config the same way that
the make_net_recovery command does the answer the following questions. Please place the
resulting file into a new file name do not overwrite archive_cfg. Run the command using the -m
option to specify all three archive types.
a. If you gave a hostname with the -l option why does an IP address get written into the
configuration?
b. Compare the sizes of the impacts for /stand are they different? Explain why they are this
way.

Note: the values for the -L and -l options to not mean very much they are written into the
configuration but since these configurations were generated for comparison reasons they do not
need to actually point to an archive. If you have previously created a network recovery archive
using make_net_recovery use the configuration directory for that session instead of creating a new
preview session.
2. When generating impacts for an archive why might you sometimes want to generate them at a
higher level than 2? Note that for make_net_recovery the level that impacts are generated at is
determined automaticallty based upon the directory depth of mounted filesystems.
3. The gen_impacts command is used to generate impacts (and is called by the make_arch_config
command to do so). Explain what recent changes were made to allow the impacts to be more
accurate.
4. In make_sys_image explain how the exit_vals file works.
5. Why does make_sys_image use functions like divide to perform math operations and other
functions like lessThan to perform mathematical comparisons?
6. Why in the filter_missing_files script generated by make_sys_image is it important that the -L

option is used first in the test to see if the file still exists or not?

1. What command is used before HP-UX B.11.31 to export filesystems? From HP-UX B.11.31 what
command is used? What permanent file is used to store the exported filesystems?
2. What version of NFS must be in use to create a large recovery archive? How do you tell what
version of NFS is in use by a make_net_recovery session?
3. Explain everything exported by Ignite-UX (especially the places writable via NFS must be owned
by bin).
Lab exercise 12 – A quick look at save_config

1. Ignite-UX shares a significant portion of source code with another product do you know what that
product is?

2. The save_config program is a script. How much easier to troubleshoot what is happening within
the script?
Lab exercise 13 – How make_tape_recovery works (part 1)

1. Answer if the following statements are true or false:
1. The make_tape_recovery command is a completely different program to the

make_net_recovery command.
2. It is almost impossible to troubleshoot the make_tape_recovery command without access

to the source code.
3. When the lock file exists (/var/opt/ignite/recovery/mnr_lockfile) and

make_tape_recovery cannot lock it you should not remove it without investigating why it
is locked.
2. Since you are unlikely to have two tape drives attached to your systems set two copies of
make_net_recovery running (with the -p option). Do both make_net_recovery sessions run, if you
get an error from one of them what error do you get?
3. Why doesn't a recovery tape have the same issues with compatibility between Ignite-UX versions
like make_net_recovery?
4. Explain the use of the configuration variable _hp_hide_other_disks.
5. What command is used to syntax check configuration files after they have been generated?
Lab exercise 14 – How make_tape_recovery works (part 2)

1. What kind of ANSI label is written by make_sys_image on HP Integrity systems?

2. What issues do you forsee with a recovery tape on a HP Integrity system if a tape drive is not
claimed by the stape or (HP-UX B.11.31 only) estape drivers?
3. How many of the 23 files present on a recovery tape for a HP Integrity server are created by
make_ipf_tape and how many by make_sys_image?
Lab exercise 15 – check_net_recovery and check_tape_recovery

Please follow the steps and answer the questions. You should have already created either a network
recovery archive or a preview of one. Run check_net_recovery from the client system to the Ignite server.
1. How many files have been added, deleted, or changed since the last time make_net_recovery was
run? Note that check_net_recovery makes no distinction between a preview session and an actual
run on make_net_recovery.
2. Look at the check_net_recovery script if you wanted to perform the functionality equivalent task
as the script what commands would you run?
Lab exercise 16 – cold install and recovery (part 1)

1. Why does an Ignite program called init run before the real init is started.
2. Are the following statements true or false?
- Ignite-UX can install software in all phases of a recovery/installation session
- Ignite-UX can only install software in only the first two phases of a recovery/installation
session
- Ignite-UX creates the kernel in phase 2
- Ignite-UX creates volume/disk groups and filesystems in phase 2
- There are four phases to an recovery/installation session.

3. Create a logical volume large enough to hold the HP-UX B.11.31 install filesystem. Place the
filesystem into the logical volume and then answer the following questions:
- How many hard links does sbin/init have?
- Is the inode number between sbin/init and sbin/ramfs the same?
- Run what on both programs. Can you tell the version of Ignite-UX they are assocated with?

1. Answer the following:
- What happens when the following message is shown "* Mapping LUN Instance Data"?
- What directory in the ram filesystem are the disk filesystems mounted on?
- Explain why commands archives are path relative rather than absolute (e.g.
SYSCMDS/SYSCMDSIA or a core OS archive).
- What is the difference between the -o and -s options to monitor_bpr?
- During archive extraction why is the "-p e" option to pax used?
2. At this point create a full network recovery archive if you have no done so already. Once complete
recover the recovery archive with debug level logging enable from boot. Note that you will
probably have to setup /etc/bootptab on your Ignite server (which is likely to be the virtual
machine host).
The reason for performing this now is that there will be questions later about debug messages that
can be seen during a recovery.

1. Using the functionality provided by os_arch_post_l why might you consider changing a file
usually saved by merge_file to use save_file?
2. When cloning why does os_arch_post_l remove /stand/vmunix in recovery mode? Why is this step
not required for a golden image install?
3. If the full make_net_recovery run earlier is complete please recover the system with debug level
logging set to 3. Please use the boot loader option -i3 to perform to enable debug level logging.
You may wish to complete this step last.
4. Have a look at the /etc/mnttab file on HP-UX B.11.31 (if possible), how does it compare to an
earlier release of HP-UX (follow any applicable symbolic links). How do you think this enables
any leading /d_cfg_mnt_sb61 to be removed from the mount points and hide the install filesystem
mounted at /?
5. From Ignite-UX version C.7.7 onwards Ignite-UX may no longer recover all of the instance
numbers it previously did - why is this?

1. Prior to HP-UX B.11.31 how does Ignite-UX determine if swconfig needs to be run later to
configure software?
2. When handling the KRS why is nothing done for HP-UX B.11.11 and why are /SAS and
/dumpinfo dropped from the KRS?
3. When Ignite-UX add inittab entries for phase 3 why are most of them run with bootwait?
Hint: Look at the manual page inittab(4) to see the definition of bootwait.

1. Consider the issue of what happens when the client directory is accessed using NFS and an error
occurs when the client directory is not mounted. How would you gather information about a
problem like that?

2. Consider some of the things that happened earlier in the recovery. Ignite-UX knows about the
impacts associated with software it will install but nothing takes into account temporary space
used in places like /tmp/ign_configure, /, and /var (and when files such as SYSCMDS are
extracted onto the disk filesystems). How might this extra space usage impact on what Ignite-UX
does?
4. What is the difference between the way that software is configured on HP-UX B.11.11 and
B.11.23 versus HP-UX B.11.31?
5. What issues can you think of with networking configuration using DHCP with
is_net_info_temporary set to FALSE?
6. Why is instance number reassignment performed again in phase 3?

1. Why is what Ignite-UX currently does with an IP address assigned by DHCP dangerous?
2. If you had an error in a final command hook where would you expect to see the messages about
the failure?
3. From an external perspective (excluding agile I/O paths) are there major differences between how
Ignite-UX presents I/O information between HP-UX B.11.11/B.11.23 and HP-UX B.11.31?
4. Should you be able to tell the difference between a HPVM Guest system and a non-HPVM Guest
system with Ignite-UX?
Lab exercise 22 – The big lab

This lab looks at recovering the system the system that you should have performed earlier and some of the
issues you may have encountered. The first issue is that when you have a version of Ignite-UX that
supports multiple HP-UX revisions on HP Integrity servers you cannot stop the bootloader to give the -i
option to set the debug level:
Shell> lanboot
Selected Acpi(PNP0A03,0)/Pci(1|0)/Mac(EA1E498D1674)
Running LoadFile()

CLIENT MAC ADDR: EA 1E 49 8D 16 74

GATEWAY IP: 10.30.128.1
Running LoadFile()
TFTP..

All rights reserved
Booting from Lan


3. Exit Boot Loader
Choose an operating system to install that your hardware supports:2

...
Instead we're going to modify the /opt/ignite/boot/AUTO file to add a new entry enabling debug. The
AUTO file was changed to look like:
KernelPrompt "Choose an operating system to install that your hardware

supports:" 120 1
reset
"target OS is B.11.31 IA (debug)" boot Rel_B.11.31/IINSTALL -i3
The new option number 3 enables debug level messages from first boot:
Shell> lanboot
Running LoadFile()

GATEWAY IP: 10.30.128.1
Running LoadFile()

TFTP.

All rights reserved
Booting from Lan


3. target OS is B.11.31 IA (debug)
4. Exit Boot Loader

...
In case you have issues with DHCP support (assuming you are not using HPVM 4.0 and direct boot
profiles) you should have setup a bootp entry on your Ignite server to look like:
ignite-defaults:\
ht=ethernet:\
hn:\
bs=48
vm001:\
ha=EA1E498D1674:\
ip=10.30.128.11:\
sm=255.255.252.0:\
gw=10.30.128.1:\
ds=10.30.130.46
The entry "ignite-defaults" should already exist in /etc/bootptab (it was added by Ignite-UX).
Go through the menus and recover the system. The following questions ask about the contents of your log
file. Later questions will ask you to perform additional tasks involving recovery.
1. How large were the two RAM filesystems created?
2. What kind of filesystems were created in the RAM filesystems?

3. The first time that debug messages show bdf type information about the install fileystem (/) how
full is it? What about the other filesystems how full are they?
4. How does the installation/recovery process check the Ignite server version?
Hint: Search for "Server Version" in the install.log file.
5. Most of the following messages are from the Ignite-UX parser:
...
* Checking configuration for consistency...
DEBUG: Entering process_also_selects
DEBUG: Exiting process_also_selects: change_iterations = 2
DEBUG: Special config #0: /var/opt/ignite/clients/0xEA1E498D1674/config.sys
DEBUG: Special config #1: /var/opt/ignite/clients/0xEA1E498D1674/config
...
What are the two files config.sys and config?
6. Do the impacts statements given in the install.log match up with the impacts statements in your
configuration?
7. The following output was from a debug install.log file, we've seen output similar to this previously.
In what context have we seen it?

* 0/0/0/0.0x1.0x0 (/dev/dsk/c0t1d0) (vg00)
* 7168 - 1842176 KB /stand
* 1842176 - 3939328 KB primary
* 3939328 - 4987904 KB /
* 4987904 - 5512192 KB /tmp
* 5512192 - 5614592 KB /home
* 5614592 - 12950528 KB /opt
* 12950528 - 17103872 KB /usr
* 17103872 - 19557376 KB /var
* 0 KB unallocated

8. What are the contents of the partition file used with the idisk command to partition the boot device?
9. What are the commands used to create the root volume group?
10. Why are the LVM lvcreate commands used to create the logical volumes and then lvextend used
to set their sizes?
11. Find where Ignite-UX creates /d_cfg_mnt_sb61. Look at how the filesystems that have now been
created are mounted. Does what you see happening match the course notes and how it describes
where the filesystems are mounted?
12. What command was used to extract the archive? Does this match the command we would expect
to see given the information in the course notes?
Hint: search for pax_iux.
13. From when the NFS client directory is unmounted until it is mounted again where are the
messages stored?
14. As of Ignite-UX version C.7.7 Ignite-UX will print information on devices that the kernel
indicates should not have persistent instance numbers. Find out if there are any entries in your
install.log file
Hint: Search for "persistent".
15. The course notes said that there were 4 trees in the KRS that were dropped from HP-UX B.11.23
onwards (if they exist). Find them in the debug output.
16. Swap systems with one another group of students have them break your Ignite server in two or
more of the following ways (please don't use more than 4). Attempt to recover the system and
work out what is wrong.
- Disable tftp
- Remove /opt/ignite and /var/opt/ignite from the /etc/inetd.conf entry of tftpd.
- Add an entry into inetd.sec so access tftp is denied to everything except the Ignite server
(e.g. use the name loopback or localhost as the only name allowed access or deny access
to the client).
- Comment out the entry for the system in /etc/bootptab (if bootp/DHCP is being used).

- Move one of the /opt/ignite/boot/AUTO, /opt/ignite/boot/nbp.efi, or

/opt/ignite/boot/fpswa.efi to a new name or change their permissions so they cannot be
accessed via tftp.
- Modify the AUTO file to load the install kernel for the wrong version of HP-UX it refers
to. Save a copy of the AUTO file before changing it.
- Change the IP address of the Ignite server in the install filesystems so the client will go to
the wrong Ignite server.
- Change the permissions on the install kernel or filesystem so it cannot be accessed or
rename it so it's not available.
- Move the orginal install kernel or filesystem aside and replace it with another file of a
similar size (e.g. replace the HP-UX B.11.31 install kernel with a copy of /stand/vmunix
from a HP-UX B.11.31 system).
- Change the permissions on one of INSTCMDSIA or SYSCMDSIA so it cannot be
accessed or rename it so it's not available.
- Save a copy of one of INSTCMDSIA or SYSCMDSIA (use the same name ending
in .save), gzip the file and then move it back to the original name.
- Change the ownership of the client directory so it is owned by root:sys and does not
allow the bin user to create or remove files in it.
- Change the client directory so it is no longer exported or has an access= entry to prevent
the client from accessing it.
- Change the permissions on the recovery archive so the client cannot read it (or rename
the file).
- Change the exported directory containing the recovery archive for the client so so it is no
longer exported or has an access= entry to prevent the client from accessing it.
- Add some garbage information into the install filesystem.
- Change the ownership and permissions on the CINDEX file in the client directory so the
client cannot read it. This will prevent the client system from being able to access
information about any recovery archives it has. Change it to be owned by root:sys with
permissions 600.
- Change the ownershop and permissions on the configuration files refered to by the cfg
clauses in the CINDEX file to prevent them from being accessed. Change them to be
owned by root:sys with permissions 600 (to make it more confusing only change one of
the 3 files referenced).
- Move the recovery archive aside to a new name and create a zero length file using the
original name of the recovery archive.
- Move the recovery archive aside to a new name create a new archive containing some
files (it doesn't matter what files) using pax. Now gzip the resulting file and move it to
the original archive name.
- This may or may not work - move the directory containing the recovery archives to a new
name create a new directory with the original name, ownership and permissions and then
move the recovery archives into the new directory 183.
Please note down what changes you have made so the other group can know what you have changed if they
cannot work it out. Please do not use the above list of potential changes as a check list to fix issues before
attempting a recovery, attempt the recovery and fix each problem you encounter then attempt the recovery
again. The objective is to get an error free recovery. If you encounter an issue with a file shipped as part of
Ignite-UX it is fair to run swverify - note that files will not help with files created by Ignite-UX only with
errors related to some files shipped with Ignite-UX.
If you complete this and time allows try again with another 4 items above (please ask a different group of
people to break your system).
183
This is likely to cause errors because the inode number of the exported directory has changed, NFS
should refuse to allow the new directory to be mounted until the directory has been shared/exported again.

Lab exercise 23 – An Extra lab

Create a debug install.log from a recovery session. You may have already created one, if so you do not
need to create another one. Please make sure that you read the start of lab 22 about to to enable debug level
logging of messages from boot.
If you do not have a debug level log file easily available please ask your instructor for an example HP-UX
B.11.31 debug log file.
1. When discussing the relocation of files into the two RAM filesystems that can be created (one
on HP-UX B.11.11) what kind of files are relocated into the RAM filesystem /RAMFS1
according to the debug output?
2. How large where the RAM filesystems that were created? Does this match the information
shown in the student notes section (see “What does /sbin/ramfs do?” – towards the end of the
section) about how large the filesystems should be based upon memory size and the minimum
and maximum size of these ram filesystems?
3. Locate the messages about the client directory being mounted during the recovery. Do the
files that are moved to the client directory match the course notes?
4. Locate the information the debug log file that shows the expected allocation of volumes on
disk. Run the following command in the per-client directory for that system “instl_dbg –D . –
d” (please cd to this directory before running the command). Does the output match? How
useful does this make this command in terms of testing configuration changes without having
to actually install a system?
5. Locate an example of Ignite-UX automatically adding IA to the end of a command archive if

you created the debug level log message on a HP Integrity system,
6. Locate an example of Ignite-UX allocating impacts to statements. What level impacts do you
have? Do you see the impacts at that level being allocated to the correct volumes?
7. Find the follow message in your debug log messages. Compare the sizes reported to the actual
sizes that your partitions end up at (use the diskinfo command on each partition).
DEBUG: Calculated EFI overhead to be 64 KB, EFI Boot Partition size: 512000
KB, HPUX Partition: 19557376 KB, HP Service Partition: 409600 KB,
Unallocated: 960 KB
8. When creating LVM volumes can you explain why logical volumes are created empty?

9. Prove from your debug level log file that the disk filesystems really do get mounted at
/d_cfg_mnt_sb61.
10. Locate any messages that relate to instance numbers that are not preserved in your install.log
file. Do you expect that these devices should not have preserved instance numbers?
11. From the recovered system how do you determine what version of Ignite-UX was used to
install and/or recover the system? Note that is not applicable to HP-UX B.11.11.

Lab exercise 1 Answers – pulling a part a recovery tape

To extract all of the files from tape on HP9000 systems use the following commands:
# mt –f <no_rewind_tape_dev> rew
# dd if=<no_rewind_tape_dev> of=file1 bs=2k
Note that even though we have used a block size of 10k here for extracting the archive since if the record
size read from tape is 5k dd will read two records from tape before writing the output record to disk.
# dd if=<no_rewind_tape_dev> of=file1 bs=80
This assumes that we reviewed the contents of the ANSI labels describing the files and set the block sizes
used with the dd command appropriately for extracting the tape contents.
1. How many files did you extract from the tape?
There should be 2 files for HP9000 recovery tapes and 23 for HP Integrity systems.
2. Did the format of the tape match the definition of the tape format for the architecture of system
that the recovery tape was created on?
It should have, if it did not there is something wrong with the tape.
3. How can you show the version of Ignite-UX that was used to create the tape?
For a HP9000 system in the first file extracted you can use the lifcp command to copy the VERSION file
from the LIF. That will show the Ignite-UX version used to create the recovery tape. For HP Integrity
systems you need to use the lifcp command still however you need to lifcp the VERSION file from the
HPUXIUXLIF file (file number 20). This is not required to answer this question but if you wish to access
the VERSION file directly on tape you will need to use the following commands:

# mt –f <no_rewind_tape_dev> fsf 19 184
# lifcp file20:VERSION –
The last command will show the version of Ignite-UX that created the recovery tape. A similar thing can be
done with HP9000 format tapes however the LIF is the first file so you need only make sure that the tape
drive is rewound and issue the dd command followed by the lifcp command.
4. How can you show the configuration associated with the tape?
Similarly to question 3, the difference is to use lifcp on the INDEX and CONFIG files (for a recovery tape
the INDEX file will always be a cfg clause pointing at the CONFIG file so really we only need to get a
copy of the CONFIG file from the LIF).
5. Are the files in the archive written with relative of absolute paths?
The files in a recovery archive (and also for any archive created by make_sys_image for a golden image
install) are created path relative.
6. Explain why the archive is written that way.
When a Core OS archive is extracted (this applies to golden image installs as well as recovery archives) the
installation session has not performed a chroot(2) yet. If the archive had absolute paths it would be
extracted into the install filesystem not the disk filesystems. This would cause an installation or recovery
failure almost as soon as the archive extraction had begun.
7. Compile and run the readtape program.
You will probably need a filesystem with up to 10GiB free depending on the size of the archive.
# cc readtape.c -o readtape +DD64

# ./readtape /dev/rmt/0mn
end of tape reached
8. Look at the files extracted by the program. Look at a few files and verify that the block size
written to file.info for the file and the size of the file is correct (hint look at the ANSI header label
describing the file).
The following shows 3 files selected at random and the ANSI label header records to show that the correct
size was extracted from the tape (the matching sizes are underlined):
# cat file10
HDR1AUTO 00000001000100008141008141 000000
HDR3
HDR4 00
UHL3EFIAUXF000000000000000005120000000000000512
# ll file11
-rw-rw-rw- 1 root sys 512 Aug 12 16:36 file11
# cat file13
HDR1IINSTALL 00000001000100008141008141 000000
HDR3
HDR4 00
184
Since we are already at file 1 on the tape when rewound we need to skip forward 19 files.

UHL3EFIAUXF000000000000431554560000000000032768
# ll file14
# cat file19
HDR1HPUXIUXLIF 00000001000100008142008142 000000
HDR3
HDR4 00
UHL3EFIAUXF000000000001021337600000000000002048
# ll file20
The block sizes from file.info match the ANSI label header records for the above files:
# grep -e file11 -e file14 -e file20 file.info

file11,512
file14,32768
file20,2048
9. Were all of the files extracted correctly by the program?
They appear to be correctly extracted. We can use various commands on the files extracted to try and show
that they appear to be correct:
No errors were reported by pax against the archive that was extracted:
# pax < file23 |tail

var/run/daemon/automountd.lock
var/run/daemon/rpc.mountd.lock
var/run/daemon/nfsd.lock
var/run/hpsmc-hpssidgen.lock
var/run/hpsmc-hpsconfig.lock
var/run/evmd.pid
var/run/evmlogger.info
var/run/esm.state
var/run/sshd.pid
var/run/envd_diag
10. If you are using Ignite-UX version C.7.7 or later use the ansitape command to list and then extract
the contents of the tape. Would this command be very useful in extracting the contents of a tape
and putting them back together again?
The ansitape command contained a defect in some releases of Ignite-UX before C.7.7 it could not correctly
extract the contents of a tape (ANSI labeled files.
The command while it can extract ansi labeled files cannot extract the archive and once you’ve extracted
files without reading the make_ipf_tape script you would not have enough information to put the tape back
together again onto a new tape.
The ansitape command also does not provide any assistance in putting the tape back together again since it
does not record any information that it read from the ANSI labels when extracting the files described by the
labels.
Lab exercise 2 Answers – comparing archive types

This lab exercise asks you to compare archive types for different features. The three archive types are pax
(pax interchange format), tar (aka ustar or extended tar interchange format), and cpio (ASCII cpio
interchange format).
1. What archive type supports the largest file size?
pax
2. What archive type supports the smallest range of uid/gid values?
cpio
3. What archive type has a limitation on the filename length of a symlink target?
tar
4. What archive type supports ACLs?
None of them support ACLs.
5. Which format has a larger default block size?
tar
6. What format does not store the user/group names in side an archive?
cpio
7. What format supports files as large as HP-UX does? Why could this be a potential issue if you
were using a different format and then change to this format?
pax, when using cpio or tar formats and switching to pax format the potential issue is a sudden increase in
the size of a recovery archive if it includes files 8GiB or larger. They aren’t included into a cpio or tar
format archive but will be included into a pax format archive.
8. Why can’t the limitations inherent in the cpio and tar formats be removed?
Because the formats are controlled by international standards, the HP-UX commands that write archives
that conform to these standards must create archives that adhere to those standards.
9. What format has a limitation on the maximum length of a file name?
tar
10. Bonus question (not covered in the course notes) – do you know why extended tar interchange
format is sometimes called ustar format?
Apart from the format name of extended tar interchange format being ustar when using the pax command,
the word ustar appears in the archive as part of the format definition:
# pax -w -x ustar -f ./tar.out ./file22

# xd -xc tar.out |more
0000000 2e2f 6669 6c65 3232 0000 0000 0000 0000
. / f i l e 2 2 \0 \0 \0 \0 \0 \0 \0 \0
0000010 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*

0000060 0000 0000 3030 3030 3636 3600 3030 3030

\0 \0 \0 \0 0 0 0 0 6 6 6 \0 0 0 0 0
0000070 3030 3000 3030 3030 3030 3300 3030 3030
0 0 0 \0 0 0 0 0 0 0 3 \0 0 0 0 0
0000080 3030 3030 3132 3000 3131 3035 3034 3635
0 0 0 0 1 2 0 \0 1 1 0 5 0 4 6 5
0000090 3536 3000 3030 3132 3035 3400 3000 0000
5 6 0 \0 0 0 1 2 0 5 4 \0 0 \0 \0 \0
00000a0 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000100 0075 7374 6172 0030 3072 6f6f 7400 0000
\0 u s t a r \0 0 0 r o o t \0 \0 \0
0000110 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
...
Unfortunately it also appears in pax format archives since the pax format is based on ustar format with
extentions to enable the format to remove limitations imposed by the extended tar interchange format:
# pax -w -x pax -f ./pax.out ./file22

# xd -xc < pax.out |more
0000000 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000060 0000 0000 3030 3030 3030 3000 3030 3030
\0 \0 \0 \0 0 0 0 0 0 0 0 \0 0 0 0 0
0000070 3030 3000 3030 3030 3030 3300 3030 3030
0 0 0 \0 0 0 0 0 0 0 3 \0 0 0 0 0
0000080 3030 3030 3030 3000 0000 0000 0000 0000
0 0 0 0 0 0 0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000090 0000 0000 3030 3036 3435 3500 7800 0000
\0 \0 \0 \0 0 0 0 6 4 5 5 \0 x \0 \0 \0
00000a0 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000100 0075 7374 6172 0030 3072 6f6f 7400 0000
\0 u s t a r \0 0 0 r o o t \0 \0 \0
0000110 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000120 0000 0000 0000 0000 0073 7973 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 s y s \0 \0 \0 \0
0000130 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
To illustrate that pax format archives are different we can attempt to review a pax format archive and a tar
archive created by pax:
# pax -w -x ustar -f ./tar.out ./file22

# pax -w -x pax -f ./pax.out ./file22
using the tar command:
# tar tvf tar.out

rw-rw-rw- 0/3 80 Aug 13 15:04 2008 ./file22
# tar tvf pax.out
Tar: blocksize = 10
However the pax command can read both archives and identify the type of archive correctly (pax format
archives are defined by the UNIX2003 standard to print “USTAR format archive extended” as the format
type when they are encountered):

# pax -v -f ./tar.out
-rw-rw-rw- 0 root sys 80 Aug 13 15:04 ./file22
# pax -v -f ./pax.out
USTAR format archive extended
-rw-rw-rw- 0 root sys 80 Aug 13 15:04 ./file22
Note that in this particular case the thing that the tar command is having problems with initially is that the
pax archive isn’t a multiple of 10KiB:
# ll pax.out tar.out
-rw-rw-rw- 1 root sys 5120 Aug 13 17:03 pax.out
-rw-rw-rw- 1 root sys 10240 Aug 13 17:05 tar.out
However if we block it a multiple of 10KiB the tar command still can’t process the archive (we don’t get an
error but we also don’t get any files listed):
# dd if=/dev/zero bs=5120 count=1 >> pax.out

1+0 records in
1+0 records out
# tar tvf pax.out
This illustrates that when reading archives created by Ignite-UX it is important to read them using the pax
command rather than cpio or tar as pax understands and can automatically determine the archive type and
display the contents of the archive appropriately 185.
Lab exercise 3 Answers – Looking at an install filesystem

These are the answers to Lab exercise 2, these answers are based on Ignite-UX version C.7.6.100 and an
11.31 IINSTALLFS file. The answers you find for other Ignite-UX versions and HP-UX revisions may
vary slightly (but not significantly).
1. What kind of filesystem is the install filesystem that you have just dd'ed into the logical volume?
# fstyp /dev/vg00/lvol11
hfs
2. Why do you think there is a directory called core in the root directory of the install filesystem?
The directory core does exist in the install filesystem:
# ll
...
dr-xr-xr-x 2 bin bin 24 Apr 16 22:15 cdev
d--------- 2 bin bin 24 Apr 16 22:15 core
dr-xr-xr-x 5 bin bin 292 Apr 16 22:15 dev
drwxr-xr-x 2 bin bin 24 Apr 16 22:15 disc
dr-xr-xr-x 4 bin bin 272 Apr 16 22:15 etc
drwxr-xr-x 2 root root 4096 Apr 16 22:15 lost+found
drwxr-xr-x 3 bin bin 40 Apr 16 22:15 opt
drwxr-xr-x 3 bin bin 548 Apr 16 22:15 sbin
drwxr-xr-x 2 bin bin 44 Apr 16 22:15 stand
drwxrwxrwx 2 bin bin 24 Apr 16 22:15 tmp
drwxr-xr-x 7 bin bin 96 Apr 16 22:15 usr
185
On HP-UX B.11.11 pax cannot show pax format archives and on HP-UX B.11.23 and enhancement
bundle is required to support pax format archives.

drwxr-xr-x 5 bin bin 60 Apr 16 22:15 var
It is present to ensure that if a core file is dropped by a program when Ignite-UX running on the install
kernel that it will not fill the root filesystem. A program core dumping may cause other failures in Ignite-
UX but this will stop issues with a core file filling up the filesystem.
3. From the root directory of the install filesystem run the following command:
# find .
The output seen in the 11.31 IINSTALLFS file shipped with Ignite-UX version C.7.6.100 was:
# find .
.
./lost+found
./core
./dev
./dev/console
./dev/kmem
./dev/mem
./dev/null
./dev/systty
./dev/tty
./dev/config
./dev/root
./dev/rroot
./dev/dlpi
./dev/lan
./dev/sad
./dev/vxportal
./dev/kepd
./dev/deviceFileSystem
./dev/dsk
./dev/rdsk
./cdev
./tmp
./disc
./stand
./stand/ioconfig
./sbin
./sbin/system.init
./sbin/ls
./sbin/sh
./sbin/reboot
./sbin/exit_0
./sbin/kcshutdown
./sbin/init
./sbin/launch
./sbin/loadfile
./sbin/rescan
./sbin/unlink
./sbin/bdf
./sbin/pstat
./sbin/sync
./sbin/cat
./sbin/mknod
./sbin/mkdir
./sbin/ramfs
./sbin/rm
./sbin/funzip
./sbin/map_root_lv
./sbin/get_disk_layout

./sbin/fs_type
./sbin/get_partition_info
./sbin/net_cfg_prep
./sbin/itemap.gz
./sbin/pre_init_rc
./sbin/ioscan
./sbin/fs
./sbin/fs/fsdaemon
./sbin/fs/cdfs
./sbin/fs/cdfs/statvfsdev
./sbin/fs/hfs
./sbin/fs/hfs/statvfsdev
./sbin/fs/lofs
./sbin/fs/lofs/mount
./sbin/fs/nfs
./sbin/fs/nfs/mount
./sbin/fs/vxfs
./sbin/fs/vxfs/mkfs
./sbin/fs/vxfs/mount
./sbin/fs/vxfs/statvfsdev
./sbin/insf
./sbin/rmsf
./etc
./etc/services
./etc/protocols
./etc/passwd
./etc/group
./etc/inittab
./etc/mnttab
./etc/utmp
./etc/utmps
./etc/X11
./etc/X11/XHPKeymaps.gz
./etc/nsswitch.conf
./etc/stcp.conf
./etc/netconfig
./etc/nfssec.conf
./etc/default
./etc/default/tz
./usr
./usr/sbin
./usr/sbin/ifconfig
./usr/sbin/route
./usr/sbin/lanadmin
./usr/sbin/setboot
./usr/sbin/mkfs
./usr/sbin/diskinfo
./usr/sbin/scsimgr
./usr/sbin/ioscan
./usr/lib
./usr/lib/libsmapi.so.2
./usr/lib/hpux32
./usr/lib/hpux32/dld.so
./usr/lib/hpux32/uld.so
./usr/lib/hpux32/libc.so.1
./usr/lib/hpux32/libdl.so.1
./usr/lib/hpux32/libdld.so.1
./usr/lib/hpux32/libsec.so.1
./usr/lib/hpux32/libnss_files.so.1
./usr/lib/hpux32/libnsl.so.1
./usr/lib/hpux32/libnss_dns.so.1
./usr/lib/hpux32/libsnet.so.1
./usr/lib/hpux32/libnm.so.1

./usr/lib/hpux32/libnm.so
./usr/lib/hpux32/libxti.so.1
./usr/lib/hpux32/libCsup.so.1
./usr/lib/hpux32/libcl.so.1
./usr/lib/hpux32/libcl.so
./usr/lib/hpux32/libunwind.so.1
./usr/lib/hpux32/libsmapi.so.2
./usr/lib/hpux32/libstd.so.1
./usr/lib/hpux32/libstream.so.1
./usr/lib/hpux32/libuca.so.1
./usr/lib/hpux32/libxcurses.so.1
./usr/lib/hpux32/libsin.so.1
./usr/lib/hpux32/libsin.so
./usr/lib/hpux32/librpcsvc.so.1
./usr/lib/hpux32/libevm.so
./usr/lib/hpux32/libevm.so.1
./usr/lib/hpux32/libpthread.so.1
./usr/lib/hpux32/libvparusr.so.1
./usr/lib/hpux32/libstd_v2.so.1
./usr/lib/hpux32/libm.so.1
./usr/lib/tztab
./usr/lib/lanadmin
./usr/lib/lanadmin/libdsbtlan.so.1
./usr/lib/lanadmin/libdsbtlan.so
./usr/lib/lanadmin/libdsintl100.so.1
./usr/lib/lanadmin/libdsintl100.so
./usr/lib/lanadmin/libdsgelan.so.1
./usr/lib/lanadmin/libdsgelan.so
./usr/lib/lanadmin/libdsigelan.so.1
./usr/lib/lanadmin/libdsigelan.so
./usr/lib/lanadmin/libdsiether.so.1
./usr/lib/lanadmin/libdsiether.so
./usr/bin
./usr/bin/tftp
./usr/bin/ttytype
./usr/bin/model
./usr/bin/autopush
./usr/bin/ndd
./usr/lbin
./usr/lbin/dhcpclient
./usr/share
./usr/share/lib
./usr/share/lib/terminfo
./usr/share/lib/terminfo/h
./usr/share/lib/terminfo/h/hp
./usr/share/lib/terminfo/v
./usr/share/lib/terminfo/v/vt100
./usr/share/lib/terminfo/w
./usr/share/lib/terminfo/w/wy60
./var
./var/tmp
./var/adm
./var/adm/sw
./var/opt
./var/opt/ignite
./opt
./opt/ignite
./opt/ignite/lib
./opt/ignite/lib/libcfg.so.1.gz
./opt/ignite/lib/libsmapi.so.2
./opt/ignite/data
./opt/ignite/listeners
./opt/ignite/listeners/IO

./opt/ignite/listeners/IO/1131io
./opt/ignite/listeners/IO/1131io/smapi_listener
./opt/ignite/listeners/VM
./opt/ignite/listeners/VM/vxvm
./opt/ignite/listeners/VM/vxvm/smapi_listener
./opt/ignite/listeners/FS
./opt/ignite/listeners/FS/vxfs
./opt/ignite/listeners/FS/vxfs/smapi_listener
There are only a relatively small number of files present in the install filesystem, what do most of
them relate to?
The largest group of files relate to networking and being able to start it from the install filesystem. This
needs to happen during a network install as once the install kernel and filesystem have been downloaded
the only things Ignite-UX has during a network install is the contents of the install filesystem until after it
can get networking started and start downloading additional files to continue an installation or recovery
session.
It is slightly easier with non-networking installation and recoveries as the additional files required are
directly accessible via tape or from disk.
Another valid answer would be that all of them relate to starting an Ignite-UX installation or recovery
session.
4. Run the following commands:
# cd sbin
# ll -i |more
What group of programs has the most hard links?
# ll -i |more
total 117716
28 drwxr-xr-x 3 bin bin 548 Apr 16 22:15 .
2 dr-xr-xr-x 14 bin bin 196 Apr 16 22:15 ..
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 bdf
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 cat
33 -r-xr-xr-x 2 bin bin 394 Apr 16 22:15 exit_0
39 dr-xr-xr-x 7 bin bin 116 Apr 16 22:15 fs
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 fs_type
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 funzip
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15
get_disk_layout
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15
get_partition_info
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 init
53 -r-xr-xr-x 2 bin bin 1224216 Apr 16 22:15 insf
38 -r-xr-xr-x 1 bin bin 1090292 Apr 16 22:15 ioscan
36 -r-xr-xr-x 1 bin bin 330400 Apr 16 22:15 itemap.gz
33 -r-xr-xr-x 2 bin bin 394 Apr 16 22:15 kcshutdown
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 launch
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 loadfile
30 -r-xr-xr-x 1 bin bin 789344 Apr 16 22:15 ls
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 map_root_lv
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 mkdir
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 mknod
35 -r-xr-xr-x 1 bin bin 471952 Apr 16 22:15 net_cfg_prep
37 -r-xr--r-- 1 bin bin 4459 Apr 16 22:15 pre_init_rc
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 pstat
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 ramfs

32 -r-xr-xr-x 1 bin bin 750064 Apr 16 22:15 reboot

34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 rescan
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 rm
53 -r-xr-xr-x 2 bin bin 1224216 Apr 16 22:15 rmsf
31 -r-xr-xr-x 1 bin bin 1343360 Apr 16 22:15 sh
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 sync
29 -r-xr-xr-x 1 bin bin 1890708 Apr 16 22:15 system.init
34 -r-xr-xr-x 18 bin bin 2833108 Apr 16 22:15 unlink
There is one program (inode 34) with 18 hard links. Those programs are bdf, cat, fs_type, funzip,
get_disk_layout, get_partition_info, init, launch, loadfile, map_root_lv, mkdir, mknod, pstat, ramfs, rescan,
rm, sync, and unlink.
What does that mean?
When a file is hard linked the contents are identical (as are the permissions and ownership of the file).
There is one large binary that supplies the functionality of the listed commands based upon the basename of
the binary.
Where does the program come from (run what on one of the hard linked files)?
They are supplied by Ignite-UX, this can be seen from the what output:
# what init
init:
ignite/launch (opt) Revision: /branches/IUX_RA0806/ignite/src@73644
Last Modified: 2008-04-15 17:21:10 -0600 (Tue, 15 Apr 2008)
ignite/headers $Revision: 72278 $ $Date: 2007-11-20 16:01:38 -0700 (Tue,
20 Nov 2007) $
5. Run the what command on sbin/system.init, try to explain the what output. If the relevant section
of the course has been completed explain why sbin/init is an Ignite-UX program and the “real” init
exists as sbin/system.init in the install filesystem.
# what sbin/system.init
sbin/system.init:
$Revision: B.11.31_LR
The what output is the same as /sbin/init has on a regular 11.31 system. It is actually a copy of the real init.
The reason why theirs is an Ignite-UX program called init and the real init is called something else is that
Ignite-UX needs to intercept arguments passed to the kernel by the loader. The real init doesn’t support any
arguments except for a run level passed with the –i option however the Ignite version of init does. The
Ignite version of init eventually execs the real init to start the installation or recovery session.
6. Explain the contents of etc/inittab from the install filesystem.
# more etc/inittab
#
ajmiller Exp $
#
#
init:0:initdefault

#
# Allocate additional RAM filesystems
#
#
# Run launch, configure disks, load archive software.
#
iux0:0:bootwait:/sbin/launch </dev/console >/dev/console 2>&1
#
# Should never get to this point.
#
After the Ignite-UX copy of init passes control to the real init the first program run at any run level (0 to 6)
is /sbin/ramfs and then /sbin/launch is called. The last two lines from inittab should never be executed.
Lab exercise 4 answers – inventory blocking and the AUTO file

1. Create a minimal boot DVD image that overrides the setting for the Ignite server to give you a
choice of booting from at least two specific Ignite servers (yours and a different one).
In this answer we’ll create an 11.23 minimal DVD image (you could just as easily create an 11.31 minimal
boot DVD).
To do that we need a place with approximately 600MiB free to create the DVD image. First we create a
pseudo root directory for the DVD then copy the EFI_CD_image file into it and then create a minimal LIF
file in the same directory.
# mkdir dvd
# cp /opt/ignite/boot/Rel_B.11.23/EFI_CD_image dvd/my_image
# make_medialif -r B.11.31 -mR -l ./dvd/mylif
The standard AUTO file in that directory doesn't have the contents or format that we're interested in. Note
that the -u option is required to copy from the EFI filesystem. If you don't have the -u option the command
will attempt to copy into the EFI filesystem.
# efi_cp -d dvd/my_image -u /AUTO .

# cat AUTO
boot :IINSTALL
So we need to replace it completely with a new one that will present a boot manager menu to choose the
options we want it to show. Now after making changes (the auto_adm commands to do this are not shown
here) the AUTO file looks like this:
# cat AUTO
reset
"Install HP-UX B.11.23 (no custom settings)" boot :IINSTALL
"Install HP-UX B.11.23 from 10.92.172.54" boot :IINSTALL -
i'server=\"10.92.172.54\"'


i'server=\"10.92.174.54\"'
We can now copy the changed AUTO file back into the EFI filesystem.
# efi_cp -d dvd/my_image ./AUTO /AUTO
Now we can create the DVD image using mkisofs. In this example we don't need a lot of the options that
we would normally use with the mkisofs command. The reason for this is that we have nothing in the
ISO9660 filesystem that we actually care about. That is is there's no SD depots, no archive or anything else
that we would end up accessing with Ignite-UX.
# /opt/ignite/lbin/mkisofs -no-emul-boot -b my_image -eltorito-alt-boot -no-

emul-boot -b mylif -o ./dvd.lab4.q1 dvd
3.78% done, estimate finish Sun Aug 17 20:17:03 2008
Total rockridge attributes bytes: 0
132316 extents written (258 MB)
Then we need to run instl_combine on the DVD to write the LIF directory to the start of the DVD image.
Note that we won't actually be performing enough of a boot to get to read it in this example.
# /opt/ignite/lbin/instl_combine -C dvd.lab4.q1
El Torito offset for LIF volume is: 0xd000
Adjusting LIF file: ISL (Old iplstart: 4096; New iplstart: 57344)
Adjusting LIF file: AUTO
Adjusting LIF file: HPUX
Adjusting LIF file: WINSTALL
Adjusting LIF file: WINSTALLFS
Adjusting LIF file: IINSTALL

Adjusting LIF file: IINSTALLFS

Adjusting LIF file: FWWKAR
Adjusting LIF file: RECCMDS
Adjusting LIF file: RECCMDSIA
Adjusting LIF file: PAD
The DVD image is moved into the backing store for the virtual DVD drive for the HPVM guest.
# chmod 444 dvd.lab4.q1

# mv dvd.lab4.q1 /var/dvd
We then access the HPVM guest and make sure it is at the EFI shell, then press ^B to get to the virtual MP.
From the virtual MP we will insert the DVD we have just created. After doing that we need to get back to
the console.
Shell>
vMP MAIN MENU
CO: Console
CM: Command Menu
CL: Console Log
SL: Show Event Logs
VM: Virtual Machine Menu
HE: Main Help Menu
X: Exit Connection
[vm006] vMP> in
Insertable Guest Devices

Num Hw-path (Bus,Slot,Tgt) Gdev
--------------------------------------------
[1] 0/0/0/0.2.0 (0,0,2) dvd
Enter menu item number or [Q] to Quit: 1
Insertable File Backing Stores

Num File
---------------------
[1] 0709.DVD.11.31
[2] MINDVD.11.23
[3] MINDVD.11.31
[4] dvd.lab4.q1
[5] tcpdump
Confirm insertion action

G - Go
F - Force
Enter menu item or [Q] to Quit: g
[vm006] vMP> co
(Use Ctrl-B to return to vMP main menu.)
- - - - - - - - - - Prior Console Output - - - - - - - - - -

blk2 : Acpi(PNP0A03,0)/Pci(0|0)/Scsi(Pun1,Lun0)/HD(Part1,SigA1751F16-4DCD-
11DD
-8000-D6217B60E588)
blk3 : Acpi(PNP0A03,0)/Pci(0|0)/Scsi(Pun1,Lun0)/HD(Part2,SigA1751FF2-4DCD-
11DD
-8000-D6217B60E588)
blk4 : Acpi(PNP0A03,0)/Pci(0|0)/Scsi(Pun1,Lun0)/HD(Part3,SigA175201A-4DCD-
11DD
-8000-D6217B60E588)
blk5 : Acpi(PNP0A03,0)/Pci(0|0)/Scsi(Pun2,Lun0)
setting hpux path(\EFI\HPUX)...

type 'fs[x]:' where x is your bootdisk (0, 1, 2...)
type 'hpux' to start hpux bootloader
Shell>
- - - - - - - - - - - - Live Console - - - - - - - - - - - -
Since the DVD has been inserted after performing the last map of devices at the EFI shell (that happened
when we escaped to the EFI shell) we need to remap the devices using the command map -r:
Shell> map -r
fs0 : Acpi(PNP0A03,0)/Pci(0|0)/Scsi(Pun1,Lun0)/HD(Part1,SigA1751F16-4DCD-
11DD-8000-D6217B60E588)
fs1 : Acpi(PNP0A03,0)/Pci(0|0)/Scsi(Pun1,Lun0)/HD(Part3,SigA175201A-4DCD-
11DD-8000-D6217B60E588)
fs2 : Acpi(PNP0A03,0)/Pci(0|0)/Scsi(Pun2,Lun0)/CDROM(Entry0)
11DD-8000-D6217B60E588)
11DD-8000-D6217B60E588)
11DD-8000-D6217B60E588)
blk6 : Acpi(PNP0A03,0)/Pci(0|0)/Scsi(Pun2,Lun0)/CDROM(Entry0)
From the DVD we go to the CD/DVD device and type install. That will start the bootloader and it presents
the menu defined in the AUTO file on the DVD.
Shell> fs2:
fs2:\> install

All rights reserved
1. Install HP-UX B.11.23 (no custom settings)

4. Exit Boot Loader
Choose Operating System to Install :

2. Create a minimal boot DVD that blocks SCSI as a protocol (in this case it could be done from the
install filesystem but please do it as a boot loader option). What happens when you reach itool, can
you see any SCSI devices? Note that you will need to connect over the network to an Ignite server
and complete select an OE to install to perform this exercise.
Some of the commands required to complete this have already been completed we’ll use some of the work
performed in the previous question.
So we already have an auto file that looks like:
# cat AUTO
reset
i'server=\"10.92.172.54\"'
i'server=\"10.92.174.54\"'
We can change it so it contains the SCSI protocol blocking configuration and copy if back into the EFI
filesystem.
# cat AUTO
reset
"Install HP-UX B.11.23 (no custom settings)" boot :IINSTALL -
i'inventory_block_protocols={\\"parallel_scsi\\"}'
i'server=\"10.92.172.54\"' -i'inventory_block_protocols={\\"parallel_scsi\\"}'
i'server=\"10.92.174.54\"' -i'inventory_block_protocols={\\"parallel_scsi\\"}'
Now create the minimal DVD image



Then write the LIF directory at the start of the filesystem.
Next we need to insert the DVD on the HPVM guest system via the virtual MP:
[vm006] vMP> in

--------------------------------------------
[1] 0/0/0/0.2.0 (0,0,2) dvd

Num File
---------------------
[1] 0709.DVD.11.31
[2] MINDVD.11.23
[3] MINDVD.11.31
[4] dvd.lab4.q1
[5] dvd.lab4.q2
[6] dvd.lab4.q5
[7] tcpdump

G - Go
F - Force
Now we can go back to the console and issue the map -r command:
Shell> map -r


11DD-8000-D6217B60E588)
11DD-8000-D6217B60E588)
11DD-8000-D6217B60E588)
11DD-8000-D6217B60E588)
11DD-8000-D6217B60E588)
The selection option 1 from the boot manager menu:
Shell> install

All rights reserved

4. Exit Boot Loader
Choose Operating System to Install :1
During startup we can see that we're blocking the parallel_scsi protocol:
* Preparing to execute init...
INIT: Overriding default level with level '0'

======= 08/17/08 07:12:29 EDT HP-UX Installation Initialization. (Sun Aug 17
07:12:29 EDT 2008)
15:53:11 -0600 (Mon, 15 Oct 2007)
* Configuring RAM filesystems...
* Scanning system for IO devices...
NOTE: Blocking protocol "parallel_scsi".
* Boot device is: 0/0/0/0.0x2.0x0
* Setting keyboard language.
It's important to note that the only devices presented to HPVM guests are virtual parallel SCSI devices.
You should not attempt to block parallel SCSI devices on HPVM guest systems. There we no errors
presented as part of the install process when this was done.

To show that no devices were seen the following is the add/remove disks screen from the installation
session:
3. Create a minimal boot DVD with boot loader menu options that enables these two conditions
(each one separately):
(_noscsi == 1)
{
inventory_block_protocols = { “scsi” }
}
(_nofc == 1)
{
inventory_block_protocols = { “fibre_channel” }
}
So the first thing we need to do is change the AUTO file to add the variable definitions that will control
what happens in the install filesystem. The AUTO file will look like this:
# cat AUTO
reset
"Install HP-UX B.11.23 (no pSCSI)" boot :IINSTALL -i'_noscsi=1'
"Install HP-UX B.11.23 (no FC)" boot :IINSTALL -i'_nofc=1'
And we need to put it back into the EFI filesystem:
Now we need to modify the LIF so we need to first extract the configuration from the install filesystem:
# instl_adm -F dvd/mylif > mylif.out
On the system that these answers were created on it looked like this:

# cat mylif.out
server="10.30.128.20"
netmask[]="255.255.252.0"
inventory_block_protocols = { "fibre_channel" }
Using vi that the install filesystem configuration was changed to become:
# cat mylif.out
server="10.30.128.20"
netmask[]="255.255.252.0"
(_noscsi == 1)
{
inventory_block_protocols = { "scsi" }
}
_noscsi visible_if false
(_nofc == 1)
{
}
_nofc visible_if false
The visible_if statements prevent the variables from being visible via the advanced interface of itool on the
additional button on the basic tab. The reason for that is it would be too late to change them there to affect
inventory and the way the boot loader arguments are defined you couldn't change them there anyway.
The configuration can be reapplied back to the LIF:
# instl_adm -F dvd/mylif -f mylif.out
Now we can create the DVD image and the LIF directory at the start of the image:



We need to insert the image into the virtual DVD drive:
[vm006] vMP> in

--------------------------------------------
[1] 0/0/0/0.2.0 (0,0,2) dvd

Num File
---------------------
[1] 0709.DVD.11.31
[2] MINDVD.11.23
[3] MINDVD.11.31
[4] dvd.lab4.q1
[5] dvd.lab4.q2
[6] dvd.lab4.q3
[7] dvd.lab4.q5
[8] tcpdump

G - Go
F - Force

Then remap the devices to find the EFI partition the CD/DVD drive:
Shell> map -r
11DD-8000-D6217B60E588)
11DD-8000-D6217B60E588)
11DD-8000-D6217B60E588)
11DD-8000-D6217B60E588)
11DD-8000-D6217B60E588)
Now we're going to do the boot several times to show that the options do make it through correctly.
fs0:\> fs2:
fs2:\> install

All rights reserved

2. Install HP-UX B.11.23 (no pSCSI)
3. Install HP-UX B.11.23 (no FC)
4. Exit Boot Loader

loading section 0
................................................................................
............ (complete)
loading section 1
...
Once we get to the initial menu we can choose advanced options:

After choosing advanced options choose the option to edit the config file.
Once networking has been started and the vi editor (and dependencies) has been loaded you should see
something like:
server="10.30.128.20"
netmask[]="255.255.252.0"


(_noscsi == 1)
{
inventory_block_protocols = { "parallel_scsi" }
}
(_nofc == 1)
{
}
_nofc=1
_hp_default_cur_lan_dev="lan0"
server="10.30.128.20"
is_net_info_temporary=FALSE
system_name="vm006"
ip_addr[]="10.30.128.16"
netmask[]="255.255.252.0"
This matches the information printed initially that shows Fibre Channel is being blocked:

09:47:41 EDT 2008)
15:53:11 -0600 (Mon, 15 Oct 2007)
NOTE: Blocking protocol "fibre_channel".
* Setting keyboard language.
Similarly if we choose option 2 instead of option 3 at the boot loader it changes the protocol that is blocked
so parallel SCSI devices are blocked instead:
fs2:\> install

All rights reserved

2. Install HP-UX B.11.23 (no pSCSI)
3. Install HP-UX B.11.23 (no FC)
4. Exit Boot Loader

loading section 0
................................................................................
............ (complete)

loading section 1
................ (complete)
loading ram disk file (:IINSTALLFS).
................................................................................
.....................................
(complete)
Going through the advanced options menu to edit the config file using vi we can see that the contents now
correctly show that parallel SCSI devices should blocked:
server="10.30.128.20"
netmask[]="255.255.252.0"
(_noscsi == 1)
{
inventory_block_protocols = { "parallel_scsi" }
}
(_nofc == 1)
{
}
_noscsi=1
_hp_default_cur_lan_dev="lan0"
server="10.30.128.20"
is_net_info_temporary=FALSE
system_name="vm006"
ip_addr[]="10.30.128.16"
netmask[]="255.255.252.0"
According to the information also printed by Ignite-UX it is blocked:

09:55:00 EDT 2008)
15:53:11 -0600 (Mon, 15 Oct 2007)
NOTE: Blocking protocol "parallel_scsi".
4. Enable debug support when booting from one of the above DVD images, what information is
printed by Ignite-UX about boot loader options added to the configuration?
There is no working provided for this question. You should have determined the following to be true:
• If you attempt to pass more than one –i option via the boot loader only the last one will
be used.

• You cannot interrupt the Itanium boot loader when it is menu mode. Note however that if
you run it has “install -?” it will print a message about it being an invalid option and
present you with a HPUX> prompt.
• The best solution is to use the mechanism presented in question 3 where multiple lines of
configuration in the install filesystem are enabled with the use of a variable.
5. Create another DVD image based upon one of the above images, this time change the boot loader
option so it contains invalid configuration syntax. What errors do you see when Ignite-UX
attempts to process this configuration?
So we already have an auto file from question 2 that looks like:
# cat AUTO
reset
i'server=\"10.92.172.54\"'
i'server=\"10.92.174.54\"'
We can change it so it contains the SCSI protocol blocking configuration (set wrongly as it should be
parallel_scsi not just scsi) and copy if back into the EFI filesystem.
# cat AUTO
reset
"Install HP-UX B.11.23 (no custom settings)" boot :IINSTALL -
i'inventory_block_protocols={\\"scsi\\"}'
i'server=\"10.92.172.54\"' -i'inventory_block_protocols={\\"scsi\\"}'
i'server=\"10.92.174.54\"' -i'inventory_block_protocols={\\"scsi\\"}'
Now we create the minimal DVD image:



Then write the LIF directory to the start of the DVD image using instl_combine:
Then set the permissions and move the DVD image into place:
# chmod 444 dvd.lab4.q5

# mv dvd.lab4.q5 /var/dvd
Now we can boot from it. We're going to choose option 1 with just the inventory blocking protocol set to
SCSI. To do that however we need to eject the last DVD 186 and then insert the new one:
[vm006] vMP> ej
Ejectable Guest Devices

Num Hw-path (Bus,Slot,Tgt) Gdev Pstore Path
-------------------------------------------------------------------------
[1] 0/0/0/0.2.0 (0,0,2) dvd file /var/dvd/dvd.lab4.q1
Confirm eject action

G - Go
F - Force
[vm006] vMP> in
186
The answer to this lab was one after question 1. That is the reason why the question 1 minimal DVD
image is in the virtual drive and needed to be ejected. However after any reboot of a VM guest there will be
no DVD image present in the virtual DVD drive (when a directory is used as a backing store).


--------------------------------------------
[1] 0/0/0/0.2.0 (0,0,2) dvd

Num File
---------------------
[1] 0709.DVD.11.31
[2] MINDVD.11.23
[3] MINDVD.11.31
[4] dvd.lab4.q1
[5] dvd.lab4.q5
[6] tcpdump

G - Go
F - Force
Now we have to go back to the console but since the DVD has changed we need to do the map -r again:
fs0:\> map -r
11DD-8000-D6217B60E588)
11DD-8000-D6217B60E588)
11DD-8000-D6217B60E588)
11DD-8000-D6217B60E588)
11DD-8000-D6217B60E588)
fs0:\> fs2:
fs2:\> install

All rights reserved


4. Exit Boot Loader
Choose Operating System to Install : 1

loading section 0
...................................................
...
When Ignite started running it printed the following errors because of the bad inventory blocking protocol
setting:

06:54:38 EDT 2008)
15:53:11 -0600 (Mon, 15 Oct 2007)
ERROR: "/installfs.cfg", line 10: Unrecognized I/O config value: scsi.
ERROR: Problems were encountered while parsing config file: "/installfs.cfg".
WARNING: ramfs: cannot parse INSTALLFS config
ERROR: "/installfs.cfg", line 10: Unrecognized I/O config value: scsi.
ERROR: Problems were encountered while parsing config file: "/installfs.cfg".
WARNING: launch: cannot parse INSTALLFS config
ERROR: "", line 10: Unrecognized I/O config value: scsi.
ERROR: Problems were encountered while parsing config file.
WARNING: Could not parse concatenated local file, ignoring.
WARNING: Failed to read all config files from local sources.
Lab exercise 5 answers – File formats and product structure

1. What version of Ignite-UX was the first version to drop support for HP-UX B.10.20?
Ignite-UX version C.6.0 was the first version of Ignite-UX after support for HP-UX B.10.20 was dropped.
The document “Supported Versions of Ignite-UX” (not mentioned in the course notes) is available from the
following URL: http://www.docs.hp.com/en/IUX/supportinfo.html. This document contains information on
Ignite-UX versions back to version [AB].3.5. The information includes the planned end of support date and
any major issues with that version of Ignite-UX.
2. What version of Ignite-UX added support for HP9000 systems for HP-UX B.11.23 and what
version of Ignite-UX first added support for HP-UX B.11.31?
It’s a slightly unfair question since the first part is not in the course notes. The OE release of HP-UX
B.11.23 to add support for HP9000 systems was the September 2004 HP-UX B.11.23 OE release. The
version of Ignite-UX that shipped with that version was version B.6.0. It is mentioned in the document
“Supported Versions of Ignite-UX” (see above).
Support for HP-UX B.11.31 was first added in Ignite-UX version C.7.0. Review the document “Supported
Versions of Ignite-UX” please be aware that this version of Ignite-UX is no longer supported by HP (it had
a shortened end of life).
3. What version of Ignite-UX changed the name of the main bundle wrapper (containing the full
version of Ignite-UX) and what was the name of the bundle wrapper before and after the change?

The bundle wrapper changed in version C.7.0 and it changed from B5725AA to IGNITE.
4. Why can’t you install the version of Ignite-UX on OE or AR media onto a different version of HP-
UX (different to the HP-UX revision that the OE or AR media was intended for)?
The packaging of the product on OE/AR media makes it impossible to install the software correctly. The
only place you can get a version of Ignite-UX that will install onto any of the HP-UX revisions it supports
is from the web.
5. What is contained in the IGNT-JPN-E-MAN fileset in the Ignite-UX product?
This fileset contains Japanese ja_JP.eucJP manual pages.
6. How do you create the recovery commands depot if it does not already exist? If it does already
exist and you have issues with it how do you recreate it?
To create the recovery commands depot you need to run the command /opt/ignite/lbin/pkg_rec_depot. If
you are having problems with the depot you can force it to be recreated by running the same command with
the –f option.
7. In the recovery commands depot what is the IUX-Recovery bundle for? If you install this onto a
system can you create a recovery tape?
The IUX-Recovery bundle contains the filesets that are required for a system to run make_net_recovery.
Since this bundle does not contain any install kernels or other related files you are unable to run
make_tape_recovery if only this bundle is installed.
8. Why was the format of the flist file changed with Ignite-UX version C.7.1?
The format was changed to add the number of hard links, the inode number, and filesystem id. This allows
Ignite-UX to correctly calculate impacts statements for hard linked files instead of overstating them.
Previously Ignite-UX used to count the size of each hard linked file separately.
This could dramatically overstate the disk impacts. It was especially noticeable on HP-UX B.11.23 and
B.11.31 in /stand where there are multiple large kernels hard linked together.
9. The archive content file can include a keyword inc_entire. What is the effect of providing a disk
device as the argument?
The only time inc_entire should be used with a disk device is when the device is a whole disk fileset. That
will include the contents of the filesystem into a recovery archive. If the device is being used a raw device
(e.g. for a database) the contents of the disk will not be included into a recovery archive.
10. Run the following list_expander commands, can you explain the resulting output? You will need
to create the files for show to provide the archive_content file argument to list_expander.
inc_all_affected
# /opt/ignite/lbin/list_expander -dv –f archive_content_one
The output from the command (information about one volume group that does not contain any mounted
filesystems has been dropped from this and further output) looks like:
# /opt/ignite/lbin/list_expander -dv -f archive_content_one


/dev/vg00/lvol2
/dev/vg00/lvol3 / 2
/dev/vg00/lvol9 /var/opt/ignite/depots 2
/dev/vg00/lvol10
/dev/vg00/lvol11
/var/opt/ignite/recovery 2
As explained in the course notes inc_all_affected is the keyword behind the –A option to
make_net_recovery and make_tape_recovery so naturally the entire vg00 volume group would be included
into the archive.
include /var
include /opt
# /opt/ignite/lbin/list_expander -dv –f archive_content_two
This produces the following output:
# /opt/ignite/lbin/list_expander -dv -f archive_content_two

/dev/vg00/lvol2
/dev/vg00/lvol3 / 1
/dev/vg00/lvol10
/dev/vg00/lvol11
You might expect that this would have marked /var and /opt as fully included. The only time that
list_expander will currently mark a filesystem as fully included is if inc_all_affected has been used. In all
other cases filesystems will only be reported as being partially included.
inc_cross /
# /opt/ignite/lbin/list_expander -dv –f archive_content_three
With this output:
# /opt/ignite/lbin/list_expander -dv -f archive_content_three

/dev/vg00/lvol2
/dev/vg00/lvol3 / 1

/dev/vg00/lvol10
/dev/vg00/lvol11
We know that all of the files on the system will be included because there are no excludes and we have
included every filesystem from “/” downwards. Note again because we didn’t use inc_all_affected the
filesystems will still all reported as partially included even though we know that they’ve all been included.
11. Inspect the recovery commands command archive (list the contents using tar or pax), what file
present in the archive do you think is most likely to provide the recovery shell menu?
# cd /opt/ignite/data/Rel_B.11.31
# ll
total 318736
-r--r--r-- 1 bin bin 17951396 Apr 17 13:54 INSTCMDS
-r--r--r-- 1 bin bin 34834462 Apr 17 14:16 INSTCMDSIA
-r--r--r-- 1 bin bin 296254 Apr 17 13:54 RECCMDS
-r--r--r-- 1 bin bin 565686 Apr 17 14:16 RECCMDSIA
-r--r--r-- 1 bin bin 40824400 Apr 17 13:54 SYSCMDS
-r--r--r-- 1 bin bin 68655757 Apr 17 14:18 SYSCMDSIA
-r--r--r-- 1 bin bin 22813 Apr 17 12:53 config
-r--r--r-- 1 bin bin 927 Apr 17 14:04 hw_patches_cfg
# gzcat < RECCMDS |pax
./
./usr/
./usr/newconfig/
./usr/newconfig/sbin/
./usr/sbin/
./usr/bin/
./sbin/
./sbin/sh
./duped_root/
./duped_root/vxvm/
./duped_root/vxvm/VXVM.RECOVER
./duped_root/lvm/
./duped_root/lvm/LVM.RECOVER
./duped_root/lvm/lvmrec.scrpt
./duped_root/.kshrc
./duped_root/clr
./duped_root/more
./duped_root/dir
./duped_root/dsleep
./duped_root/load_util
./duped_root/menu
./duped_root/recover_system
./duped_root/search_util
./duped_root/status_of_mnt
./duped_root/dot_lftype
The program is called “menu”.
12. Why should you never modify a commands archive that is shipped with Ignite-UX? Given the
close relationship between the commands archives and install kernel/filesystem how do you think
this impacts on dual media recovery?

There is a close relationship between the install kernel, filesystem, and commands depots shipped with
Ignite-UX. When a new OE ships the install kernel, filesystem, and commands depots are rebuilt. There are
dependencies between all 3 things that need to be satisfied. Replacing any one of them can lead to failures.
When you use dual media recovery you use the install kernel and filesystem from a DVD/CD and the
commands archives from the tape. This is the reason why HP only supports using matched media and why
the version of Ignite-UX on the tape must match the version on the CD/DVD that is being booted from.
Lab exercise 6 Answers – network booting a system

Choose one of your systems to be the Ignite server, make sure that Ignite-UX is installed on the system.
1. Setup an entry in /etc/bootptab for your other system.
An example of how to create an entry in /etc/bootptab is available in the section “Booting the system and
capturing the initial PXE traffic (bootp)”. It looks like this:
ignite-defaults:\
ht=ethernet:\
hn:\
bs=48
vm011:\
ha=3ae253dac61a:\
ip=10.1.1.240:\
sm=255.0.0.0
You will need to set the hostname (change your entry so it uses your hostname rather than vm011 and you
will need to supply the MAC address of the lan interface you will be using instead of the ha entry above.
Note that the ignite-defaults entry should already be present in /etc/bootptab after installing Ignite-UX you
should not need to create it.
You should also be careful about accidentally adding any white space after the line contuation character
(“\”). Doing so will cause bootpd to log errors and ignore your bootptab entry.
Please ensure that bootpd is running (look in /etc/inetd.conf). If it is commented out please
uncomment it then run the command inetd –c.
2. Attempt to network boot your system, were you successful?
You should be since we are using /etc/bootptab. If people in the course were creating DHCP device group
entries you would not be able to be sure which Ignite server you would boot from. You could boot from
any server that responded.
3. From the system you are booting from capture the packets involved in tftp transfers. Do the files
requested by the booting client match those in the course notes?
See the sections “The files downloaded for booting (part 1)” and “The files downloaded for booting (part
2)” for examples on how to capture the traffic using tcpdump.
4. From the system you are booting from capture the packets involved in the DHCP transaction
between the client and server.
See the sections “Booting the system and capturing the initial PXE traffic (DHCP)” and “Booting the
system and capturing the initial PXE traffic (bootp)” for examples on how to capture the traffic using
tcpdump. The section on bootp is the more applicable section to look at.

Note that you can also choose to use netll if you wish to but this course does not discuss how to use it.
5. Describe what errors you see if you disable tftpd from running on your system?
First we needed to setup an entry in /etc/bootptab to allow this system to boot:
vm006:\
ha=4A6B4A03C4CE:\
ip=10.30.128.16:\
sm=255.255.252.0:\
gw=10.30.128.1:\
ds=10.30.130.46
And then comment out the tftp entry in /etc/inetd.conf so it looks like:
#tftp dgram udp wait root /usr/lbin/tftpd tftpd -s\

# /opt/ignite\
# /var/opt/ignite
Then run inetd –c so inetd knows that we’ve disabled tftpd:
# inetd –c
When lanbooting we now see PXE errors that should allow us to immediately see that tftpd is not running
on the Ignite server:
Shell> lanboot
Selected Acpi(PNP0A03,0)/Pci(1|0)/Mac(4A6B4A03C4CE)
Running LoadFile()
CLIENT MAC ADDR: 4A 6B 4A 03 C4 CE

GATEWAY IP: 10.30.128.1
Running LoadFile()
TFTP.
Shell>
6. Reenable tftpd but this time add the following line into /var/adm/inetd.sec:
tftp allow loopback
Next run inetd –c to allow inetd to see the changes made. What errors do you see when network
booting the system? Make sure that you ensure that no tftpd daemons are running before
attempting the network boot.
The tftp attempt will timeout because the tftpd daemon will not reply to the client (tftp uses UDP inetd on
the server will just drop incoming packets and not reply).
Shell> lanboot

Selected Acpi(PNP0A03,0)/Pci(1|0)/Mac(4A6B4A03C4CE)
Running LoadFile()
CLIENT MAC ADDR: 4A 6B 4A 03 C4 CE

GATEWAY IP: 10.30.128.1
Running LoadFile()
TFTP...\
Lab exercise 7 Answers – Network Booting – HP9000 systems

1. What is different between the initial boot of a HP9000 system and a HP Integrity system?
The initial step for HP9000 systems is to send out a bootp broadcast. HP integrity systems send out an
initial DHCP/PXE request. So the difference is HP9000 systems use bootp and HP Integrity systems use
DHCP/PXE. The bootp protocol only gets one answer back. DHCP sends out a request, gets an offer,
accepts an offer, then recieves an acknowledgement of the acceptance.
2. What difference(s) are there in how the files required by a HP9000 are stored and transfered
compared to a HP Integrity system?
There are multiple differences (giving any one of these answers is good enough to count as a correct
answer):
b. All of the "files" initially required for HP9000 systems are located in the one file
"/opt/ignite/boot/boot_lif" when each file is required the /opt/ignite/boot/boot_lif file is
opened the LIF directory inspected and then the file is read to get the actual file required
(the starting offset and size are in the LIF directory). On a HP Integrity system the files
c. There is also a limit one the size of files that can be accessed via tftp on HP9000 systems
- they must be less the 32MiB in size because the tftp implementation in HP9000
firmware can not set a block size. HP Integrity systems can negotiate a block size with
the tftpd daemon so they support larger files. The practical limit because of the size
limitation is on the size of the install kernels and filesystem for HP9000 systems.
d. The last practical difference is when the install filesystem is downloaded. On HP

Integrity systems the bootloader downloads both the install kernel and filesystem one
after the other and then sets the install kernel running. HP9000 systems download the
install kernel and then set it running, the install kernel makes a downcall into the
bootloader to then load the install filesystem.
3. What vendor specific options does a HP9000 system supply when booting (as part of the bootp
request)
The bootp magic number and an end of vendor specific options indicator. In effect it doesn't supply any
vendor specific options.
4. Indicate if the following questions are true or false
c. Loading an install kernel on a HP9000 system requires the vPar to perform a full network
boot?
False

d. Being able to boot a vPar on a HP9000 system implies network connectivity to the Ignite
server (or boot helper)?
False
e. Being able to boot a vPar on a HP Integrity system implies network connectivity to the
Ignite server (or boot helper)?
True
f. The size field in a lif is given in multiples of 512 bytes?
False, it's 256 bytes.
Lab exercise 8 Answers – How make_net_recovery works (part 1)

1. What environment variable is used to enable debug level logging by Ignite-UX commands?
The INST_DEBUG environment variable is used to enable debug level logging by Ignite-UX commands. It
must be exported into the environment to be it's most effective. That is run as:
# export INST_DEBUG=4
# make_net_recovery ...
or
# INST_DEBUG=4 make_net_recovery ...
2. Run lanscan and look at the MAC address of the lan interface. What issues do you think you might
have during a recovery if you were to change the MAC address (depending on the lan interface
you may or may not be able to change the burnt in address (BIA) of a lan interface).
If you change the MAC address of the LAN interface that Ignite-UX has used to create the client directory
on the Ignite server make_net_recovery will no longer be able to find the client directory and will create a
new one based on the new MAC address.
During a recovery the programmed MAC address won't be there it will be the original MAC address. You
might find yourself using the original client directory or if the system always used a programmable MAC
address find yourself unable to find the client directory and have no way to recover the system.
Once you realise what the problem is (which may not be easy to do) it's a simple fix - rename the client
directory and fix the host symlink to point to the correct directory.
3. What happens when you don't have a LAN interface that has an ethernet, FDDI, or token ring
(802.5) type MAC address?
You cannot have a client directory on an Ignite server so consequently you cannot use make_net_recovery?
4. When make_net_recovery fails a pax check what happens?
The make_sys_image command when performing the pax checks will tell you what patch needs to be
installed and will then ask if you want to continue anyway. If you do not answer within 10 seconds or
answer N/n it will exit causing an error. A Y/y will cause a warning to be issued, please note that if you
choose to ignore a recommended pax patch you may encounter problems that the patch is meant to address.

The pax checks are there for reasons - customers have reported all of them as problems with pax when used
with Ignite-UX.
5. What will be the return code from check_version when the following revisions are compared?
Server Client Exit Value

C.6.10.50 C.6.9.66 5
C.7.2.42 C.7.3.50 1
C.7.6.100 C.7.6.101 1
C.7.7.98 C.7.7.125 1
C.7.7.98 C.7.7.98 0
Assume that the -r -g -s <server> options are used when run from the client system.
The easiest way to do this is to make a copy of check_version:
# whereis check_version
check_version: /opt/ignite/lbin/check_version
# cp /opt/ignite/lbin/check_version /tmp
# vi /tmp/check_version
Find the following line and replace "$(cat /opt/ignite/Version)" with the values from the client column one
at a time:
Find the following code:
then
echo "get /opt/ignite/Version $VERS_FILE" | TFTP $server
echo ""
else
echo "get /opt/ignite/Version $VERS_FILE" | tftp $server >/dev/null 2>&1
fi
if [ -s $VERS_FILE ] ; then
server_vers="$(cat $VERS_FILE)"
compare_vers
else
# tftp failed may be due to the disabled tftp daemon on server
# we will try swlist to get the Ignite-UX verion of server
fs='Ignite-UX.RECOVERY Ignite-UX.MGMT-TOOLS'
# 11.00 swlist can produce copious WARNING messages when remotely swlisting
# newer systems, producing too much output. Send stderr to /dev/null.
...
fi
fi
Remove most of the code (from the starting if to the finishing fi) and just leave:
server_vers="<server_version>"
compare_vers
Make sure you can run the script and then run it:
# chmod 755 /tmp/check_version

# /tmp/check_version -v -r -g -s localhost
Version on this system: C.6.9.66
Version on server: C.6.10.50
# print $?
5
# print $?
1
# print $?
1
# print $?
1
# print $?
0
Lab exercise 9 Answers – How make_net_recovery works (part 2)

1. Why does HP not support newer versions of Ignite-UX on clients writing to an older version of
Ignite-UX running on an Ignite server?
In a way the answer is very simple in a lot of cases it doesn't work. If you use a newer version of Ignite-UX
and you were allowed to write an network recovery archive to the Ignite server there's a good chance that it
would fail to be recovered.
The configuration language used by Ignite-UX does change over time. As far as is possible compatibility is
preserved when the Ignite server moves upwards in version so older configuration language can be parsed
by newer versions of Ignite-UX. If you were to write new configuration language to an older Ignite server
there's no chance that it would understand it.
The example in the course was the introduction of the version= keyword into the configuration language
caused problems for a customer because they moved their recovery archives between Ignite servers. You
cannot move recovery archives from a newer version of Ignite-UX to an older version and have any
guarantee that they will work. Similarly if you remove a new version of Ignite-UX and install an older
version onto an Ignite server HP cannot guarantee that any archive made with the newer version of Ignite-
UX will be recoverable with the older version of Ignite-UX.
2. When using the -u option to make_net_recovery what issues could you encounter (in terms of the
various Ignite bundles)?
When the -u option is used with make_net_recovery installs the IUX-Recovery bundle from the recovery
commands depot if it determines that the version of Ignite-UX needs updating from the server. If you had
previously installed a bundle such as IGNITE or Ignite-11-31 you would end up with multiple versions of
the Ignite product with different fileset revisions in them. The make_net_recovery command (via
check_version) would report problems and you would need to manually cleanup the software.
3. Look at the /opt/ignite/lbin/update_tools script. When it is executed how does it determine if

Ignite-UX on the client system needs to be updated from the Ignite server?

When the return code from check_version (as called by update_tools) is "1" the script attempts to update
Ignite-UX from the recovery commands depot on the Ignite server.
4. In the upodate_tools script (when called by make_tape_recovery) why is additional work required
when it is found that the versions match?
Although the versions may match it may only be IUX-Recovery that is installed. There is less software
installed by the IUX-Recovery bundle than with the Ignite-XX-YY bundles. This includes install kernels
and filesystems. One of the Ignite-XX-YY bundles is required for make_tape_recovery support otherwise
all of the required files needed to create a recovery tape will not be present.
Important: The presence of the make_tape_recovery command does not mean that all of the files required
to create a recovery tape are present because of the way Ignite-UX is packaged in the recovery commands
depot.
5. Confirm on a HP Integrity system that the boot device has a LIF. Although not discussed in the
course why do you think the LIF exists?
The LIF exists because the LABEL file in the LIF is required by LVM when you have a bootable root
volume group.
6. On one of your client systems create the following archive_content files. Explain why
list_expander shows something as being fully included, partially include, or not included into the
recovery archive. Give the options that would be required for make_net_recovery to end up with
such an archive_content file.
inc_entire vg00
exclude /var/tmp
# /opt/ignite/lbin/list_expander -dv -f archive_content1

1 v /dev/vg00 0x00 /dev/disk/disk4_p2
/dev/vg00/lvol2
/dev/vg00/lvol3 / 2
The inc_entire is one of the two keywords that can make list_expander indicate that a filesystem is fully
included (inc_all_affected is the other). This includes all of vg00 but excludes the /var/tmp directory from
the archive. The options required for this archive_content file would be "-x inc_entire=vg00 -x
exclude=/var/tmp".
inc_cross /
exclude /var/tmp

/dev/vg00/lvol2
/dev/vg00/lvol3 / 1

Although list_expander indicates that all filesystems are only partially included this should be almost
functionally equivalent to the previous example. Everything except the contents of /var/tmp downwards
should be included into the archive and if there were any other local volume or disk groups they would all
be included into the archive. The options required for this archive_content file would be "-x inc_cross=/ -x
exclude=/var/tmp".
include /
include /opt
include /usr

/dev/vg00/lvol2
/dev/vg00/lvol3 / 1
Note that most filesystems are not included into this recovery archive making any recovery done much
more difficult. The reason why difficult is used as a description is that /var isn't included so there will be no
SD IPD recovered. That means very little ability to install software and you would need to recover the
missing parts of HP-UX from a backup tape the matched the recovery archive before proceeding further
with any recovery. The options required for this archive_content file would be "-x include=/ -x
include=/opt -x include=/usr".
inc_all_affected
exclude /var/tmp

/dev/vg00/lvol2
/dev/vg00/lvol3 / 2
The inc_all_affected option is the other option that can enable list_expander to show that a filesystem was
fully included into an archive note that the volume group is only shown as partial because /var/tmp was
excluded. The options required for this archive_content file would be "-A -x exclude=/var/tmp". Note that
the have inc_all_affected added to a archive_content file the -A option is used.
Important: When using the -A option if you have any content from another volume or disk group included
into the recovery archive. Ignite-UX will fully include it into the recovery archive and recreate the volume
or disk group during a recovery.

Lab exercise 10 Answers – How make_net_recovery works (part

3)
6. Run the following command (substitute <server> with the name of your Ignite server):
# make_net_recovery -A -p -s <server>
Using the configuration create by the preview command run make_arch_config the same way that
the make_net_recovery command does the answer the following questions. Please place the
resulting file into a new file name do not overwrite archive_cfg. Run the command using the -m
option to specify all three archive types.
You can do this on the Ignite server instead of the client. Doing this saves the need to manually mount the
client directory manually back onto the client.
# cd /var/opt/ignite/clients/vm001
# cd recovery/latest
# /opt/ignite/lbin/make_arch_config -c archive_cfg_1 -g flist -n cfg_1 -r ipf -
b 64 -d "test one" -L /var/opt/ignite/archives/ -l
vhost:/var/opt/ignite/archives/vm001 -i 2 -m t
b 64 -d "test two" -L /var/opt/ignite/archives/ -l
vhost:/var/opt/ignite/archives/vm001 -i 2 -m c
b 64 -d "test three" -L /var/opt/ignite/archives/ -l
vhost:/var/opt/ignite/archives/vm001 -i 2 -m p
6. If you gave a hostname with the -l option why does an IP address get written into the configuration?
# if nfs_source is used, be sure to export the source.

(source_type == "NET") {
nfs_source = "10.30.128.20:/var/opt/ignite/archives/vm001"
}
The IP address of the NFS source was converted to be an IP address because it is not known if DNS will be
available during the recovery session. This does bring up one implication if the IP address of the NFS
server containing the archives changes between creating it and needing to recover it you will have issues
7. Compare the sizes of the impacts for /stand are they different? Explain why they are this way.
For tar:
impacts = "/" 56Kb

impacts = "/stand" 40Kb
impacts = "/stand/krs" 16Kb
impacts = "/stand/current" 118672Kb
impacts = "/stand/last_install" 7568Kb
impacts = "/stand/backup" 8552Kb
For cpio:
impacts = "/" 56Kb


For pax:
impacts = "/" 56Kb

They are all the same and they should all be the same as the information was generated from the same
source (the flist file). The information is about the expect sizes of the files when they are recovered into the
final system. They are not related to the size of the files as they are stored in the recovery archive.
Note: the values for the -L and -l options to not mean very much they are written into the configuration but
since these configurations were generated for comparison reasons they do not need to actually point to an
archive. If you have previously created a network recovery archive using make_net_recovery use the
configuration directory for that session instead of creating a new preview session.
7. When generating impacts for an archive why might you sometimes want to generate them at a
higher level than 2? Note that for make_net_recovery the level that impacts are generated at is
determined automaticallty based upon the directory depth of mounted filesystems.
When determining impacts it's important to understand what happens when they are summarised to
different levels. Take the following filesystem hierarchy on a system:
/
/stand
/usr
/var
/var/tmp
/var/opt/ignite
/var/opt/ignite/depots
/opt
/home
If you had impacts generated at level 2 the impacts for the files in /var/opt/ignite/depots would be included
into /var/opt. Ignite-UX would force you to have enough space in /var (since /var/opt is part of /var) to
contain all of the files from /var/opt/ignite/depots even though they would be recovered into that separate
filesystem. It is possible that you may not have enough space to recover a system in this case. In this case if
/var/opt/ignite/depots was included into a recovery archive the impacts would be given at level 4.
The same would apply if /var/opt/ignite and /var/opt/ignite/depots did not exist. If the impacts were not at
level 4 creating a filesystem at /var/opt/ignite/depots to move a lot of files into a new filesystem would still
not allow you to reduce the size of /var at all because the level of impacts do not allow of the impacts to
affect the new filesystem (even though the files will be recovered there).
If you encountered this issue you may need to manually create impacts for the archive and edit the
archive_cfg file to replace the current impacts with new ones (or recreate the archive_cfg file using
make_arch_config with a different impact level).
You can affect the impacts of golden images directly but make_net_recovery automatically determines the
impact level for you. However it assumes that you will not be making major changes to filesystem layout
during a recovery.
8. The gen_impacts command is used to generate impacts (and is called by the make_arch_config
command to do so). Explain what recent changes were made to allow the impacts to be more
accurate.

The impacts recently were changed to work directly off the new fields added to the flist file. They take into
account the number of hard links a file has and the number of blocks that it occupies in the filesystem when
determining impacts. This however means that the expected sizes that they will occupy are based on them
being recovered to the same filesystem type as they were originally in. In 99.9% of cases this should be true.
9. In make_sys_image explain how the exit_vals file works.
The commands used to create the archive are run in a pipeline. To the shell, since make_sys_image is a
shell script, the only exit value available for a pipeline is the exit value of the last command. To work
around this and ensure that all of the commands in the pipeline were run successfully each command writes
its name and exit value into the exit_vals file.
This allows make_sys_image to determine if any of the commands run to create the recovery archive failed.
This is extremely important as we want to ensure that all of the commands succeeded so the user can be
notified if there were any issues creating the recovery archive.
10. Why does make_sys_image use functions like divide to perform math operations and other
functions like lessThan to perform mathematical comparisons?
The POSIX shell is limited in its integer math to values between -2147483648 to 2147483647 (it's
irrelevant to this discuss but the Korn shell and C shell have the same limitations). At times because of the
size of some filesystems make_sys_image needs to perform operations on and comparisons with numbers
larger than 2147483647.
Since make_sys_image is a shell script we can look at the script:
divide()
{
val1=${1}
val2=${2}
diff=$(bcMath "${val1} / ${val2}")
echo ${diff}
}
The bcMath function calls the bc command to perform arbitrary precision math:
#
# Backbone of all the math operators.
#
bcMath()
{
bcArg=${1}
# Commented out becuase we may some day not want to have integer
# arithmatic and this would be the way to get floating point values.
#retVal=$(echo "scale=10; ${bcArg}" | bc)
# Use interger math for now.

retVal=$(echo "${bcArg}" | bc)
echo ${retVal}
}
Comparisons are performed sightly differently - they do not use bc to perform comparisons but perform
operations and look at the results, for example with lessThan:

# If val1 is less than val2 then return 1. Otherwise return

# 0.
#
# For example if val1=10 and val2=9 then:
# 10 - 9 = 1 so we would return 0
# If val1=9 and val2=10 then:
# 9 - 10 = -1 so we would return 1
#
lessThan()
{
val1=${1}
val2=${2}
ret=0
diff=$(subtract ${val1} ${val2})
minus=$(echo ${diff} | cut -c1)
if [[ ${minus} = "-" ]]
then
ret=1
fi
echo ${ret}
}
If the result of subtracting the two (so the first argument must be less than the second) 1 is returned to
indicate true otherwise 0 is returned (false).
11. Why in the filter_missing_files script generated by make_sys_image is it important that the -L
option is used first in the test to see if the file still exists or not?
In this case lstat64() is called against the file to determine of it is a symbolic link (stat64() would follow the
symbolic link and return results for what it pointed to). When a system has non-responsive NFS filesystems
it can be dangerous to follow symbolic links indescriminantly. For this reason it is important to use the -L
option first to see if the file is a symbolic link before testing for other file types.
Lab exercise 11 Answers – How make_net_recovery works (part

4)
4. What command is used before HP-UX B.11.31 to export filesystems? From HP-UX B.11.31 what
command is used? What permanent file is used to store the exported filesystems?
Up to and including HP-UX B.11.23 the exportfs command was used to export filesystems, on HP-UX
B.11.31 onwards the share command will be used. Up to and including HP-UX B.11.23 the file /etc/exports
is used to hold the permanently exported filesystems. On HP-UX B.11.31 the file is /etc/dfs/dfstab.
5. What version of NFS must be in use to create a large recovery archive? How do you tell what
version of NFS is in use by a make_net_recovery session?
You must be using NFS v3 or later (it does not matter if it is udp or tcp based NFS) to create large files.
Note that this assumes that the destination filesystem on the archive server supports large files, if it does not
creating a large file will still fail.
You need to look at the /etc/mnttab file (cat the file). NFS versions above version 2 will give the NFS
version being used as part of the filesystems entry in /etc/mnttab.

6. Explain everything exported by Ignite-UX (especially the places writable via NFS must be owned
by bin).
On the client system the make_net_recovery command must be run as root. Typically unless you've
allowed root access (as root) via NFS to a filesystem files created by root will be owned by
nobody:nogroup. This makes things difficult for Ignite-UX as it becomes very difficult to manage the files.
For this reason Ignite-UX exports the filesystem with -anon=bin. This means anonymous access (that is
access by a remote root user) gets translated to be access by the bin user instead of the nobody user and
allows make_net_recovery to effectively manage the files that it needs to.
Lab exercise 12 Answers – A quick look at save_config

1. Ignite-UX shares a significant portion of source code with another product do you know what that
product is?
The product is DRD (Dynamic Root Disk). A significant amount of code from Ignite-UX is used within the
DRD product.
2. The save_config program is a script. How much easier to troubleshoot what is happening within
the script?
If you don't have access to the Ignite source code it makes it much easier to troubleshoot what is happening
when an error comes from a script. You can read and follow the shell scrpt through what it is doing to
determine the cause of a problem.
Lab exercise 13 Answers – How make_tape_recovery works

(part 1)
1. Answer the following true false questions:
a. The make_tape_recovery command is a completely different program to the

make_net_recovery command.
False, they are in fact hard links to each other so they are in fact the same command with different names.
b. It is almost impossible to troubleshoot the make_tape_recovery command without access

to the source code.
False, although a significant portion of make_tape_recovery is compiled a lot of the functionality is

presented in scripts. If a problem occurs in a script anyone can read and troubleshoot them. Even with the
compiled parts of make_tape_recovery with debug messages enabled it is possible to gather a lot of
information about what may be going wrong and what might need to be investigated.
c. When the lock file exists (/var/opt/ignite/recovery/mnr_lockfile) and

make_tape_recovery cannot lock it you should not remove it without investigating why it
is locked.
True, if the file wasn't locked make_tape_recovery would lock it and continue to create a recovery tape. If
the file is locked you need to be careful about removing it as there may be another instance of
make_net_recovery or make_tape_recovery running. That needs to be investigated before you could
remove the file.

2. Since you are unlikely to have two tape drives attached to your systems set two copies of
make_net_recovery running (with the -p option). Do both make_net_recovery sessions run, if you
get an error from one of them what error do you get?
As you can see one session starts and completes the preview successfully:
# make_net_recovery -p -A -s vhost
mkdir: cannot create test: File exists
prealloc: /var/opt/ignite/tmp/pax_test/test/inp1.txt: File exists
prealloc: /var/opt/ignite/tmp/pax_test/test/inp.txt: File exists
* Creating NFS mount directories for configuration files.
======= 07/25/08 05:38:24 EST Started make_net_recovery. (Fri Jul 25 05:38:24

EST 2008)
@(#)ignite/net_recovery (opt) Revision:
/branches/IUX_RA0809_PAX/ignite/src@75355 Last Modified: 2008-09-03
15:56:16 -0600 (Wed, 03 Sep 2008)
* Checking Versions of Recovery Tools

* Creating System Configuration.
* /opt/ignite/bin/save_config -f /var/opt/ignite/recovery/client_mnt/0xE
A1E498D1674/recovery/2008-07-25,05:38/system_cfg vg00
* Backing Up Volume Group /dev/vg00
* /usr/sbin/vgcfgbackup /dev/vg00
* Creating Map Files for Volume Group /dev/vg00
* /usr/sbin/vgexport -s -p -m /etc/lvmconf/vg00.mapfile /dev/vg00
* Creating Control Configuration.

* Creating Archive File List
* Creating Archive Configuration
* /opt/ignite/lbin/make_arch_config -c /var/opt/ignite/recovery/client_m
nt/0xEA1E498D1674/recovery/2008-07-25,05:38/archive_cfg -g /var/opt/ig
nite/recovery/client_mnt/0xEA1E498D1674/recovery/2008-07-25,05:38/flis
t -n 2008-07-25,05:38 -r ipf -b 64 -d Recovery\ Archive -L
/var/opt/ignite/recovery/arch_mnt -l
vhost:/var/opt/ignite/recovery/archives/vm001 -i 1 -m t
* Saving the information about archive to
/var/opt/ignite/recovery/previews
*
* **** This is just Preview Only. ****

* **** No archive has been created yet. ****
* **** You may modify the configure files ****
* **** and use -r option for resuming to create archive. ****
======= 07/25/08 05:39:30 EST make_net_recovery completed successfully!
The other session ends end with an error. The session did not print that it had started so it does not print that
it had a completed either.
# make_net_recovery -p -A -s vhost
prealloc: /var/opt/ignite/tmp/pax_test/test/a.txt: File exists
ERROR: Another instance of make_net_recovery/make_tape_recovery is already
running.

You can ignore the errors about mkdir and prealloc in the output from both commands. The commands
were performing the pax checks similtaneously, this causes some error messages to be printed because a
directories and files existed that the command did not expect to exist.
3. Why doesn't a recovery tape have the same issues with compatibility between Ignite-UX versions
like make_net_recovery?
Compatibility issues are mostly not an issue for a recovery tape as it is a self contained recovery
mechanism. Since it is self contained it cannot be used with a different version of Ignite-UX, the version of
Ignite-UX that created it is the version of Ignite-UX that it has on the tape.
Note that this does not always apply. For example with dual media recovery if you use mismatched media
(which is not supported) you are introducing an external influence that can impact on the outcome of a
recovery attempt. Problems generated in this case are usually related to a mismatch between the kernel and
commands or commands and libraries they are linked to rather than version issues that were discussed
about make_net_recovery.
4. Explain the use of the configuration variable _hp_hide_other_disks.
The configuration variable _hp_hide_other_disks holds information about the disks that are currently
configured into volume and disk groups (or used as whole disks). When devices are listed in this variable
they are hidden from view in itool - they cannot be used by Ignite-UX for any purpose.
The definition of the variable looks like:
_hp_allow_use_of_imports help_text "Allow use of other disks"

enum _hp_allow_use_of_imports
init _hp_allow_use_of_imports = "NO"
_hp_hide_other_disks visible_if false
_hp_allow_use_of_imports = { "YES", "NO" }
(_hp_allow_use_of_imports == "NO")
{
_hp_hide_other_disks = "0/3/2/0.1.31.0.0.6.0 0/4/2/0.2.31.0.0.6.0"
} else {
_hp_hide_other_disks = ""
}
The definition of _hp_hide_other_disks is conditional upon the variable _hp_allow_use_of_imports. This

normally defaults to "NO" but it is possible to change its value during an interactive recovery to "YES" if
you need to access the disks that have been hidden. In most cases it's rare to need to do this, very few
customers need to be able to do this.
Note the following fix available from Ignite-UX version C.7.5 onwards:
* QXCR1000746998. Data disks configured as VxVM and whole-disk

that are to be imported after a recovery are now correctly hidden
from the user (to prevent accidentally overwriting them). Prior to
this release, only LVM disks to be imported were hidden.
make_net_recovery and make_tape_recovery now list those disks in
the _hp_hide_other_disks variable.
5. What command is used to syntax check configuration files after they have been generated?
The instl_adm command with the -T option is used to test configuration files (the file to test is given with
the -f option).

Lab exercise 14 Answers – How make_tape_recovery works

(part 2)
1. What kind of ANSI label is written by make_sys_image on HP Integrity systems?
A UHL3 header that describes the archive.
2. What issues do you forsee with a recovery tape on a HP Integrity system if a tape drive is not
claimed by the stape or (HP-UX B.11.31 only) estape drivers?
The UHL3 header that describes the archive will not be written to the tape. Such a tape will not be
recoverable - even using dual media recovery.
3. How many of the 23 files present on a recovery tape for a HP Integrity server are created by
make_ipf_tape and how many by make_sys_image?
21 out of the 23 files are created by make_ipf_tape and 2 are created by make_sys_image. Out of interest
15 out of the 23 files are ANSI labels.
Lab exercise 15 Answers – check_net_recovery and

check_tape_recovery
Please follow the steps and answer the questions. You should have already created either a network
recovery archive or a preview of one. Run check_net_recovery from the client system to the Ignite server.
1. How many files have been added, deleted, or changed since the last time make_net_recovery was
run? Note that check_net_recovery makes no distinction between a preview session and an actual
run on make_net_recovery.
The information is shown the summary line at the end of the command:
# check_net_recovery -s vhost
Generating new list of files
Comparing file lists
Added: /tmp/lanscan18983
Added: /var/opt/ignite/client.mnt
Added: /var/spool/cron/tmp/croutGKN001662
Added: /var/tmp/chk_rec.tmp.18983
Deleted: /var/opt/ignite/recovery/mnr_lockfile
Deleted: /var/opt/ignite/tmp/mnr_AAA015802
Deleted: /var/opt/ignite/tmp/mnr_AAA015802/hw.info
Deleted: /var/opt/ignite/tmp/mnr_AAA015802/io.info
Deleted: /var/opt/ignite/tmp/mnr_AAA015802/vgdisplay.tmp
Deleted: /var/opt/ignite/tmp/mnr_AAA015802/vol.tmp
Changed: /dev/null mtime: 1216928322 --> 1216938600
Changed: /dev/pts/ta mtime: 1216928303 --> 1216938766
Changed: /dev/pts/tb mtime: 1216928322 --> 1216937002
Changed: /tmp mtime: 1216928322 --> 1216938766
Changed: /tmp/.s.PGSQL.10864.lock mtime: 1216928122 --> 1216938622
Changed: /var/adm/cron/log mtime: 1216928356 --> 1216938736 size:
1369985 --> 1398565
Changed: /var/adm/kcmond/day mtime: 1216928082 --> 1216938582
Changed: /var/adm/kcmond/hour mtime: 1216928082 --> 1216938582
Changed: /var/adm/kcmond/month mtime: 1216928082 --> 1216938582
Changed: /var/adm/kcmond/year mtime: 1216928082 --> 1216938582
Changed: /var/adm/util mtime: 1216928100 --> 1216938601

Changed: /var/adm/util/108_205_-1C mtime: 1216928100 --> 1216938601

size: 53824 --> 61804
Changed: /var/adm/util/108_205_-1O mtime: 1216928100 --> 1216938601
size: 83088 --> 95408
Changed: /var/adm/util/108_205_FSS_0_-1R mtime: 1216928100 -->
1216938601 size: 24560 --> 28200
Changed: /var/adm/util/108_205_PSET_0_-1R mtime: 1216928100 -->
1216938601 size: 24560 --> 28200
Changed: /var/adm/util/disk_hw mtime: 1216928100 --> 1216938601
Changed: /var/adm/util/lan_hw mtime: 1216928100 --> 1216938601
Changed: /var/adm/vx/cmdlog mtime: 1216928356 --> 1216938767 size:
8644 --> 8756
Changed: /var/evm/evmlog/evmlog.20080725 mtime: 1216928340 -->
1216938241
Changed: /var/evm/shared mtime: 1216928340 --> 1216938241
Changed: /var/opt/ignite mtime: 1216429621 --> 1216938766
Changed: /var/opt/ignite/recovery mtime: 1216339176 --> 1216928371
Changed: /var/opt/ignite/recovery/client_mnt mtime: 1221977920 -->
1221473355 size: 8192 --> 96
Changed: /var/opt/ignite/recovery/previews mtime: 1216423794 -->
1216928370
Changed: /var/opt/ignite/tmp mtime: 1216928356 --> 1216938767
Changed: /var/opt/perf/datafiles/classinfo.db mtime: 1216928340 -->
1216938780
Changed: /var/opt/perf/datafiles/logappl mtime: 1216928100 -->
1216938600 size: 15182072 --> 15193368
Changed: /var/opt/perf/datafiles/logdev mtime: 1216928101 --> 1216938600
size: 18466436 --> 18525556
Changed: /var/opt/perf/datafiles/logglob mtime: 1216928100 -->
1216938600 size: 27669988 --> 27684040
Changed: /var/opt/perf/datafiles/logproc mtime: 1216928340 -->
1216938780 size: 386016 --> 387608
Changed: /var/opt/perf/datafiles/logtran mtime: 1216928101 -->
1216938600 size: 7582044 --> 7623060
Changed: /var/opt/sfmdb/pgsql/global mtime: 1216927493 --> 1216938294
Changed: /var/opt/sfmdb/pgsql/global/pgstat.stat mtime: 1216927493 -->
1216938294
Changed: /var/opt/wbem/localauth mtime: 1216928356 --> 1216938736
Changed: /var/spool/cron/tmp mtime: 1216928356 --> 1216938780
Changed: /var/spool/sockets/pwgr mtime: 1216928356 --> 1216938780
Changed: /var/tmp mtime: 1216928356 --> 1216938767
Changed: /var/tmp/ign_configure mtime: 1216928356 --> 1216938767
Changed: /var/tmp/ign_configure/make_sys_image.log mtime: 1216928356 -->
1216938767
Summary: Archive has 106430 records, system has 106428 records. 4 Added, 6
Deleted, 39 Changed
There are a few things to note:
- The make_net_recovery/make_tape_recovery commands in the filter_dead_files script does not update

the flist. If there were files missing then they will be reported as deleted files.
- The check_net_recovery and check_tape_recovery never make recommendations on if a new recovery
archive should be created they only present information comparing the flist file from when the recovery
archive was created and compare that to the current system.
2. Look at the check_net_recovery script if you wanted to perform the functionality equivalent task as the
script what commands would you run?
The commands required look like:
# mkdir -p /var/opt/ignite/client.mnt

# mount -o soft,bg vhost:/var/opt/ignite/clients /var/opt/ignite/client.mnt

# /opt/ignite/lbin/list_expander -S -f
/var/opt/ignite/client.mnt/vm001/recovery/latest/archive_content -l
/var/tmp/chk_rec.tmp.shane
# /opt/ignite/lbin/chk_rec -o
/var/opt/ignite/client.mnt/vm001/recovery/latest/flist -n
/var/tmp/chk_rec.tmp.shane
Added: /var/opt/ignite/client.mnt
Added: /var/tmp/chk_rec.tmp.shane
Deleted: /var/opt/ignite/recovery/mnr_lockfile
Deleted: /var/opt/ignite/tmp/mnr_AAA015802
Deleted: /var/opt/ignite/tmp/mnr_AAA015802/hw.info
Deleted: /var/opt/ignite/tmp/mnr_AAA015802/io.info
Deleted: /var/opt/ignite/tmp/mnr_AAA015802/vgdisplay.tmp
Deleted: /var/opt/ignite/tmp/mnr_AAA015802/vol.tmp
Changed: /dev/null mtime: 1216928322 --> 1216941300
Changed: /dev/pts/ta mtime: 1216928303 --> 1216941519
Changed: /dev/pts/tb mtime: 1216928322 --> 1216937002
Changed: /tmp mtime: 1216928322 --> 1216938787
Changed: /tmp/.s.PGSQL.10864.lock mtime: 1216928122 --> 1216941322
Changed: /var/adm/cron/log mtime: 1216928356 --> 1216941495 size:
1369985 --> 1406174
Changed: /var/adm/kcmond/day mtime: 1216928082 --> 1216941282
Changed: /var/adm/kcmond/hour mtime: 1216928082 --> 1216941282
Changed: /var/adm/kcmond/month mtime: 1216928082 --> 1216941282
Changed: /var/adm/kcmond/year mtime: 1216928082 --> 1216941282
Changed: /var/adm/util mtime: 1216928100 --> 1216941300
Changed: /var/adm/util/108_205_-1C mtime: 1216928100 --> 1216941300
size: 53824 --> 63856
Changed: /var/adm/util/108_205_-1O mtime: 1216928100 --> 1216941300
size: 83088 --> 98576
Changed: /var/adm/util/108_205_FSS_0_-1R mtime: 1216928100 -->
1216941300 size: 24560 --> 29136
Changed: /var/adm/util/108_205_PSET_0_-1R mtime: 1216928100 -->
1216941300 size: 24560 --> 29136
Changed: /var/adm/util/disk_hw mtime: 1216928100 --> 1216941300
Changed: /var/adm/util/lan_hw mtime: 1216928100 --> 1216941300
Changed: /var/adm/vx/cmdlog mtime: 1216928356 --> 1216941520 size:
8644 --> 8812
Changed: /var/evm/evmlog/evmlog.20080725 mtime: 1216928340 -->
1216940941
Changed: /var/evm/shared mtime: 1216928340 --> 1216940941
Changed: /var/opt/ignite mtime: 1216429621 --> 1216941495
Changed: /var/opt/ignite/recovery mtime: 1216339176 --> 1216928371
Changed: /var/opt/ignite/recovery/client_mnt mtime: 1221977920 -->
1221473355 size: 8192 --> 96
Changed: /var/opt/ignite/recovery/previews mtime: 1216423794 -->
1216928370
Changed: /var/opt/ignite/tmp mtime: 1216928356 --> 1216941520
Changed: /var/opt/perf/datafiles/classinfo.db mtime: 1216928340 -->
1216941480
Changed: /var/opt/perf/datafiles/logappl mtime: 1216928100 -->
1216941300 size: 15182072 --> 15196056
Changed: /var/opt/perf/datafiles/logdev mtime: 1216928101 --> 1216941300
size: 18466436 --> 18540612
Changed: /var/opt/perf/datafiles/logglob mtime: 1216928100 -->
1216941300 size: 27669988 --> 27687532
Changed: /var/opt/perf/datafiles/logproc mtime: 1216928340 -->
1216938840 size: 386016 --> 388168
Changed: /var/opt/perf/datafiles/logtran mtime: 1216928101 -->
1216941300 size: 7582044 --> 7633212
Changed: /var/opt/sfmdb/pgsql/global mtime: 1216927493 --> 1216940994

Changed: /var/opt/sfmdb/pgsql/global/pgstat.stat mtime: 1216927493 -->

1216940994
Changed: /var/opt/wbem/localauth mtime: 1216928356 --> 1216941495
Changed: /var/spool/cron/tmp mtime: 1216928356 --> 1216941495
Changed: /var/spool/sockets/pwgr mtime: 1216928356 --> 1216941520
Changed: /var/tmp mtime: 1216928356 --> 1216941520
Changed: /var/tmp/ign_configure mtime: 1216928356 --> 1216941520
Changed: /var/tmp/ign_configure/make_sys_image.log mtime: 1216928356 -->
1216941520
Summary: Archive has 106430 records, system has 106426 records. 2 Added, 6
Deleted, 39 Changed
# rm /var/tmp/chk_rec.tmp.shane
# umount /var/opt/ignite/client.mnt
# rmdir /var/opt/ignite/client.mnt
Note that normally check_net_recovery uses a file name of /var/tmp/chk_rec.tmp.$$ instead of

/var/tmp/chk_rec.tmp.shane. It would have been confusing to use $$ since it would have been hard to locate
the file.
Lab exercise 16 Answers – cold install and recovery (part 1)

1. Why does an Ignite program called init run before the real init is started.
The reason for this is that there are some things that need to be done by Ignite-UX before the real init starts.
The most important reason however is that the real init does not understand the additional argument that
can be communicated to Ignite-UX via the -i option in the bootloader arguments. If the real init ran it
would attempt to startup in single user mode when it does not understand the arguments.
2. Are the following statements true or false?
- Ignite-UX can install software in all phases of a recovery/installation session
False, Ignite-UX does not install software in phase 3.
- Ignite-UX can only install software in only the first two phases of a recovery/installation
session
True, if there is a core OS archive it is installed in phase 1 all other software is installed in phase 2.
- Ignite-UX creates the kernel in phase 2
True. If a kernel needs to be created it is created in phase 2.
- Ignite-UX creates volume/disk groups and filesystems in phase 2
False, Ignite-UX creates volume/disk groups and filesystems in phase 1.
- There are four phases to an recovery/installation session.
False there are 3 phases to a recovery/installation session.
3. Create a logical volume large enough to hold the HP-UX B.11.31 install filesystem. Place the
filesystem into the logical volume and then answer the following questions:
We can create the mount the install filesystem in the following way:

# dd if=IINSTALLFS of=/dev/vg00/rlvol12 bs=64k
936+0 records in
936+0 records out
# mount /dev/vg00/lvol12 /cdrom
# cd /cdrom/sbin
1. How many hard links does sbin/init have?
# ll init
-r-xr-xr-x 18 bin bin 2899088 Sep 4 14:27 init
There are 18 hard links listed for sbin/init
2. Is the inode number between sbin/init and sbin/ramfs the same?
# ll -i init ramfs
34 -r-xr-xr-x 18 bin bin 2899088 Sep 4 14:27 init
34 -r-xr-xr-x 18 bin bin 2899088 Sep 4 14:27 ramfs
Yes, they share the same inode number. This means that they the same file with different names.
3. Run what on both programs. Can you tell the version of Ignite-UX they are assocated with?
# what init ramfs

init:
ignite/launch (opt) Revision: /branches/IUX_RA0809_PAX/ignite/src@75355
Last Modified: 2008-09-03 15:56:16 -0600 (Wed, 03 Sep 2008)
20 Nov 2007) $
ramfs:
ignite/launch (opt) Revision: /branches/IUX_RA0809_PAX/ignite/src@75355
Last Modified: 2008-09-03 15:56:16 -0600 (Wed, 03 Sep 2008)
20 Nov 2007) $
Yes, they noth report the same information and in this case they are from Ignite-UX version C.7.7.125.
Please note that this was not the release version of Ignite-UX, the only version you should ever see outside
of HP is version C.7.7.98.

1. Answer the following:
- What happens when the following message is shown "* Mapping LUN Instance Data"?
Instance information for I/O devices are restored (on HP-UX B.11.31 only).
- What directory in the ram filesystem are the disk filesystems mounted on?

/d_cfg_mnt_sb61
- Explain why commands archives are path relative rather than absolute (e.g.
SYSCMDS/SYSCMDSIA or a core OS archive).
The commands archives are path relative as they can be accessed both before and after the chroot. If they
had absolute paths it would be difficult to extract onto the disk filesystems mounted at /d_cfg_mnt_sb61
before the chroot happened. Similarly for the Core OS archive if it was absolute it would be hard to extract
before the chroot. By convention however all archives should be path relative (it doesn't strictly matter for
non-Core OS archives however).
- What is the difference between the -o and -s options to monitor_bpr?
The -o option is for the order of an archive and the command periodically prints the size extracted. With the
-s option the command knows the size in KiB so it can print percentage complete messages.
- During archive extraction why is the "-p e" option to pax used?
The following is from the pax manual page:
-p string Specifies one or more file characteristics to be

retained or discarded on extraction. The string
argument consists of the characters a, e, m, o, and p.
Multiple characteristics can be concatenated within the
same string and multiple -p flags can be specified. The
specification flags have the following meanings:
a Does not retain file-access times.
e Retains the user ID, group ID, access permission,

access time, and modification time.
m Does not retain file-modification times.
o Retains the user ID and the group ID.
p Retains the access permission.
Note that "retain" means that an attribute stored in

the archive is given to the extracted file, subject to
the permissions of the invoking process; otherwise, the
attribute is determined as part of the normal file
creation action.
The "-p e" option is used to ensure that the user ID, group ID, access permission, access time, and
modification time of the files in the archive are retained.
2. At this point create a full network recovery archive if you have no done so already. Once complete
recover the recovery archive with debug level logging enable from boot. Note that you will
probably have to setup /etc/bootptab on your Ignite server (which is likely to be the virtual
machine host).

1. Using the functionality provided by os_arch_post_l why might you consider changing a file
usually saved by merge_file to use save_file?

You would consider doing this when you did not want Ignite-UX to change the file during a recovery. Note
that this makes the recovery archive less useful for cloning. If you were to change something via Ignite-UX
that required the file to be updated it would still be saved and recovered "as is".
2. When cloning why does os_arch_post_l remove /stand/vmunix in recovery mode? Why is this step
not required for a golden image install?
The reason for this is that when cloning it is relatively likely the system being cloned with be different to
the system that will end up being recovered. As an example if the boot device is on a HBA that the original
kernel does not have a driver for and the kernel is not rebuilt based on the new hardware the client would
panic on first boot as it would not be able to access the boot device after the kernel was loaded.
The reason why this isn't done for a golden image install is when make_sys_image is run at clean level 2
/stand/vmunix is not included into the archive. Remember: It's not a golden image unless it was created by
make_sys_image at clean level 2. Clean level 1 is only intended for recovery archives - it is not a golden
image.
3. If the full make_net_recovery run earlier is complete please recover the system with debug level
logging set to 3. Please use the boot loader option -i3 to perform to enable debug level logging.
No answer required. Please recover the system.
4. Have a look at the /etc/mnttab file on HP-UX B.11.31 (if possible), how does it compare to an
earlier release of HP-UX (follow any applicable symbolic links). How do you think the
undocumented ioctl enables any leading /d_cfg_mnt_sb61 to be removed from the mount points
and hide the install filesystem mounted at /?
On HP-UX B.11.31 /etc/mnttab is a symbolic link to /dev/mnttab and /dev/mnttab is a device file:
# ll /etc/mnttab
lrwxr-xr-x 1 root sys 11 Jul 19 10:47 /etc/mnttab ->
/dev/mnttab
# ll /dev/mnttab
crw-r--r-- 1 root sys 33 0x000000 Jul 19 08:59 /dev/mnttab
The undocumented ioctl that removes the leading /d_cfg_mnt_sb61 from mnttab entries and hides the real /
filesystem can do so because it is in the kernel and can modify the filesystem information being read before
it becomes visible to user space programs.
4. From Ignite-UX version C.7.7 onwards Ignite-UX may no longer recover all of the instance
numbers it previously did - why is this?
From that version of Ignite-UX onwards the kernel is asked if the instance numbers need to be preserved or
not. If the kernel reports that they do not need to be preserved Ignite-UX will not attempt to do so.

1. Prior to HP-UX B.11.31 how does Ignite-UX determine if swconfig needs to be run later to
configure software?
The last modification date on the /var/adm/sw/swinstall.log file is tracked to determine if any software has
been installed via swinstall. This could also apply to HP-UX B.11.31 if any command hooks have been
used to install software. If the last modification date has changed then swconfig will need to be executed
later.

2. When handling the KRS why is nothing done for HP-UX B.11.11 and why are /SAS and
/dumpinfo dropped from the KRS?
Nothing is done for HP-UX B.11.11 because it does not have a KRS.
The contents of /SAS in the KRS are not preserved because Ignite-UX handles the recovery of SAS
information separately. The dump devices are also handled as part of the recovery so the contents of
/dumpinfo are not required to be preserved during a recovery.
3. When Ignite-UX add inittab entries for phase 3 why are most of them run with bootwait?
The manual page inittab(4) contains the following definition of bootwait:
bootwait Process the entry only at boot init's

boot-time read of the inittab file.
Boot init starts the process, waits
for its termination, and, when it
dies, does not restart the process.
Most of the entries written by Ignite-UX contain bootwait this allows them to run as part of the boot
process before any of the regular inittab entries get run. Those entries can continue the recovery then
remove themselves when complete.
The fsdaemon entries use sysinit because they have to start before everything else starts:
sysinit Entries of this type are executed

before boot init tries to access the
console. It is expected that this
entry will be only used to initialize
devices on which boot init might
attempt to obtain run level
information. These entries are
executed and waited for before
continuing.
From the fsdaemon(1m) manual page:
DESCRIPTION
The fsdaemon is a user level daemon that provides a mechanism to pass
information between applications and common commands and library
functionality, allowing certain applications to dynamically add
functionality to a system. This is currently only supported for the
statvfsdev class of APIs, such as: statvfsdev(), fstatvfsdev(),
statfsdev(), fstatfsdev()).
The fsdaemon daemon needs to be running before any of the statvfsdev() family of APIs can be used on
HP-UX B.11.31.

1. Consider the issue of what happens when the client directory is accessed using NFS and an error
occurs when the client directory is not mounted. How would you gather information about a
problem like that?
The main way to gather information in this situation is to look at what is happening on the console. It's the
only easily accessable place where information about what Ignite-UX is doing will always be available.

3. Consider some of the things that happened earlier in the recovery. Ignite-UX knows about the
impacts associated with software it will install but nothing takes into account temporary space
used in places like /tmp/ign_configure, /, and places in /var (and when files such as SYSCMDS
are extracted onto the disk filesystems). How might this extra space usage impact on what Ignite-
UX does?
By default there is unlikely to be any impact. Assuming that there is additional unused disk space available
the default setting of _hp_addnl_fs_free_pct will force the size of filesystems to be expanded. If they are so
full when an archive is created they would be forced to be larger. The definition of _hp_addnl_fs_free_pct
from the instl_adm(4) manual page is:
_hp_addnl_fs_free_pct
Integer variable used to control the amount of additional free
space (or "breathing room") allocated to volumes beyond the space
required to load the software. If this variable is not set, it
defaults to 10 (10%). See the definition for the file system
size keyword attribute for more details.
This assumes that _hp_ignore_sw_impact has not been set to force Ignite-UX to disregard the effects of
impacts statements on filesystems (and indirectly the effect of _hp_addnl_fs_free_pct):
_hp_ignore_sw_impact
Integer variable that may be set to 1 to disable all effects the
impacts statements declared in the software selections on the
volume size calculations. This may be helpful to ensure Ignite-
UX does not automatically modify the file system volume sizes.
If there is no additional disk space available in the volume or disk group so the filesystems cannot be
expanded it is possible if the filesystems are extremely full (less than a few MiB free) that you could suffer
from a filesystem full event preventing a successful recovery.
4. What is the difference between the way that software is configured on HP-UX B.11.11 and
B.11.23 versus HP-UX B.11.31?
HP-UX B.11.31 uses swm to install software and the software is configured by continuing the saved swm
jobs. Earlier releases of HP-UX use swconfig to configure software. Although on HP-UX B.11.31 swconfig
may end up being run if a swinstall session was run as part of the configuration (Ignite-UX does not use
swinstall for installing software on HP-UX B.11.31).
5. What issues can you think of with networking configuration using DHCP with
is_net_info_temporary set to FALSE during a cold install?
Unless you've set disable_dhcp to TRUE in the configuration you will end up using DHCP for networking
information on the final system unless you configure networking via itool. This may or may not be the
behaviour that you require but care should be taken when installing system using DHCP with
is_net_info_temporary set to FALSE.
Important: If you set disable_dhcp to TRUE in the install filesystem the system will not attempt to use
DHCP at all. If you want to use DHCP during the initial boot/install process and disable its use on the final
system set disable_dhcp in the configuration describing the installation session instead.
6. Why is instance number reassignment performed again in phase 3?
In phase 3 there may be kernel drivers available that were not in the install kernel. In phase 3 since the
system is running on the final kernel hopefully those kernel drivers are now available and Ignite-UX can
correctly associate instance numbers with the devices that it claimes (and indirectly fix up any device files
as required).


1. Why is what Ignite-UX currently does with an IP address assigned by DHCP dangerous?
Ignite-UX may continue to use the IP address if it has been released. If the IP address is given out by the
DHCP server and used again before Ignite-UX is finished the recovery session may fail or hang. This will
be addressed in a future release of Ignite-UX.
2. If you had an error in a final command hook where would you expect to see the messages about
the failure?
The messages will only appear on the console. The install.log file has been closed by the time the final
command hooks are run there will be no record of what happens with those command hooks in the
install.log file.
3. From an external perspective (excluding agile I/O paths) are there major differences between how
Ignite-UX presents I/O information between HP-UX B.11.11/B.11.23 and HP-UX B.11.31?
No, Ignite-UX is multi-path aware even on HP-UX B.11.11 and B.11.23 and will present only one path to a
disk for selection. Ignite-UX will automatically extend all paths to a disk into a volume group for HP-UX
B.11.11 and B.11.23. On HP-UX B.11.31 Ignite-UX only supports agile DSFs so it only needs to place the
agile DSF into an LVM volume group.
To illustrate this look at the following screen shots of root disk selection in itool:
If we look at the More Info screen we can see the device details:

From that screen we could look at all paths to see all of the paths to the device (unfortunately this device
only has a single path):
Compare that to a HP-UX B.11.23 system:

All of the same information is available. On the more info screen we can see:
All the same information (except for the legacy information) is available.
If the devices shown had multiple paths the More Info screen would have shown additional paths to the
device. The HP-UX B.11.31 system only required the additional screens so the legacy paths to the device
could be shown.
4. Should you be able to tell the difference between a HPVM Guest system and a non-HPVM Guest
system with Ignite-UX?

In most cases the answer is No. There are some additional pieces of software that should be installed in
HPVM guests that does not need to be installed in non-HPVM guest systems. Apart from that you should
not notice differences between the systems from the perspective of Ignite-UX.
Lab exercise 22 Answers –The big lab

17. How large were the two RAM filesystems created?
The messages associated with RAM filesystem creation were:
DEBUG: RAMFS Setup enabling RAM file systems, 2039 MB of system memory
DEBUG: RAMFS for each (0x7eff53b0)
DEBUG: RAMFS for each /dev (0x7eff53b0)
DEBUG: In ramfs_disk_size_force, _hp_ramfs_size1
DEBUG: RAMFS request to create disk volume 1, device /dev/ram1, 30 MB (30 MB
min)
DEBUG: RAMFS attempt to create disk volume 1, device /dev/ram1, 30 MB
NOTE: RAMFS create disk volume 1, device files
NOTE: mknod /dev/ram1 b 9 0x101e01
NOTE: mknod /dev/rram1 c 9 0x101e01
DEBUG: RAMFS created disk volume 1, device /dev/ram1, 30 MB
DEBUG: RAMFS for each /etc (0x7eff53b0)
DEBUG: RAMFS request to create disk volume 2, device /dev/ram2, 256 MB (256
MB min)
NOTE: mknod /dev/ram2 b 9 0x210001
NOTE: mknod /dev/rram2 c 9 0x210001
On a system with 2039MiB available the first RAM filesystem was 30MiB and the second 256MiB. If you
have different amounts of RAM available the filesystems may be smaller or larger.
18. What kind of filesystems were created in the RAM filesystems?
The filesystems were VxFS filesystems:
DEBUG: RAMFS mount creating file system on /dev/ram1

version 6 layout
30720 sectors, 30720 blocks of size 1024, log size 1024 blocks
largefiles supported
...
DEBUG: RAMFS mount creating file system on /dev/ram2
DEBUG: run_cmd: read interrupted by signal (normal).
version 6 layout
262144 sectors, 262144 blocks of size 1024, log size 1024 blocks
largefiles supported
3. The first time that debug messages show bdf type information about the install fileystem (/) how
full is it? What about the other filesystems how full are they?
The first time the information is shown the install filesystem is relatively full and the other filesystems
(mounted at /RAMFS1 and /RAMFS2) are relatively empty:
DEBUG: RAMFS for each skip mount point /var (dup vol)
Filesystem kbytes used avail %cap iused ifree iused Mounted on
/ 57892 41990 15902 73% 189 14211 1% ?

DEBUG: RAMFS for each (0x7eff53d0)

DEBUG: RAMFS for each /dev (0x7eff53d0)
/RAMFS1 30720 1629 27280 6% 4 7272 0% ?
DEBUG: RAMFS for each /etc (0x7eff53d0)
/RAMFS2 262144 1685 244188 1% 4 65112 0% ?
4. How does the installation/recovery process check the Ignite server version?
The command "loadfile -rl /opt/ignite/Version" downloads the Version file from the Ignite server. This is
used to validate that the current version of the software is compatible with the version of Ignite-UX on the
server.
DEBUG: Check Server Version File!

DEBUG: The install source type is 1.
DEBUG: Running "loadfile -rl /opt/ignite/Version" to get Version file from
server.
5. Most of the following messages are from the Ignite-UX parser:
...
DEBUG: Special config #0: /var/opt/ignite/clients/0xEA1E498D1674/config.sys
DEBUG: Special config #1: /var/opt/ignite/clients/0xEA1E498D1674/config
...
What are the two files config.sys and config?
The config.sys file is a copy of the configuration from the install filesystem. The config file is also known
as the "per-client" config file. It carries a copy of the changed configuration and is usually written by itool.
Since it has a much higher order of precedence than almost all of the configuration files its settings override
the settings in other configuration files.
6. Do the impacts statements given in the install.log match up with the impacts statements in your
configuration?
The first set of debug messages about impacts from the install.log file are:
DEBUG: Adding impact of sw: golden image1 (56Kb) dir: / to volume: /

DEBUG: Adding impact of sw: golden image1 (134848Kb) dir: /stand to volume:
/stand
DEBUG: Adding impact of sw: golden image1 (2868456Kb) dir: /usr to volume:
/usr
DEBUG: Adding impact of sw: golden image1 (4250744Kb) dir: /opt to volume:
/opt
DEBUG: Adding impact of sw: golden image1 (455072Kb) dir: /var to volume:

/var
DEBUG: Adding impact of sw: golden image1 (139096Kb) dir: /sbin to volume: /
DEBUG: Adding impact of sw: golden image1 (50Kb) dir: /dev to volume: /
DEBUG: Adding impact of sw: golden image1 (146728Kb) dir: /etc to volume: /
DEBUG: Adding impact of sw: golden image1 (72Kb) dir: /.sw to volume: /
DEBUG: Adding impact of sw: golden image1 (8Kb) dir: /.ssh to volume: /
DEBUG: Adding impact of sw: golden image1 (192Kb) dir: /tmp to volume: /tmp
DEBUG: Adding impact of sw: golden image1 (80Kb) dir: /home to volume: /home
This matches the impacts statements from the archive_cfg file assocated with the recovery:
impacts = "/" 56Kb

impacts = "/usr" 2868456Kb
impacts = "/opt" 4250744Kb
impacts = "/var" 455072Kb
impacts = "/sbin" 139096Kb
impacts = "/dev" 50Kb
impacts = "/etc" 146728Kb
impacts = "/.sw" 72Kb
impacts = "/.ssh" 8Kb
impacts = "/tmp" 192Kb
impacts = "/home" 80Kb
So, Yes, the impacts statements in the install.log file do match up with the impacts statements from the
configuration.
7. The following output was from a debug install.log file, we've seen output similar to this previously.
In what context have we seen it?

* 0/0/0/0.0x1.0x0 (/dev/dsk/c0t1d0) (vg00)
* 7168 - 1842176 KB /stand
* 1842176 - 3939328 KB primary
* 3939328 - 4987904 KB /
* 4987904 - 5512192 KB /tmp
* 5512192 - 5614592 KB /home
* 5614592 - 12950528 KB /opt
* 12950528 - 17103872 KB /usr
* 17103872 - 19557376 KB /var
* 0 KB unallocated
This kind of output was seen previously in the output of instl_dbg with the -d option to make it print the
expected disk allocation. The reason for reminding you of this is that the instl_dbg command is an
extremely handy command when you want to see what an install or recovery session would do given
certain configurations.
8. What are the contents of the partition file used with the idisk command to partition the boot device?
The name of the file is used is /tmp/efi_part.info (the name isn't given in the course). The hint here was to
look for the idisk command than find the file used and it's contents. On the system this lab was written with
the contents of the file were:
DEBUG: In mk_disk_devs
NOTE: Contents of file "/tmp/efi_part.info":
3
EFI 500MB
HPUX 19099MB
HPSP 400MB

TEST: run_cmd("/usr/sbin/idisk -q -w -f /tmp/efi_part.info

/dev/rdisk/disk4")
9. What are the commands used to create the root volume group?
The commands are below:
DEBUG: configure_LVM: skipping disk "0/0/0/0.0x0.0x0"

* Creating LVM physical volume "/dev/rdisk/disk4_p2" (0/0/0/0.0x1.0x0).
TEST: run_cmd("/sbin/pvcreate -f -B /dev/rdisk/disk4_p2")
DEBUG: sigchld: wait'ed on process: 195 (last_pid=195)
DEBUG: run_cmd: process return code 0
DEBUG: Directory: /dev already exists
DEBUG: Making directory: /dev/vg00
TEST: mkdir(/dev/vg00, 0755)
TEST: chown(/dev/vg00, 0, 0)
TEST: chmod(/dev/vg00, 0755)
TEST: mknod(/dev/vg00/group, 020640, 0x0640000000)
* Creating volume group "vg00".
TEST: run_cmd("/sbin/vgcreate -A n -e 4783 -l 255 -p 16 -s 4 /dev/vg00
/dev/disk/disk4_p2")
* Creating logical volume "vg00/lvol1" (/stand).
TEST: run_cmd("/sbin/lvcreate -A n -n lvol1 -r n -C y vg00")
* Creating logical volume "vg00/lvol2" (swap_dump).
* Creating logical volume "vg00/lvol3" (/).
* Creating logical volume "vg00/lvol4" (/tmp).
TEST: run_cmd("/sbin/lvcreate -A n -n lvol4 -C n vg00")
* Creating logical volume "vg00/lvol5" (/home).
* Creating logical volume "vg00/lvol6" (/opt).
* Creating logical volume "vg00/lvol7" (/usr).
* Creating logical volume "vg00/lvol8" (/var).


* Extending logical volume "vg00/lvol1" (/stand).
TEST: run_cmd("/sbin/lvextend -A n -L 1792 /dev/vg00/lvol1
/dev/disk/disk4_p2 ")
* Extending logical volume "vg00/lvol2" (swap_dump).
* Extending logical volume "vg00/lvol3" (/).
* Extending logical volume "vg00/lvol4" (/tmp).
TEST: run_cmd("/sbin/lvextend -A n -L 512 /dev/vg00/lvol4 /dev/disk/disk4_p2
")
* Extending logical volume "vg00/lvol5" (/home).
TEST: run_cmd("/sbin/lvextend -A n -L 100 /dev/vg00/lvol5 /dev/disk/disk4_p2
")
DEBUG: No instructions file
"/var/opt/ignite/clients/0xEA1E498D1674/server.instr".
* Extending logical volume "vg00/lvol6" (/opt).
* Extending logical volume "vg00/lvol7" (/usr).
* Extending logical volume "vg00/lvol8" (/var).
10. Why are the LVM lvcreate commands used to create the logical volumes and then lvextend used
to set their sizes?
With a recovery archive Ignite-UX sets the minor number of the logical volume when the configuration is
created:
logical_volume "lvol1" {
usage=VxFS
size=1835008KB
blksize=8192

version=5
largefiles=FALSE
mount_point="/stand"
bad_block_relocate=false
contiguous_allocation=true
stripes=0
stripe_size=0KB
minor_number=0x01 <<<<<<<<<<<<<<
disk[_hp_root_disk]
} # end logical_volume
usage=SWAP_DUMP
size=2097152KB
mount_point="primary"
stripes=0
stripe_size=0KB
minor_number=0x02 <<<<<<<<<<<<<<
disk[_hp_root_disk]
usage=VxFS
size=1048576KB
blksize=8192
version=6
largefiles=TRUE
mount_point="/"
stripes=0
stripe_size=0KB
minor_number=0x03 <<<<<<<<<<<<<<
disk[_hp_root_disk]
...
It is possible that the minor numbers may not be contiguous. For this reason Ignite-UX creates the logical
volumes with a zero size first (consuming any missing minor numbers with a "fake" logical volume). Later
when the logical volumes are extended the "fake" logical volumes are removed. This preserves the logical
volume minor numbers.
11. Find where Ignite-UX creates /d_cfg_mnt_sb61. Look at how the filesystems that have now been
created are mounted. Does what you see happening match the course notes and how it describes
where the filesystems are mounted?
DEBUG: Making directory: /d_cfg_mnt_sb61

TEST: mkdir(/d_cfg_mnt_sb61, 0755)
TEST: chown(/d_cfg_mnt_sb61, 0, 0)
TEST: chmod(/d_cfg_mnt_sb61, 0755)
DEBUG: Directory: /d_cfg_mnt_sb61/ already exists
TEST: mount(/dev/vg00/lvol3, /d_cfg_mnt_sb61/)
DEBUG: Setting standard perms on: /d_cfg_mnt_sb61/
TEST: chown(/d_cfg_mnt_sb61/, 0, 0)
TEST: chmod(/d_cfg_mnt_sb61/, 0755)
DEBUG: Directory: /d_cfg_mnt_sb61 already exists
DEBUG: Making directory: /d_cfg_mnt_sb61/etc
TEST: mkdir(/d_cfg_mnt_sb61/etc, 0755)
TEST: chown(/d_cfg_mnt_sb61/etc, 0, 0)
TEST: chmod(/d_cfg_mnt_sb61/etc, 0755)
DEBUG: Making directory: /d_cfg_mnt_sb61/stand

TEST: mkdir(/d_cfg_mnt_sb61/stand, 0755)

TEST: chown(/d_cfg_mnt_sb61/stand, 0, 0)
TEST: chmod(/d_cfg_mnt_sb61/stand, 0755)
TEST: mount(/dev/vg00/lvol1, /d_cfg_mnt_sb61/stand)
...
DEBUG: Setting standard perms on: /d_cfg_mnt_sb61/usr
TEST: chown(/d_cfg_mnt_sb61/usr, 2, 2)
TEST: chmod(/d_cfg_mnt_sb61/usr, 0555)
TEST: mount(/dev/vg00/lvol7, /d_cfg_mnt_sb61/usr)
DEBUG: Setting standard perms on: /d_cfg_mnt_sb61/usr
TEST: chown(/d_cfg_mnt_sb61/usr, 2, 2)
TEST: chmod(/d_cfg_mnt_sb61/usr, 0555)
DEBUG: Making directory: /d_cfg_mnt_sb61/var
TEST: mkdir(/d_cfg_mnt_sb61/var, 0755)
TEST: chown(/d_cfg_mnt_sb61/var, 0, 0)
TEST: chmod(/d_cfg_mnt_sb61/var, 0755)
TEST: mount(/dev/vg00/lvol8, /d_cfg_mnt_sb61/var)
TEST: chown(/d_cfg_mnt_sb61/var, 0, 0)
TEST: chmod(/d_cfg_mnt_sb61/var, 0755)
It should match the course notes (there may be extra mount points if you have other filesystems defined).
The course notes explain that /d_cfg_mnt_sb61 is in the install filesystem and this is where the disk
filesystems are mounted.
12. What command was used to extract the archive? Does this match the command we would expect
to see given the information in the course notes?
While you could answer /tmp/ign_configure/archive_script the more correct answer is the contents of the
script:
TEST: Skip doing open tape device and search for archive.
TEST: symlink(/d_cfg_mnt_sb61/., /d_cfg_mnt_sb61/ )
NOTE: Contents of file "/tmp/ign_configure/archive_script":
cd /d_cfg_mnt_sb61
/sbin/cat /tmp/ign_configure/archive_nfs/2008-07-19,09:28 | /monitor_bpr -s
2442491 | /usr/contrib/bin/gunzip -c | /sbin/pax_iux -r -p e
TEST: run_cmd("/sbin/sh /tmp/ign_configure/archive_script")
Given the information in the course notes the expected commands for a gzipped recovery archive accessed
via NFS that was more than 2GiB in size it is correct since it should look like:
cd /d_cfg_mnt_sb61
/monitor_bpr –s <size_in_KiB> | /usr/bin/gunzip –c | /sbin/pax_iux -r -p e
And this is what was seen in the debug output.
13. From when the NFS client directory is unmounted until it is mounted again where are the
messages stored?
When the NFS client directory is not mounted the messages are stored in a temporary file and copied to the
log file once the NFS client directory is mounted again. No messages are printed into the log file about this
happening but it is something that you need to be aware of.
TEST: chroot (/d_cfg_mnt_sb61)

TEST: symlink(/tmp/ign_configure/RAMFS/tmp/ign_configure/log_file,
/d_cfg_mnt_sb61/tmp/ign_configure/log_file)
TEST: Unmounting NFS dir using: "/sbin/fs/nfs/umount -f

10.30.128.22:/var/opt/ignite/clients /var/opt/ignite/clients".
...
TEST: Mounting NFS dir using: "/sbin/fs/nfs/mount -orw
10.30.128.22:/var/opt/ignite/clients /var/opt/ignite/clients".
DEBUG: mod_mount_cmd: No user supplied opts.
DEBUG: Running: "/sbin/fs/nfs/mount -orw 10.30.128.22:/var/opt/ignite/clients
/var/opt/ignite/clients" (retries=4)
TEST: unlink(/sbin/fs/nfs/mount)
14. As of Ignite-UX version C.7.7 Ignite-UX will print information on devices that the kernel
indicates should not have persistent instance numbers. Find out if there are any entries in your
install.log file.
The new messages look like:

Ignite-UX version C.7.7 will print all messages for all devices that will be skipped in this way. Later
revisions of Ignite-UX may print slightly different messages, for example C.7.8 may not print antything
(not 100% decided yet) and C.7.9 may just print the first 10 for a class and print a message that further
messages have been suppressed for that class.
15. The course notes said that there were 4 trees in the KRS that were dropped from HP-UX B.11.23
onwards (if they exist). Find them in the debug output.
These are the messages printed by Ignite-UX when removing the information from the KRS:
DEBUG: Cleanse KRS registry file

DEBUG: krs_regfile_cleanse removing subtree: /escsi
DEBUG: Delete KRS registry file subtree: /escsi
DEBUG: krs_regfile_cleanse removing subtree: /SAS
DEBUG: Delete KRS registry file subtree: /SAS
DEBUG: krs_regfile_cleanse removing subtree: /dumpinfo
DEBUG: Delete KRS registry file subtree: /dumpinfo
DEBUG: krs_regfile_cleanse removing subtree: /ignite/recovery
DEBUG: Delete KRS registry file subtree: /ignite/recovery
16. Swap systems with one another group of students have them break your Ignite server in two or
more of the following ways (please don't use more than 4). Attempt to recover the system and
work out what is wrong.
- Disable tftp
You need to edit /etc/inetd.conf
# vi /etc/inetd.conf
and change the following:

/opt/ignite\
/var/opt/ignite
to:


# /opt/ignite\
# /var/opt/ignite
If your entry for tftp does not have a -s option you do not need to add it. The system where this system took
place was multi-homed with multiple LAN interfaces on the same network. This option is required to get
tftp to reply in a way that the client systems will accept.
Run "inetd -c" to have it re-read the configuration file. When network booting the following error is seen:
Shell> lanboot
Running LoadFile()

GATEWAY IP: 10.30.128.1
Running LoadFile()
TFTP.
- Remove /opt/ignite and /var/opt/ignite from the /etc/inetd.conf entry of tftpd.
You need to edit /etc/inetd.conf
# vi /etc/inetd.conf
and change the following:

/opt/ignite\
/var/opt/ignite
to:
tftp dgram udp wait root /usr/lbin/tftpd tftpd -s

# /opt/ignite\
# /var/opt/ignite
If your entry for tftp does not have a -s option you do not need to add it. The system where this system took
place was multi-homed with multiple lan interfaces on the same network. This option is required to get tftp
to reply in a way that the client systems will accept.
Run "inetd -c" to have it re-read the configuration file. When network booting the following error is seen:
Shell> lanboot
Running LoadFile()


GATEWAY IP: 10.30.128.1

Running LoadFile()
TFTP...|
- Add an entry into inetd.sec so access tftp is denied to everything except the Ignite server
(e.g. use the name loopback or localhost as the only name allowed access or deny access
to the client).
To do this edit /var/adm/inetd.sec:
# vi /var/adm/inetd.sec
and add the following line:
# vi /var/adm/inetd.sec
tftp allow loopback
This will produce the following error:
Shell> lanboot
Running LoadFile()

GATEWAY IP: 10.30.128.1
Running LoadFile()
TFTP...-
This is the same error seen above for disabling access to /opt/ignite and /var/opt/ignite.
- Comment out the entry for the system in /etc/bootptab (if bootp/DHCP is being used).
In this one we need to comment out the bootptab entry for the HPVM Guest that we're attempting to
recover. So this entry:
vm001:\
ha=EA1E498D1674:\
ip=10.30.128.11:\
sm=255.255.252.0:\
gw=10.30.128.1:\
ds=10.30.130.46
needs to become:
#vm001:\
# tc=ignite-defaults:\
# ha=EA1E498D1674:\
# ip=10.30.128.11:\
# sm=255.255.252.0:\

# gw=10.30.128.1:\
# ds=10.30.130.46
You do not need to notify bootpd of any changes to /etc/bootptab as it will see that it has changed next time
a bootp or DHCP request is recieved and re-read the file. The error seen when this is done is:
Shell> lanboot
Running LoadFile()

- Move one of the /opt/ignite/boot/AUTO, /opt/ignite/boot/nbp.efi, or

/opt/ignite/boot/fpswa.efi to a new name or change their permissions so they cannot be
accessed via tftp.
We will look at what happens when each file is moved aside and how it affects the network boot. The first
file is the AUTO file:
# mv AUTO AUTO.save
Shell> lanboot
Running LoadFile()

GATEWAY IP: 10.30.128.1
Running LoadFile()
TFTP..

All rights reserved
Booting from Lan

Obtaining size of AUTO (failed)
Downloading file AUTO
Error Code: 1, Error Str: File not found
That gave us a clear error. Next we will move nbp.efi aside (putting back the AUTO file):
# mv AUTO AUTO.save
# mv AUTO.save AUTO

# mv nbp.efi nbp.efi.save
The error seen is:
Shell> lanboot
Running LoadFile()

This is nice and confusing since it is difficult to know what the problem is. The error give is related to the
fact that the boot file given in the DHCP response is not accessiable. Note that the problem is immediately
resolved by moving nbp.efi back into place.
Next we'll move fpswa.efi away (putting back the nbp.efi file):
# mv nbp.efi.save nbp.efi
# mv fpswa.efi fpswa.efi.save
Shell> lanboot
Running LoadFile()

GATEWAY IP: 10.30.128.1
Running LoadFile()
TFTP.
Obtaining size of fpswa.efi (failed)
Downloading file fpswa.efi

All rights reserved
Booting from Lan



4. Exit Boot Loader
There's an error for a missing fpswa.efi but it doesn't stop nbp.efi from continuing to run. Don't forget to
move the file back into place:
# mv fpswa.efi.save fpswa.efi
- Modify the AUTO file to load the install kernel for the wrong version of HP-UX it refers
to. Save a copy of the AUTO file before changing it.
# mv AUTO AUTO.save
# cp -p AUTO.save AUTO
# vi AUTO
The AUTO file can then be modified to look like:
KernelPrompt "Choose an operating system to install that your hardware

supports:" 120 1
reset
When booting the system we choose the 11.31 option:

3. Exit Boot Loader
Note that because we've modified the AUTO file the 11.23 install kernel is downloaded:

Downloading file Rel_B.11.23/IINSTALL -
This will cause problems when we get into itool since we won't be able to recover an 11.31 recovery
archive. Ignite-UX requires that you use a matched kernel to recover a system. That is to recover an 11.31
system you must use an 11.31 install kernel.
- Change the IP address of the Ignite server in the install filesystems so the client will go to
the wrong Ignite server.
If we change the install filesystem on the Ignite server from:
server="10.30.128.22"
netmask[]="255.255.252.0"
to:

server="10.30.128.8"
netmask[]="255.255.252.0"
The IP address 10.30.128.8 belonged to an MP on a rp8420 and the installation session got as far as here:
* Bringing up Network (lan0)

add net default: gateway 10.30.128.1
Eventually the following was printed out:
Failed to read "INDEX" file from install server. Check that the
install server's IP address is correct and the server has the
"Ignite-UX" product loaded and is available via the tftp(1)
service. tftp error log follows:
tftp> tftp> tftp> tftp> tftp> Transfer timed out.
Press any key to return to the network configuration menu:
NOTE: Retrying loadfile command...
* tftp error log follows:
tftp>
tftp>
tftp>
tftp>
...
That takes you back to the "NETWORK CONFIGURATION" screen where you would have to spot that
the Ignite server IP address was wrong.
- Change the permissions on the install kernel or filesystem so it cannot be accessed or

rename it so it's not available.
Changing permissions on the 11.31 IINSTALL kernel gives the following errors:

4. Exit Boot Loader


Obtaining size of Rel_B.11.31/IINSTALL (failed)

Downloading file Rel_B.11.31/IINSTALL
Could not open Rel_B.11.31/IINSTALL
loading failed
Note that in this case and some previous cases you will be left at the bootloader problem (HPUX>) you
must type exit to exit from the bootloader and go back to the EFI shell or boot manager menu.
Fixing the permissions and moving the kernel out of the way gives:
# chmod 444 IINSTALL

# mv IINSTALL IINSTALL.save

4. Exit Boot Loader

Obtaining size of Rel_B.11.31/IINSTALL (failed)
Downloading file Rel_B.11.31/IINSTALL
Could not open Rel_B.11.31/IINSTALL
loading failed
Now we can do similar things with the install filesystem, first move the kernel back into place:
# mv IINSTALL.save IINSTALL
# chmod 0 IINSTALLFS
In this case the install kernel comes down fine but the install filesystem fails:

4. Exit Boot Loader

loading section 0
................................................................................
.................... (complete)
loading section 1
................. (complete)

Obtaining size of Rel_B.11.31/IINSTALLFS (failed)

Downloading file Rel_B.11.31/IINSTALLFS
Could not load ram filesystem
loading failed
Now we can set the permission on the install filesystem back to what they should be and then move it out
of the way:
# chmod 444 IINSTALLFS

# mv IINSTALLFS IINSTALLFS.save

4. Exit Boot Loader

loading section 0
................................................................................
.................... (complete)
loading section 1
................. (complete)
Obtaining size of Rel_B.11.31/IINSTALLFS (failed)
Downloading file Rel_B.11.31/IINSTALLFS
Could not load ram filesystem
loading failed
- Move the orginal install kernel or filesystem aside and replace it with another file of a
similar size (e.g. replace the HP-UX B.11.31 install kernel with a copy of /stand/vmunix
from a HP-UX B.11.31 system). Please copy /stand/vmunix to IINSTALL then gzip the
file and rename it to IINSTALL.
# mv IINSTALL IINSTALL.save
# cp /stand/vmunix ./IINSTALL
# gzip IINSTALL
# mv IINSTALL.gz IINSTALL
In this case it's a HP-UX B.11.23 kernel that has been copied to be IINSTALL for HP-UX B.11.31. Things
do not go well from there:
Console is on Serial COM1

Booting kernel...
Disabling 8259s
Memory Class Setup

-------------------------------------------------------------------------
Class Physmem Lockmem Swapmem
-------------------------------------------------------------------------
System : 2039 MB 2039 MB 2039 MB
Kernel : 2039 MB 2039 MB 2039 MB
User : 1638 MB 1426 MB 1431 MB
-------------------------------------------------------------------------
Loaded ACPI revision 2.0 tables.

krs_read_mfs: Error 5 opening MFS.
WARNING: GIO: read_ioconfig_file(): /stand/ioconfig read error.
ioconfig = NULL
NOTICE: cachefs_link(): File system was registered at index 5.
NOTICE: nfs3_link(): File system was registered at index 8.
iether0: INITIALIZING HP PCI/PCI-X 1000Base-T at hardware path 0/0/1/0
System Console is on the Built-In Serial Interface

Swap device table: (start & size given in 512-byte blocks)
entry 0 - auto-configured on root device; ignored - no room
WARNING: no swap device configured, so dump cannot be defaulted to primary swap.
WARNING: No dump devices are configured. Dump is disabled.
Starting the STREAMS daemons-phase 1
Create STCP device files
Starting the STREAMS daemons-phase 2
$Revision: vmunix: B11.23_LR FLAVOR=perf Fri Aug 29 22:35:38 PDT 2003 $
Memory Information:
physical page size = 4096 bytes, logical page size = 4096 bytes
Physical: 2088448 Kbytes, lockable: 1225416 Kbytes, available: 1674428
Kbytes
* Preparing to execute init...
INIT: /etc/inittab: WARNING: Cannot pstat_getstatic: Invalid argument

======= 07/27/08 20:14:21 EDT HP-UX Installation Initialization. (Sun Jul 27
20:14:21 EDT 2008)
/branches/IUX_RA0809_PAX/ignite/src@75355 Last Modified: 2008-09-03
15:56:16 -0600 (Wed, 03 Sep 2008)
ERROR: RAMFS Setup memory issue.
ERROR: The system does not contain the minimum supported amount of memory
needed to install and run HP-UX. HP-UX requires 450 MB of available
memory for the "B.11.23" release. The system has only 0 MB of memory
available for HP-UX use (this may be less than physical memory
installed due to space reserved by system firmware). The amount of
memory in the system must be increased if this release is to be
installed successfully.
ERROR: The system install or recovery session cannot continue.
* System will reboot in 30 seconds.
ERROR: Unable to initiate connection to IO listener: No such file or
directory (errno = 2)
WARNING: Could not find Q_BOOT device. Cannot determine what the boot device
was.
ERROR: Could not write disk information file
NOTE: System rebooting...
Shutdown at 20:14 (in 0 minutes)
System shutdown time has arrived
io_query failed: Key is undefined for specified token, or token is NULL.
- Change the permissions on one of INSTCMDSIA or SYSCMDSIA so it cannot be

accessed or rename it so it's not available.

Changing the permissions so the files can't be read:
# cd /opt/ignite/data/Rel_B.11.31
# chmod 0 SYSCMDSIA INSTCMDSIA
Things work find until we get past the network configuration screen. The reason for this is that Ignite-UX
doesn't contact the Ignite server so it can't access the SYSCMDSIA/INSTCMDSIA files until after it gets
networking up. You will see errors like:
* Loading configuration user interface, please wait...

ERROR: File /opt/ignite/data/Rel_B.11.31/INSTCMDSIA from install tftp server
was zero-length.
ERROR: Tar: blocksize = 0; broken pipe?
ERROR: File: /usr/ccs not found.
ERROR: File: /usr/dt/lib/hpux32/libDtHelp.so.1 not found.
ERROR: File: /usr/dt/lib/hpux32/libDtSvc.so.1 not found.
ERROR: File: /usr/dt/lib/hpux32/libtt.so.1 not found.
ERROR: File: /usr/lib/hpux32/libCsup.so not found.
ERROR: File: /usr/lib/hpux32/X11R6/libICE.so.1 not found.
ERROR: File: /usr/lib/hpux32/libICE.so.1 not found.
ERROR: File: /usr/lib/hpux32/X11R6/libSM.so.1 not found.
ERROR: File: /usr/lib/hpux32/libSM.so.1 not found.
ERROR: File: /usr/lib/hpux32/X11R6/libX11.so.1 not found.
ERROR: File: /usr/lib/hpux32/libX11.so.1 not found.
ERROR: File: /usr/lib/hpux32/X11R6/libXext.so.1 not found.
ERROR: File: /usr/lib/hpux32/libXext.so.1 not found.
ERROR: File: /usr/lib/hpux32/Motif2.1/libXm.so.1 not found.
ERROR: File: /usr/lib/hpux32/libXm.so.1 not found.
ERROR: File: /usr/lib/hpux32/X11R6/libXp.so.1 not found.
ERROR: File: /usr/lib/hpux32/libXp.so.1 not found.
ERROR: File: /usr/lib/hpux32/X11R6/libXt.so.1 not found.
ERROR: File: /usr/lib/hpux32/libXt.so.1 not found.
ERROR: File: /usr/lib/hpux32/libstd.so.1 not found.
ERROR: File: /usr/lib/hpux32/libstream.so.1 not found.
ERROR: File: /usr/lib/hpux32/pa_boot32.so not found.
ERROR: File: /usr/lib/nls not found.
ERROR: File: /usr/obam not found.
ERROR: File: /opt/ignite/bin not found.
ERROR: File: /opt/ignite/ui not found.
ERROR: File: /opt/ignite/help not found.
tftp> tftp> tftp> tftp> tftp> Error code 2: Access violation
tftp>
loadfile command failed, retry? ([y]/n):
The two clues to what is happening here is the tftp error "Access violation" so we know that there is a
permissions issue and that Ignite-UX printed a message that we had a zero length read (so we didn't
manage to read any of the INSTCMDSIA file).
If we couldn't access the file we would see the following slightly different messages instead:
# chmod 444 SYSCMDSIA INSTCMDSIA

# mv INSTCMDSIA INSTCMDSIA.save
# mv SYSCMDSIA SYSCMDSIA.save
ERROR: File /opt/ignite/data/Rel_B.11.31/INSTCMDSIA from install tftp server

was zero-length.


tftp> tftp> tftp> tftp> tftp> Error code 1: File not found
tftp>
loadfile command failed, retry? ([y]/n):
This of course only shows what you might see for INSTCMDS since SYSCMDS hasn’t been accessed yet.
- Save a copy of one of INSTCMDSIA or SYSCMDSIA (use the same name ending
in .save), gzip the file and then move it back to the original name.
If instead we gzipped INSTCMDSIA again (remember it's meant to be a gzipped tar archive we have seen
customer issues where someone had gzipped the file again) we would see:
# mv INSTCMDSIA INSTCMDSIA.save
# gzcat < INSTCMDSIA.save > INSTCMDSIA
WARNING: f_unzip: input not a zip or gzip file

ERROR: read_raw_file: Input not in "gzip" compressed format


This would be seen in the same place as the previous question after the networking configuration screen.
- Change the ownership of the client directory so it is owned by root:sys and does not
allow the bin user to create or remove files in it.
If we change the ownership of the client directory:
# chown root:sys 0xEA1E498D1674
We will start to see some errors when itool runs:
If we choose to answer the next dialog (do you want to keep the previous configuration) with yes then we
see an assertion failure and itool aborts:

It’s never a good idea for files under /var/opt/ignite/clients to be owned by anything other than bin:bin. You
will be asked if you want to start the user interface again with the following question:
The user interface failed, would you like to restart it? ([y]/n):
If you answer yes you will see the same initial error and itool will fail with the same assertion. The question
asking if you want to restart itool does have one very good use. If you do choose to restart it you can
investigate the initial error. Errno 13 is EPERM so you know the initial error has something do with
permissions that should be enough to resolve the issue.
Once the issue is resolved you should be able to restart the UI and continue as if nothing had happened.
Care should be taken if /var/opt/ignite/clients is not owned by bin:bin. New clients will not be able to create
their per-client directories.
- Change the client directory so it is no longer exported or has an access= entry to prevent
the client from accessing it.
On the HPVM Host (HPVM 3.5) the exports file was changed to prevent access for the guest (vm001) to
the clients directory:
# more /etc/exports
#/var/opt/ignite/clients -anon=2
/var/opt/ignite/clients -anon=2,access=blue:vm004:vm005
/var/opt/ignite/recovery/archives/blue -anon=2,access=blue
/var/opt/ignite/recovery/archives/vm005 -anon=2,access=vm005
# exportfs -au
Later when it attempted to mount the client directory the following messages were printed.

* NFS mounting clients directory.

nfs mount: 10.30.128.20:/var/opt/ignite/clients: Permission denied
NOTE: Retrying: "/sbin/fs/nfs/mount -orw
10.30.128.20:/var/opt/ignite/clients /var/opt/ignite/clients"
NOTE: NFS mount (/sbin/fs/nfs/mount -orw
10.30.128.20:/var/opt/ignite/clients /var/opt/ignite/clients) failed,
see messages above.
* Using client directory: /var/opt/ignite/clients/0xEA1E498D1674
* Could not NFS mount the server, system configuration will not be saved
on the server for future use.
A client can continue without access to a NFS client directory it will just use a local client directory and the
results of the installation or recovery session will not be stored on the Ignite server - only locally.
- Change the permissions or ownership on the recovery archive so the client cannot read it
(or rename the file).
In this case the ownership was changed to prevent the recovery archive from being read by the recovery
process:
# ll
total 9772848
-rw------- 1 bin sys 2501184937 Sep 14 21:10 2008-07-18,09:59
-rw------- 1 bin sys 2501111587 Sep 15 20:40 2008-07-19,09:28
# chown root 2008-07-19,09:28
# pwd
/var/opt/ignite/recovery/archives/vm001
When you want to use the recovery archive that has been modified:

You should end up seeing errors like:
*
Loading_software: Begin
*
Installing boot area on disk.
*
Formatting HP Service Partition.
*
Enabling swap areas.
*
Backing up LVM configuration for "vg00".
*
Processing the archive source (Recovery Archive).
*
Mon Jul 28 17:02:43 EDT 2008: Starting archive load of the source
(Recovery Archive).
cat: Cannot open /tmp/ign_configure/archive_nfs/2008-07-19,09:28: Permission
denied
gunzip: stdin: unexpected end of file

pax_iux: The archive is empty.
ERROR: Cannot load OS archive (Recovery Archive)

You know that there is a permissions issue because the error from cat (giving you the path) gave an error of
permission denied.
- Change the exported directory containing the recovery archive for the client so so it is no
longer exported or has an access= entry to prevent the client from accessing it.
In this case we can modify /etc/exports so the directory containing the archives for this system are no
longer exported. /etc/exports was changed to be:
#/var/opt/ignite/recovery/archives/vm001 -anon=2,access=vm001

Then the following commands were run to make sure that the filesystem was not exported:
# exportfs -au
# exportfs -a
# exportfs
The errors seen this case are:
* Formatting HP Service Partition.
* Backing up LVM configuration for "vg00".
* Processing the archive source (Recovery Archive).
nfs mount: 10.30.128.20:/var/opt/ignite/recovery/archives/vm001: Permission
denied
NOTE: Retrying: "/sbin/fs/nfs/mount -oro
10.30.128.20:/var/opt/ignite/recovery/archives/vm001
/tmp/ign_configure/archive_nfs"
denied
denied
denied
denied
NOTE: NFS mount (/sbin/fs/nfs/mount -oro
/tmp/ign_configure/archive_nfs) failed, see messages above.
ERROR: Command "/sbin/fs/nfs/mount -oro
/tmp/ign_configure/archive_nfs" failed. Ensure that
"/var/opt/ignite/recovery/archives/vm001" is properly exported on
10.30.128.20.
ERROR: Cannot load OS archive(s) (Recovery Archive)

- Add some garbage information into the install filesystem.
It’s a trick option. It won’t work since instl_adm syntax checks configuration items before you can apply it
to the install filesystems:
# instl_adm -d -f newconf
ERROR: "newconf", line 9: syntax error
ERROR: Problems were encountered while parsing config file: "newconf".
instl_adm: Config file: "newconf" cannot be parsed.

- Change the ownership and permissions on the CINDEX file in the client directory so the
client cannot read it. This will prevent the client system from being able to access
information about any recovery archives it has. Change it to be owned by root:sys with
permissions 600.
# chmod 0 CINDEX
# ll CINDEX
---------- 1 bin sys 987 Sep 15 20:40 CINDEX
You will see the following error just before itool starts (it is possible you may see other errors later):

ERROR: parser cannot open file:
/var/opt/ignite/clients/0xEA1E498D1674/CINDEX: Permission denied
(errno = 13)
ERROR: net_cfg_prep: Problems were encountered while parsing configuration
file: "/var/opt/ignite/clients/0xEA1E498D1674/CINDEX". See the
messages above for details. Using instl_adm with the -T and/or -D
options on the server may help isolate the problem. (See instl_adm(1M)
and instl_adm(4) man pages.)
Changing the ownership will still create the same errors as it will still be a permission denied error.
# chmod 600 CINDEX

# chown root:sys CINDEX

ERROR: parser cannot open file:
/var/opt/ignite/clients/0xEA1E498D1674/CINDEX: Permission denied
(errno = 13)
ERROR: net_cfg_prep: Problems were encountered while parsing configuration
file: "/var/opt/ignite/clients/0xEA1E498D1674/CINDEX". See the
messages above for details. Using instl_adm with the -T and/or -D
options on the server may help isolate the problem. (See instl_adm(1M)
and instl_adm(4) man pages.)
- Change the ownershop and permissions on the configuration files refered to by the cfg
clauses in the CINDEX file to prevent them from being accessed. Change them to be
owned by root:sys with permissions 600 (to make it more confusing only change one of
the 3 files referenced).
Just changing the permissions:
# cd /var/opt/ignite/clients/vm001/recovery
# cd 2008-07-19,09:28/
# ll
total 20512
-rw-r--r-- 1 bin sys 3218 Sep 15 20:10 archive_cfg
-rw-r--r-- 1 bin sys 17 Sep 15 20:09 archive_content
-rw-r--r-- 1 bin sys 498 Sep 15 20:09 control_cfg
-rw-r--r-- 1 bin sys 10373454 Sep 15 20:10 flist
-rw-r--r-- 1 bin sys 12186 Sep 15 20:40 manifest
-rw-r--r-- 1 bin sys 3016 Sep 15 20:40 recovery.log
-rw-r--r-- 1 bin sys 10322 Sep 15 20:09 system_cfg
# chmod 0 archive_cfg

Ensures you will see similar issues to the previous item:

ERROR: Could not open config file: "/var/opt/ignite/clients/0xEA1E498D1674/re
covery/2008-07-19,09:28/archive_cfg"
ERROR: net_cfg_prep: Problems were encountered while parsing the
configuration files. See the messages above for details. Using
instl_adm with the -T and/or -D options on the server may help isolate
the problem. (See instl_adm(1M) and instl_adm(4) man pages.)
Chaing the ownership and restricting the permissions so bin cannot read the file will give the same error.
- Move the recovery archive aside to a new name and create a zero length file using the
original name of the recovery archive.
So moving this recovery archive aside and creating a zero length file is easy:
# cd /var/opt/ignite/recovery/archives/vm001
# mv 2008-07-19,09:28 2008-07-19,09:28.save
# touch 2008-07-19,09:28
After this has been done the errors are not immediately obvious that they connected to the zero length
archive:
* Mon Jul 28 18:18:02 EDT 2008: Starting archive load of the source
(Recovery Archive).
* Completed 0 KBytes of archive
gunzip: stdin: unexpected end of file

pax_iux: The archive is empty.
ERROR: Cannot load OS archive (Recovery Archive)

- Move the recovery archive aside to a new name create a new archive containing some
files (it doesn't matter what files) using pax. Now gzip the resulting file and move it to
the original archive name.
This is easy to do (the files being backed up are actually from a HP-UX B.11.23 system so there’s no way
this would work regardless):
# cd /
# pax -w -x ustar -f /var/opt/ignite/recovery/archives/vm001/2008-07-
19,09:28 ./usr/lib
# cd /var/opt/ignite/recovery/archives/vm001
# gzip 2008-07-19,09:28
# mv 2008-07-19,09:28.gz 2008-07-19,09:28
# chown bin 2008-07-19,09:28
# chmod 600 2008-07-19,09:28

The archive won’t have enough in it to create a kernel or run an operating system. From this we know that
archive extraction should work but later steps will fail. The file doesn’t have to be as large as all of /usr/lib.
Remember however that it should be path relative or the install filesystem will fill up very quickly.
*
Loading_software: Begin
*
Installing boot area on disk.
*
Formatting HP Service Partition.
*
Enabling swap areas.
*
Backing up LVM configuration for "vg00".
*
Processing the archive source (Recovery Archive).
*
Mon Jul 28 18:52:05 EDT 2008: Starting archive load of the source
(Recovery Archive).
* Mon Jul 28 18:54:36 EDT 2008: Completed archive load of the source
(Recovery Archive).
* Executing user specified script:
"/opt/ignite/data/scripts/os_arch_post_l".
interpreter "/usr/bin/ksh" not found
ERROR: run_cmd: cannot execute "/tmp/ign_configure/cfg_script/opt/ignite/data
/scripts/os_arch_post_l": No such file or directory (errno = 2).
ERROR: The script: "/opt/ignite/data/scripts/os_arch_post_l" failed, exit
code was 1.
* Relocating RAM filesystems.
* Releasing RAM filesystems.
NOTE: RAMFS unmount(/dev/ram2) failed: Device busy (errno = 16)
NOTE: Ignite-UX RAMFS release failed. Installation will continue, but may
be slower than normal.
WARNING: Could not symlink "/usr/lib/hpux32/libxti.so.1" to
"/tmp/ign_configure/RAMFS/usr/lib/hpux32/libxti.so.1": File exists
(errno = 17).
NOTE: run_cmd: Process: 294 (/sbin/fs/nfs/mount): killed by signal: 9.
/usr/lib/hpux32/dld.so: Unable to find library 'libxti.so.1'.
NOTE: NFS mount (/sbin/fs/nfs/mount -orw
15.30.128.20:/var/opt/ignite/clients /var/opt/ignite/clients) failed,
see messages above.
ERROR: Command "/sbin/fs/nfs/mount -orw 15.30.128.20:/var/opt/ignite/clients
/var/opt/ignite/clients" failed. Ensure that "/var/opt/ignite/clients"
is properly exported on 15.30.128.20.


Any errors you encounter are likely to be different.
- This may or may not work - move the directory containing the recovery archives to a new
name create a new directory with the original name, ownership and permissions and then
move the recovery archives into the new directory.
Note do not reexport the filesystem as this will cause the problem not to happen.
# cd /var/opt/ignite/recovery/archives
# mkdir vm001.new
# mv vm001/* vm001.new
# rmdir vm001
# mv vm001.new vm001
# chown bin:bin vm001
# chmod 755 vm001
This leads to the following errors:
denied
denied
denied
denied
denied
NOTE: NFS mount (/sbin/fs/nfs/mount -oro
/tmp/ign_configure/archive_nfs) failed, see messages above.
ERROR: Command "/sbin/fs/nfs/mount -oro
/tmp/ign_configure/archive_nfs" failed. Ensure that
"/var/opt/ignite/recovery/archives/vm001" is properly exported on
15.30.128.20.
ERROR: Cannot load OS archive(s) (Recovery Archive)


The reason why this causes a failure is that the new directory has a different inode number and is not the
same directory that was originally exported via NFS.
Lab exercise 23 Answers – Extra lab One

Create a debug install.log from a recovery session. You may have already created one, if so you do not
need to create another one.
1. When discussing the relocation of files into the two RAM filesystems that can be created (one
on HP-UX B.11.11) what kind of files are relocated into the RAM filesystem /RAMFS1
according to the debug output?
The following is from a HP-UX B.11.31 debug install.log file showing the relocation of devices from /dev
to /RAMFS1:
NOTE: RAMFS Setup copy /dev to /RAMFS1/dev

DEBUG: Directory: /RAMFS1 already exists
DEBUG: Making directory: /RAMFS1/dev
TEST: mkdir(/RAMFS1/dev, 0755)
TEST: chown(/RAMFS1/dev, 0, 0)
TEST: chmod(/RAMFS1/dev, 0755)
TEST: Copy file: /dev/console to /RAMFS1/dev/console
TEST: Copy file: /dev/kmem to /RAMFS1/dev/kmem
TEST: Copy file: /dev/mem to /RAMFS1/dev/mem
TEST: Copy file: /dev/null to /RAMFS1/dev/null
TEST: Copy file: /dev/systty to /RAMFS1/dev/systty
TEST: Copy file: /dev/tty to /RAMFS1/dev/tty
TEST: Copy file: /dev/config to /RAMFS1/dev/config
TEST: Copy file: /dev/root to /RAMFS1/dev/root
TEST: Copy file: /dev/rroot to /RAMFS1/dev/rroot
TEST: Copy file: /dev/dlpi to /RAMFS1/dev/dlpi
TEST: Copy file: /dev/lan to /RAMFS1/dev/lan
TEST: Copy file: /dev/sad to /RAMFS1/dev/sad
TEST: Copy file: /dev/vxportal to /RAMFS1/dev/vxportal
TEST: Copy file: /dev/kepd to /RAMFS1/dev/kepd
DEBUG: Directory: /RAMFS1/dev already exists
DEBUG: Making directory: /RAMFS1/dev/deviceFileSystem
TEST: mkdir(/RAMFS1/dev/deviceFileSystem, 0755)
TEST: chown(/RAMFS1/dev/deviceFileSystem, 0, 0)
TEST: chmod(/RAMFS1/dev/deviceFileSystem, 0755)
DEBUG: Making directory: /RAMFS1/dev/dsk
TEST: mkdir(/RAMFS1/dev/dsk, 0755)
TEST: chown(/RAMFS1/dev/dsk, 0, 0)
TEST: chmod(/RAMFS1/dev/dsk, 0755)
DEBUG: Making directory: /RAMFS1/dev/rdsk
TEST: mkdir(/RAMFS1/dev/rdsk, 0755)
TEST: chown(/RAMFS1/dev/rdsk, 0, 0)
TEST: chmod(/RAMFS1/dev/rdsk, 0755)
TEST: Copy file: /dev/udp6 to /RAMFS1/dev/udp6
TEST: Copy file: /dev/udp to /RAMFS1/dev/udp
TEST: Copy file: /dev/tcp6 to /RAMFS1/dev/tcp6
TEST: Copy file: /dev/tcp to /RAMFS1/dev/tcp
TEST: Copy file: /dev/stcpmap to /RAMFS1/dev/stcpmap
TEST: Copy file: /dev/rawip6 to /RAMFS1/dev/rawip6

TEST: Copy file: /dev/rawip to /RAMFS1/dev/rawip

TEST: Copy file: /dev/nuls to /RAMFS1/dev/nuls
TEST: Copy file: /dev/rtsock to /RAMFS1/dev/rtsock
TEST: Copy file: /dev/ipsecpol to /RAMFS1/dev/ipsecpol
TEST: Copy file: /dev/ipseckey to /RAMFS1/dev/ipseckey
TEST: Copy file: /dev/ip6 to /RAMFS1/dev/ip6
TEST: Copy file: /dev/ip to /RAMFS1/dev/ip
TEST: Copy file: /dev/arp to /RAMFS1/dev/arp
TEST: Copy file: /dev/syscon to /RAMFS1/dev/syscon
TEST: Copy file: /dev/ram1 to /RAMFS1/dev/ram1
TEST: Copy file: /dev/rram1 to /RAMFS1/dev/rram1
TEST: Copy file: /dev/ram2 to /RAMFS1/dev/ram2
TEST: Copy file: /dev/rram2 to /RAMFS1/dev/rram2
The log file does however show the relocation of other files than devices to this filesystem (very few
compared to /RAMFS2 however).
2. How large where the RAM filesystems that were created? Does this match the information shown
in the student notes section (see “What does /sbin/ramfs do?” – towards the end of the section)
about how large the filesystems should be based upon memory size and the minimum and
maximum size of these ram filesystems?

DEBUG: RAMFS Setup enabling RAM file systems, 2039 MB of system memory
DEBUG: RAMFS for each (0x7eff53b0)
DEBUG: RAMFS for each /dev (0x7eff53b0)
DEBUG: RAMFS request to create disk volume 1, device /dev/ram1, 30 MB (30 MB
min)
NOTE: mknod /dev/ram1 b 9 0x101e01
NOTE: mknod /dev/rram1 c 9 0x101e01
DEBUG: RAMFS for each /etc (0x7eff53b0)
DEBUG: RAMFS request to create disk volume 2, device /dev/ram2, 256 MB (256
MB min)
NOTE: mknod /dev/ram2 b 9 0x210001
NOTE: mknod /dev/rram2 c 9 0x210001
The size of available memory on this system was 2039MiB of memory.
The percentage of memory available for the first RAM filesystems is 1% of memory with a minimum of
30MiB. 1% of the available memory is less than this (so we don't need to consider what the maximum
amount that can be used is) so we use the minimum of 30MiB.
The percentage of memory available for the second RAM filesystems is 10% of memory with a minimum
of 256MiB (on HP-UX B.11.31). 10% of the available memory is less than this (so we don't need to
consider what the maximum amount that can be used is) so we use the minimum of 256MiB.
3. Locate the messages about the client directory being mounted during the recovery. Do the files
that are moved to the client directory match the course notes?
These messages show the client directory being mounted and then the install.log and other things being
moved over to the client directory on the Ignite server:

DEBUG: Running: "/sbin/fs/nfs/mount -orw 15.30.128.20:/var/opt/ignite/clients

/var/opt/ignite/clients" (retries=4)
* Using client directory: /var/opt/ignite/clients/0xEA1E498D1674
TEST: Move file: /var/opt/ignite/clients/0xEA1E498D1674/install.log to
/var/opt/ignite/clients/0xEA1E498D1674/install.log.prev
TEST: Move file: /tmp/install.log to
/var/opt/ignite/clients/0xEA1E498D1674/install.log
TEST: Copy file: /tmp/install.log to
/var/opt/ignite/clients/0xEA1E498D1674/install.log
TEST: Copy file: /tmp/config.sys to
/var/opt/ignite/clients/0xEA1E498D1674/config.sys
TEST: Copy file: /tmp/hw.info to
/var/opt/ignite/clients/0xEA1E498D1674/hw.info
TEST: Copy file: /tmp/io.info to
/var/opt/ignite/clients/0xEA1E498D1674/io.info
TEST: Copy file: /tmp/host.info to
/var/opt/ignite/clients/0xEA1E498D1674/host.info
4. Locate the information the debug log file that shows the expected allocation of volumes on
disk. Run the following command in the per-client directory for that system “instl_dbg –D . –
d” (please cd to this directory before running the command). Does the output match? How
useful does this make this command in terms of testing configuration changes without having
to actually install a system?
The following was part of the debug output:

* 0/0/0/0.0x1.0x0 (/dev/dsk/c0t1d0) (vg00)
* 7168 - 1842176 KB /stand
* 1842176 - 3939328 KB primary
* 3939328 - 4987904 KB /
* 4987904 - 5512192 KB /tmp
* 5512192 - 5614592 KB /home
* 5614592 - 12950528 KB /opt
* 12950528 - 17103872 KB /usr
* 17103872 - 19557376 KB /var
* 0 KB unallocated
The same information is available in the output of instl_dbg and it matches:
# instl_dbg -D . -d
======= Disk and Volume allocation ======
Mount Size Usage Disk / impact amount
Directory (Mb) Group (MB / %) shy (Kb)
----------------------------------------------------------------------
/stand 1792 VxFS vg00 131 7% 0
(swap_dump) 2048 SWAP_DUMP vg00 0 0% 0
/ 1024 VxFS vg00 279 27% 0
/tmp 512 VxFS vg00 0 0% 0
/home 100 VxFS vg00 0 0% 0
/opt 7164 VxFS vg00 4151 57% 0
/usr 4056 VxFS vg00 2801 69% 0
/var 2396 VxFS vg00 444 18% 0
----------------------------------------------------------------------
Size unallocated from group: vg00: 0Mb
* 0/0/0/0.0x1.0x0 (/dev/dsk/c0t1d0) (vg00)
* 7168 - 1842176 KB /stand
* 1842176 - 3939328 KB primary
* 3939328 - 4987904 KB /
* 4987904 - 5512192 KB /tmp

* 5512192 - 5614592 KB /home

* 5614592 - 12950528 KB /opt
* 12950528 - 17103872 KB /usr
* 17103872 - 19557376 KB /var
* 0 KB unallocated
This makes the command extremely useful when testing custom configurations when there is a need to
preview what will happen with disk layouts and impacts. When also used with the itool command it allows
you to test configurations with changes in a fraction of the time compared with having to cold install a
system to test configuration changes.
5. Locate an example of Ignite-UX automatically adding IA to the end of a command archive if you
created the debug level log message on a HP Integrity system,
In this example you can see Ignite-UX loading the files required to run the itool program:
DEBUG: Running: loadfile -lINSTCMDS /usr/ccs

/usr/dt/lib/hpux32/libDtHelp.so.1 /usr/dt/lib/hpux32/libDtSvc.so.1
/usr/dt/lib/hpux32/libtt.so.1 /usr/lib/hpux32/libCsup.so
/usr/lib/hpux32/X11R6/libICE.so.1 /usr/lib/hpux32/libICE.so.1
/usr/lib/hpux32/X11R6/libSM.so.1 /usr/lib/hpux32/libSM.so.1
/usr/lib/hpux32/X11R6/libX11.so.1 /usr/lib/hpux32/libX11.so.1
/usr/lib/hpux32/X11R6/libXext.so.1 /usr/lib/hpux32/libXext.so.1
/usr/lib/hpux32/Motif2.1/libXm.so.1 /usr/lib/hpux32/libXm.so.1
/usr/lib/hpux32/X11R6/libXp.so.1 /usr/lib/hpux32/libXp.so.1
/usr/lib/hpux32/X11R6/libXt.so.1 /usr/lib/hpux32/libXt.so.1
/usr/lib/hpux32/libstd.so.1 /usr/lib/hpux32/libstream.so.1
/usr/lib/hpux32/pa_boot32.so /usr/lib/nls /usr/obam /opt/ignite/bin
/opt/ignite/ui /opt/ignite/help
DEBUG: loadfile_main: pid = 126
DEBUG: Added suffix: IA, to result in lif_file: INSTCMDSIA
The last message shows Ignite-UX converting the INSTCMDS file refered to in the loadfile command to
INSTCMDSIA.
6. Locate an example of Ignite-UX allocating impacts to statements. What level impacts do you have?
Do you see the impacts at that level being allocated to the correct volumes?
The impacts here you can see here are at level 1 (that is all of the impacts shown only show one level of
directories):
DEBUG: Adding impact of sw: golden image1 (56Kb) dir: / to volume: /

DEBUG: Adding impact of sw: golden image1 (134848Kb) dir: /stand to volume:
/stand
DEBUG: Adding impact of sw: golden image1 (2868456Kb) dir: /usr to volume:
/usr
DEBUG: Adding impact of sw: golden image1 (4250744Kb) dir: /opt to volume:
/opt
DEBUG: Adding impact of sw: golden image1 (455072Kb) dir: /var to volume:
/var
DEBUG: Adding impact of sw: golden image1 (139096Kb) dir: /sbin to volume: /
DEBUG: Adding impact of sw: golden image1 (50Kb) dir: /dev to volume: /
DEBUG: Adding impact of sw: golden image1 (146728Kb) dir: /etc to volume: /
DEBUG: Adding impact of sw: golden image1 (72Kb) dir: /.sw to volume: /
DEBUG: Adding impact of sw: golden image1 (8Kb) dir: /.ssh to volume: /
DEBUG: Adding impact of sw: golden image1 (192Kb) dir: /tmp to volume: /tmp
DEBUG: Adding impact of sw: golden image1 (80Kb) dir: /home to volume: /home
The impacts in this example are summarized into the correct volumes.

7. Find the follow message in your debug log messages. Compare the sizes reported to the actual
sizes that your partitions end up at (use the diskinfo command on the partitions). Are they different?
If they are can you explain why?
DEBUG: Calculated EFI overhead to be 64 KB, EFI Boot Partition size: 512000
KB, HPUX Partition: 19557376 KB, HP Service Partition: 409600 KB,
Unallocated: 960 KB
The information show by the diskinfo commands is a little different (note that if you don’t have a HPSP
partition you will not have a _p3 (or s2 on HP-UX B.11.23) device file.
# diskinfo /dev/rdisk/disk4_p1
SCSI describe of /dev/rdisk/disk4_p1:
vendor: HP
product id: Virtual LvDisk
type: direct access
size: 511968 Kbytes
bytes per sector: 512
vendor: HP
type: direct access
size: 19557376 Kbytes
vendor: HP
type: direct access
size: 409600 Kbytes
The EFI partition (the first partition) is short by 32KiB on HP-UX B.11.31 – this does not happen on HP-
UX B.11.23. Remember this was discussed previously, there was a change with HP-UX B.11.31 to align
the HPUX partition so would be MiB aligned. The disk space to force the alignment is taken from the end
of the EFI partition.
8. When creating LVM volumes can you explain why logical volumes are created empty?
* Creating volume group "vg00".

TEST: run_cmd("/sbin/vgcreate -A n -e 4783 -l 255 -p 16 -s 4 /dev/vg00
/dev/disk/disk4_p2")
* Creating logical volume "vg00/lvol1" (/stand).
* Creating logical volume "vg00/lvol2" (swap_dump).
...
* Extending logical volume "vg00/lvol1" (/stand).


* Extending logical volume "vg00/lvol2" (swap_dump).
* Extending logical volume "vg00/lvol3" (/).
...
You can see from the above output that this is the way that logical volumes are created. That is created with
a zero size and then extended to be the expected size.
The reason for this is that the configuration syntax for LVM volume groups allows you to give a minor
number for a LVM volume group:
...
usage=VxFS
size=1835008KB
blksize=8192
version=5
largefiles=FALSE
mount_point="/stand"
stripes=0
stripe_size=0KB
minor_number=0x01
disk[_hp_root_disk]
usage=SWAP_DUMP
size=2097152KB
mount_point="primary"
stripes=0
stripe_size=0KB
minor_number=0x02
disk[_hp_root_disk]
usage=VxFS
size=1048576KB
blksize=8192
version=6
largefiles=TRUE
mount_point="/"
stripes=0
stripe_size=0KB
minor_number=0x03
disk[_hp_root_disk]
...

The issue here is that the minor numbers of logical volumes may not be contiguous so we need to create
"dummy" logical volumes to use up minor numbers that are never used. Once the logical volumes have all
been create the "dummy" logical volumes are removed and then the "real" logical volumes are extended to
their correct size.
9. Prove from your debug level log file that the disk filesystems really do get mounted at
/d_cfg_mnt_sb61.
You can see from the following output /d_cfg_mnt_sb61 gets created and then /dev/vg00/lvol3 is mounted
on that directory:
DEBUG: Making directory: /d_cfg_mnt_sb61

TEST: mkdir(/d_cfg_mnt_sb61, 0755)
TEST: chown(/d_cfg_mnt_sb61, 0, 0)
TEST: chmod(/d_cfg_mnt_sb61, 0755)
DEBUG: Directory: /d_cfg_mnt_sb61/ already exists
TEST: mount(/dev/vg00/lvol3, /d_cfg_mnt_sb61/)
DEBUG: Setting standard perms on: /d_cfg_mnt_sb61/
TEST: chown(/d_cfg_mnt_sb61/, 0, 0)
TEST: chmod(/d_cfg_mnt_sb61/, 0755)
DEBUG: Making directory: /d_cfg_mnt_sb61/etc
TEST: mkdir(/d_cfg_mnt_sb61/etc, 0755)
TEST: chown(/d_cfg_mnt_sb61/etc, 0, 0)
TEST: chmod(/d_cfg_mnt_sb61/etc, 0755)
DEBUG: Making directory: /d_cfg_mnt_sb61/stand
TEST: mkdir(/d_cfg_mnt_sb61/stand, 0755)
TEST: mount(/dev/vg00/lvol1, /d_cfg_mnt_sb61/stand)
Other filesystems are then mounted under that directory to reflect the final disk layout of the system.
10. Locate any messages that relate to instance numbers that are not preserved in your install.log file.
Do you expect that these devices should not have preserved instance numbers?

From Ignite-UX version C.7.7 it is expected that you should see these messages for devices that the kernel
reports do not need persistent instance numbers. Currently the only only devices seen that will print these
messages are the class “target” and the class “OO” (USB devices – not all of these devices may not need
instance numbers preserved).
11. From the recovered system how do you determine what version of Ignite-UX was used to install
and/or recover the system? Note that is not applicable to HP-UX B.11.11.
The following is from a HP-UX B.11.23 that has not been recovered (only installed):
# /usr/lbin/krs_print -r /ignite
0 /ignite (0x2)
1 /ignite/install (0x2)
version KR_VTYPE_STRING: "C.7.2.94" (0x2)

1 /ignite/recovery (0x2)
version KR_VTYPE_STRING: "NONE" (0x2)
This is from a HP-UX B.11.31 system that has been recovered:
# /usr/lbin/krs_print -r /ignite
0 /ignite (0x2)
1 /ignite/recovery (0x2)
1 /ignite/install (0x2)
1 /ignite/image (0x2)
The Ignite-UX version associated with installing a system is always kept in the KRS node /ignite/install.
If a system is recovered the KRS node /ignite/recovery is updated with the version of Ignite-UX that was
used to perform the recovery. Note that the KRS node /ignite/image is only set during an initial install at
this time.

Appendix D – A side by side comparison of

make_net_recovery and make_tape_recovery.
This section only compares what happens inside the make_net_recovery and make_tape_recovery binaries.
It does not cover what happens in programs that are called by make_net_recovery or make_tape_recovery.
Where appropriate references are made to the sections what cover what happens in those programs.
This section does not attempt to reproduce tables and footnotes that are included into the original text.

How make_net_recovery works How make_tape_recovery works
• Clear the environment variable “ENV” – • Clear the environment variable “ENV”.
this ensures that unexpected commands This ensures that unexpected commands
are not run when Ignite-UX runs any shell are not run (when Ignite-UX runs any shell
scripts. Sourcing a .kshrc (ENV is usually scripts). Sourcing a .kshrc (ENV is usually
set to ~/.kshrc when it is set) has been set to ~/.kshrc when it is set) has been
known to cause Ignite-UX problems in the known to cause Ignite-UX problems in the
past. past so it is cleared.
• The umask for the process is set (in • The umask for the process is also set (in
conjunction with the current umask) to be conjunction with the current umask) to be
at least 022 (preventing at least write at least 022 (preventing at least write
access group and other). The effective uid access group and other). The effective uid
is also checked to ensure that it is 0 (if not is also checked to ensure that it is 0 (if not
an error is logged and the program exits). an error is logged and the program exits).
• Internal support for debug mode output is • Internal support for debug mode output is
setup. The environment variable setup (the environment variable
INST_DEBUG controls debug level INST_DEBUG). Note that the log file
logging. Note that the log file (recovery.log) has not been opened yet.
(recovery.log) has not been opened yet.
• The name of the archive is determined is • The name of the configuration directory
determined. This is the same name that is that will be created is determined. This is
used in recovery directory under the per- the same name make_net_recovery creates
client directory on the Ignite server to to store the configuration and other files
store the configuration and other files associated with a recovery. The name
associated with a recovery. The archive always takes the following form:
name always takes the following form:
# date +"%Y-%m-%d,%H:%M"
# date +"%Y-%m-%d,%H:%M" 2008-05-12,19:24
2008-05-12,19:24
When refered to later in this discussion
When referred to later in this course any any reference to this value will be
reference to this value will be <date/time>. <date/time>.
• Variables are setup at this point to • Variables are setup at this point to
determine if this is make_net_recovery or determine if this is make_net_recovery or
make_tape_recovery that is running. Note make_tape_recovery that is running. Note
that past this point we will not discuss that past this point we will not discuss
those variables again or if code is being those variables again or if code is being
conditionally run based on the variables as conditionally run based on the variables as
it will be assumed that it is it will be assumed that this is
make_net_recovery that is running. make_tape_recovery that is running.

• The lock file • The lock file

(/var/opt/ignite/recovery/mnr_lockfile) is (/var/opt/ignite/recovery/mnr_lockfile) is
created and Ignite-UX attempts to lock it. created and Ignite-UX attempts to lock it.
Failing to lock the file with errno values Failing to lock the file with errno values
indicating that someone else already has indicating that someone else already has
the lock causes a message about another the lock causes a message about another
instance of make_net_recovery already instance of make_tape_recovery already
running to be printed. Other errno values running to be printed. Other errno values
cause a more general error message to be cause a more general error message to be
printed. printed.
If the lock file exists but is not locked this If the lock file exists but is not locked this
causes no problems for Ignite-UX. It will causes no problems for Ignite-UX there is
simply lock the existing file. no reason to remove the file. If Ignite-UX
reports that there is another instance of
Important: If Ignite-UX reports that there make_tape_recovery running when there
is another instance of make_net_recovery should not be - do not remove the file first
running when there should not be - do not investigate with fuser on the lock file to
remove the lock file. First investigate by determine who has the file locked. With
running fuser on the lock file to determine the pid information you can determine if
who has it locked. With this information there really is another instance of
you can determine if there really is another make_tape_recovery running.
instance of make_net_recovery running.
Note that this is the same lock file that is
used by make_net_recovery so you cannot
run both at the same time.
• The hostname is retrieved. Normally we • The hostname is retrieved, normally we

won’t be discussing actions such as. It is won’t be discussing actions such as this
mentioned here because if the hostname of but it is mentioned here because if the
a system is a fully qualified domain name hostname of a system is a fully qualified
Ignite-UX will remove the domain part of domain name Ignite-UX will remove the
the hostname and use just the hostname. domain part of the hostname and leave just
the hostname.
This is discussed here because it can cause
problems if you have the same hostname
and use it in multiple domains. When
make_net_recovery is attempting to purge
older recovery archives (according to the
setting of –n) it uses the hostname symlink
to determine how many archives exist. It is
possible because it doesn’t use the MAC
address to go directly to the per-client
directory that it may end up purging the
wrong number of older archives.

• The configuration directory from the

Ignite server is mounted
(/var/opt/ignite/clients is mounted on
/var/opt/ignite/recovery/client_mnt). The
next step is to determine the MAC address
to be used for this client. See the next
section titled “Looking at add_new_client
to understand why lanscan is called” for
more information about how this is done
(this processing of the history to determine
if an old clients directory can be reclaimed
is also performed in make_net_recovery).
After this some initial files and a directory

are created in the per-client directory to
enable support for recovery. Lastly the
configuration directory is created in under
the recovery directory (in <date/time>
format) and then the latest link is removed
(if it exists) and is changed to point to the
newly created directory.
Looking at add_new_client to understand why

lanscan is called
• The configuration directory on the local

client is created
(/var/opt/ignite/recovery/<date/time>).
The “latest” symbolic link is created (or
recreated) to point to this new directory.
• Next the recovery.log file is opened, this • The recovery log file is opened (in the
file is located in the newly created configuration directory).
/var/opt/ignite/recovery/client_mnt/<MAC The name of the log file is
>/recovery/<date/time> directory. Where /var/opt/ignite/recovery/<date/time>/recov
<MAC> is the LLA (Link Level Address) very.log.
or MAC address discovered in the
previous section. The make_net_recovery
command also places the name of the log
file (including directory) into the
environment with the environment
variable INST_LOG_FILE. This allows
scripts and subsequent programs to open
and write messages into the log file.

• After that there is a check to ensure (since

we are creating a network recovery archive)
to ensure that the system can perform a
network boot. If the check fails a warning
is printed that says: "<hostname> is not
network bootable. See man page for
make_boot_tape for information on using
the system recovery archive created by
make_net_recovery". All HP Integrity
servers can network boot so this message
will never be seen on that kind of system.
The extended regular expression (ERE)

that is used to check if the system is
capable of a network boot or not is
"/[TVHGIE]|9000/8.7S". This means that
the ERE would match a model string if
one of the following is true:
3. It contained a / followed one of

the uppercase letters T, V, H, G, I,
or E.
4. It contained “9000/8” followed
by any character followed by
“7S”.
For the first kind of system all of them are

past the end of hardware support. For the
second case these systems have been out
of hardware support for a very long time.
• If the UI for make_net_recovery was

going to be discussed it would be at this
point that it is run. However we will not be
discussing it or how information is passed
back from it to make_net_recovery.
• Now we need to run make_sys_image • Now we need to run make_sys_image

using the command line using the command line
“/opt/ignite/data/scripts/make_sys_image - “/opt/ignite/data/scripts/make_sys_image
s local –tp” to determine of the system –p” to determine of the system needs pax
needs pax patches. patches. Please refer to the section
“make_sys_image does some pax patch
checks” for additional information about
this step.
make_sys_image does some pax patch checks

• After calling make_sys_image we process • After calling make_sys_image we process

the exit value. If it is 3 (indicating an error the exit value. If it is 3 (indicating an error
as discussed previously since the user as discussed previously since the user
chose to cancel the archive creation) we chose to cancel the archive creation) we
exit with error. Note an exit value of 4 exit with error. An exit value of 4
(indicating a warning) is ignored, so (indicating a warning) is ignored, so
chosing to ignore the missing pax patch chosing to ignore the missing pax patch
won’t directly cause make_net_recovery to won’t cause make_tape_recovery to exit
exit with warnings when it’s complete. with warnings when it’s complete.
• Next the archive_content file is created. • Next the archive_content file is created.
The information placed into this file is The information placed into this file is
created based up the usage of the –A and – created based up the usage of the –A and –
x options (if provided) otherwise the x options (if provided) otherwise the
archive_content file given to the command archive_content file given to the command
with the –f option is used. If there were no with the –f option is used. If there were no
–A, -x, or –f options provided and the –i –A, -x, or –f options provided and the –i
option was used (to run the user interface) option was used (to run the user interface)
the archive contents file written by the the archive contents file written by the
user interface is used, finally if none of the user interface is used, finally if none of the
above were performed a default above were performed a default
archive_content file is written that only archive_content file is written that only
allows for a minimal system to be included allows for a minimal system to be included
into the archive. into the archive.
The section of the make_net_recovery The section of the make_tape_recovery

manual page titled “Including and manual page titled “Including and
Excluding From Archive” explains the Excluding From Archive” explains the
format of the archive_content file (all of format of the archive_content file (all of
the values defined there can also be given the values defined there can also be given
with a combination of the –x and –A with a combination of the –x and –A
options). options).
• The defaults file is read. This file is • The defaults file is read if it exists. This
/var/opt/ignite/clients/<LLA>/recovery/def file is /var/opt/ignite/recovery/defaults on
aults on the Ignite server. The values from the local system. The values from the
the defaults file are only used if there are defaults file are only used if there are no
no arguments that override them given on arguments that override them given on the
the command line. If there are no values in command line. If there are no values in the
the defaults file for any item the builtin defaults file for any item the builtin
defaults used by make_net_recovery will defaults used by make_tape_recovery will
be used instead. The defaults file is be used instead. The defaults file is
automatically created by the automatically created by the
make_net_recovery GUI to communicate make_tape_recovery GUI to communicate
back information to make_net_recovery back information to make_net_recovery
but it can be created manually. but it can be created manually.

The valid information for the defaults file The valid information for the defaults file
is: is:
RECOVERY_LOCATION=<NFS source> RECOVERY_LOCATION=<NFS source>

RECOVERY_DESCRIPTION=”string” RECOVERY_DESCRIPTION=”string”
SAVE_NUM_ARCHIVES=<number> SAVE_NUM_ARCHIVES=<number>
TAPE_DESTINATION=<device> TAPE_DESTINATION=<device>
ARCHIVE_TYPE=tar|cpio|pax ARCHIVE_TYPE=tar|cpio|pax
They can be defined as: 1. RECOVERY_LOCATION is the

1. RECOVERY_LOCATION is the remote NFS filesystem where the
remote NFS filesystem where the archive needs to be stored, for
archive needs to be stored, for example
example 10.10.20.1:/var/opt/ignite/recover
10.10.20.1:/var/opt/ignite/recover y/archives/mysystem (ignored by
y/archives/mysystem. make_tape_recovery).
2. RECOVERY_DESCRIPTION is 2. RECOVERY_DESCRIPTION is
a quoted string describing the a quoted string describing the
archive. archive.
3. SAVE_NUM_ARCHIVES must 3. The value for
be a number, it is the number SAVE_NUM_ARCHIVES must
recovery archives (including the be a number, it is the number
one being created) that recovery archive configurations
make_net_recovery should leave (including the one being created)
after it completes. that make_tape _recovery should
4. TAPE_DESTINATION can be leave after it completes.
set this to a device you want to 4. For TAPE_DESTINATION you
use with make_tape_recovery can set this to the device you
(ignored by make_net_recovery). want to use with
5. ARCHIVE_TYPE can be set to make_tape_recovery (ignored by
the archive type required for your make_net_recovery).
recovery archive, the pax option 5. You can set ARCHIVE_TYPE to
is not available on systems that the archive type required for your
do not support it. recovery archive. The pax option
is not available on systems that
do not support it.
• If not set (by command line options or the • If not set (by command line options or the
defaults file) the following default values defaults file) the following default values
are assigned: are assigned:
1. The recovery description 1. The recovery description

becomes "Recovery Archive" becomes "Recovery Archive"
2. The number of archives to save 2. The number of archives to save
becomes 2 becomes 2
3. The archive type is tar (i.e. 3. The archive type is tar (i.e.
POSIX tar or ustar interchange portable tar interchange format)
format)
RECOVERY_LOCATION and
TAPE_DESTINATION do not have
default values.

• Next we need to complete the version • Next we need to complete the version
checks to check the version of Ignite-UX checks to check that the system has its
on the client against the server to ensure Ignite-UX filesets all at the same revision
that they are compatible. (mixed filesets are not supported on a
system).
make_net_recovery and the version check make_tape_recovery and the version check
A discussion of compatibility A discussion of compatibility
make_net_recovery and automatic updates
• The command • The command

“/opt/ignite/data/scripts/make_sys_image - “/opt/ignite/data/scripts/make_sys_image -
s local –L” is run to backup the non- s local –L” is run to backup the non-
default contents of the LIF on the boot default contents of the LIF on the boot
disk. The lif contents are written to disk. The lif contents are written to
/usr/lib/ignite_bootlif. We’re not going to /usr/lib/ignite_bootlif. We’re not going to
look at how this is done in look at how this is done in
make_sys_image, if you wish to review make_sys_image, if you wish to review
the code remember that make_sys_image the code remember that make_sys_image
is a script that anyone can read. is a script that anyone can read.
The following LIF entries are not copied

to the backup file: LABEL, FS, SWAP,
ISL, AUTO, HPUX, and PAD. HP
Integrity systems only contain LIF files in
this list so none of them are ever backed
up.
• The list_expander command is run to • The list_expander command is run to

determine the list of devices that are going determine the list of devices that are going
to be associated with the recovery archive. to be assocated with the recovery archive.
The command run to do this is The command run to do this is
“/opt/ignite/lbin/list_expander -d -f “/opt/ignite/lbin/list_expander -d -f
<archive_content> (we’ve previously <archive_content> (we’ve previously
discussed the archive content file and discussed the archive content file and
where it is written to). The information is where it is written to). The information is
gathered by the command is saved away gathered by the command is saved away
inside make_net_recovery. inside make_tape_recovery.
• The io.info file is created by starting the • The io.info file is created by starting the
I/O listener and asking it to perform an I/O listener and asking it to perform an
inventory of the system (we will be briefly inventory of the system (we will be briefly
discussing the listeners in a separate discussed in a separate section about the
section). listeners).

• The system_cfg file is created by calling • The system_cfg file is created by calling
“/opt/ignite/bin/save_config –f “/opt/ignite/bin/save_config –f
/var/opt/ignite/client_mnt/<MAC>/recover /var/opt/ignite/
y/<date/time>/system_cfg …” the volume recovery/<date/time>/system_cfg …”. The
groups, disk groups, or whole disks that volume groups, disk groups, or whole
will be included into the archive (fully or disks that will be included into the archive
partially) are provided to the save_config (fully or partially) are provided to the
command so it can generate the disk save_config command so it can generate
layout for the archive. Information about the disk layout for the archive (replacing
which volume groups, disk groups, or the … above). Only some parts of the
whole disks need to be included is functionality in the save_config script will
gathered from the output of list_expander. be covered in this course. When complete
the command use to check the syntax of a
Most of the functionality of the configuration file is run over system_cfg
save_config script will not be covered in (the command is /opt/ignite/bin/instl_adm
this course (parts as they relate to the I/O –T –f <configfile>).
listener and a brief general overview will
be). When complete the command use to For more information about save_config
check the syntax of a configuration file is see the section “A quick look at
run over system_cfg (the command is save_config“.
/opt/ignite/bin/instl_adm –T –f
<configfile>).
For more information about save_config

see the section “A quick look at
save_config“.
• The next step is to backup all of the • The next step is to backup all of the
volume group information. The volume group information. The
vgcfgbackup command is run for all vgcfgbackup command is run for all
volume groups (any error causes the volume groups (any error causes the
program to stop doing this and exit in program to stop doing this and exit in
error). After each vgcfgbackup command error). After each vgcfgbackup command
the following command is run “vgexport – is run the command “vgexport –p –s –m
p –s –m /etc/lvmconf/<vg>.mapfile”. A /etc/lvmconf/<vg>.mapfile” is created.
map file for each volume group is created. The –s option is used to include
The –s option is used to include information into the map file to make it
information into the map file to make it easier to vgimport volume groups
easier to vgimport volume groups manually later if required.
manually later if required.

• The configuration file • The configuration file

/var/opt/ignite/client_mnt/<MAC>/recover /var/opt/ignite/recovery/<date/time>/contr
y/<date/time>/control_cfg is created. It is ol_cfg is created. The file is created
created directly by make_net_recovery not directly by make_tape_recovery not by a
by a separate program. This control file separate program. The control_cfg file
contains configuration used to control contains configuration used to control
aspects of the recovery, these include: aspects of the recovery, these include:
1. Shell scripting to run vgimports, 1. Shell scripting to run vgimports,

vgchange, and vgcfgbackup vgchange, and vgcfgbackup
commands and sets up the commands and sets up the
variable _IMPORT_VG so the variable _IMPORT_VG so the
user can stop volume groups from user can stop volume groups from
being imported via the additional being imported via the additional
button in the advanced user button in the advanced user
interface on the basic tab in itool. interface on the basic tab.
2. If the system is using VxVM disk 2. If the system is using VxVM disk
groups a series of VxVM groups a series of VxVM
commands will also be included commands will also be included
into the configuration file to into the configuration file to
allow VxVM to re-start allow VxVM to re-start
successfully after a recovery. If successfully after a recovery. If
these commands are run or not is these commands are run or not is
also controlled by the setting of also controlled by the setting of
the _IMPORT_VG variable. the _IMPORT_VG variable.
3. Setting up the _HP_CLONING 3. Setting up the _HP_CLONING
variable based on the model variable based on the model
string of the system this can also string of the system this can also
be changed via the additional be changed via the additional
button in the advanced user button in the advanced user
interface on the basic tab in case interface on the basic tab in case
a cloning session is being a cloning session is being
performed to an identical model performed to an identical model
of system. of system.
4. The configuration variable 4. The configuration variable
_hp_hide_other_disks to allow _hp_hide_other_disks to allow
disks that are used by the system disks that are used by the system
(i.e. they're the disks that will be to be hidden so they cannot be
imported rather than recreated accidentally ovewritten. The
and recovered) to be hidden so disks in _hp_hide_other_disks are
they cannot be accidentally the disks that will be imported
ovewritten. This is controlled by rather than recreated and
the _hp_allow_use_of_imports recovered. This is controlled by
variable which appears as "Allow the _hp_allow_use_of_imports
use of other disks" on the variable which appears as "Allow
additional button in the advanced use of other disks" on the
user interface on the basic tab in additional button in the advanced
itool. The value "NO" means you user interface on the basic tab. A
cannot use them and it is the value of "NO" means you cannot
default, "YES" means that they use them (it is the default). If you
can be used during the recovery. change it to "YES" it means that
they can be used during the
recovery.

5. Set the internal variable 5. Set the internal variable

RECOVERY_MODE to TRUE RECOVERY_MODE to TRUE
so Ignite-UX knows that this is a so Ignite-UX knows that this is a
recovery session. recovery session.
After the configuration file has been After the configuration file has been
written the syntax of the file is validated written the syntax of the file is validated
using the instl_adm command. using the instl_adm command. The
command is /opt/ignite/bin/instl_adm –T –
f <configfile> (where <configfile> is
control_cfg, including the complete path to
the file).
• Now we can generate the flist file. This • Now we can generate the flist file. This
has to be done before we can generate the has to be done before we can generate the
archive_cfg file (in the next step) because archive_cfg file (in the next step) because
the information about what files will be the information about what files will be
included into the archive is used to included into the archive is used to
generate the impacts information. The generate the impacts information. The
command run to generate the flist file is command run to generate the flist file is
“/opt/ignite/lbin/list_expander -s -S -f “/opt/ignite/lbin/list_expander -s -S -f
/var/opt/ignite/client_mnt/<MAC>/recover /var/opt/ignite/recovery/<date/time>/archi
y/<date/time>/archive_content -l ve_content -l
/var/opt/ignite/client_mnt/<MAC>/recover /var/opt/ignite/recovery/<date/time>/flist
y/<date/time>/flist 2> /dev/null”. 2> /dev/null”.
A short break from make_net_recovery
• The next step is to create the archive_cfg • The next step is to create the archive_cfg
file file
(/var/opt/ignite/client_mnt/<MAC>/recove (/var/opt/ignite/recovery/<date/time>/archi
ry/<date/time>/archive_cfg). Since ve_cfg). Since multiple programs are
multiple programs are called during this called during this phase we will look at the
phase we will look at the steps in more steps in more detail.
detail.
1. The impact level that needs to be
1. The impact levels that need to be generated is determined. The
generated are determined. The impact level is based upon the
impact levels are based upon the mount point of a filesystem, the
mount point of a filesystem, the more directories in a mount point
more directories in a mount point that is fully or partially included
that is fully or partially included into an archive the higher the
into an archive the higher the impact level that will be used.
impact level that will be used. The command that is run is
The command that is run is “/opt/ignite/lbin/list_expander -d
“/opt/ignite/lbin/list_expander -d -v -f
-v -f /var/opt/ignite/recovery/<date/tim
/var/opt/ignite/client_mnt/<MAC e>/archive_content 2>/dev/null”.
>/recovery/<date/time>/archive_c The output from this command is
ontent 2>/dev/null”. The output then parsed to determine the
from this command is then parsed filesystems affected and what
to determine the filesystems level the impacts need to be.
affected and what level the
impacts need to be.

2. Now the arguments for the 2. The arguments put together for
make_arch_config command are the make_arch_config command
prepared. If the (undocumented) now depend on the archive type
option –N is used “-C n” is added chosen, the following table shows
to the arguments (the default is to the command and its options. The
gzip the archive). In the tables commands are exactly the same
below this will not be mentioned except for that final –m option to
but it is added to the arguments to indicate the archive type.
make_arch_config if –N is given
to make_net_recovery.
The arguments put together for the

make_arch_config command now depend on the
archive type chosen.
• A check is done to ensure that there is

enough space free in the filesystem where
the LIF will be created for the tape. Note
that the space check only ensures that
there is approximately 32MiB free in the
filesystem and the LIF is significantly
larger than that.
• The instl_adm command is involved to

syntax check the system_cfg, control_cfg,
and archive_cfg files.
• If the /var/opt/ignite/recovery/config.local
file exists it is it will be added to the
arguments that will be passed to
make_medialif or make_ipf_tape. If the
/opt/ignite/Version file exists the –V
option will be added to the arguments that
will be passed to make_medlif or
make_ipf_tape.
• The next steps are specific to the

architecture of the system that
make_tape_recovery is running on. The
next two sections are separate for that
reason. After they are complete the
discussion of make_tape_recovery will
merge back into a single thread.

The next step, now all of the preparation is

complete, is to create the archive.
Before we can write the archive we need to mount

the remote filesystem where the archive is going to
be stored. The local directory on which this is going
to be mounted is /var/opt/ignite/recovery/arch_mnt.
The actual remote filesystem that gets mounted
depends on if the –a option was provided to
make_net_recovery or not. If –a was given the
remote server/directory provided is used, otherwise
the remote directory mounted will be
/var/opt/ignite/recovery/archives on the Ignite
server (given with the –s option).
• The directory on which the archive

filesystem will be mounted is created.
• If the filesystem that we want to mount at

/var/opt/ignite/recovery/arch_mnt is
already mounted then we record this so we
don’t attempt to umount it later (Ignite-UX
won’t attempt to umount directories when
someone else has already mounted the
directory manually).
• If it wasn’t mounted we mount the NFS

filesystem that the archive will be written
to.
• Once mounted we ensure that the NFS

filesystem is writable (there’s no point in
continuing if we can’t write something to
the filesystem as writing the archive will
fail).
• The umask is changed to be a minimum of

077, this is done to help prevent anyone
else from accessing and reading the
archive that will be written.
Next we get the command together that will be used

to call make_sys_image. Similarly to
make_arch_confiug if the undocumented –N option
is used the arguments “-c n” will be added to the
call to make_sys_image.

• The umask is returned to what it was

before being changed above.
• The manifest is created by calling

print_manifest.
• The CINDEX file for this client is updated

to include this newly created recovery
archive.
• Cleanup processing is done (this includes

unmounting filesystems if
make_net_recovery mounted them) and
the creation of the recovery archive is
complete.
Continuing on HP Integrity servers
This section deals with specific actions taken to

create a bootable tape that are specific to HP
Integrity servers.
• On HP Integrity systems the following

warning message is printed:
"You are about to create an Itanium-based

recovery tape. If this system does NOT
support direct tape boot, you will need to
perform "two-step media recovery" where
the boot media (CD or DVD) has the same
version of Ignite-UX as the version on this
tape.".
• A file is created (/var/tmp/tmp_cfg_file)

that contains the information that will be
placed into the install filesystems that will
be written to tape, this information when
written looks like:
use_expert_ui=TRUE
env_vars += "INST_ALLOW_WARNINGS=10"
run_ui=TRUE|FALSE
sysadm_message = "Recovery tape
created from system: <hostname> on
<date>"
Where <hostname> is the name of the host

and <date> is the result returned by
ctime(2). If the –t option is supplied to
make_tape_recovery the user supplied
description is used instead for
sysadm_message

• The temporary file containing information

to be added into the install filesystem is
syntax checked using instl_adm.
• The command line for calling

make_ipf_tape is prepared. The command
used depends on if the –D option (to give a
tape volume name was given):
Continuing on HP9000 servers
This section deals with actions that are specific to

creating bootable tapes on HP9000 systems.
• The make_medialif command is run with

the following options to create the LIF that
will be written to tape:
/opt/ignite/bin/make_medialif -a - f
/var/opt/ignite/recovery/<date/time>/system_cfg -f
/var/opt/ignite/recovery/<date/time>/archive_cfg –f
/var/opt/ignite/recovery/config.local –V -l
<boot_destination> -C <description>
Italicised options are conditional see the previous

information to determine under what conditions
they may appear.
• The default contents of the install

filesystems are written to the file
/var/tmp/tmp_cfg_file:
use_expert_ui=TRUE
env_vars += "INST_ALLOW_WARNINGS=10"
run_ui=TRUE|FALSE
sysadm_message = "Recovery tape
created from system: <hostname> on
<date>"
Where <hostname> is the name of the host

and <date> is the result returned by
ctime(2). If the –t option is supplied to
make_tape_recovery the user supplied
description is used instead for
sysadm_message
• The file /var/tmp/tmp_cfg is tested using

instl_adm to ensure that it passes a syntax
check.
• The configuration file /var/tmp/tmp_cfg is

written back to the install filesystems in
the newly created LIF.

• The LIF is written to tape using dd and a

block size of 2KiB.
make_tape_recovery after writing some of the

tape
Note that at this point the two architectures have

joined back into the same code path.
• The make_sys_image script is called to

write out the archive to tape.
• The tape is rewound to the beginning of

the tape.
• The print_manfest command is called to

create the manifest.
• Cleanup processing is done.

ServiceGuard Admin

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ServiceGuard Admin

Uploaded by

Copyright:

Available Formats

Ignite-UX Advanced

Testing media without burning it ........................................................................................................ 58

How the bin and lbin directories work................................................................................................... 132

Indirect usage examples......................................................................................................................... 237

The new 11.31 I/O stack........................................................................................................................ 351

Table 1 - File numbers on a PA-RISC bootable tape ..................................................................................... 9

Tape formats – HP9000 bootable tape format

Table 1 - File numbers on a PA-RISC bootable tape

2 Archive Varies (See “Table 2 -

Table 2 - Archive block sizes on tape

Contents of the LIF

# dd if=/dev/rmt/0mn of=./lif bs=2k

The contents of the LIF from the tape are:

cfg "Recovery Archive" {

# lifcp lif:SCRIPTS - | gzcat | pax

Extracting the archive

The archive always a path relative archive:

Upon completion, dd reports the number of input and output records:

f+p records in Number of full and partial blocks read.

# dd if=/dev/rmt/0m of=archive bs=32256

Copying a boot tape

Putting the archive back onto the tape is just as easy:

# dd if=./archive of=/dev/rmt/0m bs=10k

# dd if=./archive of=/dev/rmt/0m bs=5k

# dd if=./archive of=/dev/rmt/0m bs=32256 conv=sync

Comparing the limitations of different archive types

Table 3 - archive features and limitations

Supports ACLs (f) No No No

Default block size (g) 5k 10k 5k

Maximum block size 32256 32256 32256

This raises some limitations:

# pax -w -x ustar -f pax.ustar this*

# pax -v < pax.ustar

# pax -w -x cpio -f pax.cpio test*

# define UID_MAX MAXUID /* smallest unattainable value for a

Then from /usr/include/sys/param.h we have:

#define MAXUID MAXINT /* smallest unattainable value for a user or

From the same header file we have:

Tape formats – HP Integrity older formats

Tape formats – HP Integrity history

Table 4 - Tape format history (HP Integrity systems)

C.6.4 and lower PA-RISC bootable format.

C.6.8 onwards Natively bootable format for Itanium systems.

Tape formats – HP Integrity native tape boot format

Table 5 - Contents of natively bootable tape for HP Integrity systems

1 ANSI Label containing 13 ANSI Label

3 ANSI Label 15 ANSI Label

4 ANSI Label 16 ANSI Label

6 ANSI Label 18 ANSI Label

7 ANSI Label 19 ANSI Label

9 ANSI Label 21 ANSI Label

10 ANSI Label 22 ANSI Label describing

About label files

The first ANSI label (file 1)

# dd if=/dev/rmt/0mn of=file1 bs=80

We’ll expand on what the data in here actually means:

Next we have a HDR1 record:

1. File Section Number

What is EFIBOOTHPUX? (file 2)

The second ANSI label (file 3)

# dd if=/dev/rmt/0mn of=file3 bs=80

The third ANSI label (file 4)

Here’s the data from file 4: