This section suggests actions to take if an installation fails.
If an installation to an AI client failed, you can find the log at /system/volatile/install_log.
The AI manifest that was used for this AI client is in /system/volatile/ai.xml. The system configuration profiles that were used for this AI client are in /system/volatile/profile/*.
You can also check the AI server's webserver log in /var/ai/image-server/logs/*. This log is useful if the AI client is receiving an unexpected or incorrect AI manifest or system configuration profile, or when the AI client can not download files after the initial boot phase.
Check whether DNS is configured on your AI client by verifying that a non-empty /etc/resolv.conf file exists.
If /etc/resolv.conf does not exist or is empty, check that your DHCP server is providing DNS server information to the AI client:
# /sbin/dhcpinfo DNSserv
If this command returns nothing, the DHCP server is not set up to provide DNS server information to the AI client. Contact your DHCP administrator to correct this problem.
If an /etc/resolv.conf file exists and is properly configured, check for the following possible problems and contact your system administrator for resolution:
The DNS server might not be resolving your IPS repository server name.
No default route to reach the DNS server exists.
Review the following additional information about errors that occur when the AI client 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 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
Related to this issue, when you are installing in UEFI mode, the boot disk cannot be located even if a disk is specified in the AI manifest's target boot_disk section. This limitation in UEFI installation means that if nothing is installed on the system yet, you cannot use the boot_disk section in the manifest to identify a boot disk. As a workaround, use a derived manifest specify an alternative installation target disk.
The UEFI specification forbids EFI protective MBR partition from being marked as active, but your BIOS implementation requires that at least one hard disk have at least one MBR partition that's marked as bootable/active to boot in BIOS mode. Use the fdisk utility to set the partition's status to be "ACTIVE".
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 AI 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 AI 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 AI 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 AI client. Check the DHCP configuration for this AI 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 AI 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 AI 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.3 64-bit Copyright (c) 1983, 2015, 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 18:52:30-- http://203.0.113.67:5555/export/auto_install/11_3_sparc/solaris.zlib Connecting to 203.0.113.67:5555... connected. HTTP request sent, awaiting response... 404 Not Found 2015-05-05 18:52:30 ERROR 404: Not Found. Could not obtain http://203.0.113.67:5555/export/auto_install/11_3_sparc/solaris.zlib from install server Please verify that the install server is correctly configured and reachable from the AI 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 AI client 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:
The 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 AI Client Using Secure Download.
The 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 AI 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 AI 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 AI client's install service. Use installadm list -vn svcname to see if security not disabled.
If the AI client is using custom credentials, use installadm list -ve macaddr to obtain the firmware key values.
If the AI 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 AI 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 AI 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 AI 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 Proxy DHCP offers were received PXE-MOF: Exiting Intel Boot Agent
The timeout message indicates that the AI 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 AI 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: 203.0.113.67 MASK: 255.255.255.224 DHCP IP: 203.0.113.77
GATEWAY: 203.0.113.65
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: 203.0.113.67 MASK: 255.255.255.224 DHCP IP: 203.0.113.77
GATEWAY: 203.0.113.65
If the AI 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 AI client is pointing to a valid boot archive. The boot directory of the image on the AI 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_3-i386
92052473 36629085 55423388 40% /etc/netboot/default-i386
/export/auto_install/solaris11_3-i386
92052473 36629085 55423388 40% /etc/netboot/solaris11_3-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 AI 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.3 64-bit Copyright (c) 1983, 2015, 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://203.0.113.66:5555/export/auto_install/solaris11_3-i386/solaris.zlib Connecting to 203.0.113.66:5555... connected. HTTP request sent, awaiting response... 404 Not Found 2015-05-05 20:02:26 ERROR 404: Not Found. Could not obtain http://203.0.113.66:5555/export/auto_install/solaris11_3-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 x86systems 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.3 Text Installer and command line Oracle Solaris 11.3 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 client needs to reach the IPS package repository defined in the AI manifest in order to install the Oracle Solaris OS. If the AI 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 AI client 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 AI clients. See Chapter 3, Providing Access To Your Repository in Copying and Creating Package Repositories in Oracle Solaris 11.3.
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 AI client precedes the time the certificate was generated. Check the system time on the AI 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 AI clients as described in Increasing Security for Automated Installations, and you are experiencing problems booting or installing those AI 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 AI 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 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 42, Listing AI Server Security Information.
Check the AI client's service policy with the installadm list -v -n svcnameS 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 AI 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