Review the following additional information about errors that occur when the client system is booting.
If the boot disk is not found during an automated installation, verify the book disk and modify the AI manifest.
Select the boot device explicitly in SPARC OBP or in the x86 BIOS.
Reboot the system.
Log in to the system being installed.
Identify the device to be used during the installation. The device is can be identified by the SYS/HDD* receptacle name or the the CTD disk name as displayed in the format command.
Modify the /system/volatile/ai.xml manifest and replace the "boot_disk" value. For example:
<disk_keyword key="SYS/HDD1" name_type="receptacle"/>
<disk_keyword key="c0t5000CCA012B2A254d0" name_type="ctd"/>
Refresh the installation service.
# svcadm clear auto-installer
This section describes errors or problems you might see when booting a SPARC client over the network and possible causes:
If a DHCP server is not responding to a SPARC client's request, the following messages display:
... OpenBoot 4.23.4, 8184 MB memory available, Serial #69329298. Ethernet address 0:14:4f:21:e1:92, Host ID: 8421e192. Rebooting with command: boot net:dhcp - install Boot device: /pci@7c0/pci@0/network@4:dhcp File and args: 1000 Mbps FDX Link up Timed out waiting for BOOTP/DHCP reply Timed out waiting for BOOTP/DHCP reply Timed out waiting for BOOTP/DHCP reply Timed out waiting for BOOTP/DHCP reply
The timeout message indicates that the client is sending a DHCP request and no response has been made to that request. This error is probably caused by a DHCP configuration problem. Check whether your client is configured correctly in the DHCP server.
If the AI client starts downloading the boot_archive, but then fails with the error, “Boot load failed,” that indicates that the client DHCP information is configured incorrectly.
Rebooting with command: boot net:dhcp - install Boot device: /pci@7c0/pci@0/network@4:dhcp File and args: 1000 Mbps FDX Link up HTTP: Bad Response: 500 Internal Server Error Evaluating: Boot load failed
This error could happen if another DHCP server is responding to the client. Check the DHCP configuration for this client. If the configuration appears to be correct, determine whether another DHCP server is in the subnet.
After the AI client has obtained the IP address and initial parameters to start downloading the boot archive, the client might be unable to find or download the boot_archive.
If the client cannot find the boot_archive, the following error is displayed:
Rebooting with command: boot net:dhcp - install Boot device: /pci@7c0/pci@0/network@4:dhcp File and args: 1000 Mbps FDX Link up <time unavailable> wanboot info: WAN boot messages->console <time unavailable> wanboot info: Starting DHCP configuration <time unavailable> wanboot info: DHCP configuration succeeded <time unavailable> wanboot progress: wanbootfs: Read 366 of 366 kB (100%) <time unavailable> wanboot info: wanbootfs: Download complete Mon Aug 5 20:46:43 wanboot alert: miniinfo: Request returned code 500 Mon Aug 5 20:46:44 wanboot alert: Internal Server Error \ (root filesystem image missing)
If the AI client finds the boot_archive file but cannot access the file, then the following error is displayed:
Rebooting with command: boot net:dhcp - install Boot device: /pci@7c0/pci@0/network@4:dhcp File and args: 1000 Mbps FDX Link up <time unavailable> wanboot info: WAN boot messages->console <time unavailable> wanboot info: Starting DHCP configuration <time unavailable> wanboot info: DHCP configuration succeeded <time unavailable> wanboot progress: wanbootfs: Read 366 of 366 kB (100%) <time unavailable> wanboot info: wanbootfs: Download complete Mon Aug 5 20:53:02 wanboot alert: miniroot: Request returned code 403 Mon Aug 5 20:53:03 wanboot alert: Forbidden
For both of these problems, fix the boot_archive file configured for this client. Check the pathname and permissions of the boot_archive at $IMAGE/boot/boot_archive.
The messages ERROR 403: Forbidden and ERROR 404: Not Found are displayed if the AI client successfully downloads the boot_archive and boots the Oracle Solaris kernel but fails to get one of the image archives. An error message is displayed indicating which file is causing the problem. For example, in the following output on a SPARC client, the solaris.zlib file does not exist or is not accessible at the specified location:
<time unavailable> wanboot info: Starting DHCP configuration <time unavailable> wanboot info: DHCP configuration succeeded <time unavailable> wanboot progress: wanbootfs: Read 368 of 368 kB (100%) <time unavailable> wanboot info: wanbootfs: Download complete Mon May 5 18:57:36 wanboot progress: miniroot: Read 235737 of 235737 kB (100%) Mon May 5 18:57:36 wanboot info: miniroot: Download complete SunOS Release 5.11 Version 11.2 64-bit Copyright (c) 1983, 2014, Oracle and/or its affiliates. All rights reserved. Remounting root read/write Probing for device nodes ... Preparing network image for use Downloading solaris.zlib --2014-05-05 18:52:30-- http://10.134.125.136:5555/export/auto_install/11_2_sparc/solaris.zlib Connecting to 10.134.125.136:5555... connected. HTTP request sent, awaiting response... 404 Not Found 2014-05-05 18:52:30 ERROR 404: Not Found. Could not obtain http://10.134.125.136:5555/export/auto_install/11_2_sparc/solaris.zlib from install server Please verify that the install server is correctly configured and reachable from the client
This problem can be caused by one of the following conditions:
The image path configured in WAN boot is not correct.
The image path does not exist or is incomplete.
Access is denied due to permission issues.
Check your DHCP configuration or the contents of the net image you specified when you ran installadm create-service. Check your WAN boot configuration.
When installing the Oracle Solaris OS on your client system, you need to include the install argument when you boot in order to initiate an installation:
ok boot net:dhcp - install
If you boot without the install boot argument, the SPARC client boots into the automated installer boot image but the installation does not start. See Starting an Automated Installation from the Command Line for instructions about how to start an automated installation from this point.
If you see the message Invalid HMAC value on the SPARC console shortly after booting a SPARC AI client, and the system returns to the ok prompt, one of the following conditions caused the problem:
That AI client is secured by authentication, but you have not set the OBP keys. The solution is to set the OBP keys in the client firmware. For information about authentication, see Increasing Security for Automated Installations. For information about setting OBP keys, see Installing a SPARC Client Using Secure Download.
That AI client is not secured but does have OBP keys set. The solution is to unset the OBP keys in the client firmware. See Resetting the Hashing Key and Encryption Key.
The client's install service has a policy requiring client authentication, but no credentials applicable to the client have been assigned. Be sure that there are credentials available for all clients of services with policy require-client-auth.
The following steps show how to identify the problem.
Verify that security hasn't been disabled for the AI server. Use installadm list -sv to see if security is enabled.
Verify that security hasn't been disabled for the client's install service. Use installadm list -vn <svcname> to see if security not disabled.
If the client is using custom credentials, use installadm list -ve <macaddr> to obtain the firmware key values.
If the client is not a custom client, use installadm list -vn default-sparc to see if there are any firmware keys defined for the default-sparc service.
Check the policy of the client's service with installadm list -vn <svcname>.
If there are no credentials for the default-sparc service, look for default client credentials using the installadm list -sv command. If there are default client credentials, then use the firmware keys listed for the default client.
If there are no default client credentials, use installadm list -vn default-sparc to see if the service policy is set to require-server-auth. If so, use the firmware keys listed for the default client in installadm list -sv.
This section describes errors or problems you might see when booting an x86 client over the network and possible causes:
If a DHCP server is not responding to an x86 client's request, you see the following messages:
Intel(R) Boot Agent PXE Base Code (PXE-2.1 build 0.86) Copyright(C) 1997-2007, Intel Corporation CLIENT MAC ADDR 00 14 4F 29 04 12 GUID FF2000008 FFFF FFFF FFFF 7BDA264F1400 DHCP......... No DHCP or ProxyDHCP offers were received PXE-MOF: Exiting Intel Boot Agent
The timeout message indicates that the client is sending a DHCP request and not getting a response. This issue is probably due to an error in the DHCP configuration. Check whether your client is configured correctly in the DHCP server.
The DHCP server provides an IP address and a location of the initial boot program as part of the DHCP response.
If the boot program does not exist, then the AI client boot cannot proceed. The following message is displayed:
Intel(R) Boot Agent PXE Base Code (PXE-2.1 build 0.86) Copyright(C) 1997-2007, Intel Corporation CLIENT MAC ADDR 00 14 4F 29 04 12 GUID FF2000008 FFFF FFFF FFFF 7BDA264F1400 CLIENT IP: 10.6.68.29 MASK: 255.255.255.0 DHCP IP: 10.6.68.49 GATEWAY: 10.6.68.1 TFTP. PXE-T02: Access Violation PXE-E3C: TFTP Error - Access violation PXE-MOF: Exiting Intel Boot Agent
If the boot program exists but it is an incorrect program, the AI client hangs after displaying this message:
Intel(R) Boot Agent PXE Base Code (PXE-2.1 build 0.86) Copyright(C) 1997-2007, Intel Corporation CLIENT MAC ADDR 00 14 4F 29 04 12 GUID FF2000008 FFFF FFFF FFFF 7BDA264F1400 CLIENT IP: 10.6.68.29 MASK: 255.255.255.0 DHCP IP: 10.6.68.49 GATEWAY: 10.6.68.1
If the client is able to do the initial boot but the kernel cannot be booted, the system hangs after you select the entry from the GRUB menu.
On the AI server, check whether the grub.cfg file or the menu.lst file for this client is pointing to a valid boot archive. The boot directory of the image on the server should be loopback-mounted under the /etc/netboot directory as shown in this sample excerpt from df -k for the image path shown by installadm list:
Filesystem 1K-blocks Used Available Use% Mounted on /export/auto_install/solaris11_2-i386 92052473 36629085 55423388 40% /etc/netboot/default-i386 /export/auto_install/solaris11_2-i386 92052473 36629085 55423388 40% /etc/netboot/solaris11_2-i386
On the AI server, if one of the install programs is inaccessible or does not exist in the location specified in the grub.cfg file or the menu.lst file under /etc/netboot, then the client is able to boot, but is not able to download that file. An error message is displayed indicating which file is causing the problem. For example, in the following output on an x86 client, the solaris.zlib file does not exist at the specified location:
SunOS Release 5.11 Version 11.2 64-bit Copyright (c) 1983, 2012, Oracle and/or its affiliates. All rights reserved. Remounting root read/write Probing for device nodes ... Preparing network image for use Downloading solaris.zlib --2015-05-05 20:02:26-- http://10.134.125.136:5555/export/auto_install/solaris11_2-i386/solaris.zlib Connecting to 10.134.125.136:5555... connected. HTTP request sent, awaiting response... 404 Not Found 2015-05-05 20:02:26 ERROR 404: Not Found. Could not obtain http://10.134.125.136:5555/export/auto_install/solaris11_2-i386/solaris.zlib from install server Please verify that the install server is correctly configured and reachable from the client Requesting System Maintenance Mode (See /lib/svc/share/README for more information.) Console login service(s) cannot run
Check the contents of the target directory that you specified when you ran the installadm create-service command.
When installing the Oracle Solaris OS on x86 client systems for installations that boot over the network, you must select the second entry in the GRUB boot menu to initiate an automated installation. Typically, the menu entries display as follows:
Oracle Solaris 11.2 Text Installer and command line Oracle Solaris 11.2 Automated Install
If you selected the first GRUB menu entry or allowed the prompt to time out, the system boots into the automated install boot image but the installation does not start. See Starting an Automated Installation from the Command Line for instructions about how to start an automated installation from this point.
The following errors are common to both SPARC and x86 installations:
If a failure occurs during installation, then the following message is displayed:
21:43:34 Automated Installation Failed. See install log at /system/volatile/install_log Automated Installation failed Please refer to the /system/volatile/install_log file for details Jul 6 21:43:34 solaris svc.startd[9]: application/auto-installer:default failed fatally: transitioned to maintenance (see 'svcs -xv' for details)
The installation client needs to reach the IPS package repository defined in the AI manifest in order to install the Oracle Solaris OS. If the client cannot access the package repository, the installation fails and the application/auto-installer service transitions to maintenance. The following output is an example of what is displayed on the console:
15:54:46 Creating IPS image 15:54:46 Error occurred during execution of 'generated-transfer-1341-1' checkpoint. 15:54:47 Failed Checkpoints: 15:54:47 15:54:47 generated-transfer-1341-1 15:54:47 15:54:47 Checkpoint execution error: 15:54:47 15:54:47 Framework error: code: 6 reason: Couldn't resolve host 'pkg.example.com' 15:54:47 URL: 'http://pkg.example.com/solaris/release/versions/0/'. 15:54:47 15:54:47 Automated Installation Failed. See install log at /system/volatile/install_log Automated Installation failed Please refer to the /system/volatile/install_log file for details Aug 21 15:54:47 line2-v445 svc.startd[8]: application/auto-installer:default failed fatally: transitioned to maintenance (see 'svcs -xv' for details) ... SUNW-MSG-ID: SMF-8000-YX, TYPE: defect, VER: 1, SEVERITY: major EVENT-TIME: Wed Aug 21 15:54:47 UTC 2013 PLATFORM: SUNW,Sun-Fire-V445, CSN: -, HOSTNAME: line2-v445 SOURCE: software-diagnosis, REV: 0.1 EVENT-ID: c8a5b809-ece4-4399-9646-d8c64d78aac7 DESC: A service failed - a start, stop or refresh method failed. AUTO-RESPONSE: The service has been placed into the maintenance state. IMPACT: svc:/application/auto-installer:default is unavailable. REC-ACTION: Run 'svcs -xv svc:/application/auto-installer:default' to determine the generic reason why the service failed, the location of any logfiles, and a list of other services impacted. Please refer to the associated reference document at http://support.oracle.com/msg/SMF-8000-YX for the latest service procedures and policies regarding this diagnosis.
Check the /system/volatile/install_log file for messages similar to the following:
TransportFailures: Framework error: code: 6 reason: Couldn't resolve host 'pkg.example.com' URL: 'http://pkg.example.com/solaris/versions/0/'
TransportFailures: Framework error: code: 7 reason: Failed connect to pkg.example.com:80; Connection refused URL: 'http://pkg.example.com/solaris/versions/0/'
TransportFailures: http protocol error: code: 404 reason: Not Found URL: 'http://pkg.oracle.com/mysolaris/versions/0/'
Depending on which messages you see, try the following possible remedies:
Try to reach the package server from the failed client system, for example, by using ping.
If you are using DNS, check whether DNS is correctly configured on the AI client. See Check DNS.
If you are using a local repository, check whether you have made the repository accessible to all clients. See Chapter 3, Providing Access To Your Repository, in Copying and Creating Package Repositories in Oracle Solaris 11.2 .
Make sure the URI in the AI manifest does not have a typographical error.
Use a command such as the following command to check whether the package repository is valid:
$ pkg list -g http://pkg.example.com/solaris/ entire
You might need to refresh the catalog or rebuild the index.
If one of the packages specified in the AI manifest cannot be located in the IPS repositories, then the installer fails before installing any packages on the disk. In the following example, the installer could not find the package mypkg in the IPS repository. The following output is an example of what is displayed on the console:
14:04:02 Failed Checkpoints: 14:04:02 14:04:02 generated-transfer-1230-1 14:04:02 14:04:02 Checkpoint execution error: 14:04:02 14:04:02 The following pattern(s) did not match any allowable packages. Try 14:04:02 using a different matching pattern, or refreshing publisher information: 14:04:02 14:04:02 pkg:/mypkg 14:04:02 14:04:02 Automated Installation Failed. See install log at /system/volatile/install_log
The following output is an example of a portion of the /system/volatile/install_log log file:
PlanCreationException: The following pattern(s) did not match any allowable packages. Try using a different matching pattern, or refreshing publisher information: pkg:/mypkg
Check whether the package in question is a valid package. If this package is available from a different IPS repository, add that IPS repository in the AI manifest by adding another publisher element to the source element.
A message similar to the following message when you boot the AI client means the TLS certificate is not yet valid:
SSL3_GET_RECORD:wrong version number - secure HTTPS GET REQUEST to unsecured HTTP port
The cause of this problem could be that the system time on the client precedes the time the certificate was generated. Check the system time on the client. See Increasing Security for Automated Installations for information about how to generate and assign security credentials.
If you have secured your AI server and clients as described in Increasing Security for Automated Installations, and you are experiencing problems booting or installing those clients, try the following steps to check for authentication errors:
Check the Apache access_log and error_log in /var/ai/image-server/logs/ on the client.
Log onto the console of the AI client. Examine the /tmp/install_log file and the SMF service logs in /system/volatile/.
If authentication fails after the boot archive loads in the AI client, when attempting to get image files, AI manifests, or system configuration profiles, you could have a transient networking interruption. Check that the AI server is functioning correctly, and restart the client installation.
Try using the openssl s_client command to test the connection:
$ openssl s_client -key client-key -cert client-certificate \ -CAcert server-CA-certificate -connect AI-server-address:port
Use the installadm list -s -v command to show the enabled or disabled state of security on the AI server. See Example 8–40.
Check the client's service policy with the installadm list -v -n <svcname> command
.
Check assigned credentials against the CA certificates. Use the –K and –C options with the installadm list subcommand to list the assigned keys and certificates. Compare those keys and certificates with the expected keys and certificates using a character comparison utility such as diff.
Make sure the passphrase was removed from /var/ai/ai-webserver/tls.key/server.key on the client. X.509 private key files must have any passphrase removed.
Try using the wget command to fetch a file from an AI image, using the appropriate key, certificate, and CA certification, as shown in the following example:
$ wget --private-key=client-key --certificate=client-certificate \ --ca-certificate=server-CA-certificate \ http://AI-server-address:5555/path-to-file-in-image