Ignite-UX (IUX) Document for Frequently Asked Questions (FAQ) (762793-001, March 2014) (Edition: 3)

cannot be correctly read if they are 2 GB or greater in size. When encountering this problem the
symptoms look like:
• Loading_software: Begin
• Installing boot area on disk
• Formatting HP Service Partition
• Enabling swap areas.
• Backing up LVM configuration for "vg00"
• Processing the archive source (hp client archives)
• Thu Nov 03 12:37:56 EST 2005: Starting archive load of
the source (B.11.23 client archive IA)
• Completed 0% of archive
gunzip: stdin: unexpected end of file pax_iux: The archive
is empty
ERROR: Cannot load OS archive (B.11.23 client archive IA)
The configuration process has incurred an error, would you
like to push a shell for debugging purposes? (y/[n]):
Patch PHKL_33110 contains the defect fixes for JAGaf44970
and JAGaf67476.
Ignite-UX version C.6.8 contains the equivalent fix for HP-UX
11.11.
Why is the network boot of my Itanium-based system slow?
To reduce the amount of time it takes to perform a network boot, you must use an Ignite-UX server
that is running a tftp daemon (tftpd) which supports the tsize option.
When the firmware on an Itanium-based system is downloading a file booting, it first attempts to
determine the size (in bytes) of the file. If the tftp daemon (tftpd) on the server does not support
the tsize option, the client downloads the file using the following steps:
1. Download the entire file (not storing the data), counting the bytes.
2. Allocate a buffer which is the exact size of the file.
3. Download the entire file (again) into the allocated buffer.
The B.11.11 patch which enables the tsize feature is PHNE_32825 which was posted on 20
March 2006.
NOTE: HPVM requires this patch if you are installing a virtual machine from an Ignite-UX server
running B.11.11. Not having this patch installed on the server will cause the network boot to fail
because of a firmware defect. No tftpd patch is required for B.11.23 onwards as the tftpd
daemon supports the tsize option from first release.
How can I workaround recovery failure: ERROR: A conflict has been
detected while attempting to restore the prior device file
names?
This error is caused by the way that device special files are managed while restoring a prior
instance number assignment of the ext_bus class devices (this instance number appears in the
device file names for disks following the 'c' character).
For VxVM, the device files must not be renamed prior to the kernel knowing about the new instance
assignments, and for LVM/whole-disk, they must be renamed prior. So, when the system has a
Frequently asked questions 15