Applies to: Releases 1.xx and 2.xx

To install Linux on target servers using a scripted install job, the ProLiant Integration Module on the NFS Server must be installed on an operational Linux NFS Server. A single NFS Server can be used to deploy multiple Linux distributions. Be sure that the hardware and software of the NFS Server meets the minimum requirements as specified in the appropriate Rapid Deployment Pack version installation guide including allocating enough file space for /usr where the ProLiant Integration Module files will be placed.

To create a Red Hat Enterprise Linux 3 or Red Hat Enterprise Linux 4 NFS Server:

To create a SUSE LINUX NFS Server:

Applies to: All releases

The display name is the name shown in the Deployment Server Console. The computer name is the name of the target server. The display name and computer name are two separate fields in the Deployment Server database and are not always the same value. The information in this article describes how the display name and the computer name fields are populated depending on the Deployment Server options, the Deployment Agent, and the method the operating system is installed on the target server.

When a Server Connects to Deployment Server for the First Time:

Using the Deployment Agents (DOS, Windows, or Linux) under automation, either by way of PXE or a boot diskette, it is added to the New Computers group. The initial display name:

for ProLiant ML/DL and Integrity rx servers is based on the Primary Lookup Key. The Primary Lookup Key could be defined as the MAC Address, Serial Number, UUID, or Asset Tag. The initial computer name is the same value as the initial display name.

for HP BladeSystem servers, the initial display name is the concatenation of the Rack name, Enclosure name, and Bay number, for example, UnnamedRack-HP-1. The initial computer name is the last 15 characters of the initial display name.

for VMware ESX virtual machines and with the Primary Lookup Key defined as Serial Number, the initial display name will be of form, VMware-XX XX XX XX XX XX where XX XX XX XX XX XX is a hexadecimal string including spaces. Spaces in the name are not NETBIOS compliant for Windows scripted installs. For Releases 2.20 and greater, the spaces will be removed automatically during the scripted install by code in the default unattend text file. With previous releases, the name must be changed at the console without the spaces before performing the Windows scripted install. The initial computer name is the same value as the initial display name.

for Microsoft Virtual Server virtual machines and with the Primary Lookup Key defined as Serial Number, the initial display name will be the virtual machine serial number. The initial computer name is the same value as the initial display name.

NOTE: There is a database limitation that could cause the beginning of the name to be truncated if the name is greater than the number of characters allowed for that database field.

Using the Deployment Agent for Windows (aclient) under production, it is added to the New Computers group. The initial display name is the actual computer name.

Using the Deployment Agent for Linux (adlagent) under production, it is added to the New Computers group. The initial display name is the actual hostname.

When a Server is Deployed:

Using a Windows scripted install job, the default behavior as of Release 2.00 will set the computer name to the last 15 characters of the display name. If the Synchronize the display name with computer names option is enabled, the display name will change to the computer name.

Using a Linux scripted install job, the default behavior as of Release 3.00 will set the computer name (hostname) to the display name.

Using a VMware ESX scripted install job, the default behavior will set the computer name (hostname) to the DNS name if DNS has been configured, or localhost. If the Synchronize the display name with computer names option is enabled, the display name will change to the hostname.

Using an image deploy job, the computer name will be set to the value of the computer name database field. The provided deploy image install jobs have the Automatically perform configuration task after completing this imaging task option enabled. If this option is not enabled, the computer name will be a duplicate of the computer name in the image. If the Synchronize the display name with computer names option is enabled, then the display name will change to the computer name.

Applies to: All releases

To resolve this issue, upgrade the firmware of the RILOE to version 2.40 or later. For firmware downloads and documentation, refer to: www.hp.com/servers/lights-out.

Applies to: Releases 1.xx and 2.xx

ProLiant servers using ROM-Based Setup Utility (RBSU) 1.0 or earlier (System Config-based systems) do not have the ability to bypass the F1 prompt when the server is unconfigured.

To resolve this issue during a PXE-based boot, use RILOE, iLO, or the local console to press the F1 key. To resolve this issue during a diskette-based boot, use the SIGNDISK utility in the SmartStart Scripting Toolkit.

Applies to: Releases 2.00 through 3.50

Add the following code to the Red Hat Enterprise Linux 3 kickstart file before performing a Linux scripted install.

cat >> /etc/fstab << EOF
device mountpoint auto mountoptions 0 0
EOF
mkdir -p mountpoint

where

device is the device,
mountpoint is the device mount point, and
mountoptions is the mount options separated by commas.

Examples:

Applies to: Release 1.40 through 2.20

The script called to create or join the cluster in the Packaged Cluster deployment jobs resets the IP address of the private NIC in each cluster node. During deployment, the private NIC on the secondary node can temporarily be assigned the same IP address as the primary node. This is resolved when the secondary node joins the cluster and will not affect cluster functionality.

Applies to: Releases 1.xx and 2.xx

The Linux NFS Server may drop its network connection on ProLiant servers using an Intel-based NIC and the eepro100 driver (the default driver loaded by Linux).

To resolve this issue, use the e100 driver instead of the eepro100 driver on the NFS server:

Applies to: All releases

Most ProLiant and Integrity servers support the one-time boot to PXE; however, a few servers including virtual machines need to have PXE or Network Boot first in the BIOS boot order. The platforms that require PXE or Network Boot first in the boot order are:

IMPORTANT: Never change the boot order of the Menu Items listed under the Boot Configuration tab of the PXE Configuration Utility. This will not impact the server boot order, but causes problems with the ability of the PXE server to select the correct boot image.

Applies to: Releases 1.xx and 2.xx

This error is caused by a known issue when using 2.88-MB PXE images based on Win95a DOS. This version of DOS is not compatible with 2.88-MB images.

To resolve this issue, either:

Applies to: Release 1.40 through 2.20

PXE is only enabled by default on NIC1 for ProLiant DL380 G2 and G3 servers. Ensure that NIC2 in each node is cabled as the heartbeat/cluster interconnect and that NIC1 in each node is cabled as the public network (visible to the Deployment Server).

This configuration is recommended for Packaged Clusters using the Rapid Deployment Pack and PXE, even though this is contradictory to the information provided in the Packaged Cluster documentation.

Applies to: Releases 1.xx and 2.xx

The ProLiant DL320 (first generation) server allows a connection to a PXE server by means of an embedded NIC. The server defaults to disabling PXE support on the embedded NIC.

To enable PXE support:

NOTE: The server does not display the F12 prompt when PXE is disabled, regardless of the setting for User Interface.

Applies to: Releases 1.xx and 2.xx

The ProLiant DL360 (first generation) server allows a connection to a PXE server by means of embedded NICs. The server defaults to disabling PXE support on the embedded NICs.

PXE support on the ProLiant DL360 server requires a system ROM (P21) dated later than 08/03/2001 and version 2.53 or later of the System Configuration Utility.

PXE support can be enabled for either of the embedded NICs. However, PXE support cannot be enabled for both NICs at the same time. Enable PXE support for the NIC connected to the network containing the PXE server.

Unlike the ProLiant DL320 server, the ProLiant DL360 server always attempts to boot from the network. The only way to modify the default boot order is by using the stbtordr.exe utility found in the SmartStart Scripting Toolkit. PXE boot order is not configurable through the System Configuration Utility.

To enable PXE support:

Applies to: Release 1.40 through 2.20

Occasionally the secondary node successfully completes the Create Shared Partitions task, but pauses on the following Power Control Task.

To resolve this issue, right-click on the failed job and select Retry Task.

Applies to: Release 1.40 through 2.20

Intermittently, an error occurs when determining the node roles (primary or secondary) for Packaged Cluster deployment. This prevents either node from being assigned the primary node role and both nodes act as the secondary.

To resolve this issue, restart the Packaged Cluster deployment job.

Applies to: Release 1.40 through 2.20

The Packaged Cluster deployment jobs for Windows (image and scripted) require a domain administrator level username and password for the Run Script - Create/Join Cluster task. In Windows 2000 deployments, the job pauses during the Run Script - Create/Join Cluster task waiting for a valid user name, domain, and password in order to join the cluster.

To resolve this issue, on the Deployment Server, cancel the Packaged Cluster deployment job. Using a remote management technology such as iLO, RILOE or Terminal Services, cancel the cluster installation on the cluster node. Update the Run Script - Create/Join Cluster task in the Packaged Cluster deployment job with a valid user name, domain, and password by using the Specify user button in the task. Retry the task on the failed node.

Applies to: Releases 1.xx and 2.xx

After performing an system erase on a ProLiant DL380 server, a ProLiant DL580 server, ProLiant ML370 server, ProLiant ML530 server, or a ProLiant ML570 server, you are prompted to select the operating system for which to configure the server during the next POST. If you select an operating system other than UnixWare and then Linux, a server with two processors may not be configured to use both processors in the operating system, regardless of using the Symmetric Multiprocessing (SMP) kernel.

To resolve this issue, when prompted during POST, select UnixWare and then Linux as the operating system.

Applies to: Releases 1.xx and 2.xx

After performing an system erase on a ProLiant DL 580 server, ProLiant ML 370 server, ProLiant DL 380 server, or ProLiant ML 570 server, you are prompted during the next POST to select the operating system for which to configure the server. If you select an operating system different than the one that is deployed, the server hangs at the first operating system boot because the system BIOS settings are not correct.

To resolve this issue, when prompted during POST to select an operating system, select the same operating system that will be deployed.

Applies to: Releases 1.xx and 2.xx

The 4-GB memory boundary is special because to some DOS programs, such as emm386.exe, it appears as if there is no memory at all.

To resolve this issue, in Boot Disk Creator, REM out the emm386.exe statement in the config.sys file for all applicable configurations and regenerate the PXE images or boot diskettes.

NOTE: The emm386.exe statement is commented out by default.

Applies to: Releases 1.xx and 2.xx

This error is caused by one of the following:

Applies to: Releases 1.xx and 2.xx

When a DOS embedded script or batch file is executed, the Bootworks program is loaded in a DOS command shell and the commands are executed within that environment. When the task ends, so does the Bootworks environment causing the loss of the variables defined within the task.

To resolve this issue, use the REM BOOTWORK UNLOAD statement within the embedded script or batch file. This statement causes Bootworks to unload from memory thus allowing execution within a normal DOS environment.

Applies to: Releases 1.xx and 2.xx

There are many reasons why this error may occur. Some possible reasons are:

Applies to: All releases

No, Microsoft Windows 2000 Dynamic Disks are not currently supported by the Altiris imaging tool.

Applies to: All releases

No, the provided jobs, scripts, and configuration files do not provide support for ProLiant pre-ML/DL servers. However, the SmartStart Scripting Toolkit for DOS version 1.7 and earlier does provide support for capturing and deploying the hardware configuration of these servers. Those familiar with the SmartStart Scripting Toolkit can modify the provided jobs, scripts, and configuration files to support older servers.

Applies to: Releases 1.xx and 2.xx

No, the provided jobs, scripts, and configuration files do not provide support for configuring the ATA RAID capability of the ProLiant ML330 G2 server. However, the SmartStart Scripting Toolkit does provide the HYPERCFG utility for configuring ATA RAID on the ProLiant ML330 G2 server. Those familiar with the SmartStart Scripting Toolkit can modify the provided jobs, scripts, and configuration files to use the HYPERCFG utility.

Applies to: Releases 1.xx and 2.xx

Rapid Deployment Pack supports image capture and deployment of Microsoft Windows NT 4.0. It does not support scripted installations. However, the SmartStart Scripting Toolkit does provide support and examples for installing Windows NT 4.0. Those familiar with the SmartStart Scripting Toolkit can modify the provided jobs, scripts, and configuration files to support Windows NT 4.0.

Applies to: Releases 1.xx and 2.xx

No, DOS versions other than the Windows 9x (Windows 95 OSR2 or higher, or Windows 98) may not work with the SmartStart Scripting Toolkit utilities.

Applies to: Releases 1.xx and 2.xx

The utilities in the SmartStart Scripting Toolkit for DOS are DOS programs and thus only use 8.3 file names.

To resolve this issue, use 8.3 compliant names for the output files.

Applies to: Releases 1.xx and 2.xx

The target server may experience a file lockup during the blue screen file copy phase of the Windows unattended install when the target server is connected to the Deployment Server on a gigabit network. The following error message displays:

Unattended Windows installation: Setup was unable to copy the following file: "misc.file"
Press ENTER to retry the copy operation.
Press ESC to ignore the error and continue Setup.
Press F3 to exit setup

Applies to: All releases

Some companies institute domain security policies that enable a logon banner, or an extra dialog box that displays between the execution of the Ctrl+Alt+Delete keys and the login dialog box. This logon banner causes a scripted install using a slipstream Windows 2000 with Service Pack 2 to pause at the dialog box and wait for interaction.

To resolve this issue, either:

Applies to: All releases

NOTE: For related information, refer to the Microsoft Knowledge Base Article found at: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q262688.

This situation occurs when Windows discovers additional adapters or PCI devices that are interpreted as network adapters (infrared devices or possibly the RILOE board) after setting the initial network configuration. The introduction of a new adapter modifies the adapter instances, and the device configurations are no longer valid. When this occurs, Windows resets the adapters to the default of DHCP.

To resolve this issue, either:

Applies to: All releases

The installation process was unable to read the specified kickstart file.

For Releases 3.00 and greater, several possible causes are:

For Releases 2.xx, several possible causes are:

Applies to: Releases 1.xx and 2.xx

The installation kernel and the initrd.img files found on the Deployment Server do not match the distribution files on the NFS Server. These files must be of the same Linux version and update.

To resolve this issue, reinstall the ProLiant Integration Module on the Deployment Server to update the kernel and initrd.img files. Reinstall the ProLiant Integration Module on the NFS to update the distribution files. For Rapid Deployment Pack 1.50 and 1.60, the kernel and initrd.img files are not found on the RDP CD-ROM and you will be required to use your Red Hat CD #1 to copy these files.

Applies to: All releases

Releases 3.00 and greater

The intallation process found the kickstart file, but failed to find the operating system distribution files located on the FTP server.

There are several possible causes:

Releases 2.xx

The installation process found the kickstart file, but failed to find the operating system distribution files at the location specified by the following line in the kickstart file:

nfs --server hostname.domain --dir /usr/rdp/osdist/yyyy

where hostname.domain is the fully qualified name or IP address of the NFS Server, and yyyy is the operating system shortcut name, such as rhel5 for Red Hat Enterprise Linux 5.

Applies to: Releases 1.00 through 3.10

The serial port is set as the primary console on the ProLiant BL10e or BL10e G2 so that all messages are visible from the Integrated Administrator remote console. For Releases 2.xx using the deploy BL10e Red Hat scripted install jobs, the serial port set as the primary console is the default. For Releases 3.00 and greater, the serial port would be set as the primary console if using the bl10e.cfg kickstart file. Refer to Knowledge Base article How To Set The Serial Port As The Primary Console For Red Hat Linux On The ProLiant BL10e Or BL10e G2 To View Messages From The Integrated Administrator Remote Console (Article 174) for how to use the bl10e.cfg kickstart file.

Using the diagnostic adapter, the installation process displays the following message:

Uncompressing Linux... OK, booting the kernel

Normally the following message displays several minutes into the installation process:

Kickstart installation in progress.

You can view the install process by using the
Integrated Administrator Remote Console feature.

If this message does not display, unhook the diagnostic adapter, and then use the virtual power button in the Integrated Administrator to restart the blade server. You can watch the installation process using the remote console in the Integrated Administrator and resolve the problem based on the error messages displayed.

Applies to: Releases 1.xx and 2.xx

Yes, except for Red Hat Linux 7.2 and Red Hat Enterprise Linux 2.1.

To use ISO images, either:

Applies to: Releases 1.40 through 2.20

Red Hat and SUSE provide kernel patches or fixes to resolve security issues and program errors. These patches are typically distributed as binary rpms. If Red Hat or SUSE provide only a source rpm, the appropriate kernel must be built to generate the binary rpm used in the following steps.

IMPORTANT: Only certain errata kernels are supported by HP and the provided ProLiant Support Pack files. Verify that you are installing an errata kernel that is supported by all the drivers needed for that system.

IMPORTANT: Red Hat has specific kernels that install on servers with x86 processors that have 64-bit extensions. Verify that you are installing the correct errata kernel for your server.

For Releases 2.00 through 2.20, to add a Linux errata kernel into a Linux scripted install:

For Releases 1.40 through 1.60, to add a Red Hat Linux errata kernel into a Red Hat scripted install:

Applies to: Release 2.00 or greater

For Red Hat Linux, to install GNOME or KDE within the kickstart file:

For SUSE LINUX, to install GNOME or KDE within the control file:

Applies to: All releases

For Releases 3.xx, to create a Windows scripted install job that uses a localized version of Windows:

For Releases 2.xx, to create a Windows scripted install job that uses a localized version of Windows:

Applies to: All releases

To disable the Configure Your Server wizard:

Applies to: Releases 1.xx and 2.xx

Scripted installs of the HP Management agents cannot activate the clustering information agent because clustering is not installed at the time the agents are installed.

To activate the clustering information agent in the Management Agents control panel:

Applies to: Releases 1.xx and 2.xx

The target server may experience a file lockup at 100% during the blue screen file copy phase of the Windows unattended install when using PXE or boot diskette images created with the original version of Windows 95 (Windows 95a). This is because Windows 95 doesn't support partitions over 2GB in size.

To resolve this issue, recreate the PXE and/or boot diskette images using a newer version of Windows 9x.

Applies to: Releases 1.xx and 2.xx

When attempting a Windows 2003 scripted install using the Japanese version of Windows via PXE, the install will fail with an "Out Of Memory" message. This error occurs because the Japanese winnt.exe has large memory requirement that can not be accommodated with the PXE network stack loaded.

To resolve this issue, use a boot diskette instead of PXE.

Applies to: Releases 1.xx and 2.xx

While initializing the DOS network stack, the target hangs with the message "Initializing TCP/IP via DHCP". This message is coming from the DOS driver TCPTSR.EXE. A possible reason for this error is that the DOS driver has received an IP address from the DHCP Server that has been statically defined by another client on the network.

To verify the problem is a duplicate IP address, get the IP address assigned to the target server by watching the PXE post message (the IP address given to the target is displayed by the PXE firmware). Turn off the target server, and then ping the address DHCP assigned to the target server from the Deployment Server. If the ping is answered, another server on the network has the same IP address.

To resolve this issue, create a DHCP reservation for all static IP addresses so that they will not be dynamically assigned.

Applies to: All releases

When Red Hat Linux is installed without Logical Volume Manager (LVM) on a system with multiple logical drives, the Linux partitions are installed across all the drives so all available space is used. When a disk image is captured, by default, only the partitions on the first disk are captured. Thus, when this image is deployed, some of the partitions are missing, which can lead to an "Invalid Partition" error.

To resolve this issue, either: