Dave Miner wrote: > Sundar Yamunachari wrote: >> Dave Miner wrote: >>> jan damborsky wrote: >>>> Hi Sundar, >>>> >>>> >>>> Sundar Yamunachari wrote: >>>>> Hi, >>>>> >>>>> With the introduction of GRUB, the DHCP setup for for >>>>> installing a X86 client made simple. It consists of setting up a >>>>> macro to pass the boot server address and the initial boot file >>>>> (PXE grub). The client boots grub and picks all other information >>>>> from the menu.lst file downloaded from the server. For simplicity, >>>>> the menu.lst is hard-coded using the MAC address of the client. >>>>> For the Automated Installer project, we continue to follow the >>>>> same approach with one additional parameter. We allow setting the >>>>> name of menu.lst in the macro so that any name could be used for >>>>> menu.lst instead of being hard-coded based on MAC address. The >>>>> automated installer continue to support the MAC address based name >>>>> for menu.lst if the clients are custom configured. >>>>> In the case of SPARC, menu.lst is not used for installation >>>>> which means the information configured in menu,lst comes from some >>>>> other place. The two viable options are: >>>>> >>>>> 1. Configure all the information needed by the client in DHCP. For >>>>> example, the parameters like the service to be used and the >>>>> location of user archives could be configured in the DHCP. If >>>>> these parameters are specific to our installation programs (like >>>>> sysidcfg and profile of Jumpstart installation program), new >>>>> symbols are required in the DHCP and may be added as a vendor >>>>> specific option. >>>>> >>>>> The advantage of this approach is that all information comes >>>>> from one place. Administrators may find it is easy to configure. >>>>> If DHCP is already used for installing older versions of Solaris >>>>> on SPARC machines, the changes are minimal. One of the main >>>>> drawbacks of putting all information in DHCP are the size of the >>>>> DHCP macro is limited to 255 and if the path name of the images >>>>> are long, the DHCP macro will exceed the limit. We have run in to >>>>> this problem lot of time with SPARC and with X86 before the >>>>> implementation of GRUB. Another problem is that the user needs to >>>>> add our vendor specific options to the DHCP, if it is managed >>>>> separately. >>>>> >>> >>> A technical correction here: macro lengths are not limited in this >>> way; they're merely a construct that we use to make configuring the >>> OpenSolaris DHCP server more convenient. However, the length of any >>> one *option* within a macro is limited due to the encoding specified >>> by the protocol, which uses an 8-bit length. This turns out to be a >>> problem when using the old vendor options because vendor options are >>> in fact encapsulated inside a single protocol-level option, meaning >>> that in aggregate they are limited to 255 bytes. There is no >>> specific reason that vendor options have to be used, other >>> approaches could be taken. However, I don't advocate placing this >>> stuff in DHCP, as users often encounter administrative barriers in >>> getting DHCP updated out there in the real world. >>> >>>>> 2. Configure the minimum parameters needs for the booting of >>>>> OpenSolaris and get the rest of the parameters later and start the >>>>> installation using a file similar to menu.lst. I am thinking of >>>>> using the same TFTP server directory to keep the new file where >>>>> the client gets the initial boot program. >>>> >>>> I like that approach - In general, I think that we should share for >>>> both >>>> x86 and sparc platforms as much design and implementation as possible >>>> for both client and server and diverge only when needed - that >>>> would make >>>> things better maintainable. >>>> >>>> To be honest, I am not very familiar with how newboot for Sparc works, >>>> but it seems to me that we could use the same format of menu.lst file >>>> for providing the client with necessary information - service name >>>> and location of AI image. Then server would use the same approach >>>> for preparing that kind of information for x86 as well as sparc >>>> clients. >>>> >>>> Right now in x86 case, PXE GRUB loads menu.lst file using TFT >>>> protocol, >>>> parses it and passes all parameters to the kernel - they are later >>>> obtained by x86 client using 'prtconf'. >>>> >>>> I think if we slightly modify that mechanism, we could share it for >>>> both x86 as well as sparc: >>>> >>>> x86: >>>> ---- >>>> * PXE grub is loaded >>>> * PXE grub loads menu.lst containing information about location >>>> of kernel and microroot >>>> * PXE grub loads kernel and microroot >>>> >>>> Sparc: >>>> ------ >>>> * kernel and microroot loaded using newboot >>>> >>>> both: >>>> ----- >>>> * kernel is run, microroot is mounted >>>> * obtain name of 'menu.lst' file from DHCP server in similar way >>>> PXE grub does for now - it would be the same file PXE GRUB >>>> obtained in step 'x86:' >>>> * load that file using TFTP >>>> * parse '$kernel' line and pick up service name, location of >>>> the image and other configuration from there >>>> * download and mount AI images >>>> ... >>>> >>> >>> I think this is more what I had in mind, but my suggestion would be >>> to not use the menu.lst format across platforms, instead invent or >>> steal something else that is more aligned with the purpose. >>> menu.lst format can and probably will evolve for reasons which have >>> nothing to do with the problems here, and I don't see that you'd >>> gain any significant advantage to tying yourself to that train. >> I agree. The format of menu.lst is too restrictive and we don't need >> to carry that restriction in to our design. We can use a simple name >> value pair right now to satisfy our requirements for SPARC. Also I am >> thinking if calling that file 'sparc.lst' (My imagination of naming >> things is limited) to indicate that it is for sparc and is different >> from menu.lst but used simliar to menu.lst for installation. >> > > Perhaps my suggestion wasn't quite clear: use the same file for both, > and stop loading so much into menu.lst on x86. I thought of a different file name because pxegrub downloads menu.lst to load kernel where as inetboot doesn't do that. Since we have to parse the file, we can define a simpler format. It may also confuse people to have the same menu.lst file have different data depending on whether it is sparc or X86.
- Sundar > > Dave > >> Thanks, >> Sundar >>> >>> Dave >>> >>>> Thank you, >>>> Jan >>>> >>>>> The advantages are that DHCP macros may not exceed the limit >>>>> and new vendor specific symbols need not be added to the DHCP. We >>>>> can more information in the future to customize the installation. >>>>> Also this method aligns with the X86 installer. The disadvantage >>>>> is that there is a new file to configure and add more code in the >>>>> client to down the new file. >>>>> >>>>> I feel that the second option is much better since it aligns >>>>> with X86 implementation and any option that require minimum DHCP >>>>> setup is a better option. >>>>> >>>>> Please give your feedback on these two options. If I missed any >>>>> other option that may be better than these options, please let me >>>>> know. >>>>> >>>>> Thanks, >>>>> Sundar >>>>> >>>>> _______________________________________________ >>>>> caiman-discuss mailing list >>>>> caiman-discuss at opensolaris.org >>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>>> >>>> _______________________________________________ >>>> caiman-discuss mailing list >>>> caiman-discuss at opensolaris.org >>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>> >> >
