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 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:
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.
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 net (using the device alias)
> boot /pci@1f,700000/network@2 (using a specific hardware path)
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/$client_name.info 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:
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:
All BMR supported releases of Solaris 9 and Solaris 10 Boot Servers and Clients.