Methodology used for the network boot processing of a Solaris 9/10 Bare Metal Restore (BMR) client.

  • Article ID:100029735
  • Modified Date:
  • Product(s):


Methodology used for the network boot processing of a Solaris 9 or 10 Bare Metal Restore (BMR) client.
Solaris 11 network boot method does not adhere to this method and has its own methodology and makes use of a DHCP server.  As such it does not have the same network segment restrictions that a Solaris 9 or 10 client has.,


The methodology used by Bare Metal Restore (BMR) Option for Solaris 9 and 10 clients emulates the native Solaris JumpStart process, as implemented by Sun. As such, BMR will adhere to all of the normal restrictions associated with this method.  One such major restriction requires that the restoring client be on the same subnet as the BMR Boot Server, unless a Boot Relay Server has been implemented.  Also, care must be taken if an existing Solaris JumpStart Server also resides on the same subnet.  If this is the case, the existing JumpStart Server (not the BMR Boot Server) must have all entries that are associated with the restoring client removed from its files. Failure to do this will cause the BMR restore process to fail. These restrictions can be avoided by use of the BMR Media Boot restore method.

The restore of a Solaris client, using BMR, starts with the Prepare To Restore procedure. This procedure is performed using the NetBackup Administration Console that is servicing the client being restored or the CLI command "bmrprep".  On the NBU/BMR Master Server, the " bmrprep" command will verify that a valid backup image exists for the restoring client. It then creates all the required client specific restore files that will be used during the actual system recovery and places them in the BMRDB for later download by the client.

The action of this procedure produces the following on the NetBackup Master Server:

           1. the actual restore script file to be executed during the restore process.
           2. a list file of the data streams to be restored.
           3. a temporary '/etc/hosts' file for use on the restoring client that describes the hosts that will be active for the actual restore.
           4. a temporary 'bp.conf' file that describes the NetBackup environment.
           5. a client configuration file, with environment variables that customizes the restore process to a specific client.

All of the files are saved into the BMRDB for access during the actual restore.

The action of this procedure produces the following on the BMR Boot Server:
1. An entry in the /etc/ethers file which maps the MAC address of the restoring network adapter to a host name, as known to the Boot Server. That in turn will give the client its IP address.

The network data used is extracted from "Network Interfaces" section of the restoring configuration. DHCP is not recommended for this. For initial interface settings at boot time, the IP address is what the Boot Server knows the client name to be, not what is set in the restore configuration.  This because BMR is not truly active during this time frame.
Be aware that BMR will not overlay entries in this file. If a Mac address entry line already exists in this file, the host name it specifies MUST match that of the client being restored. If not, the Prepare To Restore process will fail.  To repair this, delete the existing invalid line from the /etc/ethers file and retry the Prepare to Restore procedure.  Warning - if there does exist another JumpStart Server on the subnet and it contains an entry in its /etc/ethers file, it may respond back to the booting client.  This is a race condition and the results are indeterminate. 
2. An entry in the /etc/bootparams file that maps the restoring host name to the Shared Resource Tree (SRT) specified in the Prepare To Restore action.
3. An entry in the /etc/dfs/dfstab file which is an NFS share of the Shared Resource Tree to the restoring Solaris BMR client. This is done using native NFS share commands. If the IP address set in the restore configuration does not match the IP address that the Boot Server 'knows' the client's host name by, the NFS share operation will fail.
4. A file entry in the /tftpboot directory which is a pointer of the client to the correct boot image.  This file has a name that corresponds to the numeric IP-address of the restoring client in hexadecimal format and is a link to the appropriate boot image information.  As an example, the IP-address of "" has the file name of "0A0A2118".
5. A file entry in the /tftpboot directory which is a text file containing environment variable information used by the BMR restore process.  This text file name is $

The BMR Boot Server that performs the above activity is determined by the Share Resource Tree (SRT) that was specified for the Prepare To Restore and which BMR knows is the hosting server that created it. If the SRT is CD/DVD based, no network boot activity will be performed.

The following services must be active and available on the BMR Boot Server:

The actual restore action begins on the client.  From the firmware prompt, you specify:
> boot network_device
where network_device is the hardware path or device alias to the interface to be used for the restore.  Some examples are:

> boot net                                              (using the device alias)
> boot  /pci@1f,700000/network@2        (using a specific hardware path)
If your server has multiple network interfaces, it is important that the correct device path is specified for the network boot.  To see what device is the "net" alias for the network interface, use the Open Boot command "devalias". To display all available network interfaces, use the Open Boot command "show-net" or "watch-net".

From this point on, the process performs normal JumpStart actions of acquiring its network identity and accessing/downloading its boot image using tftpd on the BMR Boot Server. Once this is performed, the Shared Resource Tree is NFS mounted, the BMR restore script and associated support files are downloaded from the NetBackup Master Server and the restore script is executed on the client.  The SRT is there to provide an underlying Operating System kernel to run native OS, NetBackup  and (if applicable) VxVM/VxFS commands as directed in the restore script.   No SRT files are copied into the restoring client.  

The process flow is as follows:

1.  The ' boot network-device' command will cause the client to broadcast a 'whoami' or rarpd packet on the subnet of the interface specified.
2.  Any server with the rarpd daemon running and a matching MAC address in its /etc/ethers file will respond with the network parameters that will be set on the client.  If more than one server in the same subnet has the daemon running an matching MAC address in place, the first server to see the request  will respond to the request. This is a race condition.
3.  Once established on the network, the client will broadcast a bootp request to access its boot image and NFS mount the support files. Servers with the bootp daemon running and valid file information will respond to this request. If there are more than one configured Jump Start servers on the same subnet, the responding server may not necessarily be the BMR Boot Server. This information comes from the /etc/bootparams file and /tftpboot directory of the responding server.
4. Once the boot image has been transmitted and localized on the client, the system will gather client specific data from the Boot Server, as seen in the /tftpboot/$ file.
This data placed into the directory by the Prepare To Restore process and holds BMR specific data variables that help identify the client to the BMR Master Server.

The restoring client may fail to connect to the BMR Boot Server for several reasons:
1. The wrong network interface device path was used in the boot command from the firmware command line.
2. The Boot Server is not on the same subnet as the restoring client's interface
3. The client is not connected to a valid switch port.
4.  A valid Prepare To Restore was not performed for the client.  The $ file and boot file entries will not exist.
     5.  Another JumpStart Server is active on the same subnet as the BMR Boot Server and has entries and services that allow it to respond back to the booting client.

The BMR process displays major progress point information on the system console. The more detailed BMR restore log information is transmitted and captured on the NetBackup Master Server. The log location is "/usr/openv/netbackup/logs/bmrrst /$client_namee/ log.mmddyy" for Unix Master Servers and "$Inst_Path\netbackup\logs\bmrrst \$client_name\ mmddyy.log" for Windows Master Servers.  This is a text file, not a unified vxlog raw file.  All information gets appended to the file if multiple restore attempts are made on any single day.  Logging to this file does not start until the BMR restore script is downloaded and executed on the client. As such, some data displayed on the console will not be logged to any file on any system.  Also, the vxlog orgid of 131 is not used for any logging operations. Trying to set the 131 process to a high DebugLevel is a waste of time and must not be done.  The log will contain the equivalent information captured in an NBU "tar" log file. That means that all file names of restored files are part of the log file.  This can make the resulting file size extremely large. 

A Solaris JumpStart Server can co-exist on the same subnet as a BMR Boot Server under the following conditions:
1. There are no entries in the /etc/ethers and /etc/bootparams file that contain information for the restoring client.
2. Needed services for network boot(rarpd, bootpd and tftpd) are not active at the time of the boot.

Applies To


All BMR supported releases of Solaris 9 and Solaris 10 Boot Servers and Clients.

Was this content helpful?

Get Support