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. 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 >> >
