Boot-net With BOOTPARAMS/RARP in Solaris
Introduction:
Introduction: “boot net” is term used for booting over the network. Another term for this process is termed as jumpstart. Just like booting from the disk, floppy, cd-ROM, Solaris has provided an environment to boot over the net. Solaris can boot from the network by issuing traditional boot net command at the OK prompt. This way of booting uses BOOTPARAMS/RARP protocol and has limitation of having complete boot setup within the client's subnet. Boot net with DHCP option is another way of booting over the network. With dhcp option, we have no constraints of having boot setup within client's subnet. This restriction comes from the fact that BOOTPARAMS/RARP protocol implementation on Solaris has no provision of exchanging netmask information where as DHCP provides netmask information to the client. Much advanced net-booting architectures are now introduced with Solaris 9. This is called wanboot which can be used to boot over the WAN. Along with many features, security is the most attractive feature introduced with wanboot. Even though, we have advanced much in the boot-net area, still there are old setup's which still use old traditional net-booting method. In the current write-up, we will focus only on the traditional boot net process. The topics covered are -
- configuring client at the boot server
- boot net process
- First stage of booting with inetboot
- second stage of booting with genunix
- Limitation with the existing design of inetboot.
The idea here is not to emphasis on kernel booting process but to know more about the network specific activities related to boot net. There are various stages of booting while booting from disk and in each stage of booting we have a pointer to the next boot image on the disk. Boot loader loads the next boot image from the disk in a specific location and jumps to the location where the boot image is loaded to pass on the control to the new boot image. Finally, Unix kernel is loaded which boot straps itself and brings up the system. While boot strapping, kernel loads various modules/drivers and configuration files in the memory from the disk. So, primarily all the booting images, kernel and its pre-requisite components are loaded from the disk in case of disk booting. In a very similar fashion, in boot net we have various stages of booting. At each stage of booting we load in different images in the memory from the boot server over NFS. So, what additional booting client has to do here at each stage of booting is to discover its identity, configure network interface properties, find the boot server, find root file handle, mount root file system over the NFS. Finally start loading the boot image/kernel image/required drivers/modules and configuration files in the memory from NFS server from where miniroot is mounted. So, primarily nothing changes when it comes to kernel booting. In case of disk booting, all the requests are served from the disk where as in case of boot net these requests are served from the NFS server. So, we will concentrate mainly on network related activities between client and the server when client is booting over the network. Sequence & fundamentals of Kernel boot strapping is out of scope of this writeup. This writeup is purely based on the experience gained while solving the issues related with boot net and studying the code in general. There is a great scope for modifications to the writeup in terms of expansion or rectification.
Please find the complete writeup here...
( Dec 06 2005, 12:29:35 AM PST ) Permalink Comments [17]
