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