From: Ignite-UX Enhance <
[email protected]>
Newsgroups: comp.sys.hp.hpux,comp.answers,news.answers
Subject: Ignite-UX FAQ
Supersedes: <
[email protected]>
Followup-To: comp.sys.hp.hpux
Date: 11 June 2001 09:26:06 -0600
Organization: Hewlett-Packard Company
Lines: 3128
Sender:
[email protected]
Approved:
[email protected]
Expires: 6 Jul 2001 00:00:00 GMT
Message-ID: <
[email protected]>
NNTP-Posting-Host: roberts.fc.hp.com
Summary: This posting answers frequently asked questions about the
product Ignite-UX distributed by Hewlett-Packard Company.
Keywords: Ignite-UX FAQ
X-Disclaimer: Approval for *.answers is based on form, not content.
Archive-name: hp/Ignite-UX_faq
Posting-Frequency: monthly
X-Newsreader: Gnus v5.6.45/XEmacs 21.1 - "Arches"
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!newsfeed.utk.edu!news-hog.berkeley.edu!ucberkeley!newsfeed.stanford.edu!news.isc.org!agilent.com!sdd.hp.com!hp-corv.cv.hp.com!hpb10302.boi.hp.com!news.cup.hp.com!fc.hp.com!news
Xref: senator-bedfellow.mit.edu comp.sys.hp.hpux:129429 comp.answers:45818 news.answers:209155
Ignite-UX (IUX) Frequently Asked Questions
@(#) 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 "
[email protected]" 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
[email protected] (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
[email protected] (most current)
