Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

Ignite-UX FAQ


[ Usenet FAQs | Web FAQs | Documents | RFC Index | Cities ]
Ignite-UX (IUX) Frequently Asked Questions

See reader questions & answers on this topic! - Help others by sharing your knowledge
     @(#) IUX FAQ $Revision: 10.102 $ $Date: 2001/05/30 21:40:04 $

                            About this FAQ
                            --------------

The current contents were created by the Ignite-UX engineering team from
support questions gathered from various sources. For future editions, we invite
your input via the "ignite-ux-notify" mailing list. Submissions will not be
distributed to the mailing list on an individual basis, but compiled into the
FAQ and distributed periodically as input dictates.

  Submission criteria
  -------------------
  Acceptable:
   o Solutions to sticky problems you solved, from which other users might
     benefit.
   o Slick customizations that might benefit other users.
   o Customized uses for Ignite-UX of which other users could take advantage.

  Not Acceptable:
   o Support questions. Contact your Response Center for support.


To submit, send content to "ignite-ux-notify@igniteux.fc.hp.com" with subject 
"FAQ". You will not receive a response, but you will be given credit in the FAQ
for your contribution (unless you tell us otherwise).

    --------------------
    Getting this FAQ
     web  -  http://software.hp.com/products/IUX/docs/iux_faq
     mail -  null message to iux_faq@igniteux.fc.hp.com (most current)
    --------------------

---------------
Special Notice:  The Ignite-UX product is Year 2000 compliant, beginning
                 with the 1.45 release.
---------------


                          TABLE OF CONTENTS
			  -----------------

1. Known Problems
1.1  Q: Some commands core dump and die after installing or recovering, why?
1.2  Q: Ignite GUI core dumps, why?
1.3  Q: I updated my server, now it can't find "/d_cfg_mnt_sb61/monitor_bpr".
1.4  Q: Why do hostnames longer that 8 characters not work for 10.X?
1.5  Q: I updated my server, now it complains that it "Cannot determine
        dump size limit"
1.6  Q: Can the GUI interface for make_tape_recovery span multiple
        tapes?
1.7  Q: Why do I get Warnings from pax concerning files that are not
        on the system when I run either make_tape_recovery or
        make_net_recovery?
1.8  Q: When igniting from an archive I get numerous "samreg" errors.
1.9 Q: Can an IUX server install clients on multiple subnets?
1.10 Q: Recovering a system failed, could not create a logical volume.
1.11 Q: Using bootptab entries to satisfy the DHCP request doesn't work, why?
1.12 Q: How can I keep make_net_recovery version 2.0 from erasing
        volume groups that contain only unmounted and raw logical volumes?
1.13 Q: When igniting 10.20 systems, I get ERRORS regarding mounting of
	file systems, why?
1.14 Q: Why do some applications and shells hang over NFS after igniting?
1.15 Q: bootsys -i "configuration" [sys1...] fails, why?
1.16 Q: Failures, hangs, and odd behavior caused by ENV environment variable. Why?
1.17 Q: Doing a bootsys ("push") install to J2240 omits ps2/CentIF drivers.
1.18 Q: The bootsys command occasionally hangs on 11.00 clients, why?
1.19 Q: Why does loading the 11.00 64-Bit Minimal HP-UX environment fail?

2. Server Setup
2.1  Q: Should I use DHCP or bootp?
2.2  Q: Why did it call my client "<hostname>.0x080009...."?
2.3  Q: Which version of Ignite-UX supports my hardware?

3. Config files
3.1  Q: What should go in which config file?
3.2  Q: How do I preview config file changes?
3.3  Q: Is there a way in the configuration files to ignore warings?
3.4  Q: Which config file example should I use for an 11.00 archive?

4. Recovery (make_recovery)
4.1  Q: We tried running the recovery option from a client and got tftp errors.
4.2  Q: How do I duplicate a tape made with make_recovery?
4.3  Q: Why don't the Online Diagnostics LIF files get restored?
4.4  Q: I get an "bad IPL checksum" error when booting B1000, C3000, and J5000
4.5  Q: Why do I get the error: "The minor number of the volume group exceeds 
        the value IUX can support."?
4.6  Q: Dealing with hot swappable disks during recovery
4.7  Q: Why does make_recovery hang while trying to write the archive?
4.8  Q: Should I run make_recovery in single user mode or can users be
        on the system when I do the recovery?
4.9 Q: What is the maximum amount of data that a make_recovery tape can
        hold?
4.10 Q: Why do I get an error from pax saying: linkname greater
        than 100 characters?  I have PHCO_20388 installed.

5. General Install
5.1  Q: Confused about the way that IUX estimates space needed for file systems.
5.2  Q: How can I set the timezone such that the install.log file is in local
        time?
5.3  Q: When does IUX configure software?
5.4  Q: How do I set the targets final networking information?
5.5  Q: What if I don't want to use DHCP to set networking information?
5.6  Q: Having problems installing to system with small (<1GB) root disk.
5.7  Q: How is software in a depot made available for installs?
5.8  Q: How can I know whether I can install a 64-bit OS on a system?
5.9  Q: FDDI software is in my archive, yet IUX requires that I select it, why?
5.10 Q: How many systems can I install at once - in parallel?

6. Network Install
6.1  Q: What network architectures are supported?
6.2  Q: My 715/50 won't network boot off of my IUX server, why?
6.3  Q: When I try to boot, I get the following error: IPL error: bad LIF magic
6.4  Q: How do I set up a 9.0X system as a Boot Helper?
6.5  Q: Using "control_from_server=true" & "run_ui=false" I still get prompted.
6.6  Q: bootsys -w seems to work in reverse;The client didn't wait for the
        server.
6.7  Q: bootsys does not work on diskless clients, how can I remotely install?
6.8  Q: Client "search lan", the server doesn't appear on the list. 
6.9  Q: Bootsys fails due to insufficient space in the /stand volume, why?
6.10 Q: Can I have the IUX server and client on different subnets?

7. Media Install
7.1  Q: How do I create bootable IUX media with my configs on it?
7.2  Q: Can I make a bootable tape with an SD depot on it?
7.3  Q: Why does swinstall of patches hang during the software analysis?
7.4  Q: Why do I get dce / rpc errors during the configuration stage?
7.5  Q: How can I put an OS archive on multiple CD-ROM's?

8. Archive installs (golden images)
8.1  Q: What does this mean? gunzip: stdin: unexpected end of file
8.2  Q: Some files from my archive don't end up on the install target, why?
8.3  Q: What does "pax_iux: X: Cross-device link",
        "pax_iux: X: File exists", or "pax_iux: X : Device busy" mean?
8.4  Q: What HP applications are tested for use with Ignite-UX?
8.5  Q: How can the OnlineDiag LIF volumes be restored during the installation?

9. Getting Ignite-UX
9.1  Q: What is different about the Web version?
9.2  Q: Can Ignite-UX bits be retrieved via ftp rather than downloaded from
        the web?
9.3  Q: Is Ignite-UX available on media?
9.4  Q: How do I update my Ignite-UX server to a new version?
9.5  Q: How much of Ignite-UX do I need to install?

10. Loading Patches
10.1  Q: Can patches be installed with software?
10.2  Q: How do I prevent backup copies of patched files from being saved?
10.3  Q: Loading superseded patches causes a failed status, how to workaround?

11. Network Recovery
11.1  Q: How can I learn more about network recovery?
11.2  Q: How does make_net_recovery differ from make_recovery?
11.3  Q: Can I still use make_recovery on a system if I am also using
         make_net_recovery?
11.4  Q: How can I clone a system using make_net_recovery?
11.5  Q: How can I tell which files will be included in the archive
         created by make_net_recovery?
11.6  Q: How can I tell which disks or volume groups will get re-created
         during an installation from a make_net_recovery configuration? 
11.7  Q: How can I use make_net_recovery if I need to be able to recover
         from a tape?
11.8  Q: Which files does Ignite-UX change during an installation from
         a make_net_recovery configuration?
11.9  Q: How can I keep archive(s) from being deleted by make_net_recovery 
         when new archives and configurations are created by subsequent 
         invocations of make_net_recovery?
11.10 Q: How can I make configuration file additions to all recovery
         configurations for a given client?
11.11 Q: How can I select from the standard file system layouts during a 
         recovery?
11.12 Q: How can I keep make_net_recovery version 2.0 from erasing
         volume groups that contain only unmounted and raw logical volumes?
11.13 Q: Why can make_net_recovery fail when the archive is 2GB or more?
11.14 Q: How can I keep make_net_recovery version 2.0 and 2.1 from core dumping
         when I have more than 8 volume groups?
11.15 Q: How can I keep make_net_recovery version 2.0 and 2.1 from crossing
         and archiving files from NFS mounts when I have symlinks from
         essential directories to NFS mounted directories, and when there
         is a symlink in the pathname to the directory?
11.16 Q: I replaced the client system, and the LAN address is now different.
         How can I restore the new system from the old net-recovery archive?
11.17 Q: Why do I get the error: "The minor number of the volume group exceeds 
         the value IUX can support."?
11.18 Q: Dealing with hot swappable disks during recovery
11.19 Q: Why does make_net_recovery hang while trying to write the archive?
11.20 Q: Why does archive_impact fail during make_net_recovery
========================================================================

--------------------
1. Known Problems
--------------------

1.1
Q: Some commands core dump and die after installing or recovering, why?

A: When installing systems from an archive, or from a tape made
   with make_recovery or make_tape_recovery, the pax(1m)
   command attempts to optimize disk space by creating
   files with "holes" in them (sparse files) if a file
   contains a block of nulls.  In most cases
   this does not cause a problem since the files will appear
   identical in all respects except for the amount of disk space
   used as reported by the "du" command.  However when this
   happens to an executable file it can cause the executable to
   unpredictably die with a bus-error and core-dump.
   
   A kernel patch exists that will allow sparse executables to
   execute correctly.  This patch should be loaded on your
   system prior to using make_recovery or creating an
   archive using make_sys_image(1M).  The patches that contain
   the fix, are listed below.  Note that these patch numbers have
   already been superseded and only their replacement version may be
   available.
   
       10.01: PHKL_23512 (S700), PHKL_17448 (S800)
       10.10: PHKL_11240 (S700), PHKL_11241 (S800)
       10.20: PHKL_16750 (S700), PHKL_16751 (S800)
       (fixed at 10.30 & 11.00)

================================================================
1.2
Q: Ignite GUI core dumps

A: If your system has patch PHSS_12824 Motif or PHSS_13743, remove it 
or install PHSS_22944. PHSS_12824 was found to be bad.

======================================================================
1.3  Q: I updated my server, now it can't find "/d_cfg_mnt_sb61/monitor_bpr".

A: This is caused by having a mix of Ignite-UX fileset revisions on your
   server.  In most cases it happens when you update only one release
   bundle (like Ignite-UX-10-20) even though you install other
   releases from that server.

   An easy way to check for this case is to look at the output from
   the command "swlist Ignite-UX".  All the filesets should have the
   same revision, if not then you need to install all consistent
   versions.

   If you have "boot helper" systems, they also need to have the
   Ignite-UX product updated to match the same revision as the server
   that they reference.

======================================================================
1.4
Q: Why do hostnames longer that 8 characters not work for 10.X?

A: The Software Distributor tools (swinstall, etc) in 10.X use
   the system's hostname, and uname value interchangeably, and
   since the uname value is restricted to 8 characters, the
   SD tools would fail if the hostname is longer than 8.

================================================================
1.5  Q: I updated my server, now it complains that it "Cannot determine
        dump size limit"

A:   If you have a saved client config created using a version of
     Ignite-UX prior to 1.51, and then update Ignite-UX to 1.51 or
     later, and if you bring itool up for that client with having booted
     the client on the server, it will give an ERROR looking something
     like this:

     ERROR: Unable to determine dump size limit for disk
     (8/4.8.0), release (B.10.20). Internal Ignite-UX error.

     The problem is that an old version of the clients' hw.info file is
     being examined by the new Ignite-UX.  To fix things, merely boot up
     the client system using 'boot lan.<IP> install' (or whatever syntax
     your system supports) from the boot prompt, where <IP> is the IP
     address of your Ignite-UX server.  The client hw.info file will be
     updated, and everything should proceed normally.

======================================================================
1.6  Q: Can the GUI interface for make_tape_recovery span multiple
        tapes?

A:   No.  This is not possible for the DART52 (IUX 3.2) release.  We
     use pax as the tool to create the archive tape and there is no
     current communication between pax and the GUI to prompt the user
     on the GUI when pax requests a second tape.  You need to use the
     command make_tape_recovery on the client to be able to span
     multiple tapes.

======================================================================
1.7  Q: Why do I get Warnings from pax concerning files that are not
        on the system when I run either make_tape_recovery or
        make_net_recovery?

A:  We are now creating a list of files to archive and are using that
    list in multiple places in the code.  By the time the archive is
    actually created from this list, there is a chance that some
    temporary files may have been deleted or removed.  If this occurs,
    then the Warning about a missing file will be given by pax.

======================================================================
1.8  Q: When igniting from an archive I get numerous "samreg" errors.

A: The problem is that the SAM filesets haven't been configured when certain
products are trying to register themselves with SAM. The workaround is:

  This config stanza can be placed in /var/opt/ignite/config.local or directly
    in the config file with the "core" sw_source.

    sw_source "core"
    {
      post_load_cmd += "
       swconfig -xautoselect_dependencies=false -xenforce_dependencies=false SystemAdmin.SAM "
   }

======================================================================
1.9 Q: Can an IUX server install clients on multiple subnets?

A: There are a couple of problems with having an Ignite-UX server that
   is multi-homed (connected to multiple subnets).  Below are the
   known problems and possible workarounds:

   1) The instl_bootd daemon allocates IP addresses from the
      instl_boottab file without knowing which IP addresses are valid
      for the subnet that the client is requesting to boot from.  Due
      to this lack of information, it can allocate an IP address that
      is not valid for the client's subnet, and thus the client will
      not be able to boot from the server.

      The workarounds for this problem are:
        - For every possible client that you may want to boot, assign
          "reserved" IP addresses in /etc/opt/ignite/instl_boottab
          that are tied to the client's LLA address.  This will ensure
          that instl_bootd will allocate an appropriate address (See
          the comments in the instl_boottab file on how to reserve
          addresses).  Alternatively, you can set up entries in
          /etc/bootptab (See question 5.5).

        - Configure a boot-helper system on each subnet that the
          client can boot from before contacting your central IUX
          server.  See the Ignite-UX manual for details.

   2) The "server" keyword that specifies the IP address for your
      Ignite-UX server can only correspond to one of the LAN
      interfaces.  If each subnet is routed such that all clients can
      use the one IP address to contact their server, then the install
      will work.  However, it is more efficient for the client to use
      the server's IP address that is connected directly to the
      client's own subnet.  If a client is on a subnet that does not
      have a route to the IP address specified by "server", then it
      will not be able to contact the server after it boots.

      The workarounds for this problem are:
        - Manually correct the server's IP address on the networking
          screen that appears on the client console when you boot
          the client.

        - Use a boot-helper on each subnet.  When using a boot-helper,
          the server's IP address can be specified correctly on each
          helper system.

======================================================================
1.10 Q: Recovering a system failed, could not create a logical volume.

A: A defect in Ignite-UX versions A/B.1.55 and A/B.1.59 exists such that
   when a system is being recovered from a tape, it could fail with
   an error such as:

    ==============
       * Creating logical volume "vg00/lvol3" (/tmp).
lvcreate: Logical volume "/dev/vg00/lvol3" already exists.
ERROR:   Command "/sbin/lvcreate -A n -n lvol3 -C n vg00" failed.
ERROR:   The configuration process has incurred an error. If you wish to push a
         shell for debugging purposes, go to the target machine's console and 
         interact there. Otherwise, use the "Stop Install" action to reboot or 
         halt the target machine.

         The configuration process has incurred an error, would you like
         to push a shell for debugging purposes? (y/[n]):
    ==============

    This happens only on systems that have logical device files with
    the standard names but which have a minor number that did not match the
    name (For example /dev/vg00/lvol3 that does not have a minor number of 3).

    If the time comes that you need to use a recovery tape that has
    this problem, the workaround involves answering yes to pushing a
    shell for debugging when you see the error as show above, and
    executing the following steps:

        1) Remove the device files (char and block devices) for the
           logical volume that it failed to create.  Examine the error
           message with the lvcreate command to determine the path.  In
           the example shown above, the command would be:
    
            # rm /dev/vg00/*lvol3

        2) Re-run the failed lvcreate command as shown in the error
           message.  Write this command down, since you will need
           it again later in step 5.

            # /sbin/lvcreate -A n -n lvol3 -C n vg00

        3) Type "exit 2" to allow the installation to continue.

        4) The process will next fail at the lvextend step (because
           IUX internally removed the old logical volume that it
           had created temporarily to reserve the minor number).
           The error message would look something like:

           ===========
    lvextend: "/dev/vg00/lvol3": No such file or directory
    Usage: lvextend
            [-A Autobackup]
            {-l LogicalExtentsNumber |
             -L LogicalVolumeSize}
            LogicalVolumePath [ PhysicalVolumePath... |
            PhysicalVolumeGroupName... ]
    
    ERROR:   Command "/sbin/lvextend -A n -L 600 /dev/vg00/lvol3
             /dev/dsk/c1t14d0" failed.
    
             The configuration process has incurred an error, would you like
             to push a shell for debugging purposes? (y/[n]):
           ===========
    
          Answer "y" to push a shell.

        5) Recall the lvcreate command you typed in in step 2.  You
           should be able to use the ksh command history to recall and
           execute it.  If not, then retype it as you did in step 2.

            # /sbin/lvcreate -A n -n lvol3 -C n vg00

        6) Type in and re-run the failed lvextend command that you see
           in the error message:

             # /sbin/lvextend -A n -L 600 /dev/vg00/lvol3 /dev/dsk/c1t14d0

        7) Type "exit 2" to continue the installation.    

======================================================================
1.11 Q: Using bootptab entries to satisfy the DHCP request doesn't work, why?

    There is a known problem with patches PHNE_17123, and PHNE_13648 to
    the bootpd daemon.  If you are strictly using entries in /etc/bootptab
    such as described in question 5.5 in this document, you may have
    problems once these patches are on your server.

    The workaround is to either:
        - Load the patch with the fix: PHNE_19241 (11.00) or PHNE_19095 (10.X).
        - Remove these patches.
        - Or, create a dummy entry in the /etc/dhcptab file which works
          around the defect.  The entry can look something like the entry
          below.  You will need to set the subnet-mask for your network.

            DHCP_POOL_GROUP:\
                pool-name=BLUE_SUBNET_POOL:\
                subnet-mask=255.255.255.0 :\
                lease-time=120:\
                addr-pool-start-address=  192.11.22.254:\
                addr-pool-last-address=   192.11.22.254:
                        
======================================================================
1.12 
Q: How can I keep make_net_recovery version 2.0 from erasing
   volume groups that contain only unmounted and raw logical volumes?

A: See FAQ entry 11.12.

======================================================================
1.13

Q: When igniting 10.20 systems, I get ERRORS regarding mounting of file
   systems, why?

A: There is a 10.20 patch PHCO_18317 that supplies a new version of
   /sbin/mount.  This version is broken for Ignite-UX usage.  If this
   patch is loaded via either an archive or SD, then the next swinstall
   session will have fatal errors that appear like this:

ERROR:   "c02380:/":  One or more filesystems that appear in the
         filesystem table are not mounted and cannot be mounted.
ERROR:   Entry for filesystem "/dev/vg00/lvol1" in "/etc/fstab" could
         not be mounted.  If you do not want this file system mounted,
         comment it out of the "/etc/fstab" file, or set the
         "mount_all_filesystems" option to "false".
ERROR:   Cannot continue the Analysis Phase until the previous errors
         are corrected.

   One workaround is to add the following to your configuration:

     sd_command_line += " -xmount_all_filesystems=false "

   However this has the unpleasant side effect that each swinstall
   session produces a warning message stating that file systems will not
   be mounted.

   There is a new patch PHCO_20061 that supersedes PHCO_19694. Note that
   recovery methods are unaffected because they are solely OS archives,
   and no SD activity takes place.

======================================================================
1.14
Q:  Why do some applications and shells hang over NFS after igniting?

A:  The reason for the hang is most likely do to a problem with
    the NFS file locking daemons rpc.statd and rpc.lockd caused
    by the action of reinstalling the system.

    Many applications use file locking and can hang in this situation.
    Most common is user home directories that are NFS mounted, in
    which case sh and ksh will attempt to lock the .sh_history file
    and hang before giving the user a prompt.

    When a system is running and has an active NFS mount with a server
    in which files have been previously locked, both the client and
    server cache information about each other.  Part of the
    information that is cached is what RPC port number to use to
    contact the rpc.lockd daemon on the server and client.

    This RPC port information is cached in memory of the running
    rpc.statd/rpc.lockd process on both the server and client sides.
    The rpc.statd process keeps a file in the directory
    /var/statmon/sm for each system that it knows it should contact in
    the event that the system reboots (or rpc.statd/rpc.lockd
    restarts).  During a normal reboot or crash, rpc.statd will
    contact each system in /var/statmon/sm and inform them to flush
    their cache regarding this client.

    When you reinstall a system, the /var/statmon/sm directory is
    wiped out. In this case, if the reinstalled system tries to
    re-contact a server that has cached information, the server
    will try to communicate over a old RPC port.  The communication
    will fail for rpc.lockd and any file locking done by an application
    over that NFS mount will hang.

    There are a several ways to avoid and/or fix the problem if it
    happens:

            - If you are using bootsys to install clients, use the -s
              option to allow the client to shutdown normally and thus
              inform servers that it is going down.

            - If you experience a hang, you can reboot the client, or
              kill/restart rpc.lockd & rpc.statd on the client.  At
              the point of the hang, the /var/statmon/sm dir will
              contain the name of the server, and thus rebooting or
              restarting the daemons will tell the server to flush
              it's cache.  If more than one server is involved you may
              end up doing this multiple times until all servers are
              notified.

            - As part of the installation, create a file for each
              server in /var/statmon/sm which contains the server's
              name.  This will cause the first boot to generate a
              crash recovery notification message to each server,
              causing them to purge the stale port information.
              Below is an example post_config_cmd that could
              be placed in your /var/opt/ignite/config.local file.
              Replace "sys*" with your NFS server names.
                post_config_cmd += "
                    mkdir -p /var/statmon/sm
                    for server in sys1 sys2 sys3
                    do
                        echo $server > /var/statmon/sm/$server
                        chmod 0200 /var/statmon/sm/$server
                    done
                "
======================================================================
1.15 
Q: bootsys -i "configuration" [sys1...] fails, why?

A:  A defect has been found in the A/B.2.2 release of Ignite-UX.
    Specifically, bootsys(1M) must be modified in order to successfully
    push a specific configuration out to a client.  The change required is
    as follows:

    vi /opt/ignite/bin/bootsys

    <move to line 848 in the file>

    if [[ "c_opt" != "$PUSH_MODE" ]]; then

    <change "c_opt" to "$c_opt" and save the change>


    bootsys -i <configuration> [sys1..] will now work correctly.

    This defect will be fixed in the next release of Ignite-UX after
    A/B.2.2.
    
========================================================================
1.16 
Q:  Failures, hangs, and odd behavior caused by ENV environment variable. Why?

A:  DESCRIPTION:
    A defect has been found in Ignite releases A/B.2.3 and earlier that
    can have a wide range of possible side-effects.  Some commands 
    bundled as part of Ignite are scripts.  Other commands invoke 
    these scripts, or execute commands with calls to popen(3S) or 
    system(3S).  All of these invocation methods result in the execution 
    of the posix shell (sh-posix(1)) which will source any file pointed 
    to by the 'ENV' (sh-posix(1)) environment variable.  This occurs 
    whether or not the shell is invoked interactively, and thus applies 
    under the previously mentioned circumstances.  

    One of the major impacts that we have seen so far is the resetting 
    of locale(1) variables within the users environment.  Ignite
    commands such as make_recovery(1M) and make_net_recovery(1M) 
    explicitly set all language related variables to null.  They 
    rely on the fact that data is formatted in the default "C" locale
    and will not function properly otherwise.  Known failures 
    include 'exit with error' by these applications.
    
    Unconfirmed results have included application hangs during the
    sourcing of configuration files.

    Other serious side effects might occur during the execution
    of Ignite application scripts.  Aliases sourced into the 
    execution environment of the script might seriously effect
    the behavior of these scripts in an unpredictable manner. 


    SOLUTION:
    The ENV environment variable will be programmatically set to null 
    in future releases.  A temporary solution is to set the ENV environment
    variable to null while running Ignite-UX commands.  This can easily
    be accomplished in the ksh or posix shells with the following syntax:

       # ENV="" <command>

========================================================================
1.17
Q: Doing a bootsys ("push") install to J2240 omits ps2/CentIF drivers.

A:  A defect introduced in the B.2.5 release of Ignite-UX causes
    the wrong install kernel to be used on a J2240 when the "bootsys"
    command is used (either manually or via the "ignite" user interface).

    The result of the defect causes the "ps2" and "CentIf" drivers to
    be omitted from the resulting kernel after the J2240 system is
    installed.

    This problem will be fixed in the next release of Ignite-UX
    available Feb 2000 from http://software.hp.com or on the March
    2000 application CD-ROM set.

    Workarounds until it is release include either:
        - Automate the addition of "ps2" and "CentIf" drivers during the
          installation by adding the following lines to an Ignite-UX
          configuration file such as /var/opt/ignite/config.local:

            (MODEL == "9000/782/J2240")
            {
                mod_kernel += "ps2"
                mod_kernel += "CentIf"
            }

        - Or, manually add the "ps2" and "CentIf" drivers to the kernel
          after the system is installed either using sam, or other methods.

        - Or, avoid doing "push" installs using "bootsys" or "ignite"
          to J2240 systems.  Instead, initiate a network or media boot
          from the client.

========================================================================
1.18
Q: The bootsys command occasionally hangs on 11.00 clients, why?

A:  If you are experiencing the "bootsys" command hanging after
    copying over the required files to the client, you may need
    the load the latest remsh/rcp/rlogin/rexec patch onto the
    clients.  In this case, you will typically see a "cat" process
    that never completes running on the bootsys client.

            11.00:  PHNE_17030 JAGab73645
            (fixed at 11.11)

    A workaround is to kill the remsh process on the server that
    was invoked by the bootsys command.  The bootsys operation
    should complete successfully after this.

========================================================================
1.19 
Q: Why does loading the 11.00 64-Bit Minimal HP-UX environment fail?

A:
    When loading the 11.00 64-Bit Minimal HP-UX environment,
    you may encounter errors during the software load that
    look like:

          The prerequisite "PHKL_19142.C-INC,r=1.0" for fileset
          "PHKL_21306.C-INC,r=1.0" cannot be successfully resolved.
 ERROR:   The dependencies for fileset "PHKL_21306.C-INC,r=1.0" cannot
          be resolved (see previous lines).
          You must resolve the above dependencies before operating on
          this fileset or change the "enforce_dependencies" option to
          "false".

    In addition, on systems that have USB hardware, the kernel
    build process that follows will fail.

    The problem is that several required patches depend on the
    PHKL_19142 patch which in turns requires that the
    ProgSupport.C-INC fileset be loaded.  This C-INC fileset is not
    part of the HPUXMinSys64 bundle and does not get automatically
    loaded.

    A future release of Ignite-UX will include a newer version of
    swinstall that will automatically select the ProgSupport.C-INC
    dependency.  In the meantime, you can workaround this problem by
    manually editing the config file produced by make_config that you
    created for the core-OS depot.   In this config-file, search for
    a line that reads:

        sd_software_list = "HPUXMinSys64,r=B.11.00,a=HP-UX_B.11.00_64,v=HP"

    And change it to be:
 
        sd_software_list = "HPUXMinSys64 ProgSupport.C-INC"

========================================================================
--------------------
2. Server Setup
--------------------

2.1
Q: Should I use DHCP or bootp?

A: As with anything, there are some advantages and disadvantages to both
BOOTP and DHCP.

In general, DHCP allows you to specify more complete networking information.
However, there are no really good tools to manage the database so that
you can enforce the LLA <=> IP-address mapping ahead of time.  By its
very design, it dynamically allocates addresses.

You will probably want to use the Ignite GUI to set up the range of
IP addresses that you will want your server to "manage" with DHCP,
if you have not already done so.  You will need to use "sam" to
make any future changes to the DHCP address pool.

If you are dealing with multiple subnets you will either need to have
one DHCP server on each subnet or set up bootp relay agents.

See also question 5.5 (What if I don't want to use DHCP, can I still have
IUX automatically determine networking information for all my clients?).

======================================================================
2.2
Q: Why did it call my client "<hostname>.0x080009...."?

If your client has multiple LAN interfaces, and you have previously
installed the client using one interface, and then later chose to use
the other interface during the install, then the client name will have
the LLA (hardware lan link address) appended to the hostname so it
won't conflict with the prior hostname left from the prior install.

This may also happen if you had to replace the LAN interface in your
client system since the last time you installed it.  The LLA number
is attached to the LAN interface, not the system.

It is only the "icon name" that has been renamed.  And you can use the
ignite GUI action menu to "Change icon name" to rename one or both of
the clients.

========================================================================
2.3
Q: Which version of Ignite-UX supports my hardware?

A:   Below is the hardware support matrix found also in the
     /opt/ignite/share/doc/release_note document.  The information kept
     here in the FAQ will contain any information we can share about new
     hardware support in upcoming releases.
     -------------------------------------------------------------------

     There are two main versions of Ignite-UX, the "A" and "B"
     versions.  The "A" version is based on a HP-UX 10.20 kernel
     and commands.  The "B" version uses the latest 11.00 kernel.

     Occasionally HP will release a new system that is only supported
     by HP-UX 10.20 and/or 11.00 for some period of time.  This
     results in some systems only being supported by one Ignite-UX
     version.

     Below is a table that identifies systems that are supported by
     only one release, or that Ignite-UX does not yet support.  It
     also lists the minimum Ignite-UX release needed to support the
     system if support for it was recently added.

     Older systems not listed in the table can be assumed to be
     supported by both versions.

        Systems              |   A-version     |   B-version   | notes
       ======================+=================+===============+======
        N-class              |   no            |   yes (B.2.0) | 1
       ----------------------+-----------------+---------------+------
        L-class              |   no            |   yes (B.2.0) | 1
       ----------------------+-----------------+---------------+------
        V-class              |   no            |   yes (B.1.48)| 1,3
       ----------------------+-----------------+---------------+------
        V2500 SCA            |   no            |   no          | 4
       ----------------------+-----------------+---------------+------
        B1000, C3000, J5000  |   yes (A.1.59.1)|   yes (B.2.2) | 7,8
        J7000                |                 |               |
       ----------------------+-----------------+---------------+------
        B2000                |   yes (B.2.2)   |   yes (B.2.2) | 7,8
       ----------------------+-----------------+---------------+------
        A-class              |   yes (see note)|   yes         | 5
       ----------------------+-----------------+---------------+------
        Older series 700's   |   yes           |   no          | 6
       ----------------------+-----------------+---------------+------
        
        Notes:
           1) Systems are only supported by HP-UX 11.00.  No plans
              to support 10.20 on them.  Must use Ignite-UX B-version.
           2) Will be supported in the upcoming Ignite-UX release indicated.
           3) V-class systems require firmware version 4.3 or higher
              for make_recovery tape boot support.
           4) V2500 SCA at its first limited release will not have
              Ignite-UX support.  Ignite-UX will support after the
              general release.
           5) A-class systems may require a firmware update to boot
              over the network from a server running the A-version.
           6) The Series 700 systems not supported by HP-UX 11.00 are
              not supported by Ignite-UX B-version.  That list is 705,
              710, 715/33, 715/50, 715/75, 720, 725/50, 725/75, 730,
              735, 750, and 755.  In addition, systems with the
              graphics devices GRX, CRX, CRX-24, and CRX-48Z are not
              supported.
           7) For 11.00 support, the B1000, B2000, C3000, J5000, and
              J7000 require the November 1999 or later XSWGR1100 patch
              bundle.
           8) For 10.20 support, the B2000 requires the December 1999
              or later Workstation ACE patch bundle.  The B1000,
              C3000, J5000, and J7000 require the June 1999
              Workstation ACE or later patch bundle.

========================================================================
--------------------
3. Config files
--------------------

3.1
Q: What should go in which config file?
   Also, what should go in INSTALLFS?

A: Here is a short description of the common uses of the various configs.
Obviously there can be situations that aren't "common" and variations will
occur:

INSTALLFS: (accessed/modified via instl_adm(1M) ): 
Information that is needed at boot, such as the following:

       ui controls
       networking

/var/opt/ignite/config.local

   Information that should be globally applied to all clients of all types
       the post_(load/config)_scripts run on all clients

/opt/ignite/data/Rel*/config
 This file sets the definitions for that release and shouldn't be
modified.


/var/opt/ignite/date/Rel*/*_cfg
   Information regarding software selections/sources
     these files should be created by make_config(1M) (run against an SD depot)
     or in the archive case, edited versions of the examples in 
     /opt/ignite/data/examples/(core|noncore).cfg.



When Ignite-UX is run for a client, all of these config files are
combined and parsed.  If there are conflicting or duplicate definitions,
the order in which the files appear in the INDEX file determines the
precedence with the last file listed (typically
config.local) having precedence over all but the
INSTALLFS definitions.

A potential breakdown here is when the client was previously installed
and the per client directory in /var/opt/ignite/clients
exists and is populated with the previously resolved configs.  In this
case, the previously resolved config.full has precedence.

======================================================================
3.2
Q:  How do I preview config file changes?
    Fixing syntax problems with mod_kernels results in 
    statements of the following form:


   mod_kernel += "maxdsiz " + ${_maxdsiz}

    There doesn't seem to be a way to "preview" the effects of these
    types of statements.  Can a comment be added to the
    config.full with the string that was being output?

A:   The config.full file has the variable values replaced with the
real values.  So if you look in there, you should be able
to see what the real mod_kernel statement became.  In this
case you would have seen the following:

   mod_kernel +=  "maxdsiz 0"


Another option would be to have it push a shell prior to the kernel
build using a post_load_cmd:


   post_load_cmd+="/sbin/sh;"

========================================================================
3.3
Q: Is there a way to say in the configuration files "don't bother with
   the disk warning" ?  This warning can prevent automated installs.


A: We do have an environment variable which should do what you need. Look in
instl_adm(4) for INST_ALLOW_WARNINGS. This can be used to keep you from
going interactive when warnings are received.  You will need to put
the setting of this environment variable in INSTALLFS for it to have
effect.  The line you would add to allow an automated install to
proceed after the warning is:
        env_vars += "INST_ALLOW_WARNINGS=10"


========================================================================
3.4
Q: Which config file example should I use for an 11.00 archive?

A: For setting up an OS-archive for the  11.* releases, you will need
   to use the config file example: /opt/ignite/data/examples/core11.cfg
   as a starting point instead of the "core.cfg" file.

a   A failure to use the core11.cfg file, or a failure to correctly
   modify the file will result in the message below:

  ERROR: The _hp_os_bitness variable is not set to \"32\" or \"64\".
         This variable must be set in the config file that supplies
         the core archive or depot.  If using an archive, make sure
         you start with the core11.cfg example config file.  When
         using a depot, make_config will set this automatically.

========================================================================
--------------------
4. Recovery 
--------------------

4.1
Q:  We tried running the recovery system option from a client booted in
    IUX.  We ended up with errors which seemed to point to files not
    being accessible via tftp.  It looks like the default IUX config
    does not make the directories needed for recovery systems available
    via the /etc/inetd.conf file.  The directories should either be
    added or the problem documented (including in the error message).


A:  Only /opt/ignite and /var/opt/ignite should be needed for tftp access.

========================================================================
4.2
Q: How do I duplicate a tape made with make_recovery?

A: A tape created with make_recovery contains 2 tape "files" The
   first tape file is written with a 2k block size, and the second
   with a 10k block size.  The first file is a LIF file, and the
   second is a tar archive.

   If you have 2 tape drives on a system, then you can easily
   duplicate the tapes using 2 dd commands with a no-rewind-on-close
   device file for the first command.  For example:
        dd if=/dev/rmt/0mn of=/dev/rmt/1mn bs=2k
        dd if=/dev/rmt/0m of=/dev/rmt/1m bs=10k

   If you only have 1 tape drive, and have enough disk space to hold
   the contents of both tape files, then you should be using something 
   like the following:

        dd if=/dev/rmt/0mn of=/var/tmp/f1 bs=2k
        dd if=/dev/rmt/0m of=/var/tmp/f2 bs=10k
        <Insert blank tape now>
        dd if=/var/tmp/f1 of=/dev/rmt/0mn bs=2k
        dd if=/var/tmp/f2 of=/dev/rmt/0m bs=10k

========================================================================
4.3  
Q: Why don't the Online Diagnostics LIF files get restored?

A: NOTE:  This description is left in for this release.  However,
   with the [A|B].2.4 release of Ignite-UX, LIF files should now
   be saved during "recovery" and restored properly.
   -------- Pre-[A|B].2.4 Response --------
   IUX destroys the old LIF area on the boot disk and lays down new LIF
   volumes every time the system is installed.  At no point during the
   installation are the old LIF volumes copied and restored to the disk.

   To restore the LIF volumes to the disk, reinstall the application, or
   look at the SD configure scripts for the application and rerun the
   commands which put the LIF volumes in place on the disk.

   For example, for the OnlineDiag bundle, the 
   /var/adm/sw/products/LIF-LOAD/LIF-LOAD-MIN/postinstall script puts the
   OnlineDiag LIF volumes onto the root disk.

   It uses this command:
   /usr/sbin/diag/lif/lifload -f /usr/sbin/diag/lif/updatediaglif

========================================================================
4.4
Q:  I get an "bad IPL checksum" error when booting B1000, C3000, and J5000

A:  The 1.8 revision of firmware on the B1000, C3000, and J5000
    workstations has a defect that causes them to give a "bad IPL
    checksum" error when booting from a make_recovery tape (and
    possibly other bootable tapes as well).

    If you have one of these systems, your options are to update the
    system firmware once a new version with a fix is made available,
    or to use Ignite-UX version [A|B].2.0 or later which works around
    the problem.  You may be able to request a new version of the
    Ignite-UX make_medialif script from your HP support representative
    prior to the 2.0 release.
========================================================================
4.5
Q:  Why do I get the error: "The minor number of the volume group exceeds 
    the value IUX can support."?

A:  Both make_recovery and make_net_recovery check to ensure that they
    do not back up a system that Ignite-UX will be unable to recreate.

    The "A" version of Ignite-UX can only create volume groups with
    group numbers in the range 0 to 10.  This is due to the maxvgs
    kernel tunable being set to 10 in the INSTALL kernel.  In order to
    continue to have Ignite-UX work on systems with 32MB of memory,
    the kernel cannot have this parameter increased.

    The "B" version of Ignite-UX does not have this restriction due
    to reductions in the amount of memory LVM consumes.

    It is unusual for the root volume group to have a large volume
    group number, so it is uncommon to run into this with
    make_recovery.  However, since make_net_recovery can operate on
    non-root volume groups it is more likely to see the error with
    that tool.

    Workarounds:
        - If you got into this situation by manually recreating
          the LVM device files, then consider renumbering them to
          something less then 10.
        - If using make_net_recovery, exclude that volume group
          from the archive.
        - Use the "B" version of Ignite-UX which is only officially
          supported on 11.* releases.
========================================================================
4.6
Q:  Dealing with hot swappable disks during recovery

A:  Certain customers have attempted to use hot swappable disk
    functionality to avoid changing a particular disk.  Disk mirroring
    may also be involved.  Ignite-UX supports only hot swappable disks
    that are completely installed, and not removed when creating a
    recovery image.  Proper software and hardware procedures must be
    used for hot swap disk removal or replacement before or after
    recovery, but not in the middle.  The LVM command lvlnboot used by
    save_config does not work when a disk is removed and the system is
    this odd state.  If this command is not working, then recovery has
    no chance of succeeding.
========================================================================
4.7  
Q:  Why does make_recovery hang while trying to write the archive?

A:  During archive creation, both make_recovery and make_net_recovery
    can hang while attempting to read files with mutually exclusive 
    locks (see lockf(2)).  A file lock set with F_LOCK enforcement will 
    cause a process to sleep while attempting to read that file.  If
    this is the problem then you will see a pax(1) process in the sleep
    state that has blocked on a locked file.

    How to find the offending file:
    A capital 'S' character in the execute permission bit for a file is 
    one indication of this kind of lock.  The tools glance(1) or gpm(1)
    can be used to view all files in use by a process, and will easily
    help you identify the locked file.  Locate the pax(1) process 
    that is attempting to archive the file and use glance or gpm to
    view files that it is using.
  
    You can also look at the recovery log /var/opt/ignite/logs/makrec.log2
    to get a fairly accurate idea where make_recovery hung.  The
    last entry in the log file should be the last file successfully
    archived.  This file may be slightly inaccurate however if some
    output for the log file is still buffered.  To see the files that
    are supposed to follow the last recorded entry you can run 
    make_recovery in preview mode (make_recovery -p) to create the 
    contents file /var/opt/ignite/recovery/arch.include.  Sort the
    contents file with the 'sort -u' command and examine the results.
    
    Work around:
    The hanging behavior that is occurring is the appropriate behavior
    under these circumstances.  There is no way to archive files while
    they are locked in this manner.  For this reason you must exclude
    locked files from the archive.  This also means you cannot lock 
    files that are part of the minimal set of archive files built 
    into make_recovery.

       Excluding locked files from archive:
       -You can run make_recovery in preview mode which will create the
        archive content file /var/opt/ignite/recovery/arch.include.  
        You can edit this file to explicitly remove the offending
        files from the archive.  Remember not to remove files that
        are considered part of the core OS or you may not be able to
        successfully recovery your system from the archive.

       -This problem is most often encountered with the '-A' option
        of make_recovery which includes the entire root volume group.
        If possible, move the locked files to another location outside
        of the root volume group.  It is a recommended practice to
        keep user data on a separate volume group.

     Another option you have is to exit from applications that have 
     a lock on files you wish to archive during the archive process.
========================================================================
4.8
  Q: Should I run make_recovery in single user mode or can users be
     on the system when I do the recovery?
  A: It is best to have the system as "quiet" as possible before
     making any recovery.  The reason is that the file system and
     files should be constant as the tools first make a list of
     directories and files to be recovered and then does the actual
     recovery.  In most circumstances, there will few problems if
     users are on the system.  However, if a user adds a file or
     directory between the time the list was created and the actual
     archive is made, the file(s) and/or director(y|ies) will not
     be on the recovery tape.  Worse, if the user deletes a file or
     directory, it/they will cause a recovery message stating that
     an expected file/directory could not be located.

     You do not necessarily need to put the system into single
     user mode, just try to make sure that the system is as "quiet"
     as possible with as few (no?) user interactions occuring.
========================================================================
4.9
  Q: What is the maximum amount of data that a make_recovery tape can
     hold?
  A: A make_recovery tape can hold as much data as will fit on the tape.
     If make_recovery is run in the foreground it will prompt for more
     tapes if they are necessary.  NOTE: individual files may not 
     exceed 2GB due to a limitation in the pax command.
========================================================================
4.10
  Q: Why do I get an error from pax saying: linkname greater
     than 100 characters?  I have PHCO_20388 installed.
  A: This is confusing because of the ambiguous text provided in the
     patch.  Under symptoms, it says:

     1. Pax does not handle soft/hard links properly in ustar format
	if the file/link names have a length >= 100 characters.

     The patch corrected a problem in handling linknames that were >=
     100 characters.  These are still limited to less than 100
     characters.  If you have a linkname that is longer, you will see
     the error message.  Before the patch, this condition was not
     detected and pax would become confused.  Now it is correctly
     flagged as an error.
========================================================================
--------------------
5. General Install
--------------------

5.1
Q: There was some confusion about the way that IUX estimated
    needed file system sizes.  IUX seemed to pad the space by about
    300 MB.  The 10.20+apps+patches load takes about 680 MB, but IUX
    wanted about 1 GB of file space to install it.

    Does IUX do anything other that add up the impacts statements?


 A:   It will add in minfree (normally 10%) to the amount required
      by the software impact.


You may have software bundles that have overlapping contents (filesets 
and/or files).  make_config makes sw_impact statements for each bundle 
without doing anything special to guard against over-counting when the 
bundles overlap.

For example the Ignite-UX-10-XX bundles all overlap quite a bit, so
that when you load all of them via IUX, it estimates too much space.

You should be able to add the sw_impact of all the sw_sel's that
you are loading and see what that adds up to.

========================================================================
5.2
Q: How can I set the timezone such that the install.log file is in local time?

A: The TZ environment variable is what governs what timezone the message
   in the install.log contain.  The "timezone" config file keyword
   does not have any effect on the messages that occur during the
   install, but does determine the timezone setting on the target
   system (the two can be independently set).

   To set the TZ environment variable, it is best to do so in the
   INSTALLFS file so that it is set as early in the process as
   possible.  However the very first message will still be in EST
   since it is produced before the config file contents of INSTALLFS
   are read.  The procedure for setting this would be: (note this
   sets it to MST7DT).

        # /opt/ignite/bin/instl_adm -d > /tmp/cur_cfg
        # echo 'env_vars += "TZ=MST7MDT"' >> /tmp/cur_cfg
        # /opt/ignite/bin/instl_adm -f /tmp/cur_cfg

========================================================================
5.3
Q: When does IUX configure software?

A: The SD configure scripts (as well as IUX post_config_{cmd|script})
   are run after all software has been loaded and after the system
   has booted off of the target disk and final kernel.

========================================================================
5.4
Q: How do I set the target's final networking information?

A: This can be done from the "System" tab of the user interface.
   Or can be done via the keywords in the config files (see
   instl_adm(4)).

========================================================================
5.5
Q: What if I don't want to use DHCP, can I still have IUX automatically
    determine networking information for all my clients?


A:  Yes, if you want to have more control over the allocation of IP
    addresses and their mappings to your clients, you can configure
    entries in /etc/bootptab for each client.  Because BOOTP is
    a subset of DHCP, the client's request for a DHCP server will
    be satisfied with the BOOTP response.

    If you also specify a boot-file (bf) of
    /opt/ignite/boot/boot_lif in the bootptab entries, then
    you do not need any additional entries in
    /etc/opt/ignite/inst_boottab.  In this case, you would then boot the
    clients using "boot lan" instead of "boot lan install".  Only
    clients known in /etc/bootptab would be able to boot if you do not
    use instl_boottab.


    A minimal example /etc/bootptab entry would be like the entry
    below (with your own hostname, IP address, and hardware address,
    and subnet mask).  Other networking information may also be
    specified here, or can be specified via instl_adm.  The IP address
    of the IUX server must be specified with the instl_adm -t option.


sysname:\
   hn:\
   vm=rfc1048:\
   ht=ether:\
   ha=080009352575:\
   ip=15.1.51.82:\
   sm=255.255.248.0:\
   bf=/opt/ignite/boot/boot_lif 


    (For a known problem using this mechanism, see item 1.11: Q: Using
    bootptab entries to satisfy the DHCP request doesn't work, why?)
========================================================================
5.6
Q:  On a system with two disks, an internal 400 MB and an external 1 GB,
    I was unable to change the root disk to the external 1 GB in the UI.
    The first time I tried, both disks were listed on the UI, but the
    second time the external disk had disappeared (this was not always
    true -- sometimes both disks were always listed).


    I then went to the file system tab in the UI, selected both disks
    for LVM use, but, although I had 1.4 GB of disk, the UI kept telling
    me I didn't have enough space.


    I finally realized that the external disk was on a differential
    interface, and that HP-UX apparently could not be booted from it.
    So it appeared that IUX was consulting some rules which said that
    this disk was not valid as a root disk.


    The problem was that the disk was listed on the "Root Disk"
    selection initially, and there was no error message when we picked
    it.  It just reverted to the other disk.  If IUX determined that
    this disk was not bootable, it should have said so!


    When we finally figured this out, we made the internal 400 MB our root
    disk, and added the external disk as an LVM add on.  The UI kept
    complaining about not having enough space, so we had to install just
    the archive with a very small swap (even though we had 1.4 GB of disk
    space according to the file system screen).  We then proceeded with
    the install.  When the system booted the external disk had not been
    added.


A:  I think what you may have been running into is the following:

     When you pick a small disk for your root FS, and pick to use
      LVM, the default is to not create all the /usr, /var... volumes.
      You can change this back in the Additional Screen.


     But, if you don't have the /usr, /var... volumes created, then
      it tries to put all the software impact into the root (/) volume.
      However, the root volume must be contiguous, and thus it constrains
      it to fit on the 400 MB disk.  Thus, it complained that there
      was not enough disk space.

     Also, the primary swap volume must be on the root disk, along with the
      root (/) and boot volumes (/stand).  



The best thing to do in this case is the following:
    

   Pick your small root disk.
   Pick LVM.
   Go into the "Additional" screen, and toggle the option to
      create the separate volumes to TRUE.
   Optionally, in the Additional screen you can also tell it to use
      more than the one disk.
   Then add any other disks from the file system tab.



With this setup, the root (and /stand, swap) volumes should be small
enough to fit on the 400 MB disk, though the others are allowed to cross
onto the other disk.

========================================================================
5.7
Q: How is software in a depot made available for installs?

A: Change to the release directory that is appropriate for the software in 
 the depot, then run make_config against the depot. After the config is
 created run manage_index to make it visible in the Ignite GUI.
 EXAMPLE:
    SD depot machine: sdsource
    SD depot        : /var/application_depot
    For release     : 10.20

    do the following:
    cd /var/opt/ignite/data/Rel_B.10.20
    make_config -s sdsource:/var/application_depot -c app_name.cfg
    manage_index -a -f /var/opt/ignite/data/Rel_B.10.20/app_name.cfg \
    -c "HP-UX B.10.20 Default"

========================================================================
5.8
Q: How can I know whether I can install a 64-bit OS on a system?

A:  When using the B.* version of Ignite-UX (which is capable of
    installing 11.00 64-bit OS), execute the following:

       strings /opt/ignite/boot/INSTALLFS | grep 9000 | grep 64

    This will produce a list of the known system models that are 64-bit
    capable.  If the second value listed is 64, it can only run 64-bit.
    If it is 32/64, it can run either 32-bit or 64-bit.  If the system
    model being installed is not there, it is limited to 32-bit only.

    If you were only interested in one particular model (say a K370),
    execute the following:

       strings /opt/ignite/boot/INSTALLFS | grep 9000 | grep 64 | grep K370

    If nothing is output, then the model is limited to 32-bit installs
    only.

    It is also important to note that certain D- and K-class systems
    will require a firmware upgrade to support 11.00 (64-bit).
    Ignite-UX will inform you of this fact, but it can easily get lost
    amongst everything being logged.  Check the install.log file just
    after the ioscan is done.

========================================================================
5.9
Q: FDDI software is in my archive, yet IUX requires that I select it, why?

A: Ignite-UX will give an error stating that you must select the
   FDDI software for loading if the following conditions exist:

        - You are using an FDDI interface during the installation.
        - There is a sw_sel defined in a config file that has the
          string "FDDI" in the description.

   It gives an error prior to starting the configuration phase to
   avoid the situation of having a system that cannot complete the
   installation due to the lack of the FDDI drivers.  IUX does not have
   any way of knowing up-front if FDDI is included in an archive and
   assumes that it is not - just to be safe.

   If you have the FDDI software in the archive, then you can avoid
   the error by removing it from your depot, and the re-running
   make_config to reflect the removal in the associated config file.

   You may also just select the FDDI software in which case the
   swinstall command will just skip loading it since it will already
   be on the system.
========================================================================
5.10
Q: How many systems can I install at once - in parallel?

A: Although there are no set limits in Ignite-UX, you will find that
   performance will decrease as you reach the limits of your network
   and server bandwidth.

   Most users have found that installing about 20 systems at a time
   from a single server is the most they could do while maintaining
   reasonable performance and avoiding network errors.  20 at a time
   also seems to be a reasonable number for the user to keep track of
   and test when they complete.  You may also find it useful to
   stagger the installs such that they are not all doing the same
   operation at the same time - and don't all complete at the same
   time.

   Using the NFS access method to access archives is suggested in
   order to avoid a problem seen when installing many systems using
   the ftp access method.  When many ftp and tftp processes are running
   to a server at once, the tftp commands start getting the error:
        tftp: recvfile: recvfrom: Can't assign requested address
========================================================================

--------------------
6. Network Install
--------------------

6.1
Q: What network architectures are supported?

A: Version A.1.32 added support for most of HP's supported network
   interfaces via the bootsys command.  However only the built-in
   interfaces are supported for booting by the firmware on S700's and
   K/D-Class S800's.  See the /opt/ignite/doc/share/release_note
   document for more information.

========================================================================
6.2
Q: My 715/50 won't network boot off of my IUX server, why?

A: older s700 require rbootd running on the server. if the server is FDDI
rbootd won't run. In that case boot from media then switch the source to the
IUX server. older ones use RMP not BOOTP and require rbootd to translate and
handoff to bootpd.
The RMP clients are the older s700 workstations and all DTCs:
	 workstations:  705, 710, 715, 720, 725, 730, 735, 750, 755
	 The BOOTP clients are the s712 and future workstations, as well as
	 K-class and D-class s800 servers.

========================================================================
6.3
Q: When the client "searches for bootable devices", the server does
   appear on the list.  However, when I try to boot, I get the
   following error:
  IPL error: bad LIF magic

A:When I have seen this in the past, it has been caused by either:

        - not having tftp access to /opt/ignite and /var/opt/ignite,
          the /etc/inetd.conf file on the server should have
          an entry such as:

tftp         dgram  udp wait   root /usr/lbin/tftpd    tftpd\
        /opt/ignite\
        /var/opt/ignite

          if not, fix inetd.conf and run "inetd -c".  Kill any
          "tftpd" processes that may be running.
          Loading Ignite-UX should have set inetd.conf, but something
          we have not yet figured out has been removing the entries.
          I suspect some area of sam...

        - Using a bootptab entry for the client that is referencing
          a non-existent boot file (bf).

        - A corrupted /opt/ignite/boot/boot_lif file.

        - Perhaps some remnants of the old cold-install product
          conflicting with Ignite-UX (old instl_bootd running)

        - A defect in the rbootd daemon delivered in patch
          PHNE_10139.  If you have this patch loaded and do
          not need it for DTC devices, try removing it or
          updating to patch PHNE_11017 (10.20) or PHNE_11016 (10.10)


========================================================================
6.4
Q:  How do I set up a 9.0X system as a Boot Helper?

A:  On the install server (on one side of the gateway), do the
    following:

cd /opt/ignite/boot
  
  You can make the changes to the actual boot files in this directory,
  or copy INSTALLFS to another file and make changes to that file by
  adding a -F option spec to the instl_adm calls below.  The rest of
  this document assumes you just use the "real" version.  These changes
  aren't very extensive, so this should be ok.


   Run: instl_adm > fs_cfg

   Run: cp fs_cfg fs_cfg.orig
  

  This will save a copy of the current settings, in case you need to
  restore them later.  There already should be a file "fs_cfg.def"
  which may also be useful as a backup.


   Edit fs_cfg:

    Make sure the "server" spec is set to point to this machine.


 Make sure the "is_net_info_temporary" spec is set to "false":

is_net_info_temporary=false

    Set proper "route_gateway" spec for the *target* machine.  In other
     words, it should be the gateway that the target machine needs to get
     across to this server.  

 This will be different from what would currently be in there.  For example,
 there should be two lines in the file like:

route_gateway[0]="15.2.48.1"
route_destination[0]="default"

    Add the following lines (examples): 

ip_addr="15.2.43.1"
netmask="255.255.248.0"
system_name="aname"

   The effect of the "is_net_info_temporary=false" spec and the ip_addr,
   netmask, and system_name specs is to use this information for the
   install (thus avoiding DHCP) AND leave it in /tmp/install.vars on the
   target system after installation.  Set_parms will then run and pick
   up this info as defaults.  If is_net_info_temporary is set to true,
   the net info will be tossed.


   The ip_addr and system_name do not need to be (but can be) the final
   values, just valid temporary values.



   You could also set "final" net info (actually cause IUX
   to put it in the rc startup files) by adding additional "final"
   specifications for system_name, ip_address, etc.  Remember, setting a
   "final" system_name will cause set_parms not to run, so all other
   needed system info (timezone, routes, etc.)  should probably be set
   along with system_name.


   Run: instl_adm -f fs_cfg


   This applies the changes to the INSTALLFS file.  All the files in 
   the /opt/ignite/boot directory can then be copied to the helper
   machine's /opt/ignite/boot directory when ready.  

NOTE: any further changes MUST be done on the server system and copied over
   to the helper system.  The 9.0X instl_adm command does have the 10.X
   functionality.

On the (9.0X) helper, do the following:

mkdir -p /opt/ignite/boot


   Edit /etc/inetd.conf:


    Add the following line
       to the tftp spec.  Don't forget to add \ to the line before it for
       continuation:

/opt/ignite


      Modify the instl_boots spec to be the following (add the -b option):


instl_boots  dgram  udp wait   root
  /etc/instl_bootd   instl_bootd -b
    /opt/ignite/boot/boot_lif


   Run /etc/inetd -c to reread the config.

   Copy the /opt/ignite/boot stuff on the install
    server to /opt/ignite/boot on the boot helper
    machine.

   Make sure /usr/adm/instl_boottab on the helper has some IP addresses
    available/specified.


To Perform the Install on the Target:


  Boot up the target machine to the boot admin menu, and type something
  like:


      boot lan.15.1.50.57 install

  where "15.1.50.57" is replaced by the IP address of the helper machine.
  If there's only 1 install server available on the subnet, then just
  typing "boot lan install" should work.


  At that point, the install should proceed, controlled from the server
  by default...

========================================================================
6.5
Q: I put "control_from_server=true" and "run_ui=false" in the INSTALLFS, but
I still get prompted for information on the client, what's wrong?

A: There are a few possible answers here depending on what you are being
   prompted for.

  If the screen is showing the client name in an editable field and a cancel
  button at the bottom of the screen, then all is well and there should be an
  icon waiting for you on the server GUI. The text screen allows you to change
  the icon name, or switch to a client side install.

  If the screen is showing two or more lan interfaces to select from, then
  there wasn't enough information in the config files to tell it which lan to
  use. Once you select a lan and then select 'Install HP-UX' you should be set.

  If the screen is prompting you for networking information, then either
  DHCP didn't respond or there isn't an entry in /etc/bootptab for the client.
  Enter the network information, select 'Install HP-UX' and continue
  the install.

========================================================================
6.6
Q:   The bootsys command seems to work in reverse; if we typed "bootsys
    -w client" the client didn't wait for the server, if we typed
    "bootsys client", the client waited for the server.


A:  This was probably due to your running through the UI once on the server
prior to running bootsys.  The server drops the instruction for the
client to start installing and the next time the client boots it picks
that up and goes.  The message ignite give tries to tell you that the
install will happen the next time that "bootsys -w" is used, but does
not really say it will happen automatically.


And probably the next time you did a bootsys you had not gone
though the UI without the client being booted from the server.

========================================================================
6.7
Q: bootsys does not work on diskless clients, how can I remotely install?

A: The bootsys command does not support rebooting diskless clients
   from the IUX server (neither 9.X nor 10.X diskless).  There are no
   plans to add this functionality due to infrequent requests for it.

   If you really need to remotely reboot diskless clients from the
   Ignite-UX server, here are the steps you can take:

        1) If you need to duplicate the behavior of the -w or -a
           options to bootsys, you will need to modify the INSTALLFS
           file using instl_adm to set the keywords "run_ui" and/or
           "control_from_sever" appropriately.  Or you can do this
           using the ignite GUI under the
           Options->Server_Configuration menu (Run client installation
           UI option).

        2) Copy the /opt/ignite/boot directory and contents to
           the diskless server as /opt/ignite/boot:
                rcp -r /opt/ignite/boot  diskless-server:/opt/ignite/boot

        3) Edit the client's entry in /etc/bootptab on the
           diskless server to set the "bf" (boot file) flag
           to be "/opt/ignite/boot/boot_lif"

                Change current bf= setting to:
                # vi /etc/bootptab
                  bf=/opt/ignite/boot/boot_lif

           You may also need to set the bootptab entries for the
           gateway (gw), and subnet-mask (sm).  The networking
           information in the bootptab file will satisfy the client's
           DHCP request for networking information when it boots.  So
           it will need everything required to contact the IUX server.

        4) Run setup_tftp on the diskless server to allow tftp access
           to /opt/ignite:

                # /usr/sam/bin/setup_tftp /opt/ignite  # on 9.X systems
                # /usr/sbin/setup_tftp /opt/ignite     # on 10.X systems
                

        5) With this setup, the next time you reboot the client from
           the diskless server it will load the INSTALL kernel and
           INSTALLFS file system from the diskless server.  The client
           will then contact the IUX server and the installation can
           proceed as usual.

========================================================================
6.8
Q: Client "search lan install", the server doesn't appear on the list. 

A: Things to check on the Ignite-UX server that you are trying
   to boot from are:

    - Messages from instl_bootd in /var/adm/syslog/syslog.log.
      If you need to add more IP addresses to /etc/opt/ignite/instl_boottab
      you will see messages in syslog.log such as the following:

         instl_bootd: Denying boot request for host: 080009F252B3 to
         avoid IP address collision. Try booting again in 214 seconds,
         or add more IP addresses to /etc/opt/ignite/instl_boottab.

    - A message in syslog.log that indicates that you have no
      IP addresses in /etc/opt/ignite/instl_boottab is:

         instl_bootd: No available IP address found in:
         /etc/opt/ignite/instl_boottab

    - If the client is an older system that does not use the BOOTP
      protocol (like 720's, 710's, 735's, 750's) then also look in the
      log file /var/adm/rbootd.log - and check to make sure that the
      "rbootd" daemon is running.  rbootd always runs, where as
      instl_bootd is started via inetd and only runs when needed.

      Also, for these older clients, there is an intentional delay
      built into the rbootd process when a client wants to do an
      install boot (as opposed to a diskless boot).  This delay causes
      the server not to show up during the first search.  Retrying the
      search 2 or 3 times may be necessary.

========================================================================
6.9
Q: Bootsys fails due to insufficient space in the /stand volume, why?

A: The bootsys commands needs to copy the two files:
   /opt/ignite/boot/INSTALL and /opt/ignite/boot/INSTALLFS from the
   server into the client's /stand directory.  This error indicates
   that there is not enough space in /stand.  To fix this, you may
   need to remove any backup kernels.  Also check for kernels in the
   /stand/build directory (like vmunix_test).

========================================================================
6.10
Q: Can I have the IUX server and client on different subnets?

A:  Yes, however it will either require that you setup a boot-helper
    on the remote subnets, or limit yourself to using the bootsys
    command.

    Because the network boot firmware uses a broadcast BOOTP packet
    to find a server to boot from, these packets do not normally
    cross over subnets.  This limits systems to booting from
    systems only on their local subnet.

    When your Ignite-UX server is on a remote subnet, you have
    basically three options:

        1) Setup a "boot-helper" system on client's subnet which has
           the Ignite-UX.MinimumRuntime product loaded.  This system
           will provide the client with the ability to boot the
           INSTALL kernel and then contact the server once it is
           booted.  See the Ignite-UX Startup Guide for details
           (/opt/ignite/share/doc/sysadm.html)

        2) If the client system is running HP-UX 9.X or later, you
           can use the bootsys(1M) command from the server to initiate
           the install of the client.  The bootsys command copies the
           INSTALL & INSTALLFS files to the client's local disks and
           instructs it to boot from them.  So this option avoids
           the need to do a network boot altogether.

        3) Create a minimal bootable tape or CD-ROM to boot from and
           then point the client to the IUX server once it is booted.
           (See make_medialif(1M) for details).
   

========================================================================
--------------------
7. Media Install
--------------------

7.1
Q: How do I create bootable IUX media with my configs on it? (v1.09)

A: In order to create a bootable CD, that contains the golden system
images, you will need the "make_medialif" and "instl_combine" commands shipped
with Ignite-UX.  make_medialif packages up the Ignite-UX components from an
Ignite-UX server into a LIF volume that can be put onto a tape or CD-ROM. 
"instl_combine" is used to combine a LIF and a file system image into one image
for use with CD's.

make_medialif only deals with making the LIF area of the media.  It
does not deal with putting the Image archives (or SD depots) onto the
media.

So, basically what the steps for making a CD-ROM are:

       1) Setup an Ignite-UX server and build your golden images
          using make_sys_image.

       2) Build and test your config files to access the image(s)
          and get that process all working from the Ignite-UX server.

       3) Modify the config files that access the archives to point to
          the archives as you will name them on the CD-ROM.  And
          change the source_type from "NET" to "DSK".  IUX expects to
          find the archive_path relative to the top directory of the
          CD when mounted.

       4) run make_medialif to build a bootable LIF image and
          have it include all the config files needed, and
          especially the ones that you modified in step 3.

       6) IUX can use either an HFS or CDFS file system on
          the CD-ROM.  CDFS is more portable if you ever want
          to access it from a PC, or SUN, etc.  However,
          HFS is probably easier to create.  So, decide which
          way you want to go.

       7) If you chose to use an HFS file system, the easiest
          would be to create an LVM logical volume large
          enough to hold your archive(s).  Then, "newfs -F hfs"
          that device, mount it, and copy your archives to it.

       8) Unmount the file system, and use the "dd" command on the
          logical volume device file to copy the file system image from
          the logical volume to a regular file.

       9) Use the instl_combine tool to wrap the LIF file created with
          make_medialif "around" the HFS/CDFS file system image (you
          will need to get instl_combine from us, and which we will
          probably ship in a future version of IUX).

      10) You can take this image that instl_combine modified, and
          write it to a scratch hard-disk and boot from it to
          test the process before writing to a CD-ROM.  May save
          some time and $$..

      11) Write the file system image which instl_combine modified to
          contain the LIF contents to the CD-ROM burner.  We use a
          public domain tool written for linux called "cdwrite".


For a DDS tape, the steps are simpler.  Instead of a file system on the
media, the archives exist in their pure form as separate tape "files" on
the media.

       1) Setup an Ignite-UX server and build your golden images
          using make_sys_image.

       2) Build and test your config files to access the image(s)
          and get that process all working from the Ignite-UX server.

       3) Modify the config files that access the archives to point to
          the archives by using the archive_path to contain the tape
          file location of the archive (i.e.  If it is in the location
          just after the media LIF, archive_path="1")l

       4) run make_medialif to build a bootable LIF image, and
          have it include all the config files needed, and
          especially the ones that you modified in step 3.

       5) Use "dd" to write the LIF file a no-rewind-on-close
          tape device with bs=2k:
                dd if=uxinstlf of=/dev/rmt/0mn bs=2k

       6) Use "dd" to write the archive(s) to the tape following
          the LIF file (tape file location "1"), with bs=10k.
                dd if=uxinstlf of=/dev/rmt/0mn bs=10k
========================================================================
7.2
Q: Can I make a bootable tape with an SD depot on it?

A: Yes, a tape (or CD-ROM) can contain an SD depot.  A tape
   can contain at most 1 depot, and 0 or more archives.  A
   CD-ROM can have as many depots and/or archives as you have
   capacity for.

   The SD depot must come as the third tape file on the tape. The
   archives can be at any tape file location as specified by the
   "archive_path" keyword.  So the second tape file can either be an
   archive, or can be empty.

   When putting an SD depot on tape, first craft your config files to
   have all the sw_source statements that reference the archive and
   the SD depot.  For the SD depot, you can start with what make_config
   gives you, and then edit the sw_source to set source_type=MT.  SD
   assumes that the depot is the 3rd tape file, when it detects a LIF
   header on the tape, so there is no need to specify where the depot
   is on the tape.

   Then using a no-rewind device (/dev/rmt/0mn) you would:
      -  write the LIF file made by make_media_lif (bs=2k)
      -  Write your archive, or use "mt eof" to create an empty file.
      -  Write the SD depot using "swpackage target_type=tape ..."

   The tape would then end up looking like the following:

     ----------------------------------------------------------------
     |  LIF |  archive/or-empty | SD-depot | other archives, or EOT |
     ----------------------------------------------------------------
    

   For a CD-ROM, you can either have the SD depot exist at the top
   level of the CD (like the HP-UX CD-ROM's), or you can have one or
   more depots exist in a subdirectory on the CD.  To make a config
   file for the depot start with the result of running make_config.
   Then edit it to change the source_type, and change the sd_depot_dir
   to be the location of the depot directory relative to the top level
   of the CD-ROM.

========================================================================
7.3  
Q: Why does swinstall of patches hang during the software analysis?

A:  If you have created a CD-ROM that uses depots containing patches
    and the swinstall command that is loading the patches hangs, then
    you may be running into a defect in the "df" command.

    To be sure, you can type ^C^C^C until you get a prompt asking if
    you want to stop the install, answer yes, then answer yes to push
    a debug shell.  From the shell run "ps -ef" and look for a hung
    "df" command.

    The problem is caused by a defect in the "df" command.  The defect
    is that it hangs when ever it sees a mount entry with a
    one-character device string (in this case the mount device is "/").

    The workarounds for this problem are:

        - If the core OS is loaded from an archive, make sure that
          the latest "df" command patch is part of that archive (PHCO_15344)

        - If the core OS and patches are both in the same depot, and
          you are using the hw_patches_cfg config file to cause loading
          of the patches, then add the following to your config file:

            sw_source "core patches" {
                   pre_load_cmd += "
                     sed '/^. /d' /etc/mnttab > /tmp/mnt.fix &&
                     cp /tmp/mnt.fix /etc/mnttab
                     rm -f /tmp/mnt.fix
                   "
            }

        - This has been fixed in versions 1.50 or greater.

========================================================================
7.4  
Q: Why do I get DCE / RPC errors (RPC exceptions) during the
   configuration stage?  There is also a 10+ minute "hang" at the end
   of the SD configure stage, and a failure message is printed at the
   end of the installation.

A: There is an apparent problem with certain SD operations (e.g., swacl)
   when only loopback networking is enabled.  This would occur if the
   "media only" installation option is selected.  The workaround is to
   install using the "media with networking enabled" option and set up
   (perhaps temporary) networking parameters:  hostname, IP address,
   netmask, routing, etc.  This will allow the SD operations to complete
   normally.

========================================================================
7.5
Q:  How can I put an OS archive on multiple CD-ROM's?

A: If the archive of the system you want to put onto a CD is too large,
   you may want to consider creating multiple independent archives
   each of which will fit on the CD(s).

   The first archive should contain the core HPUX directories.  The
   remaining archive(s) would contain the rest of the system.

   The first step would be to determine what large (non-essential)
   directories can be omitted from the core-OS archive, and included
   it subsequent archive(s).  In this example, we will assume the /opt
   directory will be put into a second archive.  It may require some
   trial and error to exclude enough stuff to make an archive small
   enough to fit on the CD.  Keep in mind that the LIF data on the
   first CD will require space as well.

   To create the first core OS archive, use the make_sys_image command
   and use the -f option to specify a file that contains a list of
   directories that should be excluded.  For example, if you want
   to exclude /opt from the archive, create a file (/tmp/specific_files)
   that contains:

         + NO_ARCHIVE
         /opt

   Then run make_sys_image as such:

      /opt/ignite/data/scripts/make_sys_image -f /tmp/specific_files \
                   -s local -d /var/tmp 

   Then create your second archive containing the rest of the system
   (in this example, the /opt directory) Note that the archive content
   must not contain absolute paths.  This is especially true for
   core-OS archives, but is a good idea for other archives as well.
   Using pax to create the tar archive:

         cd /
         pax -wx ustar -f - opt | gzip > /var/tmp/archive2.tar.gz

   Now copy and edit the config file template
   /opt/ignite/data/examples/core11.cfg (or core.cfg for 10.20
   systems) for the first core OS archive.

   Copy and edit the /opt/ignite/data/examples/noncore.cfg template
   file for the other archive(s).  In addition to the changes required
   to make it work with a CD-ROM, make sure to change the sw_source
   definition in this file, to add the line:

         change_media=TRUE

   Now you can put these archives and config files on the CDs.  The
   first CD will contain the LIF data created using make_medialif as
   well as all the config files referencing all your archives.  See
   the make_medialif(1M) man page, FAQ item 7.1, and the white paper:
   http://www.software.hp.com/products/IUX/docs/Customized_Install_Media_Paper.pdf

   The second and subsequent CDs need to only contain a file system
   containing the archive.  Do not use instl_combine on the subsequent
   CDs as they should not have a lif area.


========================================================================
--------------------
8. Archive installs (golden images)
--------------------

8.1
Q: What does this mean?
  gunzip: stdin: unexpected end of file
  pax_iux: The archive is empty.
  ERROR:   Cannot load OS archive (HP-UX Core Operating System Archives)

A: It looks to me as if the NFS mount succeeded, but the file was not
accessible from the target machine. Several possibilities:
   - the file has a different name (check your config files)
   - the file has the wrong permissions such that it is not readable
     (check /etc/exports)

========================================================================
8.2
Q: /etc/nsswitch.conf and /etc/resolv.conf files from my archive don't end up 
 on the install target, why?

A:     There are certain files which IUX messes with during the configuration
    process (among them resolv.conf and nsswitch.conf). To end up with the
    archive versions of these files on your target machines, we provide 2
    scripts called os_arch_post_l and os_arch_post_c.

    These scripts are delivered in /opt/ignite/data/scripts. You will
    probably only need to modify os_arch_post_l. Copy it to a new name
    in the same directory and then edit it. Search on resolv.conf and
    nsswitch.conf for directions on what to change.

    After the script has been changed, modify your config file which
    describes the archive to point to the new script.

========================================================================
8.3
Q: What does "pax_iux: X: Cross-device link", "pax_iux: X: File exists" or
    "pax_iux: X : Device busy"  mean?

A: Both of these errors may occur when loading a system from an archive
   that does not have the same file-system partitioning as the system
   that the archive was created from.
 
   The first error (Cross-device link) is caused when two files exist
   as hard links in the archive, and when the two files would end up
   in separate file-systems.  For example if you created an archive on
   a system that did not use LVM, in which case the root file system
   is all one file-system.  And say you have two files, call them
   /usr/local/bin/f1 and /opt/myprod/bin/f2 are hard links.  If you
   make an archive of this system, and try to apply it to a system
   that uses LVM and has /usr and /opt as separate file systems, this
   error will occur.

   The second and third errors (File exists, and Device busy) may
   occur when the archive has a symlink, or regular file, that is
   named the same as a directory or mount point that exists when the
   archive is loaded.  This may happen for example if the original
   system that the archive was made from has a symlink like
   "/opt/myprod -> /extra/space".  And then when you are loading a
   system from the archive you decide to create a mounted file-system
   as /opt/myprod.  The pax command will fail to create the symlink
   because a directory exists in it's place.

   Is there any way to recover from this failure?  yes.  When the
   error happens you will be asked if you want to push a shell (on
   the target's console).  Answer "yes", and from the shell just
   type "exit 2" to ignore the error and it will continue on.

   Once the system is up, then you can more easily determine what
   should be done with the paths it complained about.

   To avoid the error, the system that the archive is created from
   should not contain hard links between directories that are likely
   to be created as separate file-systems.

========================================================================
8.4  
Q: What HP applications are tested for use with Ignite-UX?

A: HP applications that have been tested with Ignite-UX will have an OD1
   option on the ordering information (CPL).  This is the factory integrate
   option.  This tells the HP factories to install the software on the
   customer system before it leaves the factory.  HP manufacturing will
   load the software from a depot using the Ignite-UX process.

   An end user using Ignite-UX to ignite systems can load applications
   with Ignite-UX.  All HP applications with an OD1 ordering option can
   be loaded with Ignite-UX from a depot.

   No applications are tested for proper installation or operation when 
   included in a "golden system" archive that is loaded with Ignite-UX. 
   They may work fine in this mode but it is up to the person producing 
   the "golden system" archive to verify proper installation and operation.
   Running "swconfig -x reconfigure=true \*" after a golden installation
   may cause some software to properly configure itself after installation
   via a golden system archive.

========================================================================
8.5  
Q: How can the OnlineDiag LIF volumes be restored during the installation?

A: One possibility is setup a script in the INDEX file, which will be run
   as a post configure script. 

   For example, add this stanza to the /var/opt/ignite/INDEX file:
   scripts {
           "/var/opt/ignite/scripts/diag.sh"
   }

   The actual script, diag.sh, is included as an example script in the
   /opt/ignite/data/examples directory of the 1.50 version of IUX.  
   It basically runs this command:

   /usr/sbin/diag/lif/lifload -f /usr/sbin/diag/lif/updatediaglif

   which copies the OnlineDiag LIF volumes onto the root disk. 

========================================================================
--------------------
9. Getting Ignite-UX
--------------------

9.1
Q: What is different about the Web version?

A: Nothing, other than it is available 2-3 weeks prior to the media release.

========================================================================
9.2
Q: Can Ignite-UX bits be retrieved via ftp rather than downloaded from the web?

A: Yes but the ftp access is blind.  No "ls" can be done in the ftp
   directory.  The permissions on the "swdepot" directory do not
   have read access.  Explicit paths would have to be given.  You
   will need to just trust that they are there and do a "get" of
   them.  That is why the names of the files are listed below.

   # ftp software.hp.com
   ftp> cd /dist/swdepot
   ftp> get ignite_10.20.tar

   filename choices for 10.20 servers:
      ignite_10.01.tar
      ignite_10.10.tar
      ignite_10.20.tar
      ignite_all.tar

   filename choices for 11.00 servers:
      ignite11_10.01.tar
      ignite11_10.10.tar
      ignite11_10.20.tar
      ignite11_11.00.tar
      ignite11_all.tar

========================================================================
9.3
Q: Is Ignite-UX available on media?

A: If you have subscription service for the Application Media Release
then Ignite-UX is available to you on the media without a codeword, i.e.,
free.

========================================================================
9.4
Q: How do I update my Ignite-UX server to a new version?

A: In general, each new version of Ignite-UX is compatible with
   any scripts or configuration files that were created under older
   versions.

   If you follow some simple guidelines, updating to a new version of
   Ignite-UX involves running "swinstall" to load the new version.
   This is the same procedure as installing it for the first time.
   There is no need to remove the old version.

   Updating to a new version of Ignite-UX will preserve any changes
   you have made to files under the /var/opt/ignite and /etc/opt/ignite
   directories.  Changes to any files under /opt/ignite will be LOST
   during the update.  It is not recommended to change any files under
   /opt/ignite, and should only be done under rare circumstances.

   Guidelines for ensuring easy updates:

      - Do not modify any files under the /opt/ignite directory.

        If you need to modify any config files under /opt/ignite, copy
        them to an equivalent directory under /var/opt/ignite, and
        modify the INDEX file to use them in the new location instead.
        Some files and scripts have comments at the top that describe
        the procedure to use if you need to modify them.

        If you must modify files under /opt/ignite, then save a copy
        of your changes so you can re-apply the changes (if necessary)
        to the new files after updating Ignite-UX.

      - Make sure you load all Ignite-UX filesets you had before so
        you don't end up with a mixture of old filesets and new
        filesets.


========================================================================
9.5
Q:  How much of Ignite-UX do I need to install?

A:  Depending on what you are using Ignite-UX for, you may be
    able to reduce the disk space usage by not loading the full
    product.  Below is a list of typical usages and a list of
    what parts of Ignite-UX you need.  If you are not concerned
    with disk space, it is easiest just to load the bundle(s)
    for the HP-UX releases you plan to work with.

    For all cases the Ignite-UX.IGNT-ENG-A-MAN fileset can be
    omitted or removed if you do not want on-line documentation.

    Usage:                        What you need:
    =============================================================
    Ignite-UX server to           Load the Ignite-UX-XX-YY           
    install HP-UX on clients:     bundle(s) for each HP-UX release (XX-YY)
                                  which you plan to install onto
                                  clients.  You can omit the 
                                  Ignite-UX.OBAM-RUN fileset if your
                                  server is 11.10 or later and you
                                  don't plan on using
                                  make_net_recovery for 10.X clients.

    Ignite-UX server to           You will need the full Ignite-UX-XX-YY
    support network recovery      bundle for each version of HP-UX
    for clients:                  that your clients are running.
    

    Using only make_recovery      You only need the filesets:
    command:                          Ignite-UX.RECOVERY
                                      Ignite-UX.BOOT-KERNEL
                                      Ignite-UX.FILE-SRV-<release>
                                      Ignite-UX.MGMT-TOOLS
                                  Where <release> is the HP-UX release
                                  of the system you are running.

    Using only make_net_recovery  The filesets a client needs will
    on a client:                  normally be pushed out by the ignite
                                  GUI to each client from the
                                  depot created by pkg_rec_depot(1M).
                                  The only filesets required for
                                  make_net_recovery on the client are:
                                      Ignite-UX.RECOVERY
                                      Ignite-UX.MGMT-TOOLS

    A network "boot helper"       To setup a system on a remote subnet
                                  that is used just to allow a client to
                                  do a network boot and then contact
                                  a remote IUX server, all you need
                                  is: Ignite-UX.MinimumRuntime
    =============================================================

    Keep in mind that it is not a good idea to load a mixture of
    different versions of Ignite-UX filesets on a system.  So if you
    decide to update just a subset of Ignite-UX, you may want to use
    swremove to remove the portions you no longer need.

                                  
========================================================================

--------------------
10. Loading Patches
--------------------
========================================================================
10.1
Q: Can patches be installed at the same time the software it is
   patching is installed?

A: Yes, It is recommended that 10.X patches be kept in a depot
   separate from the software they patch (this is not the case in
   11.X).  In this way the load_order keyword can be used inside the
   sw_source to force them to be loaded after the software they patch.
   And also, the sd_command_line keyword can be used to specify the SD
   option: "-x match_target=true".

   For 11.00 core-OS patches, they should reside in the same depot as
   the 11.00 core OS.  This difference is due to the changes made for
   SD to be "patch smart".

   See also the document that comes with Ignite-UX called:
   /opt/ignite/share/doc/ace_hwe_setup

========================================================================
10.2
Q:  How do I prevent backup copies of patched files from being saved?

A:  When loading HP-UX patches from SD depots, the normal behavior is
    that the files that are patched are saved, just in case you want to
    remove the patch at a later date.  However, doing this takes up
    additional space in the /var directory, and so you may want to turn
    that feature off.

    The way to turn this feature off is different depending on if you
    are loading 10.X HP-UX, or 11.X HP-UX.  It also depends on whether
    the patches are coming from the core depot and being controlled by
    the hw_patches_cfg config file (See /opt/ignite/share/doc/ace_hwe_setup
    for more info on hw_patches_cfg).

  For 10.X releases:
    This feature is controlled by the existence of the file
    /var/adm/sw/patch/PATCH_NOSAVE.  If you don't want to save the
    patched files, then you need to have a pre_load_cmd that touches
    this file.  This pre_load_cmd can be at the global level or in the
    sw_source for the patch depot.  You can remove this file in a
    post_load_cmd if you want this feature re-enabled after the load
    is done.  For example:

        pre_load_cmd += "
            mkdir -p /var/adm/sw/patch
            touch /var/adm/sw/patch/PATCH_NOSAVE
        "
        # Put PATCH_NOSAVE back to the way it was.
        post_load_cmd += "
            rm -f /var/adm/sw/patch/PATCH_NOSAVE
        "

    Note that for patches in the core depot that are loaded via the
    hw_patches_cfg config file, PATCH_NOSAVE is always created and put
    back the way it was after the core load is complete (see the
    /opt/ignite/data/Rel_B.10.20/hw_patches_cfg file for details).

  For 11.X releases:
    This feature is controlled by an option to the swinstall command.
    That option is -xpatch_save_files=false|true.

    You can use the sd_command_line keyword either at the global level,
    or within individual sw_source clauses depending on if you want it
    to specified for all loads or just certain ones.

    Be aware that for patches in the core depot, this option is
    specified by the /opt/ignite/date/Rel.B.11.*/hw_patches_cfg file.
    It is controlled by the config file variable: _hp_patch_save_files
    and made visible to the user in the Additional screen of the UI.

    To specify this option at the global level (for example in
    the /var/opt/ignite/config.local file), you can add the line:

        sd_command_line += " -xpatch_save_files=false "

    To default the variable controlling the core patches to "NO", you
    can add the following to config.local (which must be listed after
    hw_patches_cfg in the INDEX file):

        init _hp_patch_save_files = "NO"

========================================================================
10.3
Q: Loading superseded patches causes a failed status, how to workaround?

A: When you are loading systems from multiple depots that contain
   patches, it is easy to run into the situation where patches in one
   depot supersede patches that have already been loaded from another.
   The superseded patches will prevent themselves from loading by giving
   an error.  This error is detected by Ignite-UX which causes the icon
   to turn red and the final status to be a failure.
   
   To work around this problem versions 1.45 and later Ignite-UX
   provides a script called /opt/ignite/bin/fix_patches that can be
   run on each depot that contains patches.  This script modifies
   the patch's checkinstall script so that it will "EXCLUDE" itself
   from loading without giving an ERROR.
   
   See the document /opt/ignite/share/doc/ace_hwe_setup for more details.
   
   There is no man page at this time for fix_patches, run
   "/opt/ignite/bin/fix_patches -?" for command line syntax.
      
========================================================================
10.4
Q: Why do I get errors from swinstall regarding patches in 11.00 depots?

A: If you see errors such as:

  ERROR:   The fileset "PHSS_16931.C-KRN,l=/,r=1.0" is a "sparse" or
           "patch" fileset which may only be installed upon a previously
           installed base fileset.  The specification for the required
           base fileset is "OS-Core.C-KRN,l=/,r=B.11.00".  Since fileset
           "OS-Core.C-KRN,l=/,r=B.11.00" is being excluded due to the
           errors shown above, fileset "PHSS_16931.C-KRN,l=/,r=1.0" will
           also be excluded. 

   A likely cause is that during the load of the core-OS, the version
   of swinstall that Ignite-UX placed on the system was replaced with
   the original (non-patched) version of swinstall that has some
   defects regarding patch handling.

   The solution is to ensure that all 11.00 core-OS (ACE/HWE/XSW)
   patch bundles, and individual patches, reside in the same depot as
   the core-OS.  This configuration ensures that the patches to
   swinstall are loaded in the same session as the rest of the core.
   And thus there is never a point in time where a pre-patched
   swinstall is used during the installation.

   A common cause of this problem is a defect in the make_depots
   command that is fixed in the B.2.4 Ignite-UX release.  The
   defective make_depots (which is what is used if you use the GUI to
   setup the depots) would put some of the patches from the XSW patch
   bundle into the /var/opt/ignite/depots/Rel_B.11.00/apps* depots.
   If you have this situation, the work around is to move the patch
   bundles from the apps* depot(s) into the core depot.  This can be
   done using the swcopy and swremove commands.

========================================================================

--------------------
11. Network Recovery
--------------------
11.1  
Q: How can I learn more about network recovery?

A: In addition to the information in this FAQ, there are several other
   sources of information on network recovery:

    - http://software.hp.com/products/IUX/docs/network_recovery_Slides.pdf
      This is a slide set first presented at Interworks '99. It  
      describes the basic capabilities of network recovery.

    - /opt/ignite/share/doc/makenetrec.txt
      This describes the basic functionality of network recovery. It
      explains how to install the product and how to use it.

    - These manual pages are new or were modified for network recovery:
          - make_net_recovery(1m)
          - make_boot_tape(1m)
          - pkg_rec_depot(1m)
          - instl_adm(1m)
          - instl_adm(4)
          - ignite(5)

    - /opt/ignite/share/doc/release_note
      The release note lists new features and known problems with 
      network recovery.

========================================================================
11.2
Q: How does make_net_recovery differ from make_recovery?

A:  The most fundamental difference between the commands is that
    make_net_recovery produces a backup recovery image of a system
    to an Ignite-UX server, whereas make_recovery produces a similar
    backup to a local tape device.

    Based on customer feedback, there are some fundamental issues with
    make_recovery that the IUX team wanted to resolve when they
    implemented make_net_recovery.  To accomplish this, a new design
    and a new code base was developed.  The result is that the two
    commands behave somewhat differently.  Below is a summary of some
    of the differences:

        1) make_net_recovery can archive more than just the root
           volume group.  You can include files from anywhere on the
           local file systems.  Any disks that have any data archived from
           them will be re-initialized when the system is recovered.
           make_recovery limits you to the root volume group (VG), with
           the exception of when /usr is on a separate VG.

        2) While recovering a system after using make_net_recovery,
           you can use the user interface to make changes to
           disk/file-system layouts and networking information without
           changing the basic behavior of the tool.  Your changes will
           be intelligently merged in with the original configuration.
           By default, recovering a system is an interactive process.

           When recovering from a make_recovery tape, the process is
           non-interactive by default, and interrupting the automatic
           process causes many host-specific configuration files to
           not be restored.

        3) Using the archive of one system to install a different
           system (cloning) is handled more cleanly when using
           make_net_recovery.  The changes that allow cloning to work
           better are: intelligent merging of configuration changes,
           interactive execution, and automatic kernel rebuild when
           the system model changes.  (See FAQ item 11.4 for more
           details on cloning).

        4) By default, both make_recovery and make_net_recovery
           archive only a minimal set of essential files from the
           system.  The list of minimal files used by
           make_net_recovery is smaller than make_recovery.  In
           particular, no files from /var or /opt are in that list.
           The list of essential files for make_net_recovery are
           contained in /opt/ignite/recovery/mnr_essentials.

        5) There is no "check_recovery" command equivalent for
           make_net_recovery.  Because it is so easy to automate
           running make_net_recovery from a cron job, it is likely
           that recovery backups will be done on a regular basis and
           when a known system change happens rather than relying on a
           tool to detect changes.

        6) The command line options to make_net_recovery are quite
           different from make_recovery.  For example, if you want to
           include all files from the root volume group (vg00) in the
           archive, you would use the option "-x inc_entire=vg00"
           instead of -A.

        7) make_net_recovery has a GUI that can be invoked from the
           server's "ignite" GUI using the "Create System Recovery
           Archive" action.  From this GUI you can select which
           files/dirs, volume groups, disks are to be archived.  These
           selections are saved for use the next time, and are used
           by default when running make_net_recovery from the command
           line if you do not supply any -x options.  The idea behind
           this is that you can use the GUI once to configure each
           client, and then use a generic make_net_recovery command
           line in the crontab of each client.

           If you want to use the "ignite" GUI on clients that do not
           have an icon, use the "Add New Client for Recovery" option
           from the Actions menu.

        8) The "archive_impact(1M)" command is run on the recovery
           archive produced by make_net_recovery.  This command
           supplies Ignite-UX with the amount of file space consumed
           on each file-system.  The result is that during the
           recovery, Ignite-UX may increase the sizes of volumes that
           are close to full (if it has free space in the volume
           group).  This will also prevent you from accidentally
           reducing the size of a volume below the required size.

        9) The software needed to run make_net_recovery is
           automatically pushed out to the client when using the
           "ignite" GUI.  It is also updated if it becomes out of
           date.  The ignite GUI creates a small "packaged-in-place"
           depot that is used by clients to install the subset of
           Ignite-UX needed for make_net_recovery.  See examples
           section of the make_net_recovery(1M) man page for how to
           automate client software updates when not using the GUI.

    In a future release, we plan to use the code and design of
    make_net_recovery to replace make_recovery.  At which time the two
    commands will have fewer differences and similar features.

========================================================================
11.3  
Q: Can I still use make_recovery on a system if I am also using
   make_net_recovery?

A: Yes, it is possible to use both make_recovery and 
   make_net_recovery on a single system.

   The only issue to be concerned about when doing this is to make
   sure that the version of Ignite-UX that is installed on the system
   is consistent. To run make_recovery on a system, most of the
   Ignite-UX product must be installed. To run make_net_recovery,
   only a small portion of the Ignite-UX product needs to be
   installed. 

   It's important that the Ignite-UX filesets installed on a given 
   machine be of the same revision.

   The simplest way to keep everything consistent is to always 
   install Ignite-UX from a recovery depot built on the Ignite-UX
   server. This depot can be constructed by running the following:
      pkg_rec_depot -f
   on the Ignite-UX server. This creates the 
   /var/opt/ignite/depots/recovery_cmds depot which contains the 
   entire Ignite-UX product.

   After this depot has been created, swinstall everything from it
   onto each of your target machines. If you will be doing network
   recovery from the "ignite" graphical user interface on the server,
   this installation step happens automatically.

   As of the A.2.0 and B.2.0 releases, if you try to run make_recovery
   and the Ignite-UX product is not consistently installed (all filesets
   do not have the same revision), you will be given an error. If this 
   happens, re-install the Ignite-UX product as described above. 

======================================================================
11.4
Q: How can I clone a system using make_net_recovery?

A:  The recovery configurations and archives created by
    make_net_recovery are stored in a separate directory on the
    Ignite-UX server for each client.  
 
    Using the configuration and archive created by make_net_recovery
    on one system to install a different system involves manually
    copying some configuration files, and allowing NFS access to
    the source system's archive.

    The steps to clone a system using make_net_recovery are:

        1) Use make_net_recovery (or the "ignite" GUI) to create
           a system recovery archive of the source system.

        2) Login to the Ignite-UX server.

        3) If the target system to be installed does not currently
           have a directory in /var/opt/ignite/clients but is up and
           running, then use the "ignite" GUI to create that directory
           using the "Add New Client for Recovery" action.  If the
           system is not running, you will either need to boot the
           client from the Ignite-UX server (or for a tape made
           with make_boot_tape) in order for this directory to
           be created.

        4) Copy the CINDEX and recovery directory from the source
           client to the target client directory.  Note that if the
           target client has previously used make_net_recovery then it
           will already have a CINDEX file.  If the CINDEX file for
           the target system exists already, you may want to save a
           copy, and/or hand edit the file to add the desired entries
           from the source client.  The commands below will copy the
           required files, you may specify <src-client> and
           <target-client> using either the LAN addresses
           (e.g. 0x0060B04AAB30), or by using the client's hostname
           (which is a symlink to the LAN address).

                # cd /var/opt/ignite/clients/<src-client>
                # find CINDEX recovery | cpio -pdvma ../<target-client>

        5) Give the target-client NFS access to the archive of the
           source system.  To do this, login to the server that holds
           the archive (normally the Ignite-UX server).

           Typically each client has its own directory for storing
           the archives, and the directory is exported only to the
           individual client.  In this case, you will need to edit
           the /etc/exports file to allow access to both the source
           and target clients:

                # vi /etc/exports
                  (append ":target-client" to the end of the
                  source-client's line)
                # exportfs -av

        6) Now you can boot the target-client from the Ignite-UX
           server (using any method you wish).  Then when you install
           the system, you can select from the recovery configurations
           of the source system.

======================================================================
11.5
Q: How can I tell which files will be included in the archive
   created by make_net_recovery?

A: Execute /opt/ignite/lbin/list_expander as described in
   FAQ item 11.6, replacing the -d option (which lists
   the disks and/or volume groups) with the -l option (which
   instead lists the individual directories and files that
   will be included in the archive). 

======================================================================
11.6
Q: How can I tell which disks or volume groups will get re-created
   during an installation from a make_net_recovery configuration?

A: Execute the following from the client:
   /opt/ignite/lbin/list_expander -d -f input_file

   where input_file is a file specifying what is to be archived.
   See the make_net_recovery(1m) man pages for details on the
   format of the input_file.  make_net_recovery can take
   input from an input file, no input, or input from the command
   line with the x option.  list_expander can take input
   from an input file, or no input, but does not have an
   x option like make_net_recovery does, so to see the
   result of using x options, put them in a file and
   pass list_expander the file name.

   If you used the GUI to specify what is to be included
   in the archive, then the input file can be found on
   the server in

   /var/opt/ignite/clients/<client>/recovery/archive_content

   You can copy this file from the server to the client,
   then run list_expander against that file itself.
 
   Omitting the '-f input_file' will cause list_expander to use
   only the essential files as input.  This will show what disks
   or volume groups will get re-created for the minimal archive. 

   The following is an example of the output:

   In?     dsk/vg  name            minor#  Associated disks
   0       d       /dev/dsk/c0t3d0
   1       v       /dev/vg00       0x00    /dev/dsk/c0t6d0 /dev/dsk/c0t4d0
   0       v       /dev/vg01       0x01    /dev/dsk/c0t1d0
   0       v       /dev/vg02       0x02    /dev/dsk/c0t2d0

   Column two shows that the system has one whole disk (d)
   and three volume groups (v).  Column three gives the
   names of the disks and volume groups.  Column one shows,
   for each disk or volume group, if it will be:

   2 = included in full (INC_ENTIRE dsk/vg specified),
   1 = included in part (some files included, some not), or
   0 = not included at all (no files from this dsk/vg are included).

   A 0 means the disk or volume group will NOT be touched.
   A 1 or 2 means that the disk or volume group WILL be
   re-created, and files from the archive will be restored.

======================================================================
11.7  
Q: How can I use make_net_recovery if I need to be able to recover
   from a tape?

A: There are two ways you can recover from a tape with 
   make_net_recovery. The method you choose depends on your needs.

   The first method is useful when you want to create a totally
   self-contained recovery tape. The tape will be bootable and
   will contain everything needed to recover your system, including
   the archive of your system. During recovery, no access to an 
   Ignite-UX server is needed. A description of the process required 
   to construct such a tape can be found in the 
   /opt/ignite/share/doc/makenetrec.txt file.

   The second method is useful when you do not have the ability to
   boot the target machine via the network, but are still able to
   access the Ignite-UX server via the network for your archive and 
   configuration data. This could happen if your machine does not 
   support network boot or if the target machine is not on the same 
   subnet as the Ignite-UX server. In these cases, use make_boot_tape 
   to create a bootable tape with just enough information to boot and 
   connect with the Ignite-UX server. The configuration files and archive 
   are then retrieved from the Ignite-UX server. See make_boot_tape(1m) 
   for details. 

=====================================================================
11.8
Q: Which files does Ignite-UX change during an installation from
   a make_net_recovery configuration?

A:  During a system recovery, Ignite-UX strives to restore the system
    back to the way it was.  However Ignite-UX is a general purpose
    installation tool, and as such it has the capabilities of
    modifying many system configuration files.

    When you run make_net_recovery, a lot of system configuration
    information is gathered and saved in config files that are used
    later when the system is recovered.  During the system recovery
    the user is allowed to make changes to this information, in which
    case Ignite-UX will make the appropriate changes to the system
    configuration.  If a user does not make any changes, then it
    simply re-applies the same information and you should see no
    change to the system in the end.

    Most of the system configuration files that Ignite-UX will modify
    are listed in the script: "/opt/ignite/data/scripts/os_arch_post_l".

    The os_arch_post_l script checks for the system recovery case by
    checking the $RECOVERY_MODE variable.  When this variable is TRUE,
    the os_arch_post_l script causes some configuration files to be
    protected from modification by using the "save_file" function.
    os_arch_post_l uses the "merge_file" function on files that
    Ignite-UX knows how to intelligently merge information into.

    The files operated on by "merge_file", as well as those that have
    a commented out "save_file" line are those that are likely to be
    modified by Ignite-UX.  Comments in the file explain any
    exceptions.

    Because the list of files modified by Ignite-UX may change from
    release-to-release, it is best to look at the os_arch_post_l file
    on your system to see which files are saved as-is and which are
    merged with information from the IUX config files.

=====================================================================
11.9 
Q: How can I keep archive(s) from being deleted by make_net_recovery 
   when new archives and configurations are created by subsequent 
   invocations of make_net_recovery?

A: You may want to prevent known "good" archives from being deleted 
   from your system.  The make_net_recovery tool provides the (-n) 
   option, which allows you to specify the number of archives to save.  To 
   preserve disk space, the oldest archive(s) are removed as new archives 
   are created. The number of archives that get removed is based on the 
   number of archives specified to be saved (the -n option to make_net_recovery).  
   One way to ensure that known "good" archives are saved would be to specify 
   the number of archives to save to be greater then the maximum number of 
   archives you plan to store on the system at any given time.  This would 
   cost disk space.
  
   An alternative and better approach to saving known "good" archives is to
   rename the archive and edit the configuration file to include the new
   archive name.  The steps below explain this process in detail:
  
   1. Login to the system where the archive is being stored.
      (NOTE: This system could be different from the Ignite-UX Server).
   2. Rename the archive. (The path to the archive may be different than the
      example below). The name of the archive to save can be anything unique,
      but it should be outside the naming convention "yyyy-mm-dd,hr:min"
  
      cd /var/opt/ignite/recovery/archives/<system_name>
      mv old_archive_name saved_archive_name
  
      Example: % mv 1999-05-11,15:14 Recovery_Archive.0511.save
   
   3. If the Archive server is different from the Ignite-UX server, login to
      the Ignite-UX server system.

   4. Edit the following to reference new archive name:

    /var/opt/ignite/clients/<client>/recovery/<old_archive_name>/archive_cfg

      Change the archive_path variable inside the (source_type == "NET")
      conditional to the name of the saved archive.
   
       Example:
       
       (source_type == "NET") {
         archive_path = "Recovery_Archive.0511.save"
       }else {
         archive_path = "1"
       }
    5. (Optional) Edit the cfg tag entry in the file: 
       /var/opt/ignite/clients/<client>/CINDEX so the that configuration will 
       be unique and descriptive when it is viewed via the Ignite-UX User 
       Interface.
 
       Example:
 
       Change from:
       cfg "1999-05-13,06:51 Recovery Archive" {
         description "Weekly System Recovery Archive"
            .
            .
       }

       To:
       cfg "Saved Recovery Archive" {
         description "Weekly System Recovery Archive"
            .
            .
       }

=====================================================================
11.10 
Q: How can I make configuration file additions to all recovery
   configurations for a given client?  

A: Create a new Ignite-UX configuration file called 
   /var/opt/ignite/clients/0x{LLA}/recovery/config.local. This 
   config.local file will automatically be included into your 
   recovery configuration for this client each time you run the 
   make_net_recovery command. Note that make_net_recovery is run 
   for you when you use the graphical user interface for network 
   recovery.

   If you already have recovery configurations for this client 
   and would like them to include the config.local file, edit the 
   /var/opt/ignite/clients/0x{LLA}/CINDEX file to include a 
   reference to "recovery/config.local" in all of the configuration 
   clauses.

========================================================================
11.11
Q: How can I select from the standard file system layouts during a recovery?

A: It is possible to change the way your disks are configured when you
   recover from an image saved by make_net_recovery. To do so, you
   must modify the /var/opt/ignite/clients/0x<LLA>/CINDEX file for the
   client you are recovering.

   The CINDEX file contains one or more configuration clauses that refer
   to the recovery images you have previously created with make_net_recovery.
   Add a new configuration file entry to the clause that you intend to 
   recover from. If you want to add HP's standard file system choices,
   add the file:
       "/opt/ignite/data/Rel_<release>/config"
   where "release" is the operating system release on the client you intend
   to recover. For example, /opt/ignite/data/Rel_B.10.20/config would be
   added for a client with the HP-UX 10.20 operating system. This new
   configuration file entry should be the first entry in the clause you
   are modifying.

   When you bring up the user interface during recovery, select the
   "File System" type you wish to use on the "Basic" tab.

========================================================================
11.12 
Q: How can I keep make_net_recovery version 2.0 from erasing
   volume groups that contain only unmounted and raw logical volumes?

A: make_net_recovery version 2.0 has a bug in it which causes volume
   groups that contain only unmounted and raw logical volumes to be
   re-created but not restored, causing loss of data.  When recovering
   a system, the user can specify to not recreate these volume groups,
   so that data is not lost. However, the user will need to manually
   import these volume groups after recovery.

   This problem has been fixed with version 2.1
========================================================================
11.13
Q: Why can make_net_recovery fail when the archive is 2GB or more?

A: make_net_recovery uses NFS to write/read the system archive
   from the client to/from the server.  To manage archives greater
   than 2GB requires that both the client and server use NFS protocol
   version 3 (PV3).  NFS PV3 is available for HP-UX 10.20 when the
   Networking ACE set of patches are loaded.  And is standard on
   11.00.

   If you know you have NFS PV3, and are having problems, then check
   the following:

      - If you are using the "A" version of Ignite-UX, you must
        have version A.2.1 or later.
      - If you are using the "B" version, you must have B.2.0 or later.
      - Some NFS patches in the past have caused problems with >2GB
        files.  These problems have been fixed in patches:
                10.20:   PHNE_22117 (s700 and s800)
                11.00:   PHNE_22125
      - If your NFS server is running 10.20 with the newer NFS
        patches, then the /etc/rc.config.d/nfsconf file has a
        configurable parameter (MOUNTD_VER) which determines if the
        default mount should be PV2 or PV3.  This must be set to 3.
      - If your clients are running 10.20 with the newer NFS patches,
        then the /etc/rc.config.d/nfsconf file must have the parameter
        "MOUNT_VER" set to 3.
========================================================================
11.14 
Q: How can I keep make_net_recovery version 2.0 and 2.1 from core dumping
   when I have more than 8 volume groups?

A: make_net_recovery and the Network Recovery GUI (mnr_ui) version 2.0
   and 2.1 have a bug which causes core dumping on systems with more than
   8 volume groups.  A downloadable fix is due to be available on the web
   the first week of September of 1999.
   ( http://software.hp.com/products/IUX )

   This problem will be fixed with version 2.2
========================================================================
11.15
Q: How can I keep make_net_recovery version 2.0 and 2.1 from crossing
   and archiving files from NFS mounts when I have symlinks from
   essential directories to NFS mounted directories, and when there
   is a symlink in the pathname to the directory?

A: make_net_recovery (in IUX versions 2.0 and 2.1) may cross and
   archive NFS mounts if an essential directory has a symbolic link
   to something that is NFS mounted, and the path to the NFS
   mounted directory contains a directory which is a symlink.
   A downloadable fix is due to be available on the web
   the first week of September of 1999.
   ( http://software.hp.com/products/IUX )

   This problem will be fixed with version 2.2
========================================================================
11.16
Q: I replaced the client system, and the LAN address is now different.
   How can I restore the new system from the old net-recovery archive?

A: Ignite-UX uses a separate directory for each client under
   /var/opt/ignite/clients.  Each subdirectory is named based on
   the client's LAN address (i.e. LANIC, LLA, MAC address, etc).

   If you replace the client hardware - or even the LAN card that
   the old LAN address was based on, then it will no longer access
   the same directory on the server.

   The simplest solution is to obtain the new LAN address, which you
   can do from the boot-ROM console command LanAddress (actual command
   may vary from system to system).  Once you have the new address,
   then manually rename the directory.  You may just remove the
   hostname symlink (it will be recreated automatically).  Note that
   the LAN address must be in all upper-case, and begin with 0x.
 
   If you already booted the client from the server which caused it to
   create a new directory, you can just remove that directory before
   renaming the old directory.  Be careful not to remove the original
   directory or else you will loose the recovery information.

   For example:

        # cd /var/opt/ignite/clients
        # mv 0x00108300041F 0x00108300042A
        # rm oldhostname

========================================================================
11.17 Q: Why do I get the error: "The minor number of the volume group exceeds 
         the value IUX can support."?

A: See question: 4.6
========================================================================
11.18 
Q: Dealing with hot swappable disks during recovery

A: See question: 4.7
========================================================================
11.19 
Q: Why does make_net_recovery hang while trying to write the archive?

A:  During archive creation, both make_recovery and make_net_recovery
    can hang while attempting to read files with mutually exclusive 
    locks (see lockf(2)).  A file lock set with F_LOCK enforcement will 
    cause a process to sleep while attempting to read that file.  If
    this is the problem then you will see a pax(1) process in the sleep
    state that has blocked on a locked file.

    How to find the offending file:
    A capital 'S' character in the execute permission bit for a file is 
    one indication of this kind of lock.  The tools glance(1) or gpm(1)
    can be used to view all files in use by a process, and will easily
    help you identify the locked file.  Locate the pax(1) process 
    that is attempting to archive the file and use glance or gpm to
    view files that it is using.
  
    Another method that can be used to determine the offending file
    is to examine the partially created archive file.  Archive files
    by default are located in: 
       Serverhost:/var/opt/ignite/recovery/archives/<hostname>
    The following command will allow you to view the last files
    to be archived:
       gzcat <archive file> | tar -tvf - | tail
    You can utilize the list_expander utility (see FAQ entry 11.5) to
    see the files that should be included in the archive in the 
    archive order.  Compare the last entries in the incomplete archive
    against the list_expander results to figure out the file that
    pax was working on when it hung.
    
    Work around:
    The hanging behavior that is occurring is the appropriate behavior
    under these circumstances.  There is no way to archive files while
    they are locked in this manner.  For this reason you must exclude
    locked files from the archive.  This also means you cannot lock 
    files that are part of the minimal set of archive files built 
    into make_net_recovery.

    You can can control the contents of the archive using the '-x' 
    option of make_net_recovery(1M), or with the content description 
    file /var/opt/ignite/clients/0x{LLA}/recovery/archive_content.
    See the make_net_recovery(1M) man page for rules on how to 
    control archive inclusions and exclusions.

       EXAMPLE:
       make_net_recovery -s <server> \
          -x inc_entire=vg00 -x exclude=<locked file/dir>

       The command above will write a recovery archive to the
       server in the default file system location and include all 
       contents on the root volume group 'vg00' except for 
       the excluded 'locked file/dir'.  This example assumes
       that the locked file/directory was located within the 
       volume group we are archiving.  

       Note: Exclusions are hierarchical so you are also excluding 
       all files and directories under 'locked file/dir' if it
       is a directory.
           
    Remember that you cannot exclude files or directories that are included 
    in the essentials list.  See the make_net_recovery(1M) man page for 
    more information on the essential list of files and directories.

    Other options include unlocking files to be archived or moving files 
    that need to be locked to locations on the file system that will not be 
    archived.  For a quick resolution you can exit from applications that 
    have locks on files you wish to archive during the archive process.

========================================================================
11.20
Q: Why does archive_impact fail during make_net_recovery

A: A patch was issued for ksh(1M) which in turn causes corrupt parameter 
   processing.  The corruption occurs when archive_impact is run as a part 
   of a make_net_recovery.  The patch is: PHCO_21185.

   Work around:
   PHCO_21185 has been superseded by PHCO_22020.  Please remove PHCO_21185
   and install PHCO_22020.

========================================================================
End of FAQs

Sources for this document:
    
     web  -  http://software.hp.com/products/IUX/docs/iux_faq
     mail -  null message to iux_faq@igniteux.fc.hp.com (most current)

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA


[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
Ignite-UX Enhance <iux_enhance@fc.hp.com>





Last Update March 27 2014 @ 02:11 PM